Asymmetry Finance afETH Invitational - d3e4's results

Lines of code

https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/AfEth.sol#L148-L169

Vulnerability details

Impact

The up to 2 % price discrepancy from Chainlink creates an intrinsic arbitrage. Especially, it makes withdrawals worth more than deposits in the sense that one can immediately withdraw more than just deposited.

Proof of Concept

When depositing ETH into AfEth, the ETH is split according to ratio and sold for safEth and vAfEth. The received share of afEth is then determined by the value in ETH of the resulting amounts of safEth and vAfEth. Note that there are two prices involved here: the true price at which ETH is traded for safEth and vAfEth (in sellCvx() and buyCvx()), and the estimated value in ETH that safEth and vAfEth is considered to have (ISafEth.approxPrice() and VotiumStrategy.price()). These are not necessarily the same.

If the ratio by which the deposited ETH is split is not the same as the ratio of the true values of the underlying assets, this implies that a deposit implicitly makes a trade between safEth and vAfEth according to the estimated price which may thus differ from the true price obtained when withdrawing. This presents an arbitrage opportunity. Note that if all prices were the same it would not matter if safEth is "traded" for vAfEth within a deposit as the trade then makes no change in the total value deposited.

The conditions for this issue is thus that VotiumStrategy.price() is different from the price obtained by sellCvx() and buyCvx(), and that the deposit ratio is not the same as the withdrawal ratio.

VotiumStrategy.price() in particular is based on a Chainlink oracle with a 2 % deviation threshold, which means that the true price is allowed to deviate up to 2 %, within 24 hours, from the reported price. ISafEth.approxPrice() may perhaps be similarly inaccurate (I have not looked into this).

The ratio can skew in this way for two reasons. One is when the ratio is different from the ratio of the underlying balances, such as when ratio is changed. Deposits are made according to ratio but withdrawals are made proportionally from the extant balances. In this case the implicit trade between safEth and vAfEth can happen in either direction, either beneficial or detrimental to the depositor (if there is a price discrepancy). The other is caused by the price discrepancy itself when depositing. In this case it is always beneficial to the depositor (and detrimental to the holders).

Example 1a - reconverging ratio, vAfEth is actually more expensive Suppose the contract holds 100 safEth and 0 vAfEth, but that the ratio has now been changed to 0. Further suppose that the contract thinks all prices are 1, but that 100 ETH actually trades for 102 vAfEth. Then depositing 100 ETH will convert it to 102 vAfEth, which will be valued as 102 ETH. This mints 102 afEth. The balances are now 100 safEth and 102 vAfEth and the total supply is 202 afEth. Withdrawing 102 afEth converts 102/202 of the underlying, i.e. 50.495 safEth and 51.505 vAfEth, into 50.495 + 51.505/1.02 = 100.99 ETH.

Example 1b - reconverging ratio, vAfEth is actually cheaper Suppose the contract holds 100 safEth and 0 vAfEth, but that the ratio has now been changed to 0. Further suppose that the contract thinks all prices are 1, but that 100 ETH actually trades for 98 vAfEth. Then depositing 100 ETH will convert it to 98 vAfEth, which will be valued as 98 ETH. This mints 98 afEth. The balances are now 100 safEth and 98 vAfEth and the total supply is 198 afEth. Withdrawing 98 afEth converts 98/198 of the underlying, i.e. 49.495 safEth and 48.505 vAfEth, into 49.495 + 48.505/0.98 = 98.99 ETH.

Example 2a - stable ratio, vAfEth is actually more expensive Suppose the contract holds 50 safEth and 50 vAfEth and that the ratio is 0.5. Further suppose that the contract thinks all prices are 1 but that 50 ETH actually trades for 51 vAfEth. Then depositing 100 ETH will convert 50 ETH to 50 safEth and 50 ETH to 51 vAfEth, which will be valued as 101 ETH. This mints 101 afEth. The balances are now 100 safEth and 101 vAfEth and the total supply is 201 afEth. Withdrawing 101 afEth converts 101/201 of the underlying, i.e. 50.249 safEth and 50.751 vAfEth, into 50.249 + 50.751/1.02 = 100.005 ETH.

