One of our community members, waynebruce, wrote a peg test for the Dai stablecoin, Dai Peg Test, a while back, and we’ll go over it today!

Dai by MakerDao, was designed to counter one of the problems other cryptocurrencies were having, which was unstable prices. Dai aims to change that by being a decentralized, unbiased cryptocurrency that is pegged to the US dollar. This brought along the term stablecoin, and as long as the Keepers maintain the 1 US Dollar target price, then the goal has been achieved.

Now to the Ante Test in question. This turns out to revolve around 1 crucial point, is the price of Dai within reasonable bounds as described by the Maker Protocol and understood by its users.

To get to that point, let’s start with the checkTestPasses() function:

function checkTestPasses() public view override returns (bool) {
    (, int256 price, , , ) = priceFeed.latestRoundData();
    return (95000000 < price && price < 105000000);
}

We can see that we’ll return true if the price is between 0.95 and 1.05 US Dollars.

This price we get by using latestRoundData() from Chainlink’s aggregator interface.

Moving on up, we see that the constructor for the Ante Test initializes the protocol, Dai, the contract in question, Dai’s address, and the Dai/USD aggregator deployed by Chainlink.

constructor() {
    protocolName = "DAI";
    testedContracts = [DaiAddr];
    priceFeed = AggregatorV3Interface(0xAed0c38402a5d19df6E4c03F4E2DceD6e29c1ee9);    }

And that’s it to this Dai Peg Ante Test! At it’s core, there’s just 2 important parts to a peg test, the value that the peg needs to be held at, and getting that value.

What’s interesting here will be analyzing what could cause a failure in this test.

The first way this test could fail is if DAI’s price fluctuates outside its range of 0.95 and 1.05. If the test is checked at that time, then it can fail. And this has happened before, looking at CoinGecko’s historical chart for Dai, back in November of 2019 and March of 2020.

Value of Dai from Nov 2019 to Feb 2022

As the price is what determines whether or not the test fails, the second critical piece then is how we fetch the price, in this case, the Chainlink Aggregator. If an attacker were able to manipulate or trick the aggregator to return a value that doesn’t actually represent the true Dai price, than the test could also fail.

Food for thought anyway, it’s always good to consider what different ways a test can fail and see if we can make sure that these points are carefully considered when writing an Ante Test!

As the skeleton for this test is relatively basic, it can be expanded to incorporate different types of pegs depending on what is being called for.

For example, regarding Tether, this Ante Test written by raddy outlines the fact we care more about the dropping of Tether value, so the test is written to only check if its value drops below 0.90 US dollar.

And then moving even further! This Iron Peg Holds Test written by a-deva highlights how we can take a simple peg test and take it even further! This one is a bit more complicated to go through in this post, so we’ll revisit it another time to go deeper into it.

And that’s it for this week! Please feel free to come and check out the various tests that have already been written in the Ante Community Github. Join us at our Discord to talk web3, interesting protocols, Ante Tests, or just hang out! And follow us on Twitter to see the latest news and updates we have! Till next time everybody!

This post is intended to be a technical overview of the Ribbon Ante Tests and their mechanics.

Background

Ribbon is a DeFi protocol that helps users access DeFi structured products. Their Theta Vault product offers yield through an automated options strategy (the main V2 products at the moment automate weekly covered call strategies).

Ante hosts real-time incentivized on-chain smart contract tests (”Ante Tests”) that pay out when code fails. This aligns teams and users and makes code trust explicit, resulting in a safer, more composable Web3 ecosystem. Responsible protocol teams can explicitly put “skin in the game” by staking their Ante Tests (which anyone can also challenge or stake), boosting their “Decentralized Trust Score”. In turn, developers can reference Ante trust scores to build more safely on top of protocols, and users can more clearly see community trust in protocols real-time.

Ribbon TVL Plunge Test

Code; Live test

AnteRibbonV2ThetaVaultPlungeTest checks that the TVL for any tested Ribbon V2 Theta Vault doesn’t fall by 90% from the time the test is deployed. While TVL is an imperfect metric for overall protocol success, it is a useful proxy for any number of catastrophic scenarios such as:

• Ribbon usage has declined precipitously

• Ribbon funds have been drained by a hack/exploit

Basically, if the TVL in the Ribbon V2 Theta Vaults has plunged over 90%, something catastrophic has likely befallen Ribbon.

How it works

The test checks the ETH Covered Call V2 and WBTC Covered Call V2 Theta Vaults. Upon instantiating the Ante Test, the test iterates through the list of vaults and calculates the precise failure threshold for each vault by multiplying the current balance by the drop threshold — 10%.

AnteRibbonV2ThetaVaultPlungeTest.sol, lines 38–44

When checkTestPasses() is called by a challenger, the test iterates through the same set of vaults and compares each vault’s balance to its corresponding failure threshold. If any of the vaults’ TVL is below its threshold, then the entire Ante Test fails and challengers can claim funds.

AnteRibbonV2ThetaVaultPlungeTest.sol, lines 65–73

Let’s take a closer look at how vault balances are calculated in the calculateAssetBalance() helper function. The underlying tokens controlled by the vault are split between two main contracts through the vault lifecycle:

• Opyn MarginPool contract when underlying has been used to mint call options

• Ribbon vault contract in basically any other situation: if Ribbon users deposit mid-cycle; if all the options don’t sell out that week; if its auction profits; if users have queued for withdrawal but not withdrawn yet; if options have been settled for the week and not yet used to mint next week’s options

The sum of these two balances represent the total current asset balance “in” a Ribbon vault (technically, tokens could also be held very briefly in the EasyAuction contract after people buy options but it is promptly transferred back to the Ribbon vault).

Note that we also assume that there is only one type of collateral asset in a Theta Vault. This is currently true for the two vaults tested by this Ante Test, but as the contracts are upgradeable we can’t guarantee this will always be the case.

AnteRibbonV2ThetaVaultPlungeTest.sol, lines 49–60

The reason we don’t just use Ribbon’s totalBalance() function and roll our own calculation logic in an independent calculateAssetBalance() function is because we can increase the surface area of potential vulnerabilities covered.

If we were to use the internal Ribbon state to calculate balance, since the contracts are upgradeable, there is a potential situation where an attacker could seize upgrade permissions then replace the contract with a malicious one that steals the funds but doesn’t change vaultState.lockedAmount. Another possible attack vector could be a bug in the RibbonV2 Theta Vaults which allows an attacker to steal funds but leaves vaultState.lockedAmount unchanged. In either of these cases, an Ante Test checking Ribbon’s internal state variables for balance could show the test still passing even though funds were no longer SAFU.

As a general principle, writing test logic that doesn’t depend strongly on the tested contract’s own internal state helps make the test more robust against false negatives.

Ribbon Multisig Token Test

Code; Live test

AnteRibbonMultisigRBNTest checks that the Ribbon multisig wallet always holds at least 1 million $RBN. Failure would indicate a catastrophic scenario with a >99% drop in RBN balance (currently ~140M), which could mean that the multisig had been hacked or the team had rugged.

How it works

The failure threshold is set in the constructor of the test:

AnteRibbonMultisigRBNTest.sol, lines 27–32

The balance check is super straightforward: as long as the Ribbon multisig address still holds 1M or greater of $RBN, the test passes.

AnteRibbonMultisigRBNTest.sol, lines 36–38

Pretty simple, right? But these are often the kind of fundamental assumptions that we want to make sure hold true for a protocol.

Conclusion

We all know DeFi can be a dangerous place. Smart contracts can be opaque to your average DeFi user, and bad actors abound. Ante helps make code risk explicit, helping you make informed decisions about which protocols you use. Staking their tests could show a core team’s alignment with the community and their commitment to responsible code security. It’s a hard-to-fake signal of confidence in their code (literally skin in the game).

If you would like to learn more about how Ante could be useful for your protocol team, please reach out to us at signup.ante.xyz, read the docs at docs.ante.finance, or follow the team on Twitter and join our Discord for more web3 security discussions!

This article is meant to give a technical overview of the Ante v0.5 codebase for developers — how it works, why we decided to do things the way we did, and the implications of those decisions (an internal audit of sorts). If that sounds interesting to you, then read on ~fren~.

If you are unfamiliar with Ante and what it does, we recommend checking out our short intro here before reading this article.

Overview

Ante v0.5 is a fairly simple system composed of three files:

AnteTest.sol: This file contains the abstract contract AnteTest, which both inherits the IAnteTest interface and is itself inherited by all Ante Tests written by our community.

