Ante in a nutshell

Ante allows users to create incentivized on-chain guarantees of smart contract state that are programmatically settled. Users can either stake or challenge the pool, where payment on each side is asymmetrically determined based on the result of the corresponding Ante Test. Stakers benefit from the test continuing to pass by receiving a portion of challenger capital through a mechanism we call “decay”, while challengers receive a portion of staker capital upon test failure.

What does this mean?

One way to think about this is that Ante provides “financial verification” for smart contracts. Guarantees can be made about any testable on-chain condition, with payouts delivered programmatically upon test failure without requiring intermediaries/trusted third parties (see some examples of invariants that could be tested here). Protocols that stake Ante Tests for their smart contracts are putting skin in the game, staking their confidence in the quality of their smart contracts with their own capital.

What’s more, community activity within the pool allow for an automatically generated Decentralized Trust Score that reflect the community’s trust in that particular protocol.

How we designed it

Architecture

When creating the smart contracts for Ante, we decided to separate the test logic and stake/challenge/settlement pieces into separate AnteTest and AntePool functionalities. This provides a super lightweight framework for anyone to be able to write their own Ante Tests without having to worry about writing the settlement layer.

Ante Tests contain test logic, while Ante Pools implement stake/challenge sides and wrap value transfer functions around it. This is handled programmatically via an Ante Pool Factory

Additionally, we handle deployment of Ante Pools using AntePoolFactory. Having Ante Pools deployed programmatically by the Ante Pool Factory means that users can self-serve deploy Ante Pools for their Ante Tests while being certain that every Ante Pool from that Factory behaves consistently. This greatly reduces the chance that any individual Ante Pool has a bug or flaw in its value transfer mechanism.

Note: Abstracting the user interaction layer away to Ante Pools does have certain drawbacks. For certain tests where we may have wanted to include checks for msg.sender in checkTestPasses(), because we call it through the Ante Pool contract the pool address becomes the sender.

AnteTest: the test logic

In its most basic form, all an Ante Test needs is a test name and a checkTestPasses() function. Test writers can implement any number of additional helper functions as needed to implement more complex logic (e.g. a checkpoint() function to be able to calculate a TWAP between two points in time) as needed.

Read more* about IAnteTest.sol and AnteTest.sol.*

AntePool: staking, challenging, and test verification

In addition to being able to deposit/withdraw capital into either side of the pool, we wanted to add several time-based mechanisms in the AntePool contract to prevent certain undesirable behavior:

• Staker capital is locked upon staking and stakers have a 24-hour period between initiating a withdrawal and being able to withdraw their unlocked stake. This is to prevent the scenario in which a protocol that has staked their own protocol’s test from immediately withdrawing their stake upon receiving advance knowledge of an exploit. With the withdrawal period (unlocking), the protocol’s initiation of the withdrawal can serve as a warning signal to users.
• Challengers must have challenged the test for at least 12 blocks before being able to call the checkTest() function. This is to prevent generalized frontrunning of a legitimate challenger trying to verify the test. (Note that an “aspiring” frontrunner could still circumvent this by challenging small amounts of ETH into every Ante Pool)

Conceptual state diagram for an Ante Pool

To accomplish this, we have the following state variables that divide up the pool contract’s balance and track relevant user information:

PoolSideInfo public override stakingInfo;
PoolSideInfo public override challengerInfo;
ChallengerEligibilityInfo public override eligibilityInfo;
IterableAddressSetUtils.IterableAddressSet private challengers;
StakerWithdrawInfo public override withdrawInfo;

stakingInfo and challengerInfo store the overall information (number of participants, total decay, decay multiplier) for each side of the pool. It also contains a mapping between wallet addresses and the corresponding stake/challenge information (amount, decay) for each address. When staking or otherwise interacting with the Ante Pool, we use a single stake() function with an isChallenger boolean to determine which PoolSideInfo to update.

eligibilityInfo is used to track the most recent block each challenger has challenged the test so that we are able to enforce the 12-block minimum between challenging the test and calling checkTest().

challengers is an iterable list of addresses that are currently challenging the test — this is used for checking that someone calling checkTest() has challenged the test as well as iterating through the list of challengers to calculate eligible payouts upon test failure.

withdrawInfo stores information about overall and individual stakers withdrawing stake during the withdrawal waiting (unlocking) period.

The testNotFailed() modifier is used as a “require” statement around functions that should only be called (e.g. stake()) when the Ante Test has not failed.

Using these, we are able to implement stake/challenge sides of the pool, the staker withdrawal period, the challenger waiting period, and pre/post-failure user actions.

View IAntePool.sol and AntePool.sol

Decay

Decay is a mechanism we introduced to incentivize stakers of an Ante Test by rewarding them with challenger capital if the test continues to pass. However, on a blockchain, only view functions are “free”. Continuously updating internal state variables like the amount of decay accumulated would require constantly spending gas to compute decay. To deal with this, we implement a helper updateDecay() function that calculates the accumulated decay up to that point and updates the stored decay balances. updateDecay() is then bundled into other function calls that require gas (e.g. stake(), unstake(), checkTest()) so that we can update the decay balances whenever those are called.

Note: because we are approximating a continuous function with discrete steps and also due to the nature of floating point arithmetic in Solidity, some deviation from “theoretical” decay is possible. Our next Tech Talk will dig into the implications of this in greater detail and talk about how we ensured that this never results in Ante Pool insolvency.

Conclusion

There’s a lot more detail and thought that went into Ante v0.5 that we’ll dig into a future walkthrough, but hopefully this gives you a good sense of how we approached some of the protocol design decisions for Ante v0.5. Ante v0.5 is currently live on Mainnet and allows users to (among other things):

• stake/challenge/verify Ante Pools
• Deploy your own Ante Pool from an Ante Test

We have a lot of exciting enhancements for v0.5 as well as things in the pipeline for Ante v1.0 that we’re excited to share in the upcoming months.

We encourage everyone to write Ante Tests and/or ask your favorite protocols to write and stake their own Ante Tests! Together, we can build a safer DeFi community!

Let us know if you have any questions/comments, follow @AnteFinance on Twitter, and join our Discord for more discussion!