Mini Apps

I've been working on a @farcaster miniapp recently and we're currently alpha testing it here @warpcast with a small group.

It's a kind of prediction market game with prizes at stake!

We'd love to have more participants! Join us: https://warpcast.com/lostmidas/0x3936b41d

I'm glad we're alpha testing because we've already mitigated a flaw in the prediction market contract I'm building.

I'm glad we're alpha testing because we've already mitigated a flaw in the prediction market contract I'm building. https://warpcast.com/attar/0xb61066f4

Protocol @holographxyz | Previously foundation / optimism / consensys / songtrust

We encountered a critical issue during the finalization of our game contracts: Uniswap V3's "OLD" error disrupted our 24-hour TWAP calculations. Here's a concise breakdown:

2/ Cause of the Error

Uniswap V3 pools store price observations in a fixed-size ring buffer. If the buffer isn't large enough for the entire TWAP period, older observations get overwritten. Attempting to retrieve a 24-hour TWAP without the necessary data triggers the 'OLD' error.

3/ Why This Wasn't Immediately Apparent

No Visible Shrinking: The buffer size remains constant, but older data is silently overwritten by newer observations.​

Initial Success: Our contract's validation logic checked the pool's history during game creation. Early calls to observe(86400) succeeded because the buffer contained 24 hours of data. However, as more trades occurred, older observations were overwritten, leading to the error upon finalization.

4/ Impact on the Game

With essential data overwritten, the contract couldn't finalize the 24-hour TWAP. Participants who paid to join were unable to claim potential winnings.

5/ Resolution Steps

Immediate Action: Manually compensated winners by sending direct transactions with the correct prize amounts.​

Future Measures:

Increase Observation Capacity: Before initiating a game, we'll use increaseObservationCardinalityNext to expand the pool's observation buffer, ensuring it can store the full TWAP period's data. ​
https://docs.uniswap.org/contracts/v3/reference/core/UniswapV3Pool

Implement Fallback Mechanism: Introduce an admin fallback function to finalize games using a shorter TWAP if necessary, accompanied by a script to determine the maximum available observation window.

6/ Key Takeaway

When relying on Uniswap V3's TWAP for extended periods, ensure the pool's observation buffer is sufficiently large to prevent data overwriting during finalization.

7/ Learned a lot over the last day.

These docs, in particular, helped me implement and deploy a fix: https://docs.uniswap.org/sdk/v3/guides/advanced/price-oracle#:~:text=Observations%20are%20only%20stored%20when,to%20the%20value%20we%20desire.

8/ Looking Ahead

I'd love to build something similar with Uniswap V4, but currently, these tokens are more frequently deployed in V3 pools, so that's why I'm using V3 at the moment!

1/ Post-Mortem: Uniswap V3 'OLD' Error During Game Finalization

Our game contract, referencing a Uniswap V3 pool for 24-hour TWAP calculations, failed at finalization due to an 'OLD' error.​

You can also take a look of @superboring implementation  https://github.com/superfluid-finance/averageX/blob/develop/packages/evm-contracts/src/UniswapV3PoolTwapHoppableObserver.sol , we actually observe the data ourselves instead of relying on the stored observations in the pool.

DCA every second with the most powerful streaming DEX, powered by @superfluid. Now LIVE https://superboring.xyz

Creating semantic money protocol no one knew they needed and building super boring products @superfluid.

@hellwolf looks cool! can you explain a little on how you use that? do you just call to observe periodically over a period you want to calculate the twap at the end of?