AntePool.sol: This file contains the AntePool contract. Each Ante Pool is linked to a single Ante Test and enables individuals to stake and challenge that test’s invariant.

AntePoolFactory.sol: This file contains the AntePoolFactory contract which enables the deployment of Ante Pools on-chain.

These contracts can be viewed in https://github.com/antefinance/ante-v0-core/tree/v0.5/contracts and this code tour specifically references commit hash 5d7488e3dd7946a384f24b13f6a475b3ad709451.

Now let’s examine these three contracts in detail.

AnteTest.sol

The interface IAnteTest defines 5 functions which are partially implemented by the abstract contract AnteTest.

The view functions in IAnteTest are implemented via the public variables testAuthor, testName, protocolName, and testedContracts. The checkTestPasses function is left unimplemented and must be implemented by any inheriting Ante Test.

Note that checkTestPasses is defined as an external function but NOT as a view. Though inheriting Ante Tests can implement this function as a view function if they choose, it is not necessary and ultimately determined by whether testing the invariant requires mutating state or not.

AnteTest also includes the convenience method getTestedContracts which returns the entire testedContracts array, since the default generated getter only returns specific elements given an index.

AnteTest is designed to be easy to inherit from, only requiring the inheriting contract to specify the name of the test for its own constructor. It also conveniently sets testName and testAuthor, but does not set protocolName and testedContracts, both of which must be initialized by the inheriting contract (usually in that contract’s constructor).

AntePoolFactory.sol

AntePoolFactory functions similarly to UniswapV2Factory in that it allows easy and standardized deployment of Ante Pools on chain. The key method here is createPool, which creates an Ante Pool given an Ante Test address. This method also makes sure that a pool hasn’t been created by this factory for the provided Ante Test yet and, importantly, initializes the created Ante Pool. This ensures that the Ante Pool is properly configured and performs several important validations on the Ante Test (described in the AntePool.sol section).

Another important function of AntePoolFactory is to store all of its own created Ante Pools. This mitigates a potential attack vector in which a hacker deploys a malicious Ante Pool and then steals staker and challenger funds. The pool address in this case can be checked against allPools in the official on-chain AntePoolFactory. If it’s not present, then the pool hasn’t been created by the factory and caution is warranted.

AntePool.sol

The AntePool contract is by far the most complex smart contract in our codebase, governing the interaction of stakers and challengers and ensuring that all stakeholders are properly rewarded depending on the current state of the underlying ante test.

Initialization

Initialization of the Ante Pool occurs in two steps. First, in the constructor, the factory variable is set to msg.sender. This is important because only the factory may call initialize to finish initializing the Ante Pool. Some other variables are also set in the constructor to their initial value, but it is not strictly important that they be initialized here vs in initialize or during definition.

The initialize function takes in an Ante Test address and configures the Ante Pool accordingly. Importantly, this function can only be called once to avoid malicious re-initialization of the contract, as enforced using the notInitialized modifier. This function also performs several important safety checks on the Ante Test, namely that it implements the checkTestPasses function and that this function currently returns true. Astute code readers may notice that pendingFailure (the variable which records whether or not the underlying Ante Test has failed) is initially defined as true and only set to false in the initialize method. The reason for this is to avoid introducing a redundant modifier preventing all external functions in the Ante Pool contract from being called pre-initialization (a situation which also would never occur “naturally”). Instead, we can set pendingFailure to true initially and use the existing testNotFailed modifier to accomplish the same goal and seal off an unlikely edge case without wasting gas.

In practice, this two-step initialization is taken care of by the pool factory’s createPool function. This is also the reason why the process is split into two steps — since constructor arguments modify smart contract bytecode, having the initialization of the Ante Pool occur solely in the pool’s constructor would require a comparatively expensive on-chain byte manipulation step to place the Ante Test address in the Ante Pool’s bytecode in createPool.

Decay

During normal operation (i.e. while the underlying Ante Test still passes), challengers pay stakers a 20%/year fee called decay. This calculation is managed by the updateDecay function.

Since historical state data is not normally available on-chain, all the state required to compute the decay must be present on-chain at the time of the calculation. To accomplish this, we implement a common pattern in which the decay accrued is updated whenever a contract interaction occurs which may change the decay calculation.

Namely, updateDecay is called during stake, unstake, unstakeAll, and finally upon test failure in checkTest.

Interestingly, due to issues with approximating floating point calculations with integer arithmetic, small numerical errors in accrued decay accumulate over the course of normal pool operation. We investigated these numerical errors heavily and proved, both empirically and analytically, that they remain vanishingly small relative to pool balance changes and are extremely unlikely to result in material differences in staker and challenger payouts. The more quantitatively inclined readers may be interested in our two-part writeup on this subject.

Staking/Challenging

At the code level, staking and challenging work similarly. Both use the stake method, with the msg.value of the transaction indicating how much value is being deposited and a single boolean flag isChallenger determining whether the user is staking or challenging.

The data structures used to store staker and challenger info, stakingInfo and challengerInfo respectively, are both instances of the PoolSideInfo struct. This struct also tracks how much each user balance has changed due to decay.

There are slight differences in the deposit and withdraw workflows between stakers and challengers to mitigate bad behavior. Challengers are required to deposit at least 0.01 ETH, in order to mitigate an attack whereby a user can challenge every pool and front-run a checkTest call which causes the underlying ante test to fail (this is discussed in greater detail below). Stakers must wait at least 24 hours to withdraw, to avoid a situation in which stakers are given advance warning of an exploit and can withdraw before challengers can trigger a failing test and claim their reward. The data tracking when stakers are allowed to withdraw is stored in withdrawInfo.

Check Test and Claim

Challengers can check if the underlying Ante Test linked to an Ante Pool is failing or not by calling the pool’s checkTest function. In order to properly incentivize active checking of Ante Tests, we include a VERIFIER_BOUNTY of 5% of staker capital, paid to the challenger who successfully triggers a failing test.

To avoid arbitrary addresses being able to front-run a checkTest transaction, we restrict the set of eligible verifiers to existing challengers who have been challenging for at least 12 blocks. Additionally, to prevent arbitrary addresses from challenging a failing Ante Test after observing the corresponding checkTest transaction in the mempool, we restrict the set of challengers eligible for any payout to those who have challenged for at least 12 blocks. Both these checks are enabled via the eligibilityInfo struct.

However, we acknowledge that these solutions don’t perfectly solve the front-running issue, and are actively working on more robust mechanisms.

Note that since the total eligible challenger balance (using the above criteria) is recalculated upon test failure, small numerical errors accumulated prior to test failure do not prevent challengers from claiming their full share of the staked balance.

As challengers claim their corresponding share of rewards following test failure, their balance is set to zero so they cannot erroneously claim multiple times.

Security Considerations

Writing bug-free code is hard, but there are tools available to Solidity developers which make it a bit easier. It’s extremely important to make use of methods like audits, bug bounties, insurance, unit testing, static analysis, input fuzzing, formal verification, and other emerging tools (like Ante Tests) to guarantee the safety of user funds to the maximal extent possible.

Though it by no means guarantees absolute code safety, we are proud of the unit testing suite we developed for Ante v0.5. But don’t just take our word for it — you can run the tests yourself from our public repo. These tests fall broadly into three categories:

• Tests of initial conditions

• Tests of final state after a transition (i.e, a user stakes, or calls checkTest, challengers can claim correct amount after test failure, etc.)

• Tests of specific exploits or disallowed behavior (i.e., Ante Pool can’t be initialized twice, stakers can’t withdraw after test failure, etc.)

You can see these patterns in action in our testing suite, as shown below in our tests on the reward claim functionality:

We also include the output of running slither, a popular static analyzer, on our repo for convenience here.

We hope you enjoyed this in-depth discussion of the Ante v0.5 codebase and the “peek behind the curtain” into some of the considerations underpinning the protocol design. If you have any questions or just want to discuss further, feel free to message us on Twitter or connect with us in our Discord!

This continues a multi-part series walking through the Ante v0.5 protocol design as well as basic secure smart contract development practices. Check out Part 1, Part 2, and Part 3.

Recall from Part 3 that we want to ensure

is always non-negative and does not grow too large. Our initial fuzz testing results below showed this excess balance (in blue) appears to grow quite slowly over time. Today’s post will explain how we obtained provable bounds (in orange) on the excess balance. As before, we will focus on the Challenger excess balance.

Excess balances accrued over time in a single run of our fuzz test

Characterizing and bounding the excess balance