Example 2b - stable ratio, vAfEth is actually cheaper Suppose the contract holds 50 safEth and 50 vAfEth and that the ratio is 0.5. Further suppose that the contract thinks all prices are 1 but that 50 ETH actually trades for 49 vAfEth. Then depositing 100 ETH will convert 50 ETH to 50 safEth and 50 ETH to 49 vAfEth, which will be valued as 99 ETH. This mints 99 afEth. The balances are now 100 safEth and 99 vAfEth and the total supply is 199 afEth. Withdrawing 99 afEth converts 99/199 of the underlying, i.e. 49.749 safEth and 49.251 vAfEth, into 49.749 + 49.251/0.98 = 100.005 ETH.

Thus one can make a profit by depositing and immediately withdrawing. Immediate withdrawals are possible at the moment locks expire (and before they have been relocked), but it may be enough to just immediately request a withdrawal if the true price is the same (or better) when eventually withdrawn.

The price discrepancy will appear whenever there are price fluctuations of up to 2 % within 24 hours, which seems quite likely.

Regarding the case where the underlying is reconverging after a change of ratio it is worth noting that convergence is quite slow. Several times the entire balances must be traded before the new ratio is approached.

Recommended Mitigation Steps

I would have to think more about this.

Assessed type

Math

Lines of code

https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/strategies/votium/VotiumStrategyCore.sol#L261

Vulnerability details

Impact

A withdrawal cannot be finalised if requested at a time when AfEth had only safEth, and that owed share of safEth is permanently lost.

Proof of Concept

It is possible that AfEth holds at most dust amounts of vAfEth (if ratio = 100 %). The amounts of vAfEth and safEth to withdraw is set at the time of the request. So if a withdrawal request is placed at this time then AfEth.requestWithdraw() will call VotiumStrategy.requestWithdraw(0) AfEth.sol#L190-L193

uint256 votiumWithdrawAmount = (withdrawRatio * votiumBalance) / 1e18;
uint256 vEthWithdrawId = AbstractStrategy(vEthAddress).requestWithdraw(
    votiumWithdrawAmount
);

which naturally records a cvxOwed: 0.

When later attempting to withdraw, in VotiumStrategy.withdraw() VotiumStrategy.sol#L119-L122

uint256 cvxWithdrawAmount = withdrawIdToWithdrawRequestInfo[_withdrawId]
    .cvxOwed;

uint256 ethReceived = sellCvx(cvxWithdrawAmount);

sellCvx(0) is called.

The issue is that this attempts to VotiumStrategyCore.sol#L258-L263

ICrvEthPool(CVX_ETH_CRV_POOL_ADDRESS).exchange_underlying(
    1,
    0,
    0, //@audit dx
    0 // this is handled at the afEth level
);

which reverts as dx == 0.

Since a withdrawal request is permanent and cannot be amended the user will never be able to withdraw his safEth share.

Recommended Mitigation Steps

For gas considerations this has to be addressed by checks along the following pathway. In AfEth.requestWithdraw(), skip the call to VotiumStrategy.requestWithdraw() if votiumWithdrawAmount == 0. I don't think cvxPerVotium() can be less than 1e18, but if it can then one also has to check that cvxAmount is non-zero in VotiumStrategy.requestWithdraw() and return without placing the request in VotiumStrategy. This would place an empty request which has to not revert when later called in VotiumStrategy.withdraw().

It is of course possible to let everything run and just amend sellCvx(0) to immediately return 0.

Assessed type

Invalid Validation

Lines of code

https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/strategies/votium/VotiumStrategy.sol#L32

Vulnerability details

Impact

AfEth.deposit() may mint an incorrect amount of afEth. VotiumStrategy.price() may return an incorrect price of vAfEth. AfEth.price() may return an incorrect price of afEth.

Proof of Concept

VotiumStrategy.price()

function price() external view override returns (uint256) {
    return (cvxPerVotium() * ethPerCvx(false)) / 1e18;
}

calls ethPerCvx(false) where false implies that the Chainlink response is not validated. VotiumStrategy.price() may thus return an invalid value. VotiumStrategy.price() is used by AfEth.price() in the calculation of the price of afEth. Both of these price() are used in AfEth.deposit() to calculate the amount of afEth to mint. If the Chainlink response is invalid an incorrect amount of afEth may thus be minted, instead of reverting.

