Contract Level

Thank you @chainlink for awarding YieldCoin the grand prize in the Chromion hackathon! We all know the entire world is going to run on Chainlink, so this is a great honor, and (was) a personal life goal. Thank you @CyfrinUpdraft for the resources to learn invariant testing, formal verification, and the security first approach! Thank you @concero_io for inspiring the idea, Parent-Child architecture, and custom CCIP tx types! Thank you everyone for the support! YieldCoin development continues alongside researching a proposal for the vLEI hackathon, Contract Level Identity (name pending review): A Decentralized Fuzzy Extractor, to address the critical need for absolute sybil-resistance by consensus - an inherent requirement for onchain identity and compliance. Read the YieldCoin dev notes taken during the hackathon here: @contractlevel/dev-notes-yieldcoin-chromion-hackathon-26685753741c" target="_blank" rel="nofollow noopener">medium.com/@contractlevel…

@AscendFi ACE + ERC3643 👍

Exactly why we've chosen to be powered by Chainlink, and built upon the identity-aware ERC-3643 token standard.

Can you spot the gas optimization in the Yieldcoin v2 rebalance initiation?

Thank you @cyfrin aderyn for flagging what AI missed

Now I am become gas king

Current state of Yieldcoin v2 development: There are no remaining flagged-for-review comments in the Yieldcoin v2 evm production code. Gas optimization sessions continue and have most recently exposed redundant sstores for local Parent rebalances. See the fix here: github.com/contractlevel/… Documentation in progress too and aims to be comprehensive without duplication, and accommodating to different audiences (auditors/security researchers, users, operator, contributors). Mutation tests not started. Certora monthly limit resets in less than 3 weeks. All specs will need to be revisited due to refactoring. Morpho adapter deferred in favour of prioritizing audit-ready MVP.

github.com/contractlevel/… gm to everyone who cleans

github.com/contractlevel/… Expanding the Yieldcoin v2 documentation. WIP docs contains: - README.md - USER_GUIDE.md - concepts/ - operator/ - protocol/ - security/ - test/ concepts covers rebalance, epoch, recovery and yieldcoin share token operator covers deployment, compliance, upgrades, monitoring, ir protocol covers the architecture, paths, design decisions security covers known issues, threat model, invariants, access control matrix test covers various commands and tools used

@alexvanderzon Aave's fixed-rate as a base yield would be awesome. 2step withdrawals 🤔

Earn every second ⏱️ Powered by aave.com/stable-vaults

@chainlink gas optimization vs compliance in depth either way it needs to be well documented

Interesting optimization found in Yieldcoin v2: - @chainlink ACE runPolicy enforces KYC and frozen status checks - happens at both the vault and token level - some vault functions call token functions - policy checks are run twice instinct says to leave it for simplicity

github.com/contractlevel/… gm to everyone optimizing checks and sloads

github.com/contractlevel/… working through known issues and general cleaning - all adapters now check that the underlying asset for the adapter/vault matches the one configured for the protocol correct supply amount for deposits also checked

github.com/contractlevel/… documenting a known issue feels a bit like cheating but there are some edgecases that are so practically/operationally infeasible and/or the impact is negligible that extra logic to address is unwarranted KI-010: Bootstrap price-per-share ignores residual TVL when total shares return to zero when the share price is calculated, if the total shares is 0 (as is the case for the first epoch), the price is assigned to i_sharePrecision (WAD_PRECISION / i_assetPrecision) i_assetPrecision is underlying asset.decimals ** 10, so for $usdc it's 1e6, and sharePrecision is 1e12 operationally, this is entirely mitigated by an admin deposit at launch with shares sent to an unretrievable burn contract without that mitigation, the impact would be that when the vault is entirely emptied and all shares have been redeemed, the next user to deposit would receive any residual tvl remaining. not a catastrophic loss of funds

github.com/contractlevel/… deposit intents in open epoch can be force closed by permissioned operator, returning the deposited asset to the user. this is to address the edgecase where a deposit amount ends up as 0 shares minted, which would block an epoch from closing

@aave gm to everyone building crosschain yield opportunities

Stable Vaults can operate on any chain, support any stablecoin, and plug into any strategy, including cross-chain yield opportunities and DeFi vaults. Learn more: aave.com/blog/introduci…

Introducing Stable Vaults, an all-in-one solution for embedding fixed-rate stablecoin yield into any financial product.

Check coverage after AI refactors even though entire test suite is passing, there is now redundant code lingering

Turns out a variation of the donation-inflation-attack *is* possible against Yieldcoin v2. A month or so ago when I rejected explicit permissionless donate() on the basis of not allowing settlement math manipulation, I thought this was a non-issue. I overlooked Aave and Compound logic that allows someone to supply on behalf of another address, ie a Yieldcoin v2 ProtocolAdapter, that in AaveV3's case, uses aToken.balanceOf as part of the TVL calculation. Settlement works like this: - CRE workflow reads TVL from active strategy chain - reports it to parent chain - closes current epoch - calculates share price from reported TVL and totalShares - settles intents against calculated price An attacker can increase the TVL by supplying directly to a strategy protocol on behalf of the ProtocolAdapter. This is similar to the LazySummer and Euler exploits, however is mitigated by the crosschain epoch architecture. Those exploits used flash loans, settling attack txes atomically. Yieldcoin v2's crosschain epoch and claims design means flash loans can't be used against the protocol in this way. If an attacker increases the Yieldcoin v2 TVL like this, they lose whatever money they supplied, making the attack economically irrational. Their money is lost and goes to the protocol/users. Settlement is only negatively impacted if the amount supplied is orders of magnitude larger than the current TVL, meaning the risk is only really meaningful at low TVL. (AFAIK) A monitoring service could detect anomalous increases in TVL / third party supplies on behalf of system ProtocolAdapters, then pause/delay CRE workflow execution, until the surplus has been calculated to not negatively impact settlement (in which case, free money from the attacker), or otherwise removed by the protocol operator. Extra state logic could be added to distinguish legitimate value vs attacker donations, but I don't think the complexity and potential bugs that would introduce would be better than the current mitigations. This edgecase is a known issue and likely the top thing I'd discuss with auditors. To summarize, it is mitigated by: - being economically irrational - crosschain epoch and claims architecture - monitoring and circuit breakers Documented as a known issue here: #ki-008--strategy-tvl-can-include-permissionless-third-party-supplies" target="_blank" rel="nofollow noopener">github.com/contractlevel/…

These reports link to the prover runs

@DYBL77 trying to do something with the certora autoprover and the properties in this paper would be interesting

@DYBL77 your idea made me look up "modular game theory" and this paper was first result: web.stanford.edu/~jdlevin/Econ%… (I only read the abstract) grok describes what you're doing as "essentially building a library of trust primitives"

Hitting Certora monthly limit for the first time has thrown a real spanner in the works Moving onto gas optimizations, non-certora mutation tests, documentation, and touching grass for a few weeks before configuring more-resource-sensible invariants So much for audit-ready by end of july 😑