To analyze the challenger excess balance, we first list all state variables which determine the total challenger balance and each user’s balance:

• challengerInfo.totalAmount(denominated in wei)

• challengerInfo.decayMultiplier

• challengerInfo.userInfo[addr].startAmount(denominated in wei)

• challengerInfo.userInfo[addr].startDecayMultiplier

We then determine all functions in AntePool which modify these variables. We find that all modifications occur through the following operations:

• stake()

• unstake()

• updateDecay(),

where we note that several other functions modify these variables only via updateDecay().

Our analysis (full analysis here) shows that the challenger excess balance is always non-negative and bounded above by the number of calls to these functions. More precisely, we find that

where N_D is the number of calls to updateDecay(), N_S is the number of calls to stake(), N_U is the number of calls to unstake(), and the total amount staked (in wei) is bounded by M·challengerInfo.decayMultiplier at all times.

Remember the challenger excess balance is denominated in wei, so our bound on challenger excess balance is extremely small for reasonable values of parameters. Concretely, if there are 10,000 challengers, each of which calls stake()or unstake() 100 times, updateDecay()is called every minute for 10 years, and the total value in the challenger pool is at most 25M ETH, then this bound would come to 0.0015 ETH.

Proving the bound

Our full proof of the bound is written up here, but we give a flavor of our analysis in this post. Assuming that an Ante Pool is in a state where the bounds hold, we will show that after applying any of the operations stake(), unstake(), and updateDecay() the bounds still hold. When an AntePool is started, the challenger excess balance is 0, so this would imply that the bounds hold at initialization. In this post, let’s see why the updateDecay() operation does not change the fact that challenger excess balance is non-negative.

Suppose that T blocks have passed since the last call to updateDecay(), either directly or through another external function call. The effect of updateDecay() is then to update the challenger state variables as follows:

Updates to challengerInfo state variables after updateDecay()

where we use totalAmount′ and decayMultiplier′ to denote the state after the updateDecay() call.

At this point, the unrounded challenger balance for address addr becomes:

The bound in the last line works because ⌊decayMultiplier⌋ ≤ decayMultiplier

If we sum this balance over all challenger addresses then we obtain:

which shows the challenger excess balance remains non-negative as we hoped!

Of course, we’d like to ensure that updateDecay() still preserves the upper bound, that other operations still preserve both bounds, and that a similar analysis also applies to the Staker side. We invite any interested Ante frens to check out our more formal analysis here.

Conclusion

To try out Ante for yourself, stake or challenge Ante Tests on Ante v0.5 live on Mainnet now. If you’d like to get more involved, you can now write your own Ante Tests or ask your favorite protocols to write and stake their own Ante Tests!

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

This code tour is intended to give technical or tech-adjacent people (who may be newer to Solidity or to DeFi) a casual walkthrough of the Ribbon V2 codebase so they can improve their familiarity with and understanding of Ribbon V2, with a focus on the core Solidity contracts. We’ve also added some thoughts on specific design choices and object interactions.

We’re excited to tour the Ribbon V2 code base together!

Background

Ribbon is a decentralized finance (DeFi) protocol that creates algorithmic structured products for users to earn yield on digital assets. Their most popular structured products are vaults that automatically sell “covered call” options on ETH and wrapped Bitcoin (WBTC).

Ribbon works by hosting vaults that users can use to generate yield on their digital assets. The most popular V2 vaults generate yield by selling out-of-the-money options using Gnosis auctions.

Getting Started

One thing to note is that Ribbon’s code is very modular — modularity is great for future iterations and improvements (any module can be easily “swapped out” for another and tested in a relatively self-contained and logically easy-to-understand way). However, this does mean that reading through the code base can be quite daunting (due to the number of apparent “moving parts”).

While we’ve skimmed them, we haven’t studied every single file in all the folders listed in depth line-by-line, so this is intended more as a 10,000-meter “view” of RibbonV2.

Note: this walkthrough is NOT AN AUDIT and is meant for educational purposes only. Please do NOT take anything here as a security recommendation or an investment recommendation. Not financial advice. Comments are based on the 2022–02–03 commit 735f076376edef3230771efc32f81bbd2dcecda5 on ribbon-v2 master.

Quick Tip: when browsing alongside us through the codebase, if you’re curious to see how someRibbonFunction() is used in the codebase, you can (if on a *nix machine):

1. Open up your command line (Terminal in MacOS or just a CLI)

