Executive Summary
During multiple security reviews of the Baseline Markets V2 system, we discovered in total 22 high severity issues. Of these 22 high severity issues, several resulted in complete DoS’s of the protocol, risk free arbitrages, and the invalidation of the “baseline value”.
All reported issues were promptly addressed by the Baseline team prior to the launch of the $YES token and the entirety of the baseline system that took place on June 7th, 12:00pm EST.
The first Guardian security review ran from the 29th of April to the 9th of May. A team of six auditors reviewed the source code of the Baseline system, focusing on the MarketMaking and CreditFacility modules. Remediations were made to address the issues uncovered and presented to the Guardian team along with protocol updates for a second review.
The second Guardian security review ran from the 27th of May to the 6th of June. The same team of six auditors reviewed the remediations made and the subsequent updates that were made to the system.
Both engagements relied heavily on invariant testing with Echidna, throughout the security review process over 100 invariants were assessed for tens of millions of randomized runs. These invariants are documented in the first Baseline engagement report.
The full report for both Guardian engagements can be seen here:
About Baseline Markets
The vision for Baseline Markets is lofty: introduce a baseline intrinsic value to ERC20 tokens as a standard across Web3.
Baseline imbues a guaranteed “worst-case” worth of ERC20 tokens via sophisticated liquidity management, whereby the price of a token mathematically cannot go below a floor liquidity position.
This behavior centers around 1 core invariant*(1) of the system:
Where the “floor”, “anchor”, and “discovery” are concentrated liquidity positions in a Uniswap V3 liquidity pool.
The 3 liquidity positions are distributed as follows:
where $YES price increases to the right
Floor
The Floor position serves as the last line of defense for the token’s baseline value (BLV), which is denoted as the price at the lower tick of the floor position.
The Floor holds the highest and most concentrated liquidity of all the positions to defend the BLV, but also to allow liquidity to be distributed optimally while maintaining the protocol’s core capacity invariant.
The Baseline system aims to build up enough liquidity capacity such that the Floor position price, and thus BLV, can be incremented by ~2%, or 200 ticks to be exact, while maintaining the system capacity invariant.
The more liquidity is concentrated in the Floor, the more capacity the liquidity structure is able to absorb and the more likely the system is to “bump”, or move the floor position up a full tick spacing.
Anchor
The Anchor position resides at the active price, where it is at most 10 tick spacings wide with the active price occupying the uppermost tick spacing. The goal of the Anchor position is to facilitate smooth spot trading of the $YES token near the current market price.
The Anchor also facilitates capacity increases by easily allowing the active price to move into the Discovery range, where the increased Discovery liquidity is turned into Anchor and Floor liquidity. This action moves reserve assets down the liquidity structure, allocating them towards cheaper $YES prices, and thereby increasing the capacity of the liquidity structure.
Discovery
The Discovery position allows positive price action and speculation, while generating a profit for the Baseline system and ultimately increasing the BLV. The Discovery position has more liquidity than the Anchor so that the excess liquidity can be turned into system “profits”.
The fundamental way the Baseline system creates a “profit” is by selling $YES tokens to traders at a premium to BLV in the Discovery range, and allocating the received Ether reserves towards the Floor and Anchor liquidity ranges, which value $YES at a cheaper price relative to Ether.
All “profits” created by the Baseline system this way are contributed towards increasing the BLV as a result of a Floor liquidity bump.
(1) This is a simplified version of the system invariant, which in actuality would include virtual floor reserves from borrowed funds.
Baseline Liquidity Operations
As the active price of $YES moves, the Baseline system intelligently manipulates the liquidity structure with 3 liquidity operations to create system profit and support trading at the market price.
Sweep
As price moves out of the Anchor and into the Discovery range, a sweep will occur to redistribute the excess ETH captured in the higher liquidity Discovery position and reset the bounds of the Anchor to envelop the active price.
Sweeps contribute towards an increase in the capacity of the liquidity structure via moving excess ETH from the Discovery position down into the Floor or Anchor positions. More sweeps with higher surpluses of Ether reserves will lead to Floor bumps over time.
Slide
As price moves downwards in excess of one full tick spacing a slide operation occurs, where the Anchor range is re-adapted to include the current active price in it’s upper tick spacing and extend at most 10 tick spacings below. As the Anchor moves downwards the Discovery range is adapted to sit right above the current active tick spacing as well.
Slide operations ensure there is adequate liquidity around the current active price and that the Discovery range is never greater than a full tick spacing away.
Bump
When the baseline system has accumulated enough excess reserves via sweep and slide operations as well as Uniswap V3 fees and interest from borrows, a liquidity “bump” takes place.
The liquidity bump moves the floor position up an entire tick spacing, increasing the baseline value of the $YES token by roughly 2% each time.
After a bump, the floor position, and by extension the BLV, can never be moved back down — thus creating a token who’s baseline value can only increase over time.
Borrowing Against Your $YES
As $YES tokens have an intrinsic baseline value, the Baseline protocol allows $YES holders to borrow Ether reserves against their $YES at a BLV valuation.
For example, if the BLV of $YES is 0.01 ETH, users can deposit 100 $YES as collateral to receive 1 Ether in a fixed term loan. With every loan an interest amount is taken up-front, deducting from the amount of Ether initially received by the user.
Ether reserves are drawn first from the Floor position to pay out borrowers, and then from the Anchor and Discovery positions if the Floor is exhausted. Ether reserves which are borrowed and removed from the liquidity structure this way are tracked as “virtual reserves” which are accounted as if they exist in the Floor position until they are repaid and re-allocated to the Floor.
[Resolved] Vulnerability #1: “Floor Inflation Allows Risk Free Shorts”
In our first review of the Baseline V2 system we uncovered a novel inflation attack which allows traders to create a risk free short on the $YES token by inflating the liquidity of the Floor position, the attack works as follows:
A large $YES holder Bob sells his $YES tokens to move the active price into the floor position, close to the BLV. Bob then transfers WETH reserves directly to the Baseline system before triggering a slide operation in order to attribute this liquidity to the Floor position.
The Baseline system cannot distinguish the WETH transferred by Bob from the reserves which were removed from the Floor position as it relies on the balanceOf when deploying reserves to the Floor.
After re-deploying the Floor position with the added reserves, the Baseline system will mint the corresponding $YES tokens to match in the liquidity position. However the value of $YES tokens minted will be much greater than the value of reserves added as the current price is closer to the floor tick of the position. This way most of the position is filled with minted $YES tokens, essentially leveraging the reserve assets sent by Bob.
The net result is that the floor position has significantly increased liquidity, and thus Bob can buy back the $YES tokens he originally sold, this time at at a lower average price. This is because Bob experiences less slippage at this lower price range.
This way Bob can short $YES and pay back his short while keeping a risk free portion as a guaranteed profit for himself. This attack was analyzed to yield roughly 20-30% short gains on average and up to 50%+ short gains in ideal circumstances.
See the full attack breakdown below:
[Resolved] Vulnerability #2: “DoS Via External Liquidity By Predicting Positions”
In our first review of the Baseline system we identified several ways in which external actors could attribute unwanted liquidity to the existing Floor, Anchor, and Discovery ranges. This unwelcomed outside liquidity caused many issues in the system such as a DoS of liquidity operations.
These attack vectors were resolved with the protocol updates, but a more subtle external liquidity attack vector was identified in the updated version.
Previously arbitrary addresses could attribute liquidity to the Baseline system by interacting with the Uniswap V3 pool directly and minting liquidity to the BPOOL ($YES) address. This was resolved by tracking the liquidity of each position deployed by Baseline in an internal getLiquidity mapping and only updating the mapping when a position was moved or increased through Baseline.
However, because baseline often deploys reserve amounts into positions and mints whatever $YES tokens are necessary in the uniswapV3MintCallback, the getLiquidity mapping value is assigned to the liquidity reported by Uniswap when reading the position data.
This behavior opens an attack vector, where a malicious actor may predict where the Baseline system will move their position to and mint malicious liquidity there for the Baseline system ahead of time.
For example, a bump liquidity operation may move the bottom tick of the Anchor position from tick 1,000 to tick 1,200, thereby changing the Anchor range. An attacker may observe that a bump is about to occur and deploy liquidity to the soon-to-be Anchor range in order to get this outside liquidity recorded in the getLiquidity mapping for the Anchor position.
The attacker can even call the bump function themselves to force their external liquidity into the system. Among other things this can DoS sweep operations via inflating the Anchor liquidity past that of the Discovery.
[Resolved] Vulnerability #3: “Borrows In The Floor Invalidate Baseline Value”
This vulnerability is a subtle logical oversight regarding the accounting of the funds borrowed from the floor position. The vulnerability was uncovered after several million fuzz runs assessing 100+ protocol invariants.
When reserve assets are borrowed they are removed from the Floor position and accounted for in the virtual reserves. The virtual reserves are accounted for in the capacity as if they are actively deployed in the Floor position. This is expected as the reserves will be re-deployed to the Floor once the repayment has occurred. In the interim, before the repayment, the user’s $YES collateral has been effectively removed from circulation while still accounted for in the circulatingSupply so the credit issued is accounted for being in the Floor to offset this.
However there is one key difference between reserves which are actively deployed in the Floor position and virtual reserves which are simply accounted for being in the Floor by proxy. This is that the reserves in the Floor position increase the liquidity of the Floor in Uniswap V3, while the virtual reserves do not.
Therefore when price is in the Floor range the virtual reserves do not require a corresponding inflow of reserves when $YES buys occur.
As a result, when reserves are moved into the virtual reserves via a borrow inside the Floor position and price subsequently moves upwards out of the floor, the virtual floor reserves are increasingly stretched wider across the floor. As a result the virtual floor reserves offer a smaller amount of liquidity and thus capacity as the price increases.
In some cases this can lead to an invalidation of the capacity invariant of the system, which ultimately invalidates the baseline value of the $YES token.
Finding Remediations
C-02 Floor Inflation Allows Risk Free Shorts - Report #1
The inflation attack was resolved by caching the reserve balance of the BPOOL ($YES) address before removing the reserves from liquidity positions. The cached reserve balance is now removed from the amount deployed to the Floor position in the slide function.
H-01 DoS Via External Liquidity By Predicting Positions - Report #2
This external liquidity vector is addressed by checking if an external position already exists before adding new liquidity. If an external position exists for the Baseline system, the position is removed and the reserves from it are treated as a donation to the system.
H-10 Borrows In The Floor Invalidate Baseline Value - Report #2
A simple solution to this issue would have been to disallow borrows in the Floor position entirely, however borrowing and looping whilst in the Floor range is important for the protocol to escape the Floor tick and develop positive price action.
Therefore a more accurate validation is implemented. Borrows are disallowed if they would invalidate the capacity invariant when the price moves to the top of the Floor tick range, ignoring any capacity gain that would come as a result of additional reserves in the Floor as price rises.
Additional reserves that would enter the floor as price increases must be ignored as they can mask an invalidation of the capacity invariant that would occur at an intermediate tick before the upper tick of the Floor.
Conclusion
The Baseline Markets system and the $YES token is the first of it’s kind, a token with a mathematically guaranteed baseline value.
Our audit of the codebase uncovered both severe issues and intriguing value extraction scenarios, all of which were addressed or acknowledged by the Baseline team.
As the technology of the coined ERC-420 continues to mature and new use-cases are implemented we are eager to see how the traditional approach to ERC20 tokens can be augmented through clever liquidity management.
