xERC4626 support

[dimpar]

xERC4626 adds support for rewards (yield) distribution gradually over the rewards cycle length period.

[netlify]

‼️ Deploy request for acre-dapp-testnet rejected.

Learn more in the Netlify docs →

Name	Link
🔨 Latest commit	668f5fc

[nkuba]

For each deposit, mint, redeem, and withdraw we should add checks that storedTotalAssets values got updated, to confirm that beforeWithdraw and afterDeposit were called correctly.

[dimpar]

storedTotalAssets is an internal var that is checked through the public functions. If you comment out the code inside of beforeWithdraw and afterDeposit 20 out of 44 tests in stBTC will fail (as of writing this comment). These failed tests touch deposit, withdraw, mint, and redeem. I think it's a good check that storedTotalAssets is being updated.

[nkuba]

The tests check indirectly the storedTotalAssets being updated by checking totalAssets().

I don't want to block this PR, but when working on further updates to xERC4626 and Allocator assets tracking we should revisit this discussion.

[nkuba]

Since we want to simulate a deposit here we should switch to use the exact way the deposit is being made. The previous solution was simplification, minting tokens directly to stBTC contract, but it no longer work with how total assets are calculated in xERC4626.

I propose we update these two lines:

Suggested change

	await tbtc.mint(await stbtc.getAddress(), currentTotalAssets)
	await syncRewards(1n)
	await simulateDeposit(currentTotalAssets)

And replace syncRewards helper function with simulateDeposit:

  async function simulateDeposit(amountToDeposit: bigint) {
    await tbtc.mint(await thirdParty.getAddress(), amountToDeposit)
    await tbtc
      .connect(thirdParty)
      .approve(await stbtc.getAddress(), amountToDeposit)
    await stbtc
      .connect(thirdParty)
      .deposit(amountToDeposit, await thirdParty.getAddress())
  }

[dimpar]

2e45867

[nkuba]

For approximate values, we could use chai's closeTo function, since it expects exact values as delta we could define a helper function:

function expectCloseTo(actual: bigint, expected: bigint, deltaPercentage = 1) {
  return expect(actual).to.be.closeTo(
    actual,
    (expected * BigInt(deltaPercentage)) / 100n,
  )
}

and use it in tests:

Suggested change

	// check approximate value +1%
	expect(await stbtc.totalAssets()).to.be.lt(
	((actualDepositAmount1 +
	actualDepositAmount2 +
	earnedYield / 2n) *
	101n) /
	100n,
	)
	// check approximate value -1%
	expect(await stbtc.totalAssets()).to.be.gt(
	((actualDepositAmount1 +
	actualDepositAmount2 +
	earnedYield / 2n) *
	99n) /
	100n,
	)
	expectCloseTo(
	await stbtc.totalAssets(),
	actualDepositAmount1 +
	actualDepositAmount2 +
	earnedYield / 2n),
	)

[dimpar]

Sure, I knew it has to exist such function, but couldn't find it and that's why I implemented it myself. Changed in 1650a42

[nkuba]

Since this function not only calls the syncRewards but also progresses the next cycle maybe we could rename it to something like syncAndReleaseRewards?

Another idea I had is to replace the interval divisor with percentage progress, so instead of using 2n divisor we would use 50, and instead of 1n we would use 100:

Suggested change

	async function syncRewards(intervalDivisor: bigint) {
	// sync rewards
	await stbtc.syncRewards()
	const blockTimestamp = BigInt(await time.latest())
	const rewardsCycleEnd = await stbtc.rewardsCycleEnd()
	await time.setNextBlockTimestamp(
	blockTimestamp + (rewardsCycleEnd - blockTimestamp) / intervalDivisor,
	)
	await mine(1)
	}
	async function syncAndReleaseRewards(nextCycleProgress: number) {
	// sync rewards
	await stbtc.syncRewards()
	// progress the next cycle to release rewards
	if (nextCycleProgress > 0) {
	const blockTimestamp = BigInt(await time.latest())
	const rewardsCycleEnd = await stbtc.rewardsCycleEnd()
	await time.setNextBlockTimestamp(
	blockTimestamp +
	((rewardsCycleEnd - blockTimestamp) * BigInt(nextCycleProgress)) /
	100n,
	)
	await mine(1)
	}
	}

[dimpar]

1650a42

[nkuba]

We're not introducing this feature.