2. Clone the RibbonV2 GitHub repo to your local machine (e.g. git clone https://github.com/ribbon-finance/ribbon-v2.git )

3. Navigate to the contracts folder

4. Run grep -R someRibbonFunction . to see where else in the codebase someRibbonFunction pops up!

Directory Structure

There are a few folders in the contracts repo for Ribbon, but we’ll focus the more detailed part of the walkthrough on just a small number of files within the libraries and vaults folder, where most of the “body” of Ribbon sits.

interfaces

For those new to Solidity, interfaces (typically denoted with an ‘I’ prefix) allow a developer to define how their code will interact with other pieces of code. When writing a smart contract that interacts with another smart contract, then, the simplest way to bring in those “rules of engagement” is by importing the interface.

Ribbon defines a number of interfaces here for purposes including interacting with external systems (e.g. IGnosisAuction.sol, ISwapRouter.sol) and dealing with specific tokens (IWETH.sol, IERC20Detailed.sol). Notably, IRibbonThetaVault.sol is the interface to access instances of Ribbon’s Theta Vault. This is used, for example, when the code to auction off options needs to access a given Theta Vault, or in Ribbon’s more complex Delta Vaults.

libraries

Lots of files here! It’s a good practice for any project to abstract repeated calculations into library functions or to grab those files from a trusted source. Here, in addition to libraries you’d expect for various helpers, there is also preliminary functionality for vaults (and their periodic behavior) sketched out in Vault.sol and VaultLifecycle.sol.

storage

This directory contains the data structures used by various Ribbon vaults. These storage objects are written in a way that allows them to be upgraded alongside the Ribbon protocol and seamlessly reused across minor version releases without interrupting the end user experience. We go into a little more detail below.

tests

This subdirectory contains scaffolding and mock data structures for off-chain tests.

utils

utils contains helper files (e.g. for selecting appropriate params) not referenced directly by other Solidity files in the contracts folder but used in TypeScript test scaffolding in the rest of the ribbon-v2 repository.

vaults

This subdirectory hosts a lot of the core vault code (both the base classes that get inherited, as well as the implementations) of various vaults. Note that there are several vault types here that are not yet deployed on Mainnet, including a Delta Vault that can potentially buy the options produced by a Theta Vault.

vendor

Some custom code (including what appears to be a Ribbon-written proxy) for upgrading, including a math helper (used in some libraries code).

Theta Vault Design & Walkthrough

In this section we’ll go a little deeper into one of the key files that help define the Ribbon Theta Vaults!

What is a Theta Vault?

A Ribbon Theta Vault is a vault that generates yield by algorithmically selling options on the digital assets deposited via Gnosis auctions (Learn more about Gnosis Auctions).

Design pattern: proxy upgradeable contracts

Any highly innovative DeFi protocol like Ribbon faces the challenge of balancing shipping speed with security. It can be easier to rapidly innovate when you can push upgrades to an existing contract. However, upgradeability can introduce additional security risks if not managed properly.

Ribbon uses an upgradeable proxy pattern in order to allow for protocol upgrades — that is, it uses a proxy contract to point to the current “correct” implemented version of a smart contract. There are some implementation wrinkles with proxy upgradable contracts (e.g. upgradeable contracts cannot be initialized using constructors, but there are workarounds), but from a “vault security” standpoint, there are two things we wanted to point out in Ribbon V2 before the actual walkthrough: privileged roles and storage variables.

Privileged roles

Ribbon V2 has two important “trusted” roles: Admin and Owner. Admins can upgrade the proxies for Theta Vaults, and Owners can update vault parameters. Whenever privileged roles exist, the potential for an attack through those roles exists. A compromised multisig role could theoretically cause unforeseen problems!

The Ribbon team has stated they are moving toward greater decentralization (as seen already in the Ribbon V1 → V2 feature set), but it is currently an open-source system with both trusted (e.g. upgradeable proxy pattern) and trustless components.

Note: there is a third role, Keeper, but it is used for operating vaults rather than upgrading code

Storage variables

Upgradeability means that additional functionality can be added to Ribbon Theta Vaults over time without requiring users to “exit and re-enter” the Ribbon system after major version updates. However, if there is important data saved in storage, it is important that the inheritance chain is carefully updated otherwise the data could be corrupted/lost.

Due to the way storage works in Solidity, storage can only be safely appended to the end of the existing storage slots for a contract. In practice, this implies 3 main approaches to adding storage variables in upgradeable contracts:

1. Add storage to the base contract only

2. Add storage to the final contract in the inheritance chain

3. Add “gaps” in the preceding inherited contracts just in case you need to fill these in with storage variables later on

Ribbon (as well as Compound) uses the second method of updating storage variables by creating a new version of RibbonThetaVaultStorage in the inheritance chain whenever new storage variables are needed. These versions of the storage contract (using the naming convention of affixing V1, V2, V3, etc. after the class name) are then all inherited by the base contract (abstract contract RibbonThetaVaultStorage is RibbonThetaVaultStorageV1, RibbonThetaVaultStorageV2, ...).

Doing this inheritance properly means that “wonky” (yes, that’s a very rigorous and non-hand-wavy description) things don’t happen to data in storage and that the seamless transition of user data is maintained!

VaultLifecycle.sol walkthrough

VaultLifecycle.sol is a key library file that governs the interaction of Ribbon Vaults with all other contracts/protocols including:

• Opyn — MarginPool contains all the collateral used for minting oTokens (options tokens), while Controller governs all interactions with MarginPool — any minting/redemption of oTokens goes through the Controller. This is called the GAMMA_CONTROLLER in ribbon’s Vault contracts.

• StrikeSelection — Ribbon’s contract which selects the next options strike price

• Gnosis — interacts with Gnosis EasyAuction protocol through Ribbon’s own GnosisAuction.sol smart contract. GnosisAuction also picks the option price premium by querying Ribbon’s OptionsPremiumPricer contract

A couple interesting notes on interacting with Opyn:

• All controller actions sent to the Opyn GammaController are run through the operate method. This method runs an array of actions then checks whether or not the resulting vault state is valid with _verifyFinalState

• Interestingly enough, Opyn doesn’t publicize its v2 interface and the one available online (v2.opyn.co) has no ability to create vaults

Notable functions in VaultLifecycle:

• (Lines 47–99) the somewhat confusingly-named commitAndClose calculates the parameters of the next option (strike, premium, address, etc.) but does not actually close the current option. Instead, these parameters are passed to a function in the parent Vault contract — this parent function closes the existing option (by calling VaultLifecycle’s settleShort in the case of the Theta Vault)

• (Lines 165–269) rollover is a view function that calculates the new Vault share price, vault fees, new collateral amount, pending withdraw amount based on existing vault state and rollover params. Called by RibbonVault.sol’s _rollToNextOption

• (Lines 279–371) createShort mints options based on the vault’s current locked balance. Called by parent Theta Vault’s rollToNextOption function which then subsequently starts a Gnosis auction for the minted options

• (Lines 381–427) settleShort closes the current short and retrieves collateral from Opyn, called by parent Theta Vault’s commitAndClose

Note: during our limited walkthrough, we could not find where the logic that enforces that commitAndClose can only be called after option expiry is located... it’s possible that something will revert somewhere if called before option expiry (likely in Controller). On the other hand, rollToNextOption in the Vault contract does require that the current block timestamp be greater than optionState.nextOptionReadyAt .

RibbonThetaVault.sol brief walkthrough

RibbonThetaVault.sol puts everything together and implements the unique logic for Theta Vaults.

• (Lines 1–17) Lots of imports! You’ll recognize some files mentioned earlier like Vault.sol and VaultLifecycle.sol.

• (Lines 25–203) Defining events and data structures. Note the responsible warning for developers noting that all storage variable updates need to happen in RibbonThetaVaultStorage and that RibbonThetaVault should not inherit from any contracts aside from RibbonVault and RibbonThetaVaultStorage (recall our earlier discussion about storage variables in upgradable contracts)

• Depending on usage by other contracts, the events could also be defined in a separate file and inherited by RibbonThetaVault

• (Lines 205–291): Various parameter setters — note that onlyOwner and onlyKeeper modifiers are applied to various functions, meaning that not just any anon can set these params!

• (Lines 292–494) Various vault operations. A few key things to note about the operations:

• The onlyKeeper modifier is used to restrict access for some operations (e.g. rollToNextOption()) to only Keepers

• Line 300 function withdrawInstantly(uint256 amount) is a good example of the Checks-Effects-Interactions (C-E-I) pattern used in practice! First, the requirements around a user’s deposits and balances are checked, followed by state variable changes, finally followed by transfer of value. Note the nonReentrant modifier is also used, presumably to reduce the attack surface area.

Conclusion

We hope you’ve learned a bit about Ribbon and better understand some of the design decisions and workings of the protocol. If there’s anything you’d like us to dig more into with the Ribbon codebase, let us know in the comments!

About Ante

Ante hosts real-time incentivized on-chain smart contract tests (”Ante Tests”) that pay out when code fails. This aligns teams and users and makes code trust explicit, resulting in a safer, more composable web3 ecosystem. Responsible teams like Ribbon🎀 can explicitly put “skin in the game” by staking their Ante Tests (which anyone can also challenge or stake), boosting Ribbon’s “Decentralized Trust Score”. In turn, developers can reference Ante trust scores to build more safely on top of Ribbon, and users can more clearly see community trust in Ribbon real-time.

If you would like to learn more about how Ante could be useful for your protocol team, please reach out to us at signup.ante.xyz, or follow the team on Twitter and join our Discord for more web3 security discussion!

Reference Links

Documentation: https://docs.ribbon.finance/developers/ribbon-v2

GitHub: https://github.com/ribbon-finance/ribbon-v2

Hello Pendlefrens and Anteans! As you may have heard, as of today Pendle has deployed and staked 6 different Ante Tests for the Pendle protocol. We’re all excited about our partnership and what it means for the future of decentralized trust in Web3. For those who may be wondering how the Pendle Ante Tests work, this post is intended to be a quick overview of the tests and their mechanics.

Background

Pendle allows users to deposit a yield-bearing token (e.g. the SushiSwap USDC/ETH LP) and split it into an ownership token (OT) and future yield token (YT) representing the principal and future yield components of the underlying asset value over a given period of time. The yield tokens can be purchased, sold, traded, or staked in various liquidity pools in order to earn incentives, and yield is distributed to holders of the YT until expiry.

Ante is a trust protocol that enables Ante Tests: Smart Tests for Smart Contracts that programmatically check and provide financial guarantees around a protocol’s key assumptions in real time. Responsible project teams like Pendle explicitly put “skin in the game” by staking crypto behind their Ante Tests (which anyone can also challenge or stake) to boost Pendle’s “Decentralized Trust Score” (check it out here). In turn, developers can reference Ante to build more safely on top of Pendle, and users can more explicitly see community trust in Pendle real-time.

Overall Test Architecture

In case you want to follow along, we are looking at ante-community-tests/contracts/pendle, commit 14ce1a83fca96eabb10bed0dde02db55dcb499ae on 2022-03-09.

Four of the Ante Tests cover Pendle’s forge contracts, which govern the critical process of splitting underlying yield tokens into their OT and YT components. The remaining two tests cover Pendle’s markets. Each of the six Pendle Ante Tests has its own Ante Pool. As the tests and pools are composable, in the future, one could potentially write a “wrapper” Ante Test/Pool that would act as a test aggregator for Pendle’s tests.

Pendle Aave Forge Test

(Code; Live test)

This is a pretty straightforward test that checks whether the Pendle yield token holder address owns enough aUSDC to exchange 1:1 for all aUSDC OTs, i.e. the forge never mints more OTs than can be redeemed. If Pendle is ever unable to pay out redeemed OTs, that means the protocol is insolvent, so this is a critical invariant to check!

As written, the test checks this condition for the current aUSDC OT (expiring 2022–12–29) and fails if it does not meet this condition.

AntePendleAaveForgeTest.sol, lines 39–41

Note that the test implements a 1% margin of error to account for any very minor precision issues that could arise.

Note that the OT contract that this Ante Test checks is fixed, meaning that at some point if a new aUSDC OT contract were to be deployed (e.g. for 2023 expiry), this Ante Test would not automatically check that contract. In order to check any new OT contracts, a new version of this Ante Test would need to be deployed and liquidity potentially migrated over to the new test.

A note on test “updatability”: When writing tests that iterate over a set of contracts that may update or expire over time, it can sometimes be beneficial to add functions within the test to allow the addition of additional contracts, or to reference a list of contracts held by another contract that can be updated when new contracts are added. This must be balanced with the increased attack surface area this creates for the test itself; if relying on a privileged role to update contracts, this could be seen as reducing decentralization and potentially allows a malicious protocol team to prevent a test from failing, while allowing anyone to add a contract (even with checks to make sure a valid OT contract is added) could potentially be exploited by providing a malicious contract to the test. Philosophically speaking, it could be seen as unfair for a test to change tested contracts after people have already made the decision to stake/challenge the test, even if they can withdraw their capital. In light of these considerations, the Pendle and Ante teams decided not to implement the ability to add additional contracts in any of the Pendle Ante Tests covered in this post.

Pendle Sushi PEP Forge Test

(Code, Live test)

This is similar in structure to the Pendle Aave Forge Test, with additional complexity due to the fact that we are dealing with LP tokens so we need to calculate an exchange rate for redemption.

AntePendleSushiPEPForgeTest.sol, lines 43–53

In this case, the exchange rate is determined using the following equation:

which is then used to compare the supply of OT against LP. Note that the test implements a 1% margin of error to account for minor fluctuations in exchange rate that can occur when more LPs are minted for the fee.

Pendle Sushi ETHUSDC Forge Test

(Code, Live test)

Similar to the Pendle Sushi PEP Forge Test, this checks that the yield token holder holds enough underlying token to cover OT redemption.

The only difference here is that the LP balance must be pulled through MasterChef (ETH/USDC is an incentivized pool on SushiSwap so the yield token holder needs to stake to MasterChef in order to get rewards).

// Getting LP balance for PENDLE/ETH LP
uint256 lpBal = IERC20(yieldToken).balanceOf(yieldTokenHolder);// Getting LP balance for ETH/USDC LP
uint256 lpBal = IMasterChef(masterChef).userInfo(pid, yieldTokenHolder).amount;

Pendle Compound Forge Test

(Code, Live test)

This test covers the solvency of the Compound cDAI forge — with this, the 4 non-expired major Pendle markets on Ethereum are tested for solvency. Talk about covering your bases! 💪

One thing we’re excited about with this test is that it represents the first live Ante Test that doesn’t only use external view functions to check whether the test passes. This has always been an intended capability of the Ante Test design — testing certain failure conditions may require some manipulation of state outside the Ante Test — but the tests to date had not required it.

AntePendleCompoundForgeTest.sol, lines 49–53

In this case, the exchangeRateCurrent() function updates the accrued interest when called, which can result in a state change.

Pendle Market Weight Test

(Code, Live test)

The second group of Pendle Ante Tests test the functions of the Pendle AMM implementation across their different markets. These both currently test 6 different markets (that use the 4 forges tested above).

From the Pendle AMM documentation, we see that the weights of the YT and the underlying token are set to 0.5 and 0.5 at the start of the market period, with the YT weight decreasing and underlying token weight increasing by the same amount over time until market expiry.

This test tests two characteristics that we should expect to see during proper AMM function given the above:

• During the entire market period, the sum of the two weights should always be 1

• YT weight should always be less than or equal to the underlying token weight

AntePendleMarketWeightTest.sol, lines 31–44

Note that the test ignores a market if it has entered the frozen period — at that point, the weights start to suffer from mathematical precision errors so the Pendle market stops shifting weights and trading.

Pendle Market Balance Test

(Code, Live test)

The last Pendle Ante Test checks the same 6 markets to verify that the market’s assumptions about its internal token balances are correct, i.e. the market holds enough YT and underlying token in the actual token contracts to cover the amount of each the Pendle market has stored in internal state. A failure could indicate that the AMM got rugged, for example.

AntePendleMarketBalanceTest.sol, lines 28–46

Note that this test also excludes expired markets, but for a different reason: the getReserves() function has a known bug after the market has expired.

Conclusion

We all know DeFi can be a dangerous place. Smart contracts can be opaque to your average DeFi user, and bad actors abound. Ante helps make code risk explicit by allowing for real-time financial guarantees around specific smart contract commitments. This helps you make more informed decisions about which protocols you might want to use. Responsible protocol teams like Pendle are helping pave the way for a safer Web3 future!

If you would like to learn more about how Ante could be useful for your protocol team, please reach out to us at hello@ante.finance, read the docs at docs.ante.finance, or follow the team on Twitter and join our Discord for more Web3 security discussions!

This continues a multi-part series walking through the Ante v0.5 protocol design as well as basic secure smart contract development practices. Check out Part 1 and Part 2.

Today’s post covers an idiosyncrasy arising from the fact that all variables in the EVM are represented as integers rather than floats. This means that we must use integer arithmetic to simulate computations with real numbers. Though this problem also arises in “ordinary” programming, the adversarial nature of public blockchains requires extra care.

Numerical variables in EVM and smart contracts

On any computer, data is stored using discrete bits, but real numbers are usually represented up to some level of precision using floating-point arithmetic. When dealing with financial data, however, it is often advisable to use fixed-point arithmetic instead to avoid possible issues with rounding or cross-platform reproducibility.

When writing smart contracts or writing on the EVM, these difficulties are compounded. First, gas costs are assessed on operations with 256-bit word size, meaning that floating-point operations incur additional gas costs. In addition, they are not natively included in Solidity, though it is possible to implement them.

Second, smart contract programming often occurs in an adversarial environment. In such a setting, seemingly small rounding errors which would ordinarily be immaterial can compound and potentially be economically exploited by an attacker. Because we are dealing with variables which directly determine ownership of tokens or money, we must ensure that the choices of rounding used in fixed-point arithmetic do not impact protocol security.

Fixed-point arithmetic and decay math in AntePool

AntePool represents numerical constants such as the decay rate using fixed-point arithmetic with scaling factor 1e18. In this post, we will focus on the usage of fixed-point arithmetic on the challenger side of the pool.

Recall from Part 2 that information about challengers is stored in the challengerInfo variable. Specifically, the total amount of ETH owned by challengers is given by challengerInfo.totalAmount, and the challenger balance of a given address addr is computed in getStoredBalance()by simulating a call of updateDecay() and then rounding the unrounded challenger balance:

Although the total balance would naturally be equal to the sum of each users’ balance if everything is computed to infinite precision, in practice the rounding involved in fixed-point arithmetic will make them unequal. Most importantly, we want to make sure that no sequence of operations can cause the sum of challenger balances to exceed the total amount of ETH owned by challengers, as this would make the AntePool insolvent! That is, we want to ensure that:

Secondly, any additional ETH in the total challenger side balance which is not attributed to any user is simply locked in the AntePool. We would like this amount to not grow too quickly. We call this quantity the challenger excess balance, with a similar definition for the staker side as well:

Empirically characterizing the excess balance

To get an initial sense for how the excess balance behaves, we used a randomized fuzz test to track it across a sequence of staking, challenging, and unstaking operations on a simulated blockchain. Specifically, we mocked a local testnet blockchain with Hardhat, deployed a single AntePool, and ran 100 test iterations consisting of:

• from each of 10 test addresses, staking or challenging the pool with a random amount of ETH

• advancing the chain for a random number of blocks

• from each of 10 test addresses, unstaking from either the staker or challenger pool with a random amount of ETH

• advancing the chain for a random number of blocks

After each test iteration, we recorded the excess balance for both the staker and challenger pools, plotted in blue below.

Excess balances accrued over time in a single run of our fuzz test

As the figure shows, in both staker and challenger pools, the excess balances are non-negative and stay extremely small. In fact, they remain on the order of 1,000s of wei even after 100 staking and unstaking iterations, which is an acceptable level for any practical usage.

However, this outcome is from just a single run of our fuzz test. Though we get similar results from more runs, how can we be sure that the excess balances always behave well? To get a greater level of certainty, in Part 4 of this series, we will analyze the situation theoretically and obtain provable upper bounds on the excess balances (shown in orange in the previous figure) which ensure they do not grow too quickly.

Conclusion

To try out Ante for yourself, stake or challenge Ante Tests on Ante v0.5 live on Mainnet now. If you’d like to get more involved, you can now write your own Ante Tests or ask your favorite protocols to write and stake their own Ante Tests!

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

gm frens! Welcome back to the Ante Test Series (check out our last writeup on Alchemix here). This week’s focus is everyone’s favorite Greco-mythical rebasing token, Olympus (OHM).

Whence OHM?

Olympus is an algorithmic reserve currency backed by decentralized assets that aims to be a standard store of value. Each OHM is backed at least 1:1 by 1 DAI equivalent of assets, and the price is is maintained above that level via buyback-and-burn (kind of the decentralized equivalent of a share repurchase program).

After tremendous growth in its first year (hitting nearly $900M in TVL at point), Olympus V2 was announced in Oct 2021 and migration commenced in Dec 2021. V2 Bonds went live recently with a cornucopia of upgraded features including updated payouts and vesting.

But IS it really backed? Ante Tests can verify.

Any time an upgrade or a new version of product is released, it’s important to verify that any desirable properties of the original still hold true (see our Compound test writeup for an example where a contract upgrade broke existing functionality). In this case, we can use an Ante Test to verify that OHMv2 continues to serve its stated purpose as a reserve currency by checking that it’s backed at least 1:1 by reserves and liquidity tokens in the Olympus treasury.

Checking OHM is backed

The idea for an OHM backing test was originally proposed by Ante contributor grokasm (view their test code for Olympus V1 here). The test works by looping through the list of reserve and liquidity tokens in the Olympus treasury and comparing it to the total supply of OHM.

Checking the OHMv2 token supply is easy enough; we just call totalSupply() on the token contract.

Getting the total treasury backing requires a little more work. The treasury address itself could change in the future and is now read through the OlympusAuthority contract. We implement the following helper function to return the current treasury address:

To sum up the total backing, we can iterate through the list of reserve and liquidity tokens in the treasury and add the value of each to a running total. Normally, we could check the registry of tokens in the Olympus treasury contract to get an up-to-date list of approved liquidity and reserve tokens. Unfortunately, the current version of the treasury contract does not have a functioning token registry, so we need to manually pass in the addresses of the approved liquidity and reserve tokens we want to check. The tokens approved at the time of our test deployment are: DAI (reserve token), FRAX (reserve token), and OHM/FRAX SLP (liquidity token).

*Note: Because the token addresses must be passed in manually through the constructor and cannot be changed after deployment, the Ante Test will not capture any token addresses subsequently added to or removed from the Olympus treasury token registry (a new Ante Test including any updated token addresses could be deployed if one wanted to include any changes in token addresses). ****This means that the Ante Test could fail even if OHM is still fully backed if Olympus changes the composition of their reserve and liquidity tokens. ***If you are considering staking or challenging the OHMv2 Ante Test, as with any smart contract, you should review the code before interacting with it, and never deposit more than you can afford to lose.

summing up reserve token balances

We loop through our list of reserve tokens, then loop through the list of liquidity tokens in a similar fashion to get the total treasury backing. Lastly, we compare the total backing against the supply of OHMv2 and fail the test if the OHM token is not fully backed by the Olympus treasury assets tested.

*scratchy prophetic voice* Should this fail, theomachy draws nigh

Check out the full test code here, and live test on Ante here!

Conclusion

When code is law, it’s important to verify that it works as intended if you don’t want to get rekt. Ante is a piece of Web3 infrastructure that makes on-chain guarantees easier to check. We hope fast-moving projects add Ante Tests to their launch checklist in the future (alongside audits, bug bounties, etc.) to provide their users with peace of mind that their innovative new features are working as specified.

We encourage everyone to write Ante Tests (Check out our community GitHub where other community members have written Ante Tests) and/or ask your favorite protocols to write and stake their own Ante Tests! Together, we can build a safer Web3 community!

What other protocols would you want to see Ante Tests written for? Let us know in the comments or via Twitter, and join our Discord for more Web3 security discussion!

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!

Buenos días, amigos and welcome to the first edition of the Ante Test writing series in 2022. This week, we’re highlighting another community-written Ante test — a test written for Alchemix by waynebruce0x (who currently holds the #1 spot on the Ante Community Leaderboard).

Alchemix is a protocol which lets DeFi users take out a loan against the future yield of their assets that slowly pays itself off. This is accomplished by letting users deposit collateral and subsequently mint a synthetic asset pegged 1:1 with that collateral. In order to withdraw the collateral again the user must repay the balance of the synthetic asset they borrowed, but this balance owed decreases over time until it eventually hits zero.

In the background, the collateral deposited is used to generate yield from other DeFi protocols. This synthetic asset can be transmuted or traded 1:1 into the underlying collateral fairly easily, effectively giving the user an advance on their future yield.

alUSD doesn’t exceed DAI locked in Alchemix Test

Waynebruce0x’s idea was to test that the total amount of synthetic asset outstanding was not more than the amount of underlying collateral — here specifically testing DAI and alUSD (an algo stablecoin minted using DAI collateral in alchemix).

Alchemix limits the amount of alUSD which can be minted from DAI to 50% of DAI deposited. If the amount of alUSD in circulation exceeded the DAI collateral in alchemix, it would indicate something had gone catastrophically wrong with the protocol. Such as a hacker draining DAI from the protocol or minting alUSD without depositing DAI. Fun fact — this actually happened in the case of alETH, Alchemix’s ETH-backed synthetic asset, back in June. Waynebruce0x also wrote a test for alETH which would have failed during the hack.

The test logic is fairly simple. First, check the total supply of alUSD, then the total amount of DAI controlled by the protocol. If the first quantity is more than the latter, the test fails. Otherwise, it holds true. This can be seen in the checkTestPasses function:

The total DAI balance is computed as the sum of the DAI balances controlled by the Transmuters (contracts that maintain the peg by allowing alUSD to be turned into DAI 1:1) and being farmed in Yearn — AlchemistYVAVL and TransmuterBYVAVL. Astute code-readers will notice that there is a conversion step in which the yield bearing tokens held by these latter two contracts are converted to their equivalent DAI value via PricePerShare

The actual addresses being tested are hardcoded in the contract:

This test and the corresponding Ante Pool were deployed on-chain and can be viewed here. AlUSD is currently fully backed by DAI and will hopefully continue to be solvent, but now degens have a way to parse the risk of failure in real-time without being solidity wizards.

Conclusion

You’ve probably heard it before, but DeFi can be dangerous. Hacks, exploits, and other shenanigans happen almost daily. There’s only so much we can do to prevent bugs from making it onto main-net, but as a community we can at least keep each other informed about the inherent risks involved.

Ante is an important piece of that puzzle, making DeFi safer by providing real-time risk assessments of protocol code failures — ultimately enabling you to make more informed decisions about where to park your hard-earned crypto. If that sounds interesting, then follow us on twitter and join our discord (where waynebruce0x and other big brains hang out) to talk about the latest in web3 security.

Summary

Lending markets are one of the core use cases of decentralized finance. Without them, we’d have to sell our favorite cryptos to ape into the newest 1000% APY farm. But thanks to protocols like Aave, Compound, Kashi, and Wild Credit, we can unlock the high APY potential of our favorite coins without sacrificing future gains.

Wild Credit is a money market protocol that quickly gained a lot of attention due to its eye-poppingly high APRs, often offering upwards of 25% APR for supplying ETH and 45%+ APR for supplying stablecoins (and making them available for borrowing), much higher than other protocols at the time.

The Ante team was initially made aware of Wild Credit due to an Ante Test written by resident Antean jseam. The high supply-side APR relative to the borrower interest paid made us question where the yield was coming from. Our investigation uncovered the answer — the utilization rate of the market was not being properly taken into account when calculating supplier interest accrued. This resulted in an accounting error that caused the protocol to owe more funds to its users than it actually contained.

At the time when the bug was discovered in late October, this deficit was increasing by over $100k/day. Though timely disclosure of the bug to the Wild Credit team prevented future losses, the deficit accrued by the protocol to that point already totaled around $14M.

Key takeaway— if something seems too good to be true, it probably is (even in crypto).

Vulnerability

Without loss of generality, let’s examine the DAI side of the DAI-ETH lending pair deployed here (now no longer in use): https://etherscan.io/address/0x3550e61886E1184B8BB732bb7135BDA9B7461801

Currently, DAI suppliers users accrue interest on their DAI balance every time the accrueAccount is called (when the user deposits or withdraws collateral and takes out or repays a loan). This is seen in the following code:

function accrueAccount(address _account) public {
    _distributeReward(_account);
    accrue();
    _accrueAccountInterest(_account);

    if (_account != feeRecipient()) {
      _accrueAccountInterest(feeRecipient());
    }
  }

The accrue function called here calculates the cumulativeInterestRate paid by borrowers. This cumulativeInterestRate is then used to calculate the interest paid to suppliers in _accrueAccountInterest as shown below:

function _accrueAccountInterest(address _account) internal {
    uint lpBalanceA = lpToken[tokenA].balanceOf(_account);
    uint lpBalanceB = lpToken[tokenB].balanceOf(_account);

    _accrueAccountSupply(tokenA, lpBalanceA, _account);
    _accrueAccountSupply(tokenB, lpBalanceB, _account);
    _accrueAccountDebt(tokenA, _account);
    _accrueAccountDebt(tokenB, _account);

    accountInterestSnapshot[tokenA][_account] = cumulativeInterestRate[tokenA];
    accountInterestSnapshot[tokenB][_account] = cumulativeInterestRate[tokenB];
  }

  function _accrueAccountSupply(address _token, uint _amount, address _account) internal {
    if (_amount > 0) {
      uint supplyInterest   = _newInterest(_amount, _token, _account);
      uint newSupplyAccount = supplyInterest * _lpRate(_token) / 100e18;
      uint newSupplySystem  = supplyInterest * _systemRate(_token) / 100e18;

      _mintSupply(_token, _account, newSupplyAccount);
      _mintSupply(_token, feeRecipient(), newSupplySystem);
    }
  }

The _newInterest accrued to suppliers is calculated without considering the ratio of assets supplied to assets borrowed, resulting in an overestimate of the interest accrued:

function _newInterest(uint _balance, address _token, address _account) internal view returns(uint) {
    uint currentCumulativeRate = cumulativeInterestRate[_token] + _pendingInterestRate(_token);
    return _balance * (currentCumulativeRate - accountInterestSnapshot[_token][_account]) / 100e18;
  }

The correct calculation would change the return statement in _newInterest as described in the following pseudocode:

return _balance * (debt/supply) * (currentCumulativeRate - accountInterestSnapshot[_token][_account]) / 100e18;

Writing bug-free code is hard, and the stakes are high on-chain. Here, a one-line bug caused an 8 figure loss in user funds!

NB: _lpRate and _systemRate are both set to 50% and do not affect the proof of concept

Example

Assume the borrow rate for the ETH-DAI market is 94.7% and 1000 DAI are supplied to the market, 200 DAI borrowed.

The APR paid to suppliers is set at 50% of the borrow rate (the _lpRate above).

Thus while borrowers are paying an interest of 189 DAI per year (0.947 * 200), suppliers are “earning” 473 DAI per year (0.473 * 1000), resulting in a net deficit to the protocol of 284 DAI per year. Repeat this calculation using the real parameters and across all lending markets to calculate the full impact of the bug.

Fix

The Wild Credit team moved swiftly to mitigate further losses from the protocol by (1) pausing all borrowing/supplying in the contracts and (2) moving all funds in their lending markets to the protocol treasury.

Following this, the team calculated their users’ total supplied balances net of their borrowed balances and compared this quantity to the funds present in the protocol. They determined that the total deficit amounted to 22% of user funds and this loss was socialized.

Users were refunded proportionally from the protocol assets and issued wBOND tokens equal to the deficit amount. These wBOND tokens are set to mature at $1 with no fixed expiration, and will be paid off using future protocol revenue.

Acknowledgments

We’d like to acknowledge Wild Credit for their swift and effective harm mitigation and commitment to making their users whole. We’d also like to thank Immunefi for their guidance and support during the disclosure process. Additionally, we’d like to acknowledge members of Cluster Capital for discussions which led to the discovery of the issue.

Finally, we’d like to thank our community member jseam for writing an Ante Test for Wild Credit and bringing the protocol to our attention. As part of this post-mortem and as a show of support for the Wild Credit team going forward, the Ante team will be staking our portion of the bounty payout (~2 ETH) in jseam’s Ante Test, which assesses the integrity of Wild Credit’s price oracles.

To find out more about how Ante Tests enable monetary piece of mind in DeFi and connect with other security-conscious degens, follow us on Twitter and join our Discord.

gm frens! Welcome back to the Ante Test Series (check out our first writeup on Compound here, or read more here if you need a refresher on Ante Tests).

At Ante, we believe in putting our money where our mouth is, so it’s only natural that this week’s featured Ante Tests are tests for the Ante protocol! After all, what kind of buidlers would we be if we didn’t eat our own dog food?

About the tests

Both of these Ante Tests loop over multiple contract addresses checking for specific conditions. While looping in general can be susceptible to a block stuffing attack if the number of tests in the loop gets sufficiently (read: extremely) high, we set the array of tests on deployment explicitly so we can avoid this problem.

constructor(address[] memory antePoolContracts) {
    testedContracts = antePoolContracts;
    protocolName = "Ante";
}

Having the tested contracts be passed in as an argument on deploy also makes it easy to deploy new versions of the test if the set of Ante Pools we want to check changes.

AntePoolTest

AntePoolTest checks several Ante Pools to confirm that the balance matches the total amount staked, challenged, and paid out (check it out on the Ante app). This is an example of using an Ante Test to verify that smart contract functionality works as intended.

function checkTestPasses() public view override returns (bool) {
    for (uint256 i = 0; i < testedContracts.length; i++) {
        IAntePool antePool = IAntePool(testedContracts[i]);
        // totalPaidOut should be 0 before test fails
        if (
            testedContracts[i].balance < 
            (
                antePool
                    .getTotalChallengerStaked()
                    .add(antePool.getTotalStaked())
                    .add(antePool.getTotalPendingWithdraw())
                    .sub(antePool.totalPaidOut())
            )
        ) {
            return false;
        }
    }
    return true;
}

When AntePoolTest was deployed, there were 6 Ante Pools on mainnet, so AntePoolTest checks each of those 6 pools and if any of them fail to meet the conditions, AntePoolTest fails.

AnteAVLDropTest

Our second (and brand new) Ante Test for Ante is a plunge protection test to make sure that there isn’t a 99% drop in value locked across the tested contracts (check it out here). In the test, we define a helper function getCurrentAVL(), which loops through the Ante Pools and sums up the balances:

function getCurrentAVL() public view returns (uint256) {
    uint256 currentAVL;

        for (uint256 i = 0; i < testedContracts.length; i++) {
        currentAVL = currentAVL.add(testedContracts[i].balance);
    }

    return currentAVL;
}

In the constructor, a snapshot of the total AVL is taken on deploy and used to calculate the failure threshold. For the current deployment, we’ve included all 11 Ante Tests that are currently on Mainnet, which includes 4 community-written tests 🥳.

constructor(address[] memory _testedContracts) {
    protocolName = "Ante";
    testedContracts = _testedContracts;// Calculate test failure threshold using 99% drop in total AVL at time of deploy
    avlThreshold = getCurrentAVL().div(100);
}

Once we have our AVL threshold, checking the failure condition is pretty straightforward:

function checkTestPasses() public view override returns (bool) {
    return getCurrentAVL() >= avlThreshold;
}

Dead simple, right? Honestly, besides helping bootstrap trust in a protocol, writing an Ante Test is also a great way to onboard junior developers and teach them basic smart contract development. I mean, our UX designer wrote AnteAVLDropTest!

Conclusion

Risks in DeFi are really hard to understand unless you’re super technical. Ante Tests help quantify those risks in a simple manner, and we’ve made it super easy for anyone to write your own Ante Tests. Check out our community GitHub where other community members have written Ante Tests for protocols like OlympusDAO and Wild Credit and help write tests for your favorite protocols, follow us on Twitter, and join our Discord for more discussion!

gm frens, and welcome to the first article in our Ante Test Series. Each week, we’ll highlight Ante Tests deployed on-chain: what they do, why we wrote them, and why you should care (learn more about Ante Tests here).

To kick things off, we’ll start with two Ante Tests our core team wrote for Compound and submitted to the EthGlobal hackathon. Our submission won the Compound grant and the prize money was staked in the Ante Tests on-chain.

$COMP (Comptroller) Issuance Rate Test

On September 29th, Compound introduced a bug into their Comptroller contract via a governance-approved upgrade. This bug allowed certain users to claim significantly more $COMP awards than they were entitled to, leading to $90M being drained from the protocol in a span of 48 hours.

Our Issuance Rate Test fails if such an event occurs again. The test logic snapshots the current Comptroller $COMP balance whenever the checkpoint function is called, and also once when the contract is deployed. Then, the current $COMP balance is checked against the snapshotted balance whenever checkTestPasses is called:

function checkTestPasses() public view override returns (bool) {
        uint256 timeSinceLastCheckpoint = block.timestamp.sub(lastCheckpointTime);
        if (timeSinceLastCheckpoint > MIN_PERIOD) {
            uint256 compBalance = COMP.balanceOf(COMPTROLLER);
            // if COMP was added to contract then return true to avoid reversion due to underflow
            if (compBalance >= lastCompBalance) {
                return true;
            }            return lastCompBalance.sub(compBalance).div(timeSinceLastCheckpoint) < COMP_PER_SEC_THRESHOLD;
        }        // if timeSinceLastCheckpoint is less than MIN_PERIOD just return true
        // don't revert test since this will trigger failure on associated AntePool
        return true;
    }

If the rate of $COMP decrease is ever greater than 10,000 $COMP/day, as it was when the bug was introduced, the test will fail. To prevent abuse and false positives, the checkpoint function can only be called once every 48 hours and at least 12 hours must have passed since the last checkpoint before the test can fail.

This functions as a live, on-chain regression test for re-occurrence of this bug. DeFi users staking and challenging this test asynchronously produce real-time measurements of community trust that the bug won’t be re-introduced. These measurements will become particularly interesting as further upgrades to the Comptroller contract are made.

Compound Markets TVL Drop Test

Encapsulating the risk of catastrophic protocol failure in a few lines of code can be tricky business. In some cases however, the Total Value Locked (TVL) functions as a proxy. If the TVL plunges, it can indicate that a hack has occurred or that a bug has caused a loss of user funds or user confidence. Testing for a drop in TVL therefore equivalently tests for a wide variety of failure modes — particularly in the case of lending markets.

This is the motivation behind this test — if the TVL in any of Compound’s top 5 markets falls by over 90%, it indicates that Compound itself has likely suffered serious damage. The TVL in each of these markets is snapshotted on test deploy:

constructor() {
        protocolName = "Compound";        for (uint256 i = 0; i < 5; i++) {
            ICToken cToken = cTokens[i];
            testedContracts.push(address(cToken));            thresholds[i] = ((cToken.getCash() + cToken.totalBorrows()) * PERCENT_DROP_THRESHOLD) / 100;
        }
    }

and checkTestPasses checks whether that TVL has dropped severely:

function checkTestPasses() public view override returns (bool) {
        for (uint256 i = 0; i < 5; i++) {
            ICToken cToken = cTokens[i];
            if ((cToken.getCash() + cToken.totalBorrows()) < thresholds[i]) {
                return false;
            }
        }        return true;

This test will fail (i.e., return false ) only if Compound itself fails, and thus staker and challenger actions on this pool provide real-time plunge protection. Pretty cool.

Conclusion

Check out our Compound Ante Tests here and here. You can stake in support or, if you think they might fail, you can challenge them.

DeFi is pretty amazing. We came together as anons to build a new financial system — and we built it using cats, frogs, anime, and food memes. All while making lasting friends along the way. It’s also pretty scary. Unless you’re a super coder, you really can’t tell if or how likely it is that you’re going to lose all of your hard-earned crypto. Audits, bug bounties, and insurance help — but none of these are perfect tools.

Here at Ante, we’re trying to make DeFi just a little less scary, or at least just make that scariness legible. Imagine a future where you can see which protocols have staked money behind their code, the perceived risk of these protocols to exploits in real-time, and even build on top of this information in a composable way. If that sounds interesting to you, join us and other security-conscious degens in building the new economy of trust.

For more info on protocol mechanics and Ante Tests, subscribe to our Twitter and join our Discord.

Checks-Effects-Interactions is a pattern that helps minimize the attack surface area of smart contracts by ordering control flow:

1. First, run checks (e.g., sanity checks, safety checks of potential state changes)

2. Next, apply internal effects (e.g., in-contract variable and parameter changes)

3. Lastly, conduct external interactions (e.g., interactions with external contracts and/or sending of ETH)

This might feel unintuitive to someone coming from Web 2.0 where you might typically apply effects after interactions. However, in Solidity, this would open the function up to an attack via reentrancy (of which The DAO hack is probably the most well-known example). In Solidity, when a value transfer of ETH occurs a payable function can be automatically invoked — a malicious actor could write this function in a way to potentially exploit the interacted contract. By checking state and applying effects before external interactions, we can make it more difficult for a potential attacker to create a scenario where a malicious contract is able to repeatedly call functions that should only be called once.

CEI example: claim() in AntePool.sol

To see this pattern in action, let’s take a look at the claim() function in AntePool.sol:

Lines 318–334 in AntePool.sol

As a refresher, Ante allows users to create incentivized on-chain guarantees of smart contract state that are programmatically settled. Since claim() is one of the primary value transfer functions for the Ante protocol, it is critical that we prevent improper withdrawals from a pool. Let’s break down how we use the CEI pattern here to guard against some common attack vectors.

Checks

We conduct two checks here to verify that the person calling claim() is an eligible claimant:

require(pendingFailure, “ANTE: Test has not failed”);
require(user.startAmount > 0, “ANTE: No Challenger Staking balance”);

First, we check that the Ante Test has failed. This prevents people from claiming from an active test. Next, we check that user has a challenge balance greater than zero — since one must challenge the Ante Test in order to be eligible to claim a payout from its failure, this prevents people that haven’t challenged the test from claiming a share that doesn’t belong to them.

Effects

Now that we’ve verified that the sender is an eligible claimant, we can calculate the payout amount and apply the following effects:

user.startAmount = 0;
numPaidOut = numPaidOut.add(1);
totalPaidOut = totalPaidOut.add(amount);

The important bit here is that we zero out the challenger balance before we transfer any value so that the user can’t claim again via reentrancy. If they were to attempt this, since the user’s balance is now 0 the initial checks would fail and only one value transfer will go through.

We also increase the count for number of payouts and total amount paid out but this is less important as it doesn’t affect value transfer or calculation.

Interactions

_safeTransfer(msg.sender, amount);
emit ClaimPaid(msg.sender, amount);

Finally, we use _safeTransfer to send value to challenger and emit the ClaimPaid event. (Note: in this implementation of _safeTransfer we send the lesser of the pool balance and the amount owed in the likely impossible edge case that rounding errors cause the pool to not have enough ETH)

DeFi has experienced a momentous surge in interest and adoption over the last several years. Since early 2020, the total value locked (“TVL”) on DeFi protocols has increased over 100x and as of this writing, TVL is over $115 billion. On December 4, 2020, the DeFi ecosystem exceeded one million unique wallet addresses and, less than five months later, exceeded two million.

DeFi adoption still pales in comparison to both the crypto and global lending markets, at roughly 5% and 1.5%, respectively. Readers here are no strangers to the innovation and potential that exists in DeFi, so what is the main obstacle to adoption and acceptance of DeFi among institutional and retail investors?

In a word, trust. Trust that the system is secure and legitimate, with staying power to be a commonly used financial system for the future. Trust that of the many DeFi projects out there, the ones gaining use are the ones that will endure.

Inertia Towards TradFi

Inertia in Tradfi is powerful. Most people are used to traditional financial institutions and, consciously or not, equate familiarity with legitimacy. But banks make mistakes, from making bad loans based on flawed credit models to accidentally wiring nearly a billion dollars to hedge funds. Retail banking customers accept slow service, arbitrary account fees, inconvenient wire cutoffs, low APYs, and other inefficiencies because that’s how things have been for a very long time. These antiquated banking processes and potential for human error are accepted as cost of doing business.

Indeed, when friends, family, coworkers, and the general public all rely on Tradfi solutions, it is taken as the “safe” default option. With so much money held by centralized institutions, the tendency to follow everyone else’s lead is powerful. With something as serious as one’s own money, the inertia to move to a new financial system is only that much greater.

Trust Protocols

New/potential users must trust — deeply trust — anywhere they are putting their own capital. They need assurances that the DeFi team is skilled, does not have misaligned incentives, and that it has produced secure, bug-free smart contracts. As importantly, users need to believe that others also trust in the legitimacy of the protocol.

However, trust in DeFi is both precious and elusive. New DeFi projects launch on a daily basis. Some of these are driven by generating quick profits for the team, often at the expense of its community. Malicious DeFi teams have rugged their own users.

Still, other projects, despite best efforts to conduct annual audits and implement bug bounty programs, remain subject to vulnerability and hacks:

In total, over $284 million has been lost to hackers since 2019.

DeFi Trust Solutions

Audits, insurance, and bug bounties help lend credibility to protocols. But they do not create the perception of community trust or widespread legitimacy. Further adoption among retail and institutional actors first requires the ability for anyone (technically trained or not) to be able to instantly discern how much the general public believes in a DeFi project, its team, and its code.

The Ante team has been working on a trust solution and is excited to share it with you at Ante Finance!