Recommended Mitigation Steps

ethPerCvx(true) is used in the far less critical AfEth.depositRewards(). It should be used here as well.

Assessed type

Invalid Validation

Lines of code

https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/AfEth.sol#L140

Vulnerability details

Impact

AfEth.price() may be calculated as too low.

Proof of Concept

AfEth.requestWithdraw() does not burn the afEth but only transfers it to itself. Hence the withdrawRatio is calculated using only the free supply of afEth: AfEth.sol#L180-L185

// ratio of afEth being withdrawn to totalSupply
// we are transfering the afEth to the contract when we requestWithdraw
// we shouldn't include that in the withdrawRatio
uint256 afEthBalance = balanceOf(address(this));
uint256 withdrawRatio = (_amount * 1e18) /
    (totalSupply() - afEthBalance);

Later the afEth is burned in withdraw() (AfEth.sol#L255).

Similar accounting is done for safEth: AfEth.sol#L195-L197

uint256 safEthBalance = safEthBalanceMinusPending();

uint256 safEthWithdrawAmount = (withdrawRatio * safEthBalance) / 1e18;

Whereas for vAfEth AfEth.sol#L191-L193

uint256 vEthWithdrawId = AbstractStrategy(vEthAddress).requestWithdraw(
    votiumWithdrawAmount
);

VotiumStrategy.requestWithdraw() just burns the vAfEth immediately (VotiumStrategy.sol#L60).

However, the AfEth.price() calculation does not use the same accounting for the effective supply of afEth: AfEth.sol#L133-L141

function price() public view returns (uint256) {
    if (totalSupply() == 0) return 1e18;
    AbstractStrategy vEthStrategy = AbstractStrategy(vEthAddress);
    uint256 safEthValueInEth = (ISafEth(SAF_ETH_ADDRESS).approxPrice(true) *
        safEthBalanceMinusPending()) / 1e18;
    uint256 vEthValueInEth = (vEthStrategy.price() *
        vEthStrategy.balanceOf(address(this))) / 1e18;
    return ((vEthValueInEth + safEthValueInEth) * 1e18) / totalSupply();
}

It uses totalSupply() instead of totalSupply() - balanceOf(address(this)). This means that with withdrawal requests outstanding the price() will be too low, and deposit() will thus mint too much afEth.

Recommended Mitigation Steps

Amending the price() calculation to use totalSupply() - balanceOf(address(this)) in the denominator would resolve this issue.

But a better solution is to just burn the afEth immediately in requestWithdraw(). Since requestWithdraw() immediately fixes the withdrawal in terms of safEth and CVX, it doesn't matter for the withdrawal when the afEth is burned.

Assessed type

ERC4626

Lines of code

https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/AfEth.sol#L183-L185

Vulnerability details

Impact

AfEth.deposit() can be bricked.

Proof of Concept

AfEth makes use of its own balance of afEth as a temporary store of afEth for withdrawal requests. On requestWithdraw() afEth is transferred to the AfEth contract and these are then burned on withdraw(). The contract's balance of afEth is excluded from the calculation of the withdrawRatio. One can thus cause the contract to withdraw all its underlying with less than its total supply. This implies a price of zero by which is divided in deposit().

1. deposit() some ETH for 2 afEth.
2. Transfer 1 afEth to the AfEth contract.
3. requestWithdraw() the remaining 1 afEth. This is precisely totalSupply() - afEthBalance in

uint256 afEthBalance = balanceOf(address(this));
uint256 withdrawRatio = (_amount * 1e18) /
    (totalSupply() - afEthBalance);

so withdrawRatio is set to 100 % and the entire safEth and vAfEth balances are withdrawn. The request may or may not be finalised by withdraw(); the withdrawals are still implicit in the accounting. Only the 1 afEth transferred with the withdrawal request would be burned; the totalSupply() still carries the 1 afEth transferred directly to the contract.

Now price()

function price() public view returns (uint256) {
    if (totalSupply() == 0) return 1e18;
    AbstractStrategy vEthStrategy = AbstractStrategy(vEthAddress);
    uint256 safEthValueInEth = (ISafEth(SAF_ETH_ADDRESS).approxPrice(true) *
        safEthBalanceMinusPending()) / 1e18;
    uint256 vEthValueInEth = (vEthStrategy.price() *
        vEthStrategy.balanceOf(address(this))) / 1e18;
    return ((vEthValueInEth + safEthValueInEth) * 1e18) / totalSupply();
}

returns 0.

This causes deposit() to revert at uint256 amountToMint = totalValue / priceBeforeDeposit;.

deposit() is the only intended way to bring the safEth and vAfEth balances to non-zero so the only way out would be to send safEth or vAfEth directly to the contract. But all this would of course be claimable by the very next deposit, and so we return to the same state. The contract is effectively bricked.

Recommended Mitigation Steps

The afEth transferred by requestWithdraw() could be specifically accounted instead of just using the contract balance.

But a better solution is to just burn the afEth immediately in requestWithdraw(). Since requestWithdraw() immediately fixes the withdrawal in terms of safEth and CVX, it doesn't matter for the withdrawal when the afEth is burned.

Assessed type

ERC4626

Lines of code

https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/strategies/votium/VotiumStrategyCore.sol#L239 https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/strategies/votium/VotiumStrategyCore.sol#L272

Vulnerability details

Impact

Rewards deposit is not slippage protected and susceptible to MEV-attacks.

Proof of Concept

VotiumCoreStrategy.buyCvx() is not slippage protected, as even acknowledged by the comment in

ICrvEthPool(CVX_ETH_CRV_POOL_ADDRESS).exchange_underlying{
    value: _ethAmountIn
}(
    0,
    1,
    _ethAmountIn,
    0 // this is handled at the afEth level
);

This is handled at the afEth level only for deposits (when it is called via VotiumStrategy.deposit() by AfEth.deposit() which has a _minout), but NOT for rewards deposits.

Rewards are initiated by VotiumStrategyCore.applyRewards() which calls VotiumStrategyCore.depositRewards() either directly or via AfEth.depositRewards(). VotiumStrategyCore.depositRewards() then buyCvx(). None of these functions has a _minout or similar for slippage protection (it is sufficient to note that applyRewards() doesn't have such a parameter).

Recommended Mitigation Steps

Add a if (ethReceived < _minout) revert BelowMinOut() slippage protection in VotiumStrategyCore.applyRewards().

Assessed type

MEV

Lines of code

https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/strategies/votium/VotiumStrategyCore.sol#L287-L290

Vulnerability details

Description

VotiumStrategyCore.applyRewards() gives unlimited allowance on its claimed rewards tokens. It is not thereafter reset and there is not even any way to reset the allowance. It is dangerous to trust the spenders indefinitely in case they are compromised or otherwise turns undesirable.

Recommended Mitigation Steps

Reset the allowance to 0 at the end of applyRewards().

Assessed type

ERC20

Lines of code

https://github.com/code-423n4/2023-09-asymmetry/blob/6b4867491350f8327d0ac4f496f263642cf3c1be/contracts/strategies/votium/VotiumStrategy.sol#L78

Vulnerability details

Impact

A user might be given an unnecessarily late withdrawal epoch. VotiumStrategy.requestWithdraw() might revert altogether.

Proof of Concept

VotiumStrategy.requestWithdraw() finds the epoch at which withdrawal is possible by the following logic:

(
    ,
    uint256 unlockable,
    ,
    ILockedCvx.LockedBalance[] memory lockedBalances
) = ILockedCvx(VLCVX_ADDRESS).lockedBalances(address(this));
uint256 cvxAmount = (_amount * _priceInCvx) / 1e18;
cvxUnlockObligations += cvxAmount;

uint256 totalLockedBalancePlusUnlockable = unlockable +
    IERC20(CVX_ADDRESS).balanceOf(address(this));

for (uint256 i = 0; i < lockedBalances.length; i++) {
    totalLockedBalancePlusUnlockable += lockedBalances[i].amount;
    // we found the epoch at which there is enough to unlock this position
    if (totalLockedBalancePlusUnlockable >= cvxUnlockObligations) {
        /*
        Withdraw epoch set to the unlock time of lockedBalances[i].
        */
    }
}
// should never get here
revert InvalidLockedAmount();

This fails to account for when totalLockedBalancePlusUnlockable is sufficient for immediate withdrawal (before the for-loop), and at best sets it to the epoch of the first locked balance. Withdrawal which should be possible immediately is thus artificially given an extended lock time. If all locks have expired then lockedBalances is a zero-length array and the for-loop is skipped and it reaches revert InvalidLockedAmount().

Recommended Mitigation Steps

Check whether totalLockedBalancePlusUnlockable >= cvxUnlockObligations before adding any lockedBalances[i].amount and set the withdrawal to the current epoch or immediately effectuate a withdrawal.

Assessed type

Invalid Validation

[L-01] Dust loss

Dust may be lost in AfEth.deposit() by calculating uint256 sValue = (amount * ratio) / 1e18; and then uint256 vValue = (amount * (1e18 - ratio)) / 1e18;. The second should instead be calculated as uint256 vValue = amount - sValue;. This is also cheaper.

[L-02] Division before multiplication

AfEth.price() loses some precision in the form of (a/k + b/k)*k <= a + b. Refactor:

function price() public view returns (uint256) {
    if (totalSupply() == 0) return 1e18;
    AbstractStrategy vEthStrategy = AbstractStrategy(vEthAddress);
    uint256 safEthValueInEth = (ISafEth(SAF_ETH_ADDRESS).approxPrice(true) *
-        safEthBalanceMinusPending()) / 1e18;
+        safEthBalanceMinusPending());
    uint256 vEthValueInEth = (vEthStrategy.price() *
-        vEthStrategy.balanceOf(address(this))) / 1e18;
+        vEthStrategy.balanceOf(address(this)));
-    return ((vEthValueInEth + safEthValueInEth) * 1e18) / totalSupply();
+    return (vEthValueInEth + safEthValueInEth) / totalSupply();
}

[L-03] Missing zero-address check for manager in VotiumStrategyCore.initialize()

manager is initialised without any check. Unlike for other initialised values there is no function to later change/set manager.

[L-04] Unsafe setRatio()

ratio > 1e18 breaks deposit(). AfEth.setRatio(_newRatio) should check that _newRatio <= 1e18.

[L-05] AfEth.canWithdraw() does not consider pauseWithdraw

AfEth.canWithdraw() is inconsistent with pauseWithdraw which is checked in AfEth.withdraw(). This is the only place where it is internally used, so it may just be inlined instead. If this function still needs external visibility it should be amended to also check pauseWithdraw itself.

[L-06] VotiumStrategy.canWithdraw() returns true for non-existent withdraw requests

VotiumStrategy.canWithdraw() should return false when withdrawIdToWithdrawRequestInfo[_withdrawId].epoch == 0 which means that there is no withdraw request with that id.

[L-07] VotiumStrategy deposits and withdrawals are not slippage protected

Rather slippage is handled by AfEth.deposit() and by AfEth.withdraw(). VotiumStrategy() can be deposited into and withdrawn from directly. If this is not the intention consider preventing user mistakes by restricting calls to AfEth, or, if VotiumStrategy() ever is to be accessed directly, add a slippage protection.

[L-08] depositRewards(_amount) do not check that _amount == msg.value

This goes for both AfEth.depositRewards() and VotiumStrategyCore.depositRewards(). Any discrepancy would be lost. AfEth.depositRewards() is called only by VotiumStrategyCore.applyRewards() (and may therefore be changed to external), whereas VotiumStrategyCore.depositRewards() is called either by VotiumStrategyCore.applyRewards() or by AfEth.depositRewards(). VotiumStrategyCore.applyRewards() is not payable but obtains ether by itself. VotiumStrategyCore.depositRewards() can therefore not check msg.value in the case it is used internally. It can be checked when called by AfEth.depositRewards(), and AfEth.depositRewards() can be checked in any case. Consider checking that _amount == msg.value when possible or restricting the call flow. Alternatively, use msg.value or address(this).balance, whichever is applicable.

[L-09] No way to retrieve stuck ether

VotiumStrategyCore has a withdrawStuckTokens(), but no function to unstuck ether. Nor does AfEth. Both have receive() external payable {}. Consider implementing functions to retrieve stuck ether.

[N-01] Comment errors

The comment Sets the target ratio of safEth to votium. is misleading. The ratio is not "safEth to votium" i.e. safEth/votium, but safEth to total balances, i.e. safEth/(safEth + votium).

VotiumStrategy.requestWithdraw() does not burn afEth tokens as stated in a notice. It burns its own vAfEth tokens. The afEth tokens are burned in AfEth.withdraw().

cvxPerVotium returns the price of CVX per vAfEth, not per afEth as stated in the comments.

[N-02] Typos

transfering -> transferring equivilent -> equivalent

Use try-catch instead of retrieving check-value

In `VotiumStrategy.relock()``

(, uint256 unlockable, , ) = ILockedCvx(VLCVX_ADDRESS).lockedBalances(
    address(this)
);
if (unlockable > 0)
    ILockedCvx(VLCVX_ADDRESS).processExpiredLocks(false);

unlockable is retrieved simply to avoid calling processExpiredLocks, which reverts if there are no expired locks. lockedBalances() is not a trival function and can be avoided here by just putting processExpiredLocks() in a try-catch instead.

Use VotiumStrategy.withdrawTime() in VotiumStrategy.requestWithdraw() instead of identical inline code

VotiumStrategy.requestWithdraw() performs the exact same calculation as VotiumStrategy.withdrawTime() to find the epoch at which there is enough to unlock this position. withdrawTime() can be reused in requestWithdraw() for finding the lockedBalances[i].unlockTime. The other calculations do not have to be performed in the loop, and withdrawTime() has the same revert condition. Note that cvxUnlockObligations += cvxAmount; would have to be performed after withdrawTime().

Refactor if-statement

In VotiumStrategy.relock()

uint256 cvxAmountToRelock = cvxBalance > cvxUnlockObligations
    ? cvxBalance - cvxUnlockObligations
    : 0;
if (cvxAmountToRelock > 0) {
    IERC20(CVX_ADDRESS).approve(VLCVX_ADDRESS, cvxAmountToRelock);
    ILockedCvx(VLCVX_ADDRESS).lock(address(this), cvxAmountToRelock, 0);
}

can be refactored into

if (cvxBalance > cvxUnlockObligations) {
    uint256 cvxAmountToRelock = cvxBalance - cvxUnlockObligations;
    IERC20(CVX_ADDRESS).approve(VLCVX_ADDRESS, cvxAmountToRelock);
    ILockedCvx(VLCVX_ADDRESS).lock(address(this), cvxAmountToRelock, 0);
}

ratio, then remainder

uint256 vValue = (amount * (1e18 - ratio)) / 1e18;, can be calculated as uint256 vValue = amount - sValue;, where uint256 sValue = (amount * ratio) / 1e18;. This is also prevents dust loss.

Centralisation risks

Deposits and withdrawals to AfEth can be independently paused by the owner. Especially pausing withdrawals could be leveraged to harm users. The protocol fee can be set up to 100 % by the owner, which combined with paused withdrawals effectively steals the users stake. The owner could also just steal all CVX, or any other reward tokens, from VotiumStrategy by using withdrawStuckTokens(). The rewarder can also exploit applyRewards() to give anyone unlimited allowance on any of VotiumStrategy's tokens.

Ratio mechanism

The ratio can be freely set by the owner (even to > 100 % such that it causes deposits to revert). The ratio between the held safEth and vAfEth is adjusted by depositing in the set ratio. Withdrawals are done in proportion to whatever the balances are. Only the rewards adjusts the balances actively towards the intended ratio by depositing only on the side where there is a shortage. The rewards are relatively small compared to the balances however. This means that the balance ratio will converge approximately exponentially but quite slowly. Several times the balances have to be deposited and withdrawn in order to reach close to the new ratio.

Tokenisation of underlying assets

Several issues were found related to how AfEth exchanges its afEth for its underlying safEth and vAfEth. A complicating factor is that unlike a vault with only one asset, this one has two. That means that afEth cannot simply represent a direct share of its underlying, but there must be an intermediary valuation by which they can be measured together. Here their estimated values in ETH is used. An issue arises from this when the estimated value is not the same as the effective value when actually deposited or withdrawn.

Time spent:

40 hours