Stories by Contract Level on Medium

Compliance at the Contract Level: Building with Chainlink ACE

Contract Level — Tue, 19 May 2026 13:43:38 GMT

This article covers how Yieldcoin v2 integrates Chainlink ACE, what the architecture looks like and the non-obvious problems I ran into.

Yieldcoin v2 is a compliance-ready, crosschain yield optimizer built entirely on the Chainlink stack. ACE handles contract level compliance enforcement: user operations are checked against a KYC provider through a modular policy engine before any vault or token logic executes.

How runPolicy Works

Users interact with the Yieldcoin v2 system via the ParentVault, which inherits PolicyProtected and receives a PolicyEngine in its constructor. Every user-facing function implements the runPolicy modifier:

function deposit(uint256 amount) external runPolicy returns (...)
function withdraw(uint256 shareBurnAmount) external runPolicy returns (...)
function claimShares(uint256 epochNonce) external runPolicy returns (...)
function claimUsdc(uint256 epochNonce) external runPolicy returns (...)
function cancelDeposit() external runPolicy
function cancelWithdraw() external runPolicy

The vault’s function bodies encode no compliance rules. Policy logic exists outside the contract entirely, wired at deploy time by attaching policies to each function selector:

policyEngine.setExtractors(selectors, address(senderExtractor));

policyEngine.addPolicy(address(parentVault), selector, address(kycPolicy), senderParameter);
policyEngine.addPolicy(address(parentVault), selector, address(terminalAllow), noParameters);

The full execution path for a deposit looks like this:

user -> ParentVault.deposit(...)
     -> runPolicy // modifier fires before function body
     -> PolicyEngine
     -> SenderExtractor      // extracts msg.sender as "sender"
     -> CredentialRegistryIdentityValidatorPolicy  // validates KYC
     -> TerminalAllowPolicy   // returns Allowed
     -> // vault body executes

When an ACE policy contract runs, it can resolve in one of three ways:

Revert — Immediately blocks the transaction from executing
Continue — The check passed, but the final execution decision is deferred
Allowed — The transaction is approved to execute, and any remaining policies in the stack are skipped

The KYC policy returns Continue, not Allowed. The PolicyEngine is initialized with defaultAllow = false, which means that a policy chain that ends with Continue rejects the transaction, rather than silently permitting.

TerminalAllowPolicy is the explicit resolution at the end of every Yieldcoin policy chain. It returns Allowed, which is what actually permits execution. Its terminal position is not optional: placed earlier, it would allow execution and skip every subsequent check.

The Credential Model

Offchain, the user completes KYC with a registered provider. Onchain, that provider writes to two registries:

IdentityRegistry: maps address → CCID
CredentialRegistry: maps CCID → a credential type

A CCID is a bytes32 identifier created by the identity provider, unique to the user. The credential type is keccak256(“common.kyc”).

The credential requirements are configured with the type, both registries and a data validator:

sources[0] = ICredentialRequirements.CredentialSourceInput({
            credentialTypeId: keccak256("common.kyc"),
            identityRegistry: address(identityRegistry),
            credentialRegistry: address(credentialRegistry),
            dataValidator: address(0)
        });

Setting dataValidator to address(0) configures ACE to check credential existence and validity, not metadata. Richer validation such as jurisdiction class or accreditation status can be added later by wiring in a data validator without touching the vault or token contracts.

The registries are PolicyProtectedUpgradeable contracts attached to the PolicyEngine. The KYC provider is authorized to write to the registries by the protocol operator, via the OnlyAuthorizedSenderPolicy. Adding and removing providers is a configuration change, not a deployment one.

Token-Level Compliance

The Yieldcoin v2 share token extends ACE’s ComplianceTokenERC3643. Policies are attached to token operations at deploy time: transfer, transferFrom, batchTransfer, approve, increaseAllowance, and decreaseAllowance.

A single address check is not enough for token compliance. I wrote a custom extractor that builds an address list per operation, and a custom policy that checks every address in that list:

transfer: checks caller and recipient
transferFrom: checks caller, from, and to
batchTransfer: checks caller and every recipient
approve: checks caller and spender
increaseAllowance: checks caller and spender
decreaseAllowance: checks caller only

That last one is deliberate. If a user has approved a spender and that spender later loses KYC, the user should still be able to reduce or revoke the allowance. Checking the spender on decreaseAllowance would trap users with live allowances to addresses that can no longer interact with the token.

Building Custom ACE Components

ACE policies do not automatically know which addresses in a function call should be compliance checked. The PolicyEngine receives the target contract, selector, caller, calldata, and context, but each policy needs named parameters in the shape it expects. Extractors are the adapter layer between calldata and policy inputs.

For Yieldcoin v2 I wrote three custom components: SenderExtractor, YieldcoinShareKycExtractor, and CredentialRegistryAccountListValidatorPolicy.

SenderExtractor

For every user-facing function on ParentVault, the only address that needs checking is the caller. SenderExtractor exposes payload.sender as a named ACE parameter so the PolicyEngine can map it into the KYC policy:

policyEngine.setExtractors(selectors, address(senderExtractor));

senderParameter[0] = senderExtractor.PARAM_SENDER();
policyEngine.addPolicy(
    address(parentVault),
    selectors[i],
    address(kycPolicy),
    senderParameter
);

The address passed to the policy is payload.sender — the external caller, not something decoded from the vault’s own calldata.

YieldcoinShareKycExtractor

For the token, compliance subjects are not only the caller. YieldcoinShareKycExtractor decodes the calldata by selector and builds an address[] called kycAccounts. Every address must pass KYC for that operation. If the extractor only surfaced payload.sender, an approved user could transfer to a non-KYC recipient or approve a non-KYC spender.

CredentialRegistryAccountListValidatorPolicy

Chainlink’s standard CredentialRegistryIdentityValidatorPolicy validates one address. For the token, where a single call can involve multiple parties, that’s not enough.

CredentialRegistryAccountListValidatorPolicy accepts kycAccounts = abi.encode(address[]) and loops over every address:

for each account in kycAccounts:
    validate(account, context)
    if false -> revert PolicyRejected
return Continue

The vault uses SenderExtractor with the standard single-account validator. The token uses the YieldcoinShareKycExtractor and list validator.

The Access Control Problem Nobody Warns You About

I wrote a full access control matrix before finalizing roles at the contract level. If a change would alter the authority model, the matrix is updated first. I strongly recommend anyone integrating ACE to do the same.

The hardest part of integrating ACE was not the KYC logic. It was reconciling OpenZeppelin’s AccessControlDefaultAdminRules (role checks at the modifier) with ACE’s RoleBasedAccessControlPolicy (same concept, but running as a policy through the policy engine).

My solution was a clear primary division: OpenZeppelin roles control vault and module administration; ACE policies control compliance checks and token and registry permissions.

ACE also governs some administrative token operations like attachPolicyEngine and setCCIPAdmin, a consequence of ComplianceTokenERC3643 inheritance, which prevented some functions from being overridden.

Not a perfect separation, but a legible one.

The rules that came out of this:

DEFAULT_ADMIN_ROLE grants and revokes roles, with direct operational functions avoided where possible
ACE policy stacks and configuration are administered through the PolicyEngine
PolicyEngine.ADMIN_ROLE wires policy stacks; PolicyEngine.POLICY_CONFIG_ADMIN_ROLE configures policy internals
Compliance operation is not policy administration; COMPLIANCE_OPERATOR_ROLE can freeze an address, not rewire the policy stack

One asymmetry worth noting: AccessControlDefaultAdminRules imposes stricter guardrails on DEFAULT_ADMIN_ROLE: two-step transfer, optional timelock, additional transfer constraints. PolicyEngine has none of these. The vault’s default admin is more secure out of the box than the PolicyEngine’s. The protocol operator must compensate for that at the operational level by ensuring PolicyEngine admin roles are held by appropriately hardened multisigs.

A Practical Note on Compilation

ACE’s CredentialRegistryIdentityValidator requires via_ir = true in foundry.toml due to stack-too-deep errors. Any policy that inherits from it inherits that requirement. Therefore Yieldcoin v2 uses via_ir = true, which meaningfully slows compilation and test runs.

A Note on Chainlink ACE’s Licence

Chainlink ACE is released under BSL 1.1, which restricts commercial use for a defined period. The pattern is established in DeFi. Uniswap v3 and Aave v3 both launched under BSL 1.1 before transitioning to open licences.

The practical implication: the commercial operator needs to contact Chainlink for a use grant before launch.

Yieldcoin v2 is finishing its test suite and seeking a launch partner.

If you are building in the Chainlink ecosystem and want to discuss the architecture, or if you are a protocol that needs compliance-ready yield infrastructure, I am happy to talk.

One-pager available on request.

Yieldcoin & Crosschain Race-conditions

Contract Level — Wed, 06 May 2026 10:11:51 GMT

Crosschain race-conditions have been the biggest obstacle to Yieldcoin being meaningfully production-grade. This article discusses the security rationale behind Yieldcoin’s design shift from supporting concurrent deposits and withdrawals on all chains to single-chain epoch-batching.

A crosschain race-condition refers to the scenario where state on chain A is required on chain B, but by the time it is used on B, it might be different on A.

System Model

Yieldcoin is a crosschain yield optimization protocol. Understanding the architecture is necessary context for the race-condition analysis that follows.

Chains

The system operates across two logical roles:

Parent chain — holds authoritative protocol state, including the location of the active strategy.
Active strategy chain — where protocol-managed funds are deployed into a yield-bearing protocol (Aave V3). May be the same chain as Parent or a remote chain. Changes via rebalance when a materially better yield opportunity exists elsewhere.

State

Two values underpin every share pricing calculation in the system:

totalShares — the total supply of Yieldcoin share tokens in circulation. Lives on the Parent chain.
TVL — the total value of the underlying asset deployed in the active strategy. Lives on the active strategy chain as a live balance. Never approximated or tracked on Parent (unless the Parent is the active strategy).

Message flow Pricing calculations require both values, so when the active strategy is on a remote chain from the Parent, at least one must cross a message boundary before the calculation can execute. This is the origin of the race-condition described below.

The Problem

Deposit

When a user deposits USDC into Yieldcoin, it is routed to the active yield-generating strategy. `tvlBeforeDeposit` is read from the strategy chain before depositing the user’s USDC. Assuming the active strategy is on a remote chain, either `tvlBeforeDeposit` or `totalShares` must be communicated across chains before `shareMintAmount` can be calculated.

shareMintAmount = usdcDepositAmount * totalShares / tvlBeforeDeposit

Withdraw

When a user submits their Yieldcoin share tokens to redeem USDC, `totalShares` from the Parent chain and `tvlBeforeWithdraw` from the active strategy chain must both be used alongside `shareBurnAmount` to calculate `usdcWithdrawAmount`.

usdcWithdrawAmount = shareBurnAmount * tvlBeforeWithdraw / totalShares

The race window

In both flows, one value is read locally and one must arrive from a remote chain. They can never be read atomically. Between the moment the remote value is captured and the moment the calculation executes, another operation can mutate the other value. This is the race window.

The window duration is determined by CRE hop latency — the time between a state change settling on the strategy chain and its corresponding write landing on the Parent chain. In practice, approximately 30–60 seconds per hop.

In the deposit-in-flight withdrawal case — a deposit increases TVL before the corresponding shares are minted, and a concurrent withdrawal executes against the inflated TVL — the withdrawal overpayment is:

withdrawal_overpayment_bps = (deposit_in_flight / tvl_before_deposit) * BPS_DENOMINATOR

For other race directions, such as a withdrawal reducing TVL before the corresponding shares are burned, this ratio is a useful approximation. The exact mispricing differs slightly because the calculation may use stale values in different parts of the pricing formula.

The impact is worst at low TVL. At launch, with a $1M TVL and a single $100k deposit in flight, a concurrent withdrawal can be mispriced by 1,000 bps — the withdrawer receives 10% more USDC than they are entitled to, and the depositor’s capital directly subsidizes that excess.

The Attack

The window is short but observable. A sophisticated actor (or bot) monitoring CCIP message transit can time a withdrawal to land during a large in-flight deposit’s race window.

Concrete example: TVL = $10M, totalShares = 10M. A $500k deposit has settled on the strategy chain, increasing Aave TVL to $10.5M, but the corresponding shares have not yet been minted on Parent. An attacker withdrawing 100,000 shares in this window calculates:

usdcWithdrawAmount = 100,000 * 10,500,000 / 10,000,000 = $105,000

Fair value is $100,000. The attacker extracts $5,000, paying a 10 bps withdrawal fee of $105. Net profit: $4,895 per event. At $10M TVL with large in-flight operations, this is repeatable for any actor already holding shares or able to source them temporarily, and there is no protocol mechanism to detect or prevent it.

Mitigations Considered

Serialization Gate — A global gate prevents concurrent operations for the duration of a CCIP transaction (and CRE write) — approximately 25 minutes per operation. Only one operation runs at a time. The gate opens when the CCIP leg fully settles. This eliminates the race entirely, but makes the protocol effectively unusable at any meaningful user load.

Transaction Nonces / Onchain Queue — Each operation is assigned a nonce on the Parent, with the strategy chain processing operations in strict nonce order, buffering out-of-order arrivals. This was rejected because the strategy chain would have to hold pending operations, and execute them after the correct one, placing strain on costs. This would either involve a ccipReceive tx looping through queued txes, or a CRE workflow serially draining the queue.

Per-operation Size Cap — Cap each deposit and withdrawal as a percentage of TVL. This limits worst-case mispricing per event, but does not eliminate the race. For example, a 1% deposit cap limits the deposit-in-flight withdrawal overpayment to approximately 100 bps of the withdrawal amount. With only a 10 bps withdrawal fee, this remains profitable in the adversarial case. A cap low enough to make the attack fee-negative would need to be below the withdrawal fee rate, which would severely constrain legitimate user flows. This mitigation reduces blast radius but does not solve the underlying race.

Parent-tracked TVL — Maintain a `lastKnownTVL` on the Parent chain, updated on every settlement. Would allow share calculations to read both tvl and totalShares locally and atomically on Parent, eliminating the cross-chain read pair. Rejected because the active strategy’s live balance is the authoritative TVL precisely because yield accrues there continuously. Any Parent-side TVL representation is perpetually stale between updates and contaminates the core value proposition of the protocol.

None of these fully solved the problem. Each either constrained the race, moved the complexity elsewhere, or introduced additional operational overhead.

Final Design: Epoch-Based Batch Pricing

The correct solution eliminates the race by construction rather than constraining it. Yieldcoin adopts an epoch-based batching model.

As described in the Zealynx security glossary, epoch-based batching is a settlement mechanism that collects deposit and redemption requests over a defined time period, then processes all requests simultaneously at a single price. The pattern is established in RWA protocols and traditional fund administration, where investor orders are batched and processed at daily NAV cutoffs.

Applied to Yieldcoin: users submit deposit and withdrawal intents on the Parent chain at any time during an open epoch. The underlying asset token (ie USDC) and Yieldcoin shares are escrowed locally. No crosschain activity occurs at intent submission — there is nothing to race on.

At epoch close, a single CRE workflow reads TVL from the active strategy chain and writes it to Parent. All financial calculations execute in that single Parent transaction:

pricePerShare     = tvl * SHARE_PRECISION / totalShares
totalWithdrawUSDC = totalShareBurnAmount * pricePerShare / SHARE_PRECISION
netFlow           = totalDepositAmount - totalWithdrawUSDC
newShares         = totalDepositAmount * SHARE_PRECISION / pricePerShare
s_totalShares     = totalShares + newShares - totalShareBurnAmount

The first epoch requires bootstrap handling because `totalShares == 0`. In practice, the initial deposit mints against a fixed initial share price, after which later epochs use the standard price-per-share formula.

Settlement uses a single TVL snapshot and the current Parent-chain `totalShares` in one atomic Parent-chain execution. No user operation can interleave between the price calculation, share minting, share burning, and settlement accounting. The race window does not exist.

The net flow — the difference between aggregate deposits and aggregate withdrawals — determines whether the underlying asset moves to the strategy chain for deployment into the active yield-generating protocol, or the strategy chain withdraws the asset from the active protocol and returns it to the Parent. In many epochs, deposit and withdrawal volume partially offsets, requiring only the net difference to bridge across chains. This reduces CCIP message count and cost significantly compared to per-operation routing.

Security Properties

The epoch model provides guarantees that:

No user operation prices against a live crosschain read pair. Settlement uses one TVL snapshot and the current Parent-chain `totalShares` in a single atomic Parent transaction.
No pricing advantage exists within an epoch. All participants receive identical settlement pricing regardless of when their intent was submitted.
CRE failure modes are bounded. If the settlement workflow drops, the epoch stalls. Funds are safe. No per-user flows are stuck.

The tradeoff is latency. Users submit intents and claim after settlement, rather than receiving shares or the underlying asset immediately. This is a standard model for yield products where capital is deployed across settlement cycles — the same broad pattern used by Centrifuge, Maple, and Ondo. For a protocol optimizing for security over UX immediacy, it is the correct choice.

Residual Considerations: Epoch Boundary Timing

While the epoch model eliminates all intra-epoch timing games and crosschain races by construction, participants can still optimize submission timing across epoch boundaries to minimize opportunity cost. This is standard economic behaviour in any periodic NAV settlement system — not a protocol-level exploit or source of mispricing — but is called out here for completeness.

Asset deposits and Yieldcoin shares submitted for withdrawals are escrowed on the Parent chain from intent submission until epoch settlement. Escrowed capital earns no yield. Rational actors therefore minimize idle time by submitting large intents as close to epoch close as possible.

All participants who submitted intents during the epoch — regardless of when — receive shares at the same settlement price, derived from TVL at epoch close. The late depositor’s sole advantage over an early depositor is opportunity cost.

Reduced Failure Surface

The per-user/operation architecture this new design replaces had a failure mode for every crosschain hop. Each deposit or withdrawal involved up to 4 CRE writes and a CCIP message. A failure at any transition step would have left funds for individual users stuck in an intermediate step, requiring operator identification, diagnosis, and explicit recovery. At meaningful volume, the recovery surface grows linearly with operation count.

The epoch model collapses this.

User-facing operations produce no crosschain activity — Deposit and withdrawal intents are recorded on Parent. Tokens are escrowed locally. There are no hops to fail, no intermediate states to get stuck in, and no per-user recovery paths to manage. A failed user transaction reverts cleanly on Parent. The user retries. Nothing else is affected.

Because no user operation crosses a chain boundary, there is no per-user transaction state to track. The previous v2 design required correlating individual deposit and withdrawal operations across chains — matching origin intents to strategy confirmations to share mints. That tracking infrastructure is eliminated entirely. The epoch nonce is the only identifier needed.

Crosschain activity is net flow only — Per-operation routing sent one CCIP message per deposit and one per withdrawal. The epoch model sends at most one CCIP message per epoch — the net difference between aggregate deposits and withdrawals. In epochs where flows offset, no CCIP message is sent at all. Settlement workflows are protocol-level, not user-level. If one drops, the epoch stalls and all users are affected equally — one global stuck state to recover, not one per user.

In the per-operation model, operators must distinguish between: deposit stuck pre-strategy, deposit stuck post-strategy, withdrawal stuck pre-strategy, withdrawal stuck post-strategy, CCIP message delayed, CCIP message failed, CRE execution dropped at step N of M, and combinations thereof — multiplied by every in-flight user operation.

In the epoch model, the same failure surfaces exist at the adapter and CCIP level, but they are epoch-scoped rather than user-scoped. A stuck Aave deposit or withdrawal affects the entire epoch, not a single user. Detection is simpler — one watchdog monitors one epoch state machine rather than one per user operation. Recovery targets one epoch at a time rather than an unbounded queue of individual operations.

Cost Reduction

This article has focused on the security rationale, but the operational cost reduction is substantial and worth stating explicitly.

In the per-operation model, every deposit and withdrawal involving a remote strategy chain required up to 4 CRE writes and 1 CCIP message. At any meaningful volume — say 500 deposits and 500 withdrawals per day — that is up to 4,000 CRE executions and 1,000 CCIP messages daily, each carrying gas costs on both source and destination chains.

The epoch model requires at most 2 CRE writes and 1 CCIP message per epoch settlement, regardless of how many users participated. 1,000 users settling in a single epoch costs the same as 10 users settling in that same epoch. The cost structure is flat per epoch, not linear per user.

CCIP fees in particular scale with message count. Reducing from one message per operation to one message per epoch — or zero, when deposit and withdrawal volume offsets — can represent a reduction of several orders of magnitude at scale. Those savings accrue directly to users through lower fees and to the protocol through lower operational overhead.

Introducing Yieldcoin v2

Contract Level — Fri, 17 Apr 2026 11:54:53 GMT

The original v1 codebase won the Chainlink Chromion hackathon grand prize for enabling optimal stable yield. v2 is the hardened evolution of that vision.

Architecture

Yieldcoin v1 was originally built with Chainlink Functions and Automation, which were then later replaced with a CRE workflow in place of the original logic. The workflow did some cool things like calculating APY based on onchain state, but exceeded CRE service quotas — particularly the amount of EVM reads per workflow run.

A few months ago I said to a friend “if I was going to build Yieldcoin again from scratch, I’d start with CRE”. And that’s exactly what I’ve been doing.

I started by thinking about how much of the infrastructure can actually be done in CRE, and where the contracts would fit in the peripheral. This led to failure modes between workflows.

v1 relied on optimistically successful transition steps across up to 4+ crosschain transactions in a single execution path. Any single step could fail. Any crosschain tx could fail. User funds could be left stuck in an unreachable transition state.

v2’s architectural foundation is failure mode recovery at every transition step — a baseline in the infrastructure for cleaning state and recovering funds no matter what the active step is.

There are only 3 crosschain tx types in v2 — one for each execution path type — Deposit, Withdraw, and Rebalance. v1 had roughly 3 times as many crosschain tx types as that.
There is a maximum of only a single crosschain tx executed in each execution path in v2. Similarly, v1 had roughly 3 times as many as that per path. This makes v2 faster and cheaper, without sacrificing functionality or security.

Each path type has 5 distinct (sub)paths, giving us 15 possible flows for depositing, withdrawing and rebalancing.

The Yieldcoin v2 architecture has been mapped out as comprehensively as possible over the last month before a single line of code was written. This architecture map includes paths, events, workflows, transition steps, failure modes, contracts, integrations, state space etc.

For every single transition step, we want to know:

crosschain state
where the funds are
every failure mode
recovery mechanism for each failure mode (including why, when, and by who/what)
timeout threshold
the last step
the next step

v2 explicitly tracks individual deposits, withdraws, and rebalances across chains. This is something v1 never did, and is required for v2’s recovery model.

Recovery modes are the prima materia of Yieldcoin v2.

Fees

Yieldcoin v2 introduces a fee model designed for sustainability, simplicity, and fairness to users.
v1 charged a configurable deposit fee of up to 1%, which created unnecessary admin complexity and was not sustainable at scale.
v2 removes that configurability entirely in favour of hardcoded constants, making it simpler to audit.
v2 charges two fees:

A flat fee on deposits and withdrawals, taken in USDC. This (or the aggregate of) is intended to cover the operational cost of CRE and CCIP (and possibly contribute to protocol revenue). Users pay for what they use. The decision to pass the cost of CCIP to the user via native was rejected in favour of $LINK reserves. The exact value for this flat fee is essentially a placeholder until we know how to charge more accurately for CRE.
A management fee of approximately 1% of TVL annually, collected in Yieldcoin at each rebalance, proportional to time elapsed since the previous rebalance. This is the protocol’s primary revenue stream and scales directly with TVL. It is capped at a maximum of 1% of TVL per year regardless of rebalance frequency. Users keep all of their yield — the management fee dilutes their share of TVL modestly and predictably, rather than taking a cut of their returns. At $10M TVL this generates approximately $100k annually for the protocol. The protocol is designed with fees that are transparent, hardcoded, and impossible to change.

Management fees are preferable to performance fees for both users and protocol security. For users, a performance fee requires the protocol to accurately measure individual yield earned — a complex calculation that becomes unreliable when crosschain vault shares are transferred between addresses, used as collateral in other protocols, or partially redeemed. This complexity introduces measurement risk: errors in yield calculation directly translate to users being overcharged or undercharged. A management fee requires no per-user yield tracking whatsoever. The fee is calculated solely from the total Yieldcoins across chains and time elapsed — two values that are always precisely known onchain.
From a security perspective, this means the fee mechanism has a minimal attack surface: there are no yield calculations to manipulate, no per user state to corrupt, and no edge cases around partial positions or token transfers. The simpler the mechanism, the smaller the audit surface, and the harder it is to exploit.

For comparison: Yearn historically took a 2% management fee and 20% performance fee, but in more recently deployed vaults, takes a 10% performance fee.

My only reservation with this model is potentially not generating enough revenue for an attractive-enough bug bounty.

Compliance

Yieldcoin v2 is being developed specifically to comply with the US gov’s CLARITY Act. Legislation progress is being monitored closely alongside development. The infrastructure will include modular compliance through Chainlink ACE and CCID, allowing it to stay compliant with future regulations without mutating the core infrastructure.
Yieldcoin v2’s CCID implementation will be built for full KYC with any integrateable provider.

The actual Yieldcoin (YIELD) token in v2 (a vault share token for redeeming deposits + yield) will feature the same compliance and pausable controls as the rest of the infrastructure.
The Yieldcoin (YIELD) token will comply with Chainlink’s CCT standard, but also potentially be non-transferrable. The token’s logic is being intentionally built for maximum functionality, yet (contradictorily) maximum regulatory compliance.
Chainlink provides a compliant token standard for explicitly freezing specific amounts. Integrating this directly, or taking inspiration from it, is a remaining open design question.

Legal

The v2 codebase will remain fully and explicitly unlicensed during development, has an assignment CLA for external contributors, and clean IP. This deliberate legal structure will enable maximum flexibility and value to any potential investors, launch partners, licensees etc.

Final

I am finishing a production-grade implementation of the project I started, on my own terms, to my own audit-ready standard.

A final word of thanks to George (@ygorz01) and Caducus (@chain_linkd), the external contributors to v1. George picked up Certora at an astonishing pace and wrote some truly beautiful CVL. Caducus brought exceptional understanding of Aave contracts and the kind of sharp adversarial thinking every serious project needs. I’m grateful to have worked with and learned from them both, and I look forward to seeing what they build next.

Yieldcoin v2 is being built independently by Contract Level.
Follow the progress: https://github.com/contractlevel/yield-v2

Commercial Advice for Developers

Contract Level — Wed, 15 Apr 2026 09:35:30 GMT

The most important lessons they don’t teach you in Cyfrin Updraft

Most developers encounter these issues only after they arise. What follows is practical guidance on avoiding common and costly mistakes in commercial development.

1. Understand licensing and copyright

Your code is your intellectual property by default. The moment you write it, you own it. But that protection is only as strong as your understanding of how licensing works.

Every file in your repository is making a statement about who can use your work and how. Make that statement deliberately.

SPDX-License-Identifier: MIT at the top of your Solidity files is not a neutral default. It means anyone in the world can use, copy, modify, and distribute your code freely. Think carefully before applying it to commercial work.

UNLICENSED means the opposite. No one can use your code without your explicit permission. For commercial protocol development, this is a strong default position. It means your work remains yours until you choose otherwise.

If you are working with contributors, implement a Contributor License Agreement (CLA) from the very first commit. A CLA documents that contributors grant you the rights to their contributions. Without one, every contributor to your codebase has a potential claim over their work. This can create complications later if you want to license, sell, or transfer the protocol.

Copyright and moral rights are also worth understanding. In many jurisdictions, copyright protects your code automatically. Moral rights — where they exist — protect your identity as the author. Their scope varies significantly: in the UK and EU they are relatively broad, while in the US they are limited and largely do not apply to software. Be careful about signing anything that waives moral rights in jurisdictions where they apply. Once waived, that right is gone permanently.

Finally, understand the difference between you personally and your company as a contracting party. If your company signs an IP assignment, your company’s contributions may be assigned. But IP you created personally, before any commercial arrangement existed, belongs to you personally. Your company cannot assign what it does not own.

Know what you own. Know what you give away — never let it happen by accident.

2. Do your due diligence on working relationships

If someone wants to commercialize your code or invest in your work, approach the opportunity with proper due diligence. Many opportunities are legitimate and well-structured. The goal here is simply to verify that before committing.

Is their company incorporated? In many jurisdictions, unincorporated entities cannot legally hold IP, issue equity, or enforce contracts. Checking this takes just a few minutes — review the company registry for their jurisdiction or ask to see an incorporation certificate.

Do they have prior relevant experience? A track record of completed, successful projects is different from a track record of initiated ones. Ask specifically what they have built, launched, and seen through to completion.

What is the source of their funding and how much runway do they have? Clear, verifiable funding gives confidence that the project can support the planned work. If your payments are contingent on a future raise closing, it’s important to understand that upfront.

Can they demonstrate liquidity before asking for your commitment? Reliable payment from the outset is a strong indicator of long-term stability.

Do they have signed agreements with their other contributors? If other people on the team are working informally without signed agreements, this may indicate the project is less formally structured than it appears.

What happens to your work if the company folds, pivots, or is acquired? This question is often overlooked and almost always matters. Make sure the answer is in writing before you begin.

The excitement of a compelling vision is real. Do the due diligence regardless. Ask the uncomfortable questions. The right counterparty will engage with them seriously.

3. Get your own lawyer

Your lawyer — not a shared one, and not someone introduced as “our lawyer.” If the other party refers to counsel as “our lawyer,” be aware that their lawyer’s duty is to them, not to you.

Independent legal counsel isn’t about being difficult or adversarial. It simply means you’re handling the matter professionally. A good lawyer reviewing an agreement before you sign usually costs far less than resolving issues afterward.

You don’t need a lawyer for every email. But before you sign anything that involves your IP, your equity, or your commercial future, get independent advice.

A lawyer can also confirm what you are not bound by. Sometimes that clarity is worth more than anything else.

4. Understand what you are signing — and what you are not signing

Reading a contract is not enough. You need to understand what each clause actually means and what it commits you to.

A few specific things to look for:

IP assignment clauses transfer ownership of your work to the other party. This is often buried in boilerplate. Understand exactly what is being assigned, when, and to whom. Pre-existing IP you created before the agreement should be explicitly carved out.

Moral rights waivers — where enforceable — permanently remove your right to be identified as the author of your own work. Treat this clause with the seriousness it deserves, as it can affect how your contributions are credited in the future.

Limitation of liability and indemnification are not the same thing. A limitation of liability clause caps your financial exposure if something goes wrong. An indemnification clause means the other party actively defends or compensates you against third-party claims. You want both. Many agreements only offer the first.

Non-compete clauses are often written so broadly that they prevent you from working in your own field. Take time to understand the scope, duration, and which entity would actually be able to enforce it.

Counterpart clauses state that the agreement is not effective until all parties have signed. If a counterpart clause exists and you have not signed, the agreement is not binding.

Termination clauses define how the agreement ends and what happens when it does. Understand the notice requirements, the grounds for immediate termination, and what obligations survive after the engagement ends.

Finally, confirm exactly who the contracting parties are. Whether you or your company is signing changes your obligations, and the legal status of the counterparty determines whether the agreement is enforceable at all.

Only sign once you’re clear on what each clause means. And if something is not in the document, it does not exist as a commitment.

5. Get a signed formal arrangement before writing any code

This is the most important step, but should only be followed after the previous ones. Avoid writing commercial code until you have a signed formal agreement in place. But don’t just sign anything — make sure the arrangement protects your interests and clearly reflects the terms you’ve discussed.

Do not commit to working relationships publicly without this. Do not involve other people without this.

Without a signed agreement, informal conduct, commitments, or payments can sometimes be interpreted as implying a contract on terms you never intended.

The shared excitement of building something meaningful makes it easy to move fast and skip the paperwork. In practice, a clear formal arrangement sets professional expectations and lets both sides focus on the work with greater confidence.

Final Note

Most issues in commercial development arise from unclear ownership, undefined expectations, or informal arrangements. These issues are usually avoidable with some deliberate structure and clear agreements early on.

Disclaimer: This article is not legal advice. Get your own lawyer.

vLEI Hackathon Proposal

Contract Level — Mon, 25 Aug 2025 09:23:04 GMT

This article is the proposal for Contract Level Identity: A Decentralized Fuzzy Extractor. Hackathon questions are formatted as titles/subtitles and answers are normal text.

Proposal title

Contract Level Identity

Short description

At its core, Contract Level Identity (CLID) is a Decentralized Fuzzy Extractor, to address the critical need for absolute sybil-resistance by consensus.

Here’s the current problem with identity: there is no secure and reliable way to cryptographically guarantee that an onchain tx was executed by a unique individual. To put this more in context with GLEIF: there is no guarantee that the private key controlling a credential through KERI is always used by the unique individual authorized to do so.

To really understand this problem in the simplest of terms, we must understand that identity and identification are *not* the same thing. Identity is the aggregation of all the physical bits of data about a person that makes them uniquely identifiable out of all other humans on the planet. Whereas identification is physically separate to (and derived from) identity, like a passport, SBT, driving license, social media handle, AID.
The conflation of these concepts is the cause of identity oracle attacks.

Fuzzy extractors are a cryptographic technique for deriving a key from “noisy data” like biometrics. Noisy data is data that is not exactly the same each time it is used, but close enough it can reproduce the same key. Examples of biometric data being noisy could be dust on a fingerprint scan, hair being longer/shorter, or increased wrinkles on a face as the person ages.
The fuzzy extracted key can then be used as the base private key for identity.
This process needs to be decentralized to make it securely reliable.
Users are required to scan their biometrics everytime they sign a message.

Having a system like this as the base identity layer guarantees the prevention of unauthorized credential use, and would provide regulatory compliant institutions with the foundation they need to ensure non-compliant actors are unable to participate in smart contracts on public blockchains.

1. Accelerate Mainstream Adoption of Digital Asset Infrastructure:

How vLEI can unlock institutional participation in regulated on-chain finance? Please describe your idea in terms of process, business model, technology design and architecture as well as other relevant features.

As development progresses, the exact technical implementation is subject to change.

The current thesis is as follows:
The computation for the core fuzzy extractor application runs via Multiparty Computation (MPC). An external user’s biometric data is provided to the fuzzy extractor MPC as input for enrollment. Reed-Solomon (or similar error correcting) will be applied to the noisy biometric data, and compared against all previous public enrollment helper data stored on IPFS, to check for duplicate enrollment. If the noisy input successfully decodes against any helper data, a duplicate is confirmed and enrollment is rejected. Otherwise, fresh helper data is generated and stored, enabling future duplicate rejection.

The biometric input is then used in the fuzzy extractor’s generate() function to create a reproducible key, which signs an enrollment message and produces helper data for subsequent key reproductions. The MPC outputs an attestation/signature confirming the signing key was derived from a unique human. Enrollment signatures can be used onchain to register the user with a contract (and pay a fee). Subsequent uses require reproduce(), ensuring the same individual is always present when signing.

By binding this process to vLEI credentials, financial institutions can anchor legal-entity verification (via vLEI/KERI) to biometric enforcement of “who is authorized to act.” This enables vLEI-based KYB/KYC at both the signer *and* contract level, reduces settlement risk, and ensures that tokenized securities, cross-border stablecoin/CBDC flows, DEX activity, and even custodial/non-custodial operations are always restricted to verified, compliant actors. In this way, CLID provides the missing trust/identity layer for institutional participation in regulated digital asset ecosystems.

What is the expected result from using your idea, product and/or service? If you have already achieved a result, please provide details, providing quantitative data wherever possible.

The result from this idea for GLEIF will be the prevention of unauthorized credential use through the integration of a reliable and secure identity layer.

Consider this scenario:
The private key used for controlling an AID can be given to (or stolen by) someone who is not authorized to use it. This scenario may be unlikely, but it is still a vulnerability that exists. When a vulnerability exists, it will eventually be exploited. When dealing with smart contracts, Chainlink, immutable ledgers, etc. end-to-end security is essential.
A decentralized fuzzy extracted key can NOT be given to someone else, because it can only ever be derived from a unique individual’s biometrics.

This will illustrate the foundations for “solving” identity in the age of smart contracts and AI. The philosophical implications are huge and this piece of tech is essential for smart contracts to progress to the next plateau of potentiality.

I have already confirmed that a transient key, fuzzy extracted from biometric data, can reliably control a stable, deterministic AID through KERI. (Very exciting!)

Please briefly outline the critical success factors, and steps, required to bring this idea to life, and a reasonable timeline in which this can be achieved. You may set these out in bullet point.

fuzzy extract key from noisy data — complete
control an AID through KERI with fuzzy extracted key — complete
biometric input for noisy data — complete with basic input, if there is enough time during the hackathon, will look at implementing additional biometrics
decentralize fuzzy extraction process
secure handling of fuzzy extractor helper data

These can very reasonably be achieved within the 4–5 week timeframe of the hackathon development period to demonstrate a functional MVP. Once these core requirements are achieved, the focus will shift to optimizing security, user experience, and possibly implementing “multi-factor fuzzy extraction” — which is when multiple biometric sources plus a password are used for key generation/reproduction.

What are the key benefits to the wider community if we were to go ahead to implement your proposed solution?

A base layer of identity, or “absolute sybil-resistance by consensus”, that CLID seeks to demonstrate, would enable:

voting
fairdrops
auctions
public access compliance for smart contracts (institutions would have the assurance a sanctioned or high-risk actor is not participating in the same public DeFi protocols as they are)
prevention of identity oracle attacks / sybil attacks
justification of the word “identity” in Chainlink’s CCID
securely restricted sections in next-generation/metaverse environments such as professional or NSFW settings

As a bonus, this system will also inadvertently solve the problem of society plunging into chaos from AI deepfakes and agents in the next few years, where noone can distinguish reality in the digital world. The world will need reliable cryptographic guarantees that they are interacting with a unique human, as opposed to a duplicated identity/sybil attacker or bot/AI agent.

What other companies or organizations already offer a similar solution?

Everest.org is the only thing that comes close. They use a biometric login to access their onchain wallet. They do not use a fuzzy extractor as far as I know, they use a third-party biometrics provider. https://wallet.everest.org/

Everest previously did a PoC with GLEIF: https://medium.com/about-everest-updates-and-news/everest-gleif-and-adb-to-streamline-cross-border-transactions-between-companies-80eda13fcd57

It was actually Everest that inspired this research. I previously developed an automated compliance framework for public access smart contracts with Chainlink and Everest: https://github.com/contractlevel/compliance
Unfortunately, Everest’s provision of absolutely sybil-resistant identity data to the Chainlink network was not reliable, due to their identity infrastructure not being sufficiently decentralized.

Here is an article I wrote on the topic where I first publicly considered the application of fuzzy extractors in this context: https://medium.com/coinsbench/the-problem-with-contract-level-compliance-f81528e55866

Worldcoin and Humanode also incorporate biometrics into their approaches, but neither achieve absolute sybil-resistance, and both have a history of being exploited because of this.

I also found this whitepaper on decentralized digital identity which discusses the application of fuzzy extractors: https://ceur-ws.org/Vol-3550/paper4.pdf
However their approach is also easily exploitable.

What are the key competitive advantages that your team and your proposed solution have over your competitors?

Everest is the only serious competitor, and they are not sufficiently decentralized and reliable. Everest’s identity infrastructure is also closed source, whereas Contract Level Identity will be open source.

Worldcoin has a history of being sybil-attacked where users were able to exchange their “world identities” due to their infrastructure not verifying identity for every action taken: https://www.coindesk.com/policy/2023/05/24/black-market-for-worldcoin-credentials-pops-up-in-china
https://cointelegraph.com/news/worldcoin-singapore-investigation-money-laundering-terrorism-financing
Worldcoin has questionable user data handling: https://x.com/CA_Kenya/status/1686718736940580864
Worldcoin has impractical user onboarding. They require users to sign up via one of their “orbs” — a physical device for scanning biometrics. It is unreasonable to expect people to travel to a limited location. Users should be able to enroll from their own device and location.

Humanode is the same thing. They scan a users’ biometrics once to enroll them into the system, but then never again. So you’d use a typical EOA wallet to scan your biometrics, and get approved as a “unique human” in their system. Then all it takes for an attacker to gain an advantage over this system is hire a village from the third world to sign up and then give the attacker the private keys to the EOA associated with their confirmed “uniqueness”. Humanode even goes as far as describing themselves as “not ideal” in their own marketing material: https://x.com/humanode_io/status/1919462537612976174

Another project called zkKYC has the exact same approach and problem.

The whitepaper I linked in the previous answer which discusses fuzzy extractors basically does the same thing. They suggested minting users an NFT based on fuzzy extracted data, which is completely useless because the private key holding the NFT can still be passed around to anyone in the world.

What differentiates you with your competitors? What is your unique value proposition?

Contract Level Identity’s unique value proposition is open sourcing absolute sybil-resistance by consensus. When I use the phrase “absolute sybil-resistance by consensus”, I am referring to the guaranteed impossibility of one actor in a system posing as more than that.

Where Everest fails to reliably provide absolutely sybil-resistant identity data to smart contracts, CLID will provide.

Where Worldcoin and Humanode have enabled sybil-attacks, CLID will prevent them.

Basically every so-called identity solution is exploitable because it is based around something that isn’t actually identity (except for Everest, which fails because it’s too centralized).

Please indicate any key dependencies on technical, governance or regulatory issues about which the community should be aware.

The currently identified technical limitations (which can be worked with/around for the context of a producing an MVP for the hackathon) are:

1. Secure handling of fuzzy extractor helper data. Fuzzy extractors have 2 key functions: generate() and reproduce(). Generate takes in noisy data and outputs a key and helper data. Reproduce takes noisy data and the helper data to output the same key. The helper data will need to be securely handled. The current working approach is for the user to store it safely themselves, and they are expected to provide it when they scan their biometrics to reproduce their key and sign a message. Secure alternatives for an improved user experience are being explored, such as splitting the helper data and storing its shares separately on infrastructure like IPFS. Though this would need careful consideration of the shares retrieval for the correct user.

2. The actual decentralization of the fuzzy extraction and message signing process. A lot of research time for this proposal was spent experimenting with running the fuzzy extractor logic in a Trusted Execution Environment, which would then output an attestation/signature anyone could verify. The issue with this though is TEEs are a closed box for secure execution, and the app would need to interact with IPFS for reading and storing helper data. The current working approach is to have the logic running via Multiparty Computation (MPC). Traditionally, participating parties in MPC provide input, so the current challenge is enabling an external user to securely provide input without being one of the computation running parties.

Another challenge will be handling of biometric input such that 2 persons do not reproduce the same key, whilst the noisy distance remains sufficient for a single person to reliably reproduce their own key.

Multifactor fuzzy extraction for increased security and user control will be a longterm preference.

Please indicate any specific dependencies, uncertainties or implementation risks related to GLEIF architecture or software

The only current uncertainty is insufficient familiarity with the software, though this is being improved with vLEI training resources repo. I’ve already confirmed that a transient, fuzzy extracted key can successfully control a persistent, stable AID through KERI.
The video resources were beneficial and the LLM-compatible md file of the resources was particularly helpful, so thanks for that.

Please indicate commercial benefits for your organizations and clients as well as indirect benefits to regulators, infrastructure providers or other stakeholders.

Commercial benefits include the accelerated adoption of digital assets and market infrastructure by TradFi institutions, due to a safer public regulatory environment from the (private and user-controlled) identification of public participant uniqueness.
Institutional clients would have securer access to tokenized securities, reduced settlement risk, and a superior compliant environment for stablecoin/CBDC flows, because of CLID’s inherent enforcement of arbitrary implementations at the signer level — as opposed to at the credential level.
Private bank chain liquidity could be confidently connected to public chains, knowing that none of the users in the public access system are on sanctions lists, North Korean hackers, etc

Benefits for the average retail/end user would be enabling all of the things Web3 requires identity for but currently cannot efficiently facilitate (voting, fairdrops, reputation, auctions, etc) — actual sybil-resistant smart contract systems.

An indirect benefit to regulators would be enhanced oversight, without compromising privacy. CLID would provide regulators with cryptographic proof of unique, vLEI-verified participation in public ecosystems.

Chainlink’s ACE/CCID would benefit from having a base layer of identity via CLID, and would no longer be vulnerable to identity oracle attacks.

CLID could be monetized by requiring a registration fee, or fees for subsequent reproduce() signatures.

Private key compromises is one of the single biggest attack vectors in blockchain. CLID would solve that because biometric keys cannot be compromised (with a high enough multifactor fuzzy extraction threshold).

Contract Level Identity (CLID) is a Decentralized Fuzzy Extractor currently being researched and proposed as a solution for the vLEI Hackathon.

Dev notes: YieldCoin/Chromion hackathon

Contract Level — Thu, 03 Jul 2025 19:29:49 GMT

This is not meant to be a polished article. These are the (mostly) unedited notes taken during development of YieldCoin for the Chainlink Chromion hackathon. These notes are messy, disjointed, often frustrated, and occasionally incoherent, but relatively linear.

Get interest rates

The current goal is to efficiently find the pool with the highest interest rate for USDC deposits out of Aave and Compound across Eth, Base, Arb, Opt, Polygon, maybe Avalanche.

The current approach to “getting” the chain and pool with the highest APY is to use Chainlink Functions to read either onchain data or an offchain API. Let’s try reading onchain data with CLF first. We’ll probably want to use ethers.js.

Compound v3/Comet has this getSupplyRate() function - https://docs.compound.finance/interest-rates/#get-supply-rate

Aave Getter Function: The getReserveData function, from Aave’s V3 Pool contract, returns a ReserveData struct containing the currentLiquidityRate, which is the supply interest rate for USDC pools (in ray, 10^27).

https://aave.com/docs/developers/smart-contracts/pool#view-methods-getreservedata

Contract Modules

This project is being built non-linearly. Let’s try and separate as much stuff into different inheritable contracts as possible (ie crosschain, functions, deposits/withdrawals). There will inevitably be crossover with some of this stuff.

Let’s start with Chainlink Functions. We’ll need the FunctionsClient and FunctionsRequest. Inherit FunctionsClient and set functionsRouter in constructor.

We’re going to use time based Automation to trigger the Functions call at every interval. Time based Automation is easy mode, we don’t even need performUpkeep, we can just specify any function we want to be called by the Upkeep address. It’s worth noting time based Automation isn’t called by a “Forwarder” address, but the “Upkeep” address. https://docs.chain.link/chainlink-automation/guides/forwarder#finding-the-forwarder-address

I’m not sure how realistic separating bits into different module contracts will be, given how heavily intertwined the various services will be. Let’s just continue with CLF and CLA in the same contract for now with nothing else.

Contract Modules 2

Going back to the CLF/CLA module, the _fulfillRequest is going to need to update state for the new Strategy. The s_strategy needs to contain the chainSelector (ie Arb or Eth) and the protocol (ie Aave or Compound).

If the new strategy is on a different chain (or same chain, but different protocol), then we need to send a message to the currentStrategy.chain, telling it where to move funds. If the new strategy is the same as the current, we don’t need to do anything, except maybe emit an event.

What do we need on every single YieldPeer (ie parent AND child yield contracts - the contracts on each chain that handle deposits, withdraws and rebalances)?? (The Parent is the only one with the CLF/CLA logic)

Every YieldPeer requires:

deposit(uint256 amount) function for depositing USDC
withdraw(uint256 amount) function for withdrawing USDC
immutable i_aavePool
immutable i_comet (Compound Pool)
immutable i_usdc
immutable i_thisChainSelector - does every peer really need this? or just the parent??
CCIP compatible
CCIPReceiver inherit
IRouterClient
Client
immutable i_link (each one needs to be funded with LINK too)

Does every child need certain state updates? Hopefully not, [REDACTED]

If someone deposits on a child peer, their address along with deposit amount will need to be sent to the parent? The LPCCT can be minted to them on the child chain, but all state should really be consolidated on the parent…

Does every YieldPeer need to know where the current strategy is? so that if someone deposits on the child chain where the current strategy is, it knows to deposit there?

If the LPCCT token is ERC677, then users could just transferAndCall it to the system to initiate withdrawals - instead of having to approve first. They could also transferAndCall it to the LPCCTPool to move across chains, including the chainSelector in the bytes data.

Let’s call the token SHARE or i_share for simplicity now, since it’s not exactly, strictly an LP token. Well it kind of is, but whatever.

Share Token

So the SHARE token will be a burnable and mintable ERC677, and it will be a CCT. We’re using Chainlink’s BurnMintERC677 contract which is extremely convenient because it comes with all the basic functionality we need. Thank you, Chainlink!

Let’s think about the deployment and initial setter flow.

Deploy SHARE
Deploy SharePool, passing share
Deploy YieldPeer, passing share
share.owner() grants burn and mint roles to SharePool and YieldPeer

Ok that wasn’t so complicated. This should be done in a script that’s run on each chain. It should also include setting allowed chain selectors and peers for CCIP.

// mint tokens to msg.sender based on amount and total liquidity
// do we want to update state for every yield peer? we'd have to do a for loop for ccipSend
// that'd be expensive
// the alternative is send a message to the parent contract with the amount to mint
// and get a message back which would be slow

This is the first significant development issue of this project. Due to CCIP, the first option we have is expensive operations across all peer contracts (ie updating state across ALL peers everytime someone deposits and withdraws). This would be so expensive, it’s definitely not worth it.

The second option is sending a message to parent chain to fetch state, and return it to deposit/withdrawal chain. This means users would have to wait 45 mins to get their SHARE tokens or redeem their USDC. I think this option is preferable, purely because [REDACTED]

So… someone makes a deposit or withdrawal and they have to wait for the bidirectional crosschain tx to get their respective tokens.

Contract Modules 3

YieldPeer is abstract. We inherit it in the ParentPeer and ChildPeer contracts. ParentPeer is where CLF and CLA happen. It’s also where the state of the entire crosschain system is tracked. ChildPeer is where messages get sent to ParentPeer querying and updating state. The purpose of life is to [REDACTED]. [REDACTED] modular smart contract development entertaining? I think so. [REDACTED] mission statement. Should we be storing the parent chain selector as immutable in ChildPeer? I’m not sure yet, but the answer will become clear as development progresses. Let’s update state in the ParentPeer first. We can use modular helper functions for transferring from in the abstract YieldPeer.

ParentPeer::deposit() now includes _revertIfZeroAmount(amountToDeposit) (YieldPeer helper), _updateDepositState(msg.sender, amountToDeposit) (ParentPeer, might change this to just _updateState and use a flag to indicate deposit or withdrawal later), and _transferUsdcFromMsgSender(amountToDeposit) (another YieldPeer helper).

State tracking USDC deposits and SHARE

Alright let’s think about this.

users deposit USDC and mint SHARE in return
users withdraw USDC and burn SHARE in return
SHARE is a CCT

If we are tracking user deposits in the ParentPeer, then this number will differ from the total USDC accumulated in the system because of interest accumulated. We’d track it in some state var like s_totalUsdcDeposits

Are we gonna need another state var to track total crosschain supply for SHARE? If we are burning and minting across chains, then the totalSupply won’t be accurate.

If SHAREs represent ownership of protocol funds, then we probably don’t need a mapping for user ⇒ deposit because we want them to be able to transfer their SHAREs if they want.

Maybe we should be tracking totalSharesMinted in the ParentPeer. s_totalShares will need to be updated everytime someone makes a deposit on any chain.

Ok we’ve got a big issue here. When someone deposits, they need to get minted SHAREs, right? Well the amount that they are minted needs to be proportional to the total value in the system, including accumulated interest. So when someone deposits, not only do we need to message ParentPeer (if Child) and back, but we also need to query the strategy for accumulated interest. The more you build with CCIP, the more apparent the value proposition of Concero becomes.

Let’s consider this:

total system usdc is in aave pool on chain b
user deposits USDC on chain a
ccip sends message to chain b to query amount (maybe send usdc in same tx)
ccip sends message back to chain a with amount
chain a mints user SHAREs

There will inevitably be time taken between the initial user usdc deposit and actual share mint because of ccip messages, so who will lose out on this? the new user depositing, or the rest of the SHARE holders? If it’s the rest of the SHARE holders, that’s bad. The new user would be preferable to not earn during the message times.

Maybe the user’s USDC deposit is sent to the strategy, and THEN we message back the shareMintAmount to the deposit chain.

https://docs.chain.link/ccip/tutorials/evm/usdc Good thing there’s a page in the ccip docs for transferring USDC with data to make things easier.

CCIP Tx Types 2

We will need more than just Deposit, Withdraw and Rebalance tx types. (CCIPTxType will be an enum btw). We will likely need at least DepositInitial and DepositCallback.

User deposits USDC on chain A → CcipTxType.DepositInitial

Strategy chain callsback totalValueAmount to mint SHARE → CcipTxType.DepositCallback

We might even need a third deposit type in case of:

user deposit on chain A (child)
needs to update state on chain B (parent)
needs to deposit on chain C (strategy)

Maybe we should just be minting SHAREs on parent chain

User deposits on Chain A (Child)
USDC tokenAmounts and address(user/depositor) sent to strategy — but HOW do we get the strategy chain from the child????

Are we seriously going to have to go Child → Parent → Strategy → Parent → Child??? Crosschain is so unbelievably broken. That’s 4 CCIP txs. That’s nearly 2 hours. I mean, once you’re in the system: you’re in. So there is that. This definitely incentivizes people to deposit on the Parent.

Any child or the parent can be the strategy chain.

These are the current deposit types I’m entertaining:

DepositToParent, // DepositInitialParent
 DepositToStrategy, // DepositInitialStrategy
 DepositCallbackParent,
 DepositCallbackChild,

Let’s go through them.

DepositToParent

This is when a deposit is made on the child chain and the tx needs to pass through the parent to find the strategy. We should have a flag in each child to check if that chain is the strategy.

DepositToStrategy

This is when a deposit has passed from the child to the parent to get the strategy, or the deposit is made on the parent, and the USDC is being sent to the strategy chain.

DepositCallbackParent

The USDC has been deposited in the strategy and now we are sending data back to the parent to mint SHAREs to the depositor.

DepositCallbackChild

USDC has been deposited in the strategy and state has been updated in the parent, and a final message is sent back to the user’s chain to mint their SHAREs.

Depending on which chain the user has deposited on, they will not have to experience this many crosschain txs.

But wait, what about if when we rebalance strategies we update where the new strategy is on that Peer? It won’t work because the strategy could hop between a chain of chains. ie chain A still thinks chain B is the current strat, but chain b knows it’s chain c. A flag will have to do.

What happens if someone deposits during a rebalance? Potential known issue. Let’s come back to that.

Handling Cases

We need to handle various cases for CcipTxTypes.

We have a Parent, Child and Strategy. The parent or any child can be the strategy.

We need to handle cases where deposits are made on any chain and the strategy is on any chain.

Let’s think about these cases:

Deposit made from child

parent is strategy
send usdc and depositData from child to parent strategy
deposit usdc directly into parent strategy
calculate and send shareMintAmount from parent-strategy to child
child/deposit is strategy
deposit usdc directly into this-child-strategy
ccipMessage to parent, passing amount deposited and totalValue
ccipReceive from parent, getting shareMintAmount
chain c is strategy
send usdc and depositData from child to parent
send usdc and depositData from parent to strategy (and deposit in strategy)
send totalValue and depositData from strategy to parent
send shareMintAmount from parent to child

Deposit made from parent

parent is strategy
deposit usdc directly into parent strategy
calculate shareMintAmount and mint to depositor
child is strategy
send usdc and depositData from parent to strategy-child
send totalValue and depositData from strategy to parent
calculate shareMintAmount and mint to depositor

We should probably be verifying tokenAmounts for each step.

Deposit into Aave and Compound

Aave has this:

/**
   * @notice Supplies an `amount` of underlying asset into the reserve, receiving in return overlying aTokens.
   * - E.g. User supplies 100 USDC and gets in return 100 aUSDC
   * @param asset The address of the underlying asset to supply
   * @param amount The amount to be supplied
   * @param onBehalfOf The address that will receive the aTokens, same as msg.sender if the user
   *   wants to receive them on his own wallet, or a different address if the beneficiary of aTokens
   *   is a different wallet
   * @param referralCode Code used to register the integrator originating the operation, for potential rewards.
   *   0 if the action is executed directly by the user, without any middle-man
   */
  function supply(address asset, uint256 amount, address onBehalfOf, uint16 referralCode) external;

Compound has this:

function supply(address asset, uint256 amount) external;

Ok, now how do we get the totalValue in either of these pools? aUSDC.balanceOf(address(this)) for aave? and something similar for compound?

Comet/Compound v3 has it’s own internal balanceOf() — not a receipt token like aave

/**
     * @notice Query the current positive base balance of an account or zero
     * @dev Note: uses updated interest indices to calculate
     * @param account The account whose balance to query
     * @return The present day base balance magnitude of the account, if positive
     */
    function balanceOf(address account) override public view returns (uint256) {
        (uint64 baseSupplyIndex_, ) = accruedInterestIndices(getNowInternal() - lastAccrualTime);
        int104 principal = userBasic[account].principal;
        return principal > 0 ? presentValueSupply(baseSupplyIndex_, unsigned104(principal)) : 0;
    }

HelperConfig script

Writing the deposit functions has been going well, but they have a lot of paths we need to handle correctly. Before moving on to withdraws and rebalancing, we should write some unit tests for the deposit functionality and dry them a bit.

We have to go to docs for various contract addresses for our HelperConfig (best place to start if we’re going to be writing tests, so we can just fork mainnets and we don’t have to refactor later).

https://docs.chain.link/ccip/directory/mainnet/chain/mainnet

Oh right yeah, the Aave docs says to use PoolAddressesProvider to get the pool

https://aave.com/docs/developers/smart-contracts/pool-addresses-provider

We’ll refactor our contract to use it.

https://aave.com/docs/resources/addresses

https://docs.compound.finance/ Compound addresses are here. We can see the cUSDCv3 proxy here: https://etherscan.io/address/0xc3d688B66703497DAA19211EEdff47f25384cdc3#writeProxyContract and the current implementation here: https://etherscan.io/address/0x40f6c8c12eb5009933449d6b22de094024061821#code

https://developers.circle.com/stablecoins/usdc-on-main-networks

UnsupportedDestinationChain(0) debugging

Trying to test basic deposits at the moment. Deposits are successful on the Parent when the Strategy is also on the Parent for both Aave and Compound.

Now trying to test deposit on Parent when Strategy is on Child. We currently do not have the CLF functionality setting the strategy on the parent, so we’re using a temporary setter which will later be replaced with either a wrapper or the full/simulated CLF calltrace.

Anyway the internal _setStrategy() which would be called by CLF or the temporary setter.

Well I fixed it without much to document. That’s happened more than once now, I got stuck, started noting down the process, it was an easy fix, and there was nothing much to document.

Foundry panicked and crashed… The path to forking ccipLocalSimulatorFork to work with USDC

Good god, look at this error:

The application panicked (crashed).
Message:  called `Option::unwrap()` on a `None` value
Location: /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/revm-19.7.0/src/journaled_state.rs:402

This is a bug. Consider reporting it at

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 8 frames hidden ⋮                               
   9: core::panicking::panic::h3ce9043ca357f318
      at :
  10: core::option::unwrap_failed::h84f662fc2717d129
      at :
  11: revm::journaled_state::JournaledState::checkpoint_revert::ha2372507612e4e6e
      at :
  12: core::ops::function::Fn::call::haf5c10b983b13451
      at :
  13: revm::evm::Evm::transact::h511e14095f81b969
      at :
  14: foundry_evm::executors::Executor::call_with_env::h154335a27f5af478
      at :
  15: foundry_evm::executors::Executor::call::h782f7de7b909665b
      at :
  16: core::ops::function::impls:: for &F>::call_mut::h8d82ba17ce23719f
      at :
  17: rayon::iter::plumbing::bridge_producer_consumer::helper::h9d171e5d4c76ff86
      at :
  18: forge::runner::ContractRunner::run_tests::hc7d7ccc88d63e1eb
      at :
  19: forge::multi_runner::MultiContractRunner::run_test_suite::hb4141630c8c82fc8
      at :
  20: rayon::iter::plumbing::bridge_producer_consumer::helper::hfa56bb258a9a151b
      at :
  21: forge::multi_runner::MultiContractRunner::test::h7f9aaca9b2669fcd
      at :
  22: tokio::runtime::task::raw::poll::h43285f4cb434870b
      at :
  23: std::sys::backtrace::__rust_begin_short_backtrace::h6f6727b8eb7b339b
      at :
  24: core::ops::function::FnOnce::call_once{{vtable.shim}}::hc8a24ab009e1ac94
      at :
  25: std::sys::pal::unix::thread::Thread::new::thread_start::h6d53b1b0c047a3b9
      at :
  26: __pthread_joiner_wake
      at :

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
Run with RUST_BACKTRACE=full to include source snippets.
zsh: abort      forge test --mt test_parent_deposit_strategyIsChild_aave -vvvv

Never seen that before. This is happening when trying to switch chains and route a message with the CCIP local simulator fork.

Someone else had a similar issue in 2023: https://github.com/foundry-rs/foundry/issues/4572 and it didnt receive any replies, but said it was fixed. This issue was mentioned in another issue: https://github.com/foundry-rs/foundry/issues/4586

Someone else had a similar error too: https://github.com/foundry-rs/foundry/issues/4058 looks like they were doing something with Optimism (same as us) and someone replied saying it’s probably an issue with the RPC URL. If we don’t think of something else we could try replacing the public rpc urls with alchemy ones, but I don’t think that’s our issue because that github issue explicitly mentioned missing trie node.

So great it looks like we found a bug with Foundry right when we start testing our deposits.

I tried switching the receiver chain from being opt → eth and it’s still giving the same error.

How likely is reporting this going to get it fixed before it’s too late?

I’m annoyed because it’s looking possible we won’t have the exact unit tests I was planning, which would’ve been with fully forked CCIP local simulator facilitating the whole codebase.

With Chainlink Automation anything can trigger anything. The question is how do you monetize that anything can do anything. What two things need to happen to make money?

I’ve tried using an older version of foundry. foundryup -i 1.2.0. nope still getting that same error.

I restarted Cursor and now im getting a different error. Revert] Contract 0x0000000000000000000000000000000000000000 does not exist and is not marked as persistent, see vm.makePersistent()

We just had to register some stuff with ccipLocalSimulatorFork for the networks being used.

Now we’re getting a custom error

25265] 0x5931822f394baBC2AACF4588E98FC77a9f5aa8C9::releaseOrMint(ReleaseOrMintInV1({ originalSender: 0x000000000000000000000000a8452ec99ce0c64f20701db7dd3abdb607c00496, remoteChainSelector: 4949039107694359620 [4.949e18], receiver: 0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809, amount: 1000000000 [1e9], localToken: 0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85, sourcePoolAddress: 0x0000000000000000000000009fcd83bc7f67ada1fb51a4cabea333c72b641bd1, sourcePoolData: 0x0000000000000000000000000000000000000000000000000000000000089e9e0000000000000000000000000000000000000000000000000000000000000003, offchainTokenData: 0x }))
    │   │   │   ├─ [7494] 0x55b3FCa23EdDd28b1f5B4a3C7975f63EFd2d06CE::isCursed(0x000000000000000044ae84d8e9a37444) [staticcall]
    │   │   │   │   ├─ [2429] 0x4E76D19073eF8c0CE63C2A0034e52745a94db284::isCursed(0x000000000000000044ae84d8e9a37444)
    │   │   │   │   │   └─ ← [Return] false
    │   │   │   │   └─ ← [Return] false
    │   │   │   ├─ [2922] 0x3206695CaE29952f4b0c22a169725a865bc8Ce0f::isOffRamp(4949039107694359620 [4.949e18], 0xEB3d6956BCf7b1E29634C8cd182fC9FA740Bce34) [staticcall]
    │   │   │   │   └─ ← [Return] true
    │   │   │   └─ ← [Revert] EvmError: Revert
    │   │   └─ ← [Revert] custom error 0xe1cd5509

This is a side note but I’m concerned about testing with usdc and the local simulator fork, might have to fork the local sim fork’s bnm or the other token.

Turns out this is directly related to exactly that side note. contract level intuition

0x5931822f394baBC2AACF4588E98FC77a9f5aa8C9 is the CCIP USDC Token pool contract on Optimism.

here’s the function that’s reverting

Cursor is telling me it needs some cctp message attestation which ccip local sim isn’t providing

Based on the code and error analysis, I can explain what's happening and how to fix it:
The USDC token pool on Optimism is failing because it's missing the required CCTP (Cross-Chain Transfer Protocol) message and attestation data. This data is required for USDC cross-chain transfers.
The releaseOrMint function expects two key pieces of data in the offchainTokenData parameter:
A USDC CCTP message
An attestation for that message
The message format for USDC CCTP is:
Apply to TokenPool.so...
116
The attestation is a signature that proves the message is valid and came from the source chain.
To fix this, you need to:
When sending USDC cross-chain, the source chain's USDC token pool will emit a MessageSent event with the CCTP message.
This message needs to be attested by Circle's attestation service. The service will provide a signature that proves the message is valid.
Both the message and attestation need to be passed to the destination chain's USDC token pool in the offchainTokenData parameter.
Looking at your test code in ParentDepositTest.t.sol, you're using ccipLocalSimulatorFork.switchChainAndRouteMessage(optFork) to simulate the cross-chain message. However, for USDC transfers, you need to:
Get the CCTP message from the source chain's USDC token pool
Get an attestation for that message from Circle's attestation service
Pass both to the destination chain's USDC token pool

“I’ll help you with all three steps. Let’s start by modifying the test to properly handle USDC CCTP messages and attestations.

Now we need to add the switchChainAndRouteMessageWithData function to the CCIPLocalSimulatorFork contract. Let me help you with that:”

/**
     * @notice Similar to switchChainAndRouteMessage but allows passing custom offchainTokenData
     * @param forkId The ID of the destination network fork
     * @param offchainTokenData Custom offchain token data to be passed to the offRamp
     */
    function switchChainAndRouteMessageWithData(uint256 forkId, bytes[] memory offchainTokenData) external {
        Internal.EVM2EVMMessage memory message;
        Vm.Log[] memory entries = vm.getRecordedLogs();
        uint256 length = entries.length;
        for (uint256 i; i < length; ++i) {
            if (entries[i].topics[0] == CCIPSendRequested.selector) {
                message = abi.decode(entries[i].data, (Internal.EVM2EVMMessage));
                if (!s_processedMessages[message.messageId]) {
                    s_processedMessages[message.messageId] = true;
                    break;
                }
            }
        }
        vm.selectFork(forkId);
        assertEq(vm.activeFork(), forkId);
        IRouterFork.OffRamp[] memory offRamps =
            IRouterFork(i_register.getNetworkDetails(block.chainid).routerAddress).getOffRamps();
        length = offRamps.length;
        for (uint256 i = length; i > 0; --i) {
            if (offRamps[i - 1].sourceChainSelector == message.sourceChainSelector) {
                vm.startPrank(offRamps[i - 1].offRamp);
                uint256 numberOfTokens = message.tokenAmounts.length;
                uint32[] memory tokenGasOverrides = new uint32[](numberOfTokens);
                for (uint256 j; j < numberOfTokens; ++j) {
                    tokenGasOverrides[j] = uint32(message.gasLimit);
                }
                IEVM2EVMOffRampFork(offRamps[i - 1].offRamp).executeSingleMessage(
                    message, offchainTokenData, tokenGasOverrides
                );
                vm.stopPrank();
                break;
            }
        }
    }

Ok, so it does look like we will be forking ccipLocalSimulatorFork to make it compatible with usdc.

Alright let’s take a step back from the AI for a second and just look at what we need.

This is from the USDCTokenPool natspec:

/// @dev Only supports version SUPPORTED_USDC_VERSION of the CCTP message format
  /// @dev Message format for USDC:
  ///     * Field                 Bytes      Type       Index
  ///     * version               4          uint32     0
  ///     * sourceDomain          4          uint32     4
  ///     * destinationDomain     4          uint32     8
  ///     * nonce                 8          uint64     12
  ///     * sender                32         bytes32    20
  ///     * recipient             32         bytes32    52
  ///     * destinationCaller     32         bytes32    84
  ///     * messageBody           dynamic    bytes      116

and that is going to be what is passed first here: _validateMessage(msgAndAttestation.message, sourceTokenDataPayload);

The message comes from here:

MessageAndAttestation memory msgAndAttestation =
      abi.decode(releaseOrMintIn.offchainTokenData, (MessageAndAttestation));

struct:

struct MessageAndAttestation {
    bytes message;
    bytes attestation;
  }

uh i think we can get the message directly from the logs

and then we need the attestation for this:

i_messageTransmitterProxy.receiveMessage(msgAndAttestation.message, msgAndAttestation.attestation)

CCTPMessageTransmitterProxy public immutable i_messageTransmitterProxy;

takes us here:

/// @notice Receives a message from the `IMessageTransmitter` contract and validates it.
  /// @dev Can only be called by an allowed caller to process incoming messages.
  /// @param message The payload of the message being received.
  /// @param attestation The cryptographic proof validating the message.
  /// @return success A boolean indicating if the message was successfully processed.
  function receiveMessage(bytes calldata message, bytes calldata attestation) external returns (bool success) {
    if (!s_allowedCallers.contains(msg.sender)) {
      revert Unauthorized(msg.sender);
    }
    return i_cctpTransmitter.receiveMessage(message, attestation);
  }

IMessageTransmitter public immutable i_cctpTransmitter;

ok so there’s another implementation somewhere

/// @notice Unlocks USDC tokens on the destination chain
  /// @param message The original message on the source chain
  ///     * Message format:
  ///     * Field                 Bytes      Type       Index
  ///     * version               4          uint32     0
  ///     * sourceDomain          4          uint32     4
  ///     * destinationDomain     4          uint32     8
  ///     * nonce                 8          uint64     12
  ///     * sender                32         bytes32    20
  ///     * recipient             32         bytes32    52
  ///     * destinationCaller     32         bytes32    84
  ///     * messageBody           dynamic    bytes      116
  /// param attestation A valid attestation is the concatenated 65-byte signature(s) of
  /// exactly `thresholdSignature` signatures, in increasing order of attester address.
  /// ***If the attester addresses recovered from signatures are not in increasing order,
  /// signature verification will fail.***
  /// If incorrect number of signatures or duplicate signatures are supplied,
  /// signature verification will fail.
  function receiveMessage(bytes calldata message, bytes calldata attestation) external returns (bool success);

i_messageTransmitter on optimism is https://optimistic.etherscan.io/address/0x4D41f22c5a0e5c74090899E5a8Fb597a8842b3e8

this is on circles github https://github.com/circlefin/evm-cctp-contracts/blob/6e7513cdb2bee6bb0cddf331fe972600fc5017c9/src/MessageTransmitter.sol#L250

* @param attestation Concatenated 65-byte signature(s) of `message`, in increasing order
     * of the attester address recovered from signatures.

https://github.com/circlefin/evm-cctp-contracts/blob/6e7513cdb2bee6bb0cddf331fe972600fc5017c9/src/roles/Attestable.sol#L227

* @dev Rules for valid attestation:
     * 1. length of `_attestation` == 65 (signature length) * signatureThreshold
     * 2. addresses recovered from attestation must be in increasing order.
     * For example, if signature A is signed by address 0x1..., and signature B
     * is signed by address 0x2..., attestation must be passed as AB.
     * 3. no duplicate signers
     * 4. all signers must be enabled attesters

Hmmm ok, so if we can set the enabled attesters ourselves in our tests, then we can just use the foundry cheat for signing.

here’s the full logic:

function _verifyAttestationSignatures(
        bytes calldata _message,
        bytes calldata _attestation
    ) internal view {
        require(
            _attestation.length == signatureLength * signatureThreshold,
            "Invalid attestation length"
        );
        // (Attesters cannot be address(0))
        address _latestAttesterAddress = address(0);
        // Address recovered from signatures must be in increasing order, to prevent duplicates
        bytes32 _digest = keccak256(_message);
        for (uint256 i; i < signatureThreshold; ++i) {
            bytes memory _signature = _attestation[i * signatureLength:i *
                signatureLength +
                signatureLength];
            address _recoveredAttester = _recoverAttesterSignature(
                _digest,
                _signature
            );
            // Signatures must be in increasing order of address, and may not duplicate signatures from same address
            require(
                _recoveredAttester > _latestAttesterAddress,
                "Invalid signature order or dupe"
            );
            require(
                isEnabledAttester(_recoveredAttester),
                "Invalid signature: not attester"
            );
            _latestAttesterAddress = _recoveredAttester;
        }
    }

Hoho looks like we have this:

/**
     * @notice Enables an attester
     * @dev Only callable by attesterManager. New attester must be nonzero, and currently disabled.
     * @param newAttester attester to enable
     */
    function enableAttester(address newAttester) public onlyAttesterManager {
        _enableAttester(newAttester);
    }

and this:

function updateAttesterManager(
        address newAttesterManager
    ) external onlyOwner {
        _setAttesterManager(newAttesterManager);
    }

so we just _prank(messageTransmitter.owner()) into setting a new attester manager and then enableAttesters

We are violating this requirement in the signature validation:

require(
            _attestation.length == signatureLength * signatureThreshold,
            "Invalid attestation length"
        );

it looks like we can set the signatureThreshold here:

function setSignatureThreshold(
        uint256 newSignatureThreshold
    ) external onlyAttesterManager {
        _setSignatureThreshold(newSignatureThreshold);
    }

Alright now we’re getting this error:

[9629] 0x4D41f22c5a0e5c74090899E5a8Fb597a8842b3e8::receiveMessage(0x000000000000000300000002000000000008a34c00000000000000000000000019330d10d9cc8751218eaf51e8885d058642e08a0000000000000000000000002b4069517957735be00cee0fadae88a26365528f0000000000000000000000005931822f394babc2aacf4588e98fc77a9f5aa8c900000000000000000000000000000000af88d065e77c8cc2239327c5edb3a432268e5831000000000000000000000000deb1e9a6be7baf84208bb6e10ac9f9bbe1d70809000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000009fcd83bc7f67ada1fb51a4cabea333c72b641bd1, 0x46f25e0bbf6d5c3e7ae163609cb2fa40d7b1a2c317c2ea19470a04fd24d8f7cf1d06211827e9aad4850e7096bdf17a929afb45fab898e27390f6102979267d8e1b4c4608b14f50bff9f0d410649f8944917c318635fce304c2b87e703b719246110260aebdae8d8b25bbef3149799c7f40d0edba5ae44b374ceb6c4b809b5c51a31c41fb1d35d25e80e10f7c6ecde31e1f1bf78ae3896ac80dff665f140a20b2d8a90cd2afb4e526267f5d673cfea48eedbd15dd397a0a67fb5b603f99f69131c76b1c96c6f1d1fb12f120f10d57d5bea03cc3f25339ac3925089efd440fd06af177755bd53eaeb54ed232de030f763e3fb1dacf157431fbd653648ead38441c9f5eef1c)
    │   ├─ [3000] PRECOMPILES::ecrecover(0x5e31ccb367219843ab7348ad6b92e66c67e3ec6555be5d1b7167207216e97c08, 27, 32090125471380663783919729957721618702990925299666511819881923089833890740175, 13127902100174864198037556882014640611685641739399205196949603256843815517582) [staticcall]
    │   │   └─ ← [Return] 0x00000000000000000000000002f7958355d959f8710ac9fc2338af1506840261
    │   └─ ← [Revert] Invalid signature: not attester
    ├─ [0] console::log("Message receive failed with reason:", "Invalid signature: not attester")

the source of this in the cctp message transmitter signature validation is here:

require(
                isEnabledAttester(_recoveredAttester),
                "Invalid signature: not attester"
            );

let’s look at the logic for how the _recoveredAttester is recovered:

address _recoveredAttester = _recoverAttesterSignature(
                _digest,
                _signature
            );
// Signatures must be in increasing order of address, and may not duplicate signatures from same address
            require(
                _recoveredAttester > _latestAttesterAddress,
                "Invalid signature order or dupe"
            );
            require(
                isEnabledAttester(_recoveredAttester),
                "Invalid signature: not attester"
            );

/**
     * @notice Checks that signature was signed by attester
     * @param _digest message hash
     * @param _signature message signature
     * @return address of recovered signer
     **/
    function _recoverAttesterSignature(
        bytes32 _digest,
        bytes memory _signature
    ) internal pure returns (address) {
        return (ECDSA.recover(_digest, _signature));
    }
    
    import "@openzeppelin/contracts/cryptography/ECDSA.sol";

With certora and invariants, you’re thinking of things that are always true, no matter what. Invariants is thinking about what is always true. An invariant is always true. A mathematical expression

this is from the contract:

length of _attestation == 65 (signature length) * signatureThreshold
addresses recovered from attestation must be in increasing order.
For example, if signature A is signed by address 0x1…, and signature B
is signed by address 0x2…, attestation must be passed as AB.
no duplicate signers
all signers must be enabled attesters

Message receive failed with reason: Invalid caller for message

Nice we are getting somewhere. How did I do that? I removed the Eth message prefix thing from the attestation signature.

// Validate destination caller
        if (_msg._destinationCaller() != bytes32(0)) {
            require(
                _msg._destinationCaller() ==
                    Message.addressToBytes32(msg.sender),
                "Invalid caller for message"
            );
        }

so this is happening in the cctp message transmitter. I should apply for a grant from chainlink for this, im making their local ccip sim fork tool compatible with usdc

the USDCTokenPool calls depositForBurnWithCaller, it sets the destinationCaller parameter to domain.allowedCaller. This is the key piece we’re missing.

The CCTPMessageTransmitterProxy contract has a list of allowed callers that can call receiveMessage
The USDCTokenPool contract has a Domain struct that includes an allowedCaller field, which is used when calling depositForBurnWithCaller

The allowedCaller in the domain config must match the address of the CCTPMessageTransmitterProxy on the destination chain, encoded as a bytes32

/// @notice Sets the CCTP domain for a CCIP chain selector.
  /// @dev Must verify mapping of selectors -> (domain, caller) offchain.
  function setDomains(
    DomainUpdate[] calldata domains
  ) external onlyOwner

lovely.

The allowedCaller must be the MessageTransmitterProxy address of the destination chain
The domainIdentifier must be the correct USDC domain ID for the destination chain
The destChainSelector must be the CCIP chain selector of the destination chain
The configuration must be set on both the source and destination chain’s USDCTokenPools

https://developers.circle.com/stablecoins/supported-domains

assuming this is what a domainIdentifier is

it’s very useful and quite fun having people with the right knowledge and experience challenge your ideas

https://developers.circle.com/stablecoins/evm-smart-contracts

Share CCT

You can think of it as a crosschain wrapper for yield bearing money

the frontend should just be a single button in the middle. how much do you want to deposit? boom done. money money money money money.

Back to the integrating usdc/cctp with ccip local thing

ok so looks like we need to do this thing:

/// @notice Configures the allowed callers for the `receiveMessage` function.
  /// @param configArgs An array of `AllowedCallerConfigArgs` structs.
  function configureAllowedCallers(
    AllowedCallerConfigArgs[] calldata configArgs
  ) external onlyOwner {
    for (uint256 i = 0; i < configArgs.length; ++i) {
      if (configArgs[i].allowed) {
        if (s_allowedCallers.add(configArgs[i].caller)) {
          emit AllowedCallerAdded(configArgs[i].caller);
        }
      } else {
        if (s_allowedCallers.remove(configArgs[i].caller)) {
          emit AllowedCallerRemoved(configArgs[i].caller);
        }
      }
    }
  }

struct AllowedCallerConfigArgs {
    address caller;
    bool allowed;
  }

ok we’re configuring but why are we reverting?

[248] 0xC30362313FBBA5cf9163F0bb16a0e01f01A896ca::configureAllowedCallers([AllowedCallerConfigArgs({ caller: 0x9fCd83bC7F67ADa1fB51a4caBEa333c72B641bd1, allowed: true })])
    │   └─ ← [Revert] EvmError: Revert

“EvmError: Revert” great, very helpful. let’s go back to CCTPMessageTransmitterProxy::configureAllowedCallers

wait a minute that’s not the right contract.

IMessageTransmitter internal arbCCTPMessageTransmitter =
        IMessageTransmitter(0xC30362313FBBA5cf9163F0bb16a0e01f01A896ca);

that’s the CCTP deployment, we need the chainlink deployment

where is the CCTPMessageTransmitterProxy contract address?

wait a minute

we are going in the wrong direction. we dont need to be configuring those callers on that contract…i think… what we need is to be doing something with that weird message that gets sent through cctp. the one with the weird formatting listed out in the natspec

* Message format:
     * Field                 Bytes      Type       Index
     * version               4          uint32     0
     * sourceDomain          4          uint32     4
     * destinationDomain     4          uint32     8
     * nonce                 8          uint64     12
     * sender                32         bytes32    20
     * recipient             32         bytes32    52
     * messageBody           dynamic    bytes      84
     * @param message Message bytes
     * @param attestation Concatenated 65-byte signature(s) of `message`, in increasing order
     * of the attester address recovered from signatures.
     * @return success bool, true if successful
     */
    function receiveMessage(
        bytes calldata message,
        bytes calldata attestation
    ) external override whenNotPaused returns (bool success) {
        // Validate each signature in the attestation
        _verifyAttestationSignatures(message, attestation);  
        bytes29 _msg = message.ref(0);
        // Validate message format
        _msg._validateMessageFormat();
        // Validate domain
        require(
            _msg._destinationDomain() == localDomain,
            "Invalid destination domain"
        );
        // Validate destination caller
        if (_msg._destinationCaller() != bytes32(0)) {
            require(
                _msg._destinationCaller() ==
                    Message.addressToBytes32(msg.sender),
                "Invalid caller for message"
            );
        }

this is from Message.sol in the cctp codebase:

function _destinationCaller(bytes29 _message)
        internal
        pure
        returns (bytes32)
    {
        return _message.index(DESTINATION_CALLER_INDEX, 32);
    }

alright we implemented a helper function to parse the dest caller

function parseDestinationCaller(bytes memory message) internal pure returns (bytes32) {
        // DESTINATION_CALLER_INDEX is 84, and it's 32 bytes long
        bytes32 destinationCaller;
        assembly {
            destinationCaller := mload(add(message, 116)) // 84 + 32 = 116 to get the start of the field
        }
        return destinationCaller;
    }

and our logs reveal this: Destination caller: 0x4D41f22c5a0e5c74090899E5a8Fb597a8842b3e8

which is the MessageTransmitter we are trying to call receiveMessage on.

well if we prank to that: _changePrank(address(uint160(uint256(destinationCaller)))); then the message is received successfully and the childPeer gets minted the correct amount of usdc. that’s nice. but we still need to figure out: what is happening under the hood with the local ccip simulator handling the offchainTokenData which includes the cctp msgAndAttestation

what we want is to initiate the crosschain tx with this: arbParentPeer.deposit(DEPOSIT_AMOUNT);

and to route it with

ccipLocalSimulatorFork.switchChainAndRouteMessageWithData(optFork, offchainTokenData);

but the message isnt going through properly on the other end and the logs dont reveal the cause.

the offchainTokenData is being used in this bit:

IEVM2EVMOffRampFork(offRamps[i - 1].offRamp).executeSingleMessage(
                    message, offchainTokenData, tokenGasOverrides
                );

the address being called is the offRamp, stored here:

/**
     * @notice Structure representing an offRamp configuration
     *
     * @param sourceChainSelector - The chain selector for the source chain
     * @param offRamp - The address of the offRamp contract
     */
    struct OffRamp {
        uint64 sourceChainSelector;
        address offRamp;
    }

perhaps we need to register the offRamp address with ccip local sim register……..

struct NetworkDetails {
        uint64 chainSelector;
        address routerAddress;
        address linkAddress;
        address wrappedNativeAddress;
        address ccipBnMAddress;
        address ccipLnMAddress;
        address rmnProxyAddress;
        address registryModuleOwnerCustomAddress;
        address tokenAdminRegistryAddress;
    }

nope, doesnt look like the offRamp.

we’re getting offRamp address from here

IRouterFork.OffRamp[] memory offRamps =
            IRouterFork(i_register.getNetworkDetails(block.chainid).routerAddress).getOffRamps();
        length = offRamps.length;

This is the goal: the usdc MUST reach the childPeer on opt via ccip local sim.

things we know: the attestation is correct.

the message is correct.

the usdc is being sent through ccip on the src chain (arb)

but it isnt reaching the destination chain (opt)

the logs show us we are switching chains to opt and getting the network details for opt, including the ccip Router.

i dont see this happening in the logs:

for (uint256 i = length; i > 0; --i) {
            if (offRamps[i - 1].sourceChainSelector == message.sourceChainSelector) {
                vm.startPrank(offRamps[i - 1].offRamp);
                uint256 numberOfTokens = message.tokenAmounts.length;
                bytes[] memory offchainTokenData = new bytes[](numberOfTokens);
                uint32[] memory tokenGasOverrides = new uint32[](numberOfTokens);
                for (uint256 j; j < numberOfTokens; ++j) {
                    tokenGasOverrides[j] = uint32(message.gasLimit);
                }
                IEVM2EVMOffRampFork(offRamps[i - 1].offRamp).executeSingleMessage(
                    message, offchainTokenData, tokenGasOverrides
                );
                vm.stopPrank();
                break;
            }
        }

Cursor said this:

The code is iterating through the offRamps array in reverse order (for (uint256 i = length; i > 0; — i)), looking for a matching sourceChainSelector.

What should happen:

The message is sent from Arbitrum (source chain)
The code switches to Optimism (destination chain)
It gets the offRamps from Optimism’s router
It looks for an offRamp that has Arbitrum’s chainSelector as its sourceChainSelector
The message is sent from Arbitrum (source chain)
The code switches to Optimism (destination chain)
It gets the offRamps from Optimism’s router
It looks for an offRamp that has Arbitrum’s chainSelector as its sourceChainSelector

The key part is this check:

if (offRamps[i — 1].sourceChainSelector == message.sourceChainSelector)

This means we need to find an offRamp in Optimism’s router that is specifically configured to receive messages from Arbitrum. If this match isn’t found, the message won’t be executed.

well this is the arb selector and inbound offramp on opt for arb: sourceChainSelector: 4949039107694359620 [4.949e18], offRamp: 0xEB3d6956BCf7b1E29634C8cd182fC9FA740Bce34

Logs:
  Destination caller: 0x4D41f22c5a0e5c74090899E5a8Fb597a8842b3e8
  Message hash (hex):
  0x4d7da1c326405e1571e175b34218e8a2e2621ff1ca22b78ac6a7e7d2419be0b3
  Comparing offRamp sourceChainSelector: 124615329519749607
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 1224752112135636129
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 7613811247471741961
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 1923510103922296319
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 3993510008929295315
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 9027416829622342829
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 1346049177634351622
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 1673871237479749969
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 1562403441176082196
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 15971525489660198786
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 11344663589394136015
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 7264351850409363825
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 6433500567565415381
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 5009297550715157269
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 4949039107694359620
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 4051577828743386545
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 465200170687744372
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 5142893604156789321
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 7264351850409363825
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 465200170687744372
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 11344663589394136015
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 6433500567565415381
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 5142893604156789321
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 4949039107694359620
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 15971525489660198786
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 5009297550715157269
  Message sourceChainSelector: 0
  Comparing offRamp sourceChainSelector: 4051577828743386545
  Message sourceChainSelector: 0

well i think we’ve found our problem. why on earth is the src selector 0? Good thing we can see 4949039107694359620 in the list though!

this is not going well

the CCIPSendRequested event is emitted in the logs, but it is not being correctly identified in the local sim getRecordedLogs.

the event in the local sim looks like this:

event CCIPSendRequested(Internal.EVM2EVMMessage message);

now heres a problem, the latest version of smartcontractkit/chainlink doesnt include that struct in Internal.sol

it’s included in earlier versions such as that the local sim is based on

struct EVM2EVMMessage {
    uint64 sourceChainSelector; // ────────╮ the chain selector of the source chain, note: not chainId
    address sender; // ────────────────────╯ sender address on the source chain
    address receiver; // ──────────────────╮ receiver address on the destination chain
    uint64 sequenceNumber; // ─────────────╯ sequence number, not unique across lanes
    uint256 gasLimit; //                     user supplied maximum gas amount available for dest chain execution
    bool strict; // ───────────────────────╮ DEPRECATED
    uint64 nonce; //                       │ nonce for this lane for this sender, not unique across senders/lanes
    address feeToken; // ──────────────────╯ fee token
    uint256 feeTokenAmount; //               fee token amount
    bytes data; //                           arbitrary data payload supplied by the message sender
    Client.EVMTokenAmount[] tokenAmounts; // array of tokens and amounts to transfer
    bytes[] sourceTokenData; //              array of token data, one per token
    bytes32 messageId; //                    a hash of the message data
  }
  
  
  Client.EVMTokenAmount
  struct EVMTokenAmount {
    address token; // token address on the local chain.
    uint256 amount; // Amount of tokens.
  }

these are giving different outputs,

console2.log("Expected:");
            console2.logBytes32(CCIPSendRequested.selector);
            console2.logBytes32(keccak256("CCIPSendRequested((uint64,address,address,uint64,uint256,bool,uint256,address,uint256,bytes,tuple[],bytes[],bytes32))"));

will need to double check that second one

this is the exact event we are looking for:

emit CCIPSendRequested(message: EVM2EVMMessage({ sourceChainSelector: 4949039107694359620 [4.949e18], sender: 0xA8452Ec99ce0C64f20701dB7dD3abDb607c00496, receiver: 0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809, sequenceNumber: 828, gasLimit: 0, strict: false, nonce: 0, feeToken: 0xf97f4df75117a78c1A5a0DBb814Af92458539FB4, feeTokenAmount: 16328573801608606 [1.632e16], data: 0x0000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000001ffc33f5e217b1cf95e713db49fcd86c8195666c000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044ae84d8e9a37444, tokenAmounts: [EVMTokenAmount({ token: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831, amount: 1000000000 [1e9] })], sourceTokenData: [0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000002bf2000000000000000000000000000000000000000000000000000000000000000200000000000000000000000009fcd83bc7f67ada1fb51a4cabea333c72b641bd100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000b2c639c533813f4aa9d7837caf62653d097ff850000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000008b1bd0000000000000000000000000000000000000000000000000000000000000003], messageId: 0x9b15a7ffbda31d57d616caa6ce79324be5b2a65ef98cb0d239bea50b14a0e4e2 }))

console2.logBytes32(keccak256("CCIPSendRequested((uint64,address,address,uint64,uint256,bool,uint64,address,uint256,bytes,(address,uint256)[],bytes[],bytes32))"));

well i guess the .selector was correct

0xd0c3c799bf9e2639de44391e7f524d229b2b55f5b1ea94b2bf7da42f7243dddd
  0xd0c3c799bf9e2639de44391e7f524d229b2b55f5b1ea94b2bf7da42f7243dddd

the original switchChain and route blah blah is finding the event so why isnt our fork?? i think it was because we were breaking when the message sent event was found before the ccipsend requested event

oh good we’re finally getting somewhere. our fork of the local ccip sim is moving usdc across chains, now we’re back to the invalid caller error on the MessageTransmitter side.

alright so Destination caller: 0x4D41f22c5a0e5c74090899E5a8Fb597a8842b3e8

that looks like the opt contract we are trying to call again.

if we cant prank that address because the ramp is pranked then maybe we need to intercept and redefine the cctp message

ok we managed that by adding these lines into the loop where the offramp on the dstchain does it’s thing:

cctpMessage = _replaceDestinationCaller(cctpMessage, offRamps[i - 1].offRamp);
                bytes[] memory offchainTokenData = _createOffchainTokenData(cctpMessage, attesters, attesterPks);
                
function _replaceDestinationCaller(bytes memory cctpMessage, address destinationCaller) internal pure returns (bytes memory) {
        bytes32 destinationCallerBytes32 = bytes32(uint256(uint160(destinationCaller)));
        bytes memory newCctpMessage = new bytes(cctpMessage.length);
        assembly {
            mstore(add(newCctpMessage, 116), destinationCallerBytes32) // 84 + 32 = 116 to get the start of the field
        }
    }

now we’re getting this error: [Revert] InvalidSourceDomain(3, 0)

wait actually maybe we didnt fix the destCaller thing, maybe this error is happening before getting to that

ok this is from the usdc token pool error InvalidSourceDomain(uint32 expected, uint32 got); so maybee we did fix the dstCaller

we need to intercept the message again and replace the domainId with the srcChain

this isnt going well

Logs:
  Found MessageSent event
  Found CCIPSendRequested event
  Message decoded successfully
  Decoded message sourceChainSelector: 4949039107694359620
  CCTP message initial:
  0x000000000000000300000002000000000008b27a00000000000000000000000019330d10d9cc8751218eaf51e8885d058642e08a0000000000000000000000002b4069517957735be00cee0fadae88a26365528f0000000000000000000000004d41f22c5a0e5c74090899e5a8fb597a8842b3e800000000000000000000000000000000af88d065e77c8cc2239327c5edb3a432268e5831000000000000000000000000deb1e9a6be7baf84208bb6e10ac9f9bbe1d70809000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000009fcd83bc7f67ada1fb51a4cabea333c72b641bd1
  Destination caller: 0x4D41f22c5a0e5c74090899E5a8Fb597a8842b3e8
  Source domain: 0
  CCTP message after replacing dstCaller:
  0x

ok this is bad, we are clearly messing up the dstCaller replacement

Logs:
  Found MessageSent event
  Found CCIPSendRequested event
  Message decoded successfully
  Decoded message sourceChainSelector: 4949039107694359620
  CCTP message initial:
  0x000000000000000300000002000000000008b27c00000000000000000000000019330d10d9cc8751218eaf51e8885d058642e08a0000000000000000000000002b4069517957735be00cee0fadae88a26365528f0000000000000000000000004d41f22c5a0e5c74090899e5a8fb597a8842b3e800000000000000000000000000000000af88d065e77c8cc2239327c5edb3a432268e5831000000000000000000000000deb1e9a6be7baf84208bb6e10ac9f9bbe1d70809000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000009fcd83bc7f67ada1fb51a4cabea333c72b641bd1
  Destination caller: 0x4D41f22c5a0e5c74090899E5a8Fb597a8842b3e8
  Source domain: 0
  CCTP message after replacing dstCaller:
  0x000000000000000300000002000000000008b27c00000000000000000000000019330d10d9cc8751218eaf51e8885d058642e08a0000000000000000000000002b4069517957735be00cee0fadae88a26365528f000000000000000000000000eb3d6956bcf7b1e29634c8cd182fc9fa740bce3400000000000000000000000000000000af88d065e77c8cc2239327c5edb3a432268e5831000000000000000000000000deb1e9a6be7baf84208bb6e10ac9f9bbe1d70809000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000009fcd83bc7f67ada1fb51a4cabea333c72b641bd1

this is looking a bit better

the implementation for replacing the dstCaller is failing though

lets review some new ideas:

go through the logs, find the initial cctp MessageSent event and where it’s being emitted from and how the data is formed
then we can either manipulate the data at the source or copy what is happening
the dstCaller is the MessageTransmitter we are calling receiveMessage on. so it MUST be getting set somewhere.

wait a minute. oh really

domains[0] = USDCTokenPool.DomainUpdate({
            allowedCaller: bytes32(uint256(uint160(address(optCCTPMessageTransmitter)))),
            domainIdentifier: 2,
            destChainSelector: optChainSelector,
            enabled: true
        });
        domains[1] = USDCTokenPool.DomainUpdate({
            allowedCaller: bytes32(uint256(uint160(address(ethCCTPMessageTransmitter)))),
            domainIdentifier: 0,
            destChainSelector: ethChainSelector,
            enabled: true
        });
        domains[2] = USDCTokenPool.DomainUpdate({
            allowedCaller: bytes32(uint256(uint160(address(arbCCTPMessageTransmitter)))),
            domainIdentifier: 3,
            destChainSelector: arbChainSelector,
            enabled: true
        });

are you serious right now? i spent the last few hours doing all this assembly stuff and the issue was right here in the base test setup????

right whatever. what do we need to change that address to?

(I havent verified this, im making an assumption right now that the allowedCaller in that struct is the dstCaller)

lets find out by changing it real quick

domains[0] = USDCTokenPool.DomainUpdate({
            allowedCaller: bytes32(uint256(uint160(address(1)))),
            domainIdentifier: 2,
            destChainSelector: optChainSelector,
            enabled: true
        });

Destination caller: 0x0000000000000000000000000000000000000001

no way. well at least we got it.

So the msg.sender will be offRamps[i — 1].offRamp. This means we need to set the destinationCaller to be the offRamp address, but aren’t there different offRamp addresses for different lanes? ie arb → opt has a different offRamp address on opt as eth → opt ?

so we need to figure out all of our lanes and get the offRamps for each scenario

Optimism offRamps

arb → opt 0xEB3d6956BCf7b1E29634C8cd182fC9FA740Bce34

eth → opt 0x9979c2dfEcA9051Cf7f08274d978984B2dB12C60

Arb offRamps

opt → arb 0x27a971D482335d0f8d1917451390734f7372A4a3

eth → arb 0x91e46cc5590A4B9182e47f40006140A7077Dec31

Eth offRamps

arb → eth 0xdf615eF8D4C64d0ED8Fd7824BBEd2f6a10245aC9

opt → eth 0x562a2025E60AA19Aa03Ea41D70ea1FD3286d1D3B

alright lets just try hardcoding the one we need for this to see if it works

ok it doesnt work, invalid caller, guess the offRamp thing wasnt true

the offRamp thing may not have worked but i hardcoded whatever address 0x5931822f394baBC2AACF4588E98FC77a9f5aa8C9 this is - it’s the usdc token pool on the dst chain

and now the failure is happening in the ccipReceive impl in our childPeer!!!!!!!!

this is amazing, we have integrated cctp/usdc with ccip local sim. this was alot of effort just for a unit test, but tbf its something i’ve needed many times in the last year when testing ccip and always been annoyed it’s not a feature

ok the problem here was we werent setting the s_ccipGasLimit, so it was 0. and now it’s working! it’s finally working!

Back to the actual project

we are successfully moving usdc across, but the deposit is staying in the childPeer when it should be getting sent to the strategy, which in this test is the aavePool.

so why isnt it getting sent to the strategy?

because the strategyPool is currently set to 0 on that chain

test_parent_deposit_strategyIsChild_aave is passing. amazing. there’s a nice satisfaction from putting all the pieces together and seeing it behave as intended.

look at this (we’re using a setter for the strategy because clf trace not implemented)

function test_parent_deposit_strategyIsChild_aave() public {
        // @review REPLACE THIS WITH A WRAPPER OR ACTUAL CLF CALLTRACE
        _selectFork(optFork);
        optChildPeer.setStrategy(optChainSelector, IYieldPeer.Protocol.Aave);
        _selectFork(arbFork);
        arbParentPeer.setStrategy(optChainSelector, IYieldPeer.Protocol.Aave);
        uint256 usdcBalanceBefore = arbUsdc.balanceOf(depositor);
        /// @dev act
        arbParentPeer.deposit(DEPOSIT_AMOUNT);
        /// @dev assert depositor's USDC balance reduced by the deposit amount on parent chain
        uint256 usdcBalanceAfter = arbUsdc.balanceOf(depositor);
        assertEq(usdcBalanceAfter, usdcBalanceBefore - DEPOSIT_AMOUNT);
        /// @dev switch to child chain and route ccip message with USDC to deposit to strategy
        ccipLocalSimulatorFork.switchChainAndRouteMessageWithUSDC(optFork, attesters, attesterPks);
        /// @dev assert USDC was deposited to Aave on child chain
        address aUsdc = _getATokenAddress(optNetworkConfig.aavePoolAddressesProvider, address(optUsdc));
        assertEq(IERC20(aUsdc).balanceOf(address(optChildPeer)), DEPOSIT_AMOUNT);
        /// @dev switch back to parent chain and route ccip message with totalValue to calculate shareMintAmount
        ccipLocalSimulatorFork.switchChainAndRouteMessage(arbFork);
        /// @dev assert correct amount of shares minted
        uint256 expectedShareMintAmount = DEPOSIT_AMOUNT * INITIAL_SHARE_PRECISION;
        assertEq(arbShare.totalSupply(), expectedShareMintAmount);
        assertEq(arbShare.balanceOf(depositor), expectedShareMintAmount);
        assertEq(arbParentPeer.getTotalShares(), expectedShareMintAmount);
    }

for the purpose of a deposit on the parent when the child is the strategy, this is what we want. the user makes a single tx, depositing on the parent, the usdc is sent to pool with highest interest, user receives back SHAREs, representing their share of the pool.

what do we need to test next? the child deposit? are we there now?

what were the types of deposits a child could do again? SEE HANDLING CASES

we have successfully tested the case a child is the strategy and deposits are made there for both aave and compound protocols

ok and now we’ve successfully tested the cases where a deposit is made on a child when the parent and another child are the strategies, for both protocols

i think we can probably move on to withdrawals

Withdraw

we’re going to use SHARE.transferAndCall() to withdraw (and also to move across chains)

what sort of CcipTxTypes will we need for withdrawing?

withdrawToParent
withdrawToStrategy
withdrawCallbackParent
withdrawCallbackChild

to calculate usdcWithdrawAmount (aka amountToWithdraw), we will need totalValue, totalShares, shareBurnAmount

let’s consider the various cases again.

Withdraw made from parent

parent is strategy
SHAREs are burnt
totalShares is updated @review - should this happen before or after withdraw?
amountToWithdraw is calculated
amountToWithdraw withdrawn from strategy pool and sent to withdrawer
child is strategy
SHAREs are burnt
ccip message to parent with sharesBurnt and to update/get totalShares
callback to child, sharesBurnt is used to calculate amountToWithdraw and totalShares is updated

Withdraw made from child

parent is strategy
shares are burnt
shareBurnAmount sent to parent strategy
usdcToWithdraw amount calculated and USDC ccipSend back to child
child/withdraw is strategy
shares are burnt
shareBurnAmount sent to parent and totalShares updated
totalShares (preupdate amount) and shareBurnAmount sent back to withdraw-child-strategy
usdcToWithdraw calculated and transferred to withdrawer
chain c is strategy
shares are burnt
shareBurnAmount sent to parent and totalShares updated
totalShares (preupdate amount) and shareBurnAmount are forwarder to child strategy
usdcToWithdraw calculated and ccipSend back to child-withdraw chain

if we’re going via the parent we should really be getting the totalShares value there before doing totalShares -= shareBurnAmount

and then we want to send the totalShares along with the shareBurnAmount to the strategy where we will get the totalValue, use that to calculate the amountToWithdraw, and then send the usdcAmountToWithdraw back to the withdrawData.chainSelector

we are successfully withdrawing when the withdraw chain and strategy chain are the parent

lets see if we can successfully withdraw when the withdraw is the parent but the strategy is a child

ok we have successfully tested the withdraws made from parent scenarios. time for lunch.

[19570] ParentPeer::ccipReceive(Any2EVMMessage({ messageId: 0x5db94a200cb2d9a6b0e4601198ce4167c4bc3378a286f750aa5ecd9c8eb1dc52, sourceChainSelector: 3734403246176062136 [3.734e18], sender: 0x000000000000000000000000deb1e9a6be7baf84208bb6e10ac9f9bbe1d70809, data: 0x0000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000002246e37fded1bf7eefafeecc506e0933cec1a42400000000000000000000000000000000000000000000003635c9adc5dea000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000033d343f77863cab8, destTokenAmounts: [] }))
    │   │   │   │   ├─ [4639] 0x141fa059441E0ca23ce184B6A78bafD2A517DdE8::getFee(4949039107694359620 [4.949e18], EVM2AnyMessage({ receiver: 0x0000000000000000000000000000000000000000000000000000000000000000, data: 0x0000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000002246e37fded1bf7eefafeecc506e0933cec1a42400000000000000000000000000000000000000000000003635c9adc5dea0000000000000000000000000000000000000000000000000003635c9adc5dea00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000033d343f77863cab8, tokenAmounts: [], feeToken: 0xf97f4df75117a78c1A5a0DBb814Af92458539FB4, extraArgs: 0x181dcf10000000000000000000000000000000000000000000000000000000000007a1200000000000000000000000000000000000000000000000000000000000000001 })) [staticcall]
    │   │   │   │   │   └─ ← [Revert] UnsupportedDestinationChain(4949039107694359620 [4.949e18])

had this error before and didnt write it down. i think the issue was arb is trying to send to its own chain selector

alright we are successfully withdrawing from both protocols when the withdraw is initiated on a child and the parent is the strategy

time for the last withdrawal scenarios! when a different child to the one we are withdrawing from is the strategy.

ok done.

next up will be Rebalancing, then CLF/Automation

Rebalancing

https://x.com/Route2FI/status/1929610156314067093 this could be useful

lets remember that for later

back to rebalancing, what do we want to accomplish? for now just successful ccip rebalance tx.

eventually it will look like this:

CLA triggers CLF request (on parent chain)
CLF DON runs script to find best yield opportunity
clf.fulfillRequest returns strategy (on parent chain)
parent chain checks if current/old strategy is same as returned
if it is, return, probably emit event
parent chain checks if current/old strategy is on parent
if it is, then update and reallocate to new strategy
if new strategy is still parent, just move funds there
otherwise, ccipSend.RebalanceNewStrategy to newStrategy.chainSelector
if old strategy is not on parent, ccipSend.RebalanceOldStrategy to oldStrategy.chainSelector
old strategy then reallocates system funds to new strategy
if new strategy is same chain as old strategy, move funds there
otherwise, oldStrategy ccipSend.RebalanceNewStrategy to newStrategy.chainSelector
we’ll need to handle the CCIPReceive cases for RebalanceOldStrategy and RebalanceNewStrategy txs on both child and parent, maybe we can put all the logic in the YieldPeer

here’s a very messy implementation

/// @notice This function sets the strategy on the parent
    /// @notice This function uses ccipSend to send the rebalance message to the old strategy
    /// @notice Rebalances funds from the old strategy to the new strategy
    /// @notice Handles the case where both the old and new strategy are on this chain
    /// @notice Handles the case where the old or new strategies are on different chains with ccipSend
    /// @param chainSelector The chain selector of the new strategy
    /// @param protocol The protocol of the new strategy
    function _setStrategy(uint64 chainSelector, Protocol protocol) internal {
        /// @dev get the old strategy
        Strategy memory oldStrategy = s_strategy;
        /// @dev emit event and return if the new strategy is the same as the old strategy
        if (oldStrategy.chainSelector == chainSelector && oldStrategy.protocol == protocol) {
            emit CurrentStrategyOptimal(chainSelector, protocol);
            return;
        }
        Strategy memory newStrategy = Strategy({chainSelector: chainSelector, protocol: protocol});
        /// @dev set the new strategy on parent
        s_strategy = newStrategy;
        // if the new strategy is on this chain AND the old strategy was on this chain, but the protocol is different, we need to reallocate funds and update state
        if (
            chainSelector == i_thisChainSelector && oldStrategy.chainSelector == i_thisChainSelector
                && protocol != oldStrategy.protocol
        ) {
            // get current strategy pool
            address oldStrategyPool = _getStrategyPool();
            // withdraw totalValue from current strategy
            uint256 totalValue = _getTotalValueFromStrategy(oldStrategyPool);
            _withdrawFromStrategy(oldStrategyPool, totalValue);
            // update state
            address newStrategyPool = _getStrategyPool(protocol);
            s_strategyPool = newStrategyPool;
            // deposit totalValue to new strategy
            _depositToStrategy(newStrategyPool, i_usdc.balanceOf(address(this)));
        }
        // if the old strategy is on this chain, but the new strategy is on a different chain, we need to ccipSend funds to the new Strategy
        else if (oldStrategy.chainSelector == i_thisChainSelector && chainSelector != i_thisChainSelector) {
            // get current strategy pool
            address oldStrategyPool = _getStrategyPool();
            // withdraw totalValue from current strategy
            // withdraw totalValue from current strategy
            uint256 totalValue = _getTotalValueFromStrategy(oldStrategyPool);
            _withdrawFromStrategy(oldStrategyPool, totalValue);
            // update state
            s_strategyPool = address(0);
            // ccipSend funds to new strategy - RebalanceNewStrategy
            bytes32 ccipMessageId = _ccipSend(
                chainSelector, CcipTxType.RebalanceNewStrategy, abi.encode(newStrategy), i_usdc.balanceOf(address(this))
            );
        }
        // if the old strategy is on a different chain, we need to send a message to it to rebalance funds to the new strategy
        else if (oldStrategy.chainSelector != chainSelector) {
            // ccipSend funds to new strategy - RebalanceOldStrategy
            bytes32 ccipMessageId = _ccipSend(
                oldStrategy.chainSelector, CcipTxType.RebalanceOldStrategy, abi.encode(newStrategy), ZERO_BRIDGE_AMOUNT
            );
        }
        /// @dev if the new strategy is on this chain or the old strategy was on this chain, set the strategy pool
        if (chainSelector == i_thisChainSelector || oldStrategy.chainSelector == i_thisChainSelector) {
            _setStrategyPool(chainSelector, protocol);
        }
    }
    
    /// @notice Sets the strategy pool for the YieldPeer
    /// @param protocol The protocol of the strategy
    /// @param chainSelector The chain selector of the strategy
    /// @notice If the Strategy is this chain, the strategy pool is set to the Aave or Compound pool
    /// @notice If the Strategy is not this chain, the strategy pool is set to address(0)
    function _setStrategyPool(uint64 chainSelector, Protocol protocol) internal {
        address strategyPool;
        if (chainSelector == i_thisChainSelector) {
            if (protocol == Protocol.Aave) strategyPool = address(i_aavePoolAddressesProvider);
            else if (protocol == Protocol.Compound) strategyPool = address(i_comet);
        }
        s_strategyPool = strategyPool;
        emit StrategyPoolSet(strategyPool);
    }

lets clean this baby up a bit all the tests are failing now

this is a mess. WHY DID I NOT GIT COMMIT BEFORE REFACTORING WITH AI

THIS

we’re getting this error [Revert] No CCTP message found which means no usdc is being sent, when it should. for this test test_yield_child_deposit_strategyIsChainC_aave this is an awful setback and entirely my own fault for not git commiting

let’s take this slow and debug what is happening

the last event to be emitted before the local sim fail is this:

emit CCIPMessageSent(messageId: 0x758a7acc4c102a7b806544ca4fed47ed9d0711a7418d3da3d796ea09819530dc, txType: 3, amount: 0)

txType 3 is DepositCallbackChild, assuming enums start at 0

that shouldnt be right because we are failing on this final line of this snippet:

/// @dev act
        optChildPeer.deposit(DEPOSIT_AMOUNT);
/// @dev assert depositor's USDC balance reduced by the deposit amount
        uint256 usdcBalanceAfter = optUsdc.balanceOf(depositor);
        assertEq(usdcBalanceAfter, usdcBalanceBefore - DEPOSIT_AMOUNT);
        /// @dev switch to parent chain and route ccip message with USDC to deposit to strategy
        ccipLocalSimulatorFork.switchChainAndRouteMessageWithUSDC(arbFork, attesters, attesterPks);
        /// @dev switch to third chain and route ccip message with USDC to deposit to strategy
        ccipLocalSimulatorFork.switchChainAndRouteMessageWithUSDC(ethFork, attesters, attesterPks);

so we successfully send usdc to the parent from the child, but the parent is not properly forwarding it to the strategy

CCIPLocalSimulatorFork::switchChainAndRouteMessageWithUSDC(2, [0x235739A3558844a3A6bC892E58160c8866B2F48a, 0x1F8830562d09e0091c45C4497d578698D4CcA495, 0x46b3351cEC2e2894fB86f516571c71af735129cc, 0x98CCf16957d570D7b08ee14cb7f28B7134629A89], [20446281702270753840690766545487606775683492866242999899033812487149029933055 [2.044e76], 49122242058703694249118830405974474269253475590835006894245756864029220552986 [4.912e76], 18324067312630338727698582437758273338129539904811332467964650786258440414685 [1.832e76], 2410372839825060559863049644307281798630208676479422982278344845517011015526 [2.41e75]])

2 is the network fork. can we verify this is eth?

yes

looks like we’re hitting the wrong condition here:

if (strategy.chainSelector == i_thisChainSelector || strategy.chainSelector == depositData.chainSelector) {
            depositData.shareMintAmount = _calculateMintAmount(depositData.totalValue, depositData.amount);
            s_totalShares += depositData.shareMintAmount;
            bytes32 ccipMessageId = _ccipSend(
                depositData.chainSelector, CcipTxType.DepositCallbackChild, abi.encode(depositData), ZERO_BRIDGE_AMOUNT
            );
            // do something with ccipMessageId?
        }
        /// @dev If Strategy is on third chain, forward deposit to strategy
        if (strategy.chainSelector != i_thisChainSelector && strategy.chainSelector != depositData.chainSelector) {
            bytes32 ccipMessageId =
                _ccipSend(strategy.chainSelector, CcipTxType.DepositToStrategy, encodedDepositData, depositData.amount);
            // do something with ccipMessageId?
        }

i think i found the problem, we weren’t updating s_strategy.chainSelector in the temporary parent setter. yep. thank goodness for that. that was a bad half hour. better git commit.

we are back to testing rebalancing.

we correctly emit event and return if current strategy is optimal

we correctly rebalance from one parent pool to another

now we are stuck trying to rebalance from one pool to another on same child chain

for some reason it looks like we are not withdrawing the totalValue from the first pool (aave), which we want so we can rebalance it to another pool (compound)

ok all rebalance txs are passing unit tests

lets move onto chainlink functions

Chainlink Functions

We are creating a new module contract that will inherit the ParentPeer, just to keep the code cleaner and easier to maintain

ParentCLF is ParentPeer.

defi llama has an api that looks like it returns APY data for pools across chains and protocols, this may be alot more simple to use than reading state off every chain

it seems that the json response from the defi llama api is too large for clf to handle.

we made a proxy api and deployed it on aws, so i guess we’re going for an aws sponsor prize now

curl -X POST <[REDACTED]> -H "Content-Type: application/json" -d '{"symbol":"USDC","projects":["aave-v3","compound-v3"],"chains":["Arbitrum","Ethereum","Base","Optimism"]}'

This is going very well. It’s amazing how quickly the initial prototype for an automated crosschain yield optimizer can be built.

first coverage report is looking good

added a few functions related things to the network config and getting stack too deep errors. will probably have to refactor the network config to be comprised of multiple structs

Chainlink Functions requires the user to sign terms of service to create subscriptions. We could split up a signature and sign it, but seeing as we’re just going to do it through the frontend for the testnet deployments, I don’t see a problem with just pranking the functionsRouter.owner() and bypassing the signature requirement for our fork tests.

This is annoying:

[1008162101] ParentCLF::sendCLFRequest()
    │   ├─ [1008146008] 0x97083E831F8F0638855e2A515c90EdCF158DF238::sendRequest(49, 0x6c636f64654c6f636174696f6ec258200000000000000000000000000000000000000000000000000000000000000000686c616e6775616765c25820000000000000000000000000000000000000000000000000000000000000000066736f7572636563313233, 1, 300000 [3e5], 0x66756e2d617262697472756d2d6d61696e6e65742d3100000000000000000000)
    │   │   ├─ [1008114796] 0xd93d77789129c584a02B9Fd3BfBA560B2511Ff8A::startRequest((0x6c636f64654c6f636174696f6ec258200000000000000000000000000000000000000000000000000000000000000000686c616e6775616765c25820000000000000000000000000000000000000000000000000000000000000000066736f7572636563313233, 0x0000000000000000000000000000000000000000000000000000000000000000, 0xBb2180ebd78ce97360503434eD37fcf4a1Df61c3, 1000000000000000000000 [1e21], 0, 49, 0, 300000 [3e5], 1, 0, 0x1804c8AB1F12E6bbf3894d4083f33e07309d1f38))
    │   │   │   ├─ [15643] 0x86E53CF1B870786351Da77A57575e79CB55812CB::latestRoundData() [staticcall]
    │   │   │   │   ├─ [7410] 0x9b8DdcF800a7BfCdEbaD6D65514dE59160a2C9CC::latestRoundData() [staticcall]
    │   │   │   │   │   └─ ← [Return] 0x0000000000000000000000000000000000000000000000000000000000044dab0000000000000000000000000000000000000000000000000000000055d6df940000000000000000000000000000000000000000000000000000000068400b310000000000000000000000000000000000000000000000000000000068400b310000000000000000000000000000000000000000000000000000000000044dab
    │   │   │   │   └─ ← [Return] 0x0000000000000000000000000000000000000000000000010000000000044dab0000000000000000000000000000000000000000000000000000000055d6df940000000000000000000000000000000000000000000000000000000068400b310000000000000000000000000000000000000000000000000000000068400b310000000000000000000000000000000000000000000000010000000000044dab
    │   │   │   ├─ [1118] 0x86E53CF1B870786351Da77A57575e79CB55812CB::decimals() [staticcall]
    │   │   │   │   ├─ [276] 0x9b8DdcF800a7BfCdEbaD6D65514dE59160a2C9CC::decimals() [staticcall]
    │   │   │   │   │   └─ ← [Return] 8
    │   │   │   │   └─ ← [Return] 8
    │   │   │   ├─ [3143] 0x86E53CF1B870786351Da77A57575e79CB55812CB::latestRoundData() [staticcall]
    │   │   │   │   ├─ [1410] 0x9b8DdcF800a7BfCdEbaD6D65514dE59160a2C9CC::latestRoundData() [staticcall]
    │   │   │   │   │   └─ ← [Return] 0x0000000000000000000000000000000000000000000000000000000000044dab0000000000000000000000000000000000000000000000000000000055d6df940000000000000000000000000000000000000000000000000000000068400b310000000000000000000000000000000000000000000000000000000068400b310000000000000000000000000000000000000000000000000000000000044dab
    │   │   │   │   └─ ← [Return] 0x0000000000000000000000000000000000000000000000010000000000044dab0000000000000000000000000000000000000000000000000000000055d6df940000000000000000000000000000000000000000000000000000000068400b310000000000000000000000000000000000000000000000000000000068400b310000000000000000000000000000000000000000000000010000000000044dab
    │   │   │   ├─ [1118] 0x86E53CF1B870786351Da77A57575e79CB55812CB::decimals() [staticcall]
    │   │   │   │   ├─ [276] 0x9b8DdcF800a7BfCdEbaD6D65514dE59160a2C9CC::decimals() [staticcall]
    │   │   │   │   │   └─ ← [Return] 8
    │   │   │   │   └─ ← [Return] 8
    │   │   │   ├─ [0] 0x000000000000000000000000000000000000006C::getPricesInWei() [staticcall]
    │   │   │   │   └─ ← [InvalidFEOpcode] EvmError: InvalidFEOpcode

what? because we’re forking arbitrum some opcode isnt working in foundry? is that it?

inconvenient. we could replace arb as our parent chain with base maybe

yep the problem was arbitrum. going to have to refactor all our tests to use base as the parent now. Wow, refactoring is going very quick with cursor!

ok chainlink functions send request and fulfill request are working.

To Do list:

let’s list the things we need to complete this project:

string constant SOURCE_CODE pointing to code on github
src.js on github
should proxy api url be a secret?
minimise src.js code
clean up peer contracts
clean up unit tests
onTokenTransfer SharePool ERC677Receiver
unit tests
fees
implement other strategy protocols such as euler
invariant tests
certora
deploy on testnets
register with time-based automation
frontend
comprehensive natspec
demo video
detailed README
submit before 29th

1. string constant

let’s see what concero do https://github.com/concero/contracts-v1/blob/fa45c941685cbf9816b89a19d2690d4a3365b52c/contracts/InfraCLF.sol#L47

string private constant CL_JS_CODE =
        "try{const m='';const u=m+'ethers-io/ethers.js/v6.10.0/dist/ethers.umd.min.js';const [t,p]=await Promise.all([ fetch(u),fetch(m+'concero/contracts-v1/'+'release'+`/tasks/CLFScripts/dist/infra/${BigInt(bytesArgs[2])===1n ? 'DST':'SRC'}.min.js`,),]);const [e,c]=await Promise.all([t.text(),p.text()]);const g=async s=>{return('0x'+Array.from(new Uint8Array(await crypto.subtle.digest('SHA-256',new TextEncoder().encode(s)))).map(v=>('0'+v.toString(16)).slice(-2).toLowerCase()).join(''));};const r=await g(c);const x=await g(e);const b=bytesArgs[0].toLowerCase();const o=bytesArgs[1].toLowerCase();if(r===b && x===o){const ethers=new Function(e+';return ethers;')();return await eval(c);}throw new Error(`${r}!=${b}||${x}!=${o}`);}catch(e){throw new Error(e.message.slice(0,255));}";

looks like they’re doing some fancy stuff handling different scripts depending on src/dst chain txs. the hash verification thing is nice, but im not sure we strictly need it.

so we can point to the raw js on github for the clf don to run

we should make the proxy API secret because I dont want other people spamming it.

put the proxy api url in a secret gist on github and encrypt it with chainlink functions toolkit

the script we have on the raw github works in playground, but not if we paste the raw url there.

trying deploying on base sepolia

none of the deployments are working. this is getting stressful. javascript is the worst part about using chainlink and verifying contracts on explorers is the worst part of development.

i suppose i could do something else and come back to this…

SharePool ERC677Receiver

we are jumping ahead to something easy

do tokenPools need to hold LINK for ccip fees?

Side note

invariant: ParentPeer::s_totalShares == ghost_totalSharesMintedAcrossChains

we can probably track ghost_totalSharesMintedAcrossChains via ccipReceive data, or even events

ERC677 CCT,

should be redeemable across chains, ie users can transferAndCall it, with a dstChainSelector of their choice to receive their USDC on. if data is left blank, it defaults to current chain/

CLF debugging

Today we are trying to figure out why CLF won’t work with encrypted secrets and raw gist github link. This is likely to be the worst part of this project. I hate verifying contracts on explorers. I’ve made a basic contract with the absolute bare bones needed to use clf and check the params we are using and the tx isnt going through with cast send, so to debug with tenderly i want to deploy on base sepolia but it wont verify, even when flattening. there has never been a project where i had a worse experience during development than verifying on block explorers. horrible process.

ok we did it with a flattened file, optimizer runs and removing the “0x” at the start of the abi encoded constructor args. lets get this on tenderly and figure out why clf isnt working

even though we are passing the constructor args of the clfRouter and clfSubId through our helper config, AND included them in contract verification, the getters are returning 0 for both.

didnt include this line in helperconfig

else if (block.chainid == 84532) activeNetworkConfig = getBaseSepoliaConfig();

………ok

we are successfully making the request to chainlink functions now. thank goodness. and it is returning an error.

ok this means the problem is the secrets encryption. i put the encrypted secret in a storage slot and added a setter, so can just retry the encryption and change it without having to redeploy (hopefully)

interesting ok so there’s a problem with the gist hosted secrets.json?

NOTE: CHANGE FUNCTIONS REQUEST LIBRARY FROM X TO 1

in the encryption script we used a different private key to the one we are using to interact with our contract/CLF… maybe that’s the issue? nope still failed to fetch valid secrets

I encrypted the {api: “proxyapi.url”} uploaded it to gist like so https://gist.githubusercontent.com/contract-level/7ee5ca74aa43f85e1ca0c525616e4bd9/raw/6033ef099eaa4089df591187a2f4d4d3fd629de6/encrypted-secrets.json

{
    "encryptedSecrets": "0x7b225444483243747874223a2265794a48636d393163434936496c41794e5459694c434a44496a6f695545465a54314a564d324653564570314b32684256566b77596d4d775156684f636b5651576a686b5530316a4b325a7559556455565578564d4430694c434a4d59574a6c62434936496b464251554642515546425155464251554642515546425155464251554642515546425155464251554642515546425155464251554642515545394969776956534936496b4a5064544252556e557257556868625774785930673461335577656e6873546d7772553268526230383256334a524e464d72646d645561444a794e456772626a525164324d345444685a56466f786232706c57456b765a584273556e6850543035336245685662334e33516d564f556e566f565430694c434a5658324a6863694936496b4a50614559796357686a5646707a64556c584d316732563356705a586456546b6c6d626e686f4b3256584d455a75513046334e7a526b6248424a6558704256585a544e4446525a5563724b7a564b634670514d437475636a41324e3278514e484a42616c517863564a6e5231567a4e6a5631637a30694c434a46496a6f695a335a6f5757707a546c5a70617a426b656a46554d58564756545a6e526d6c59645849305431704d54314a434e335249616d684b64336c6e535430694c434a47496a6f695a6e6b3265544e6d6257743363334231563264304e5441765345743259565a45546e67324b7a5236526c464c6330457854546c485655526d597a306966513d3d222c2253796d43747874223a22775663326c66335a5358446f364a3573716945594749514b54696548646f6d5059737576794e4c516d2f76444a392b636e73615871684a50394c55536f7a4d2f5879586a54474d35393070516e733459626733716c5445425539564d4175433230762b39707a4e4936596c4f383867306952463767516a4e4d50366e70704c7a562f734e444575506d337038336b2b6d5851746a7761566978595949546e75386c5a3846485165774d534d566855424c32666f593734553749713852504254324859353964712f4772334f766e4d35794b7769493462386d63576c6c54516a636f53456f4b474a594e6b313768325232554b4b6358444863645651754768474c3749726d4c785a48685934616666506c6e4d5755447751395479414662667274704248303250353958634931656f6e58656b6d4f5975536255416a47757a50722f6149464f73462b3556495a472b48636975394f636e5239743170547637725a5033376a49446c50442f344b615078754e4c496346364a355846566368374b4272577446616f6a4434594b305a4f5457646877306e6361684a2f68323855587477756e5138386c6d71384552766e7a6e2b4f684b796761686465355552706670327549467273565258623561684847432f2b51624e706975733471466b342b65506f3266584645592f667069314d696b597a4156504a387074576f432b59525856687466564c76783164323634456533576b516455634873437638385a54774e767630422f4b3453786b42774a47364250763634452f4d4b7865514779533665495341784f5637737a53563145785a374664766d53464d5a79342b6f784c2b4c6a6f314c3779427935567a4e553071593644792f744b62544f456a5847413d3d222c224e6f6e6365223a224c794465706b68375766377854475946227d"
}

then encrypted the gist url,

0x73184483ace400c49c8591c3fbfc8e9202de8d53b4ac7336364a4544d15f6dd674d4508e7ac8063f6433d795a5a541d3cad4262c778fb9ef7c5f7eda944437465e6707fef1ad0698aee7f78e67d1d746cc0c7a59cf4d8fac4c19ae83c5a4816f573ff65409af783eaac8d68d9d58b5ec84552b0f9034b6288d681fd9967e37601e425d00b9bfe96ae4c2e325b650a607e05f83f0813a82d68566077fa60d4ebbebe6e617acd7b7d111953a67e630c95988a31c3dbed01a8ad43d98b0e5408592fdd4fbe64aa43997fc350a7351b4f79fb0bc6e3cbb0b3843429dab7f0cc96b54d4aab3c6f7117fe5d61940c94effadee46

and passed that to the contract, and got this error

after a few hours of debugging and searching, i got nowhere.

i deployed a new contract with inline code location and got this error

Error:
Failed to decrypt secrets URLs

so close to giving up on the remote hosted encrypted secrets thing. it’s not essential for our project’s functionality, it would just be nice to have.

i set the encryptedSecret url again on the newly deployed contract and got this

Error:
Invalid secrets ownership

https://stackoverflow.com/questions/78915151/getting-invalid-secrets-ownership-error-while-using-chainlink-functions-on-eth

zubin said this “cannot repro error based on this. Also, this may be because the signer of the secrets is different from the person trying to use them? Check the PRIVATE_KEY env var’s value for each of those scripts?”

so how is this supposed to work if we’re using chainlink automation to send requests? is the “person trying to use them” the address that registered with chainlink functions?

https://gist.githubusercontent.com/contract-level/7ee5ca74aa43f85e1ca0c525616e4bd9/raw/1a76b23239fe571d507d49edceb1c7274317b2e0/encrypted-secrets.json

0x1b4e2d1a565a496c987dc6d8303c52370378b6dcecfd8c1a11b7141822be2b3cb96daba5632633858fe0f07fd5ac85b5293101588003a9f260b0c3d1134765de7b9b16bc1d9087affbf117c4b40a259bc618892ade4707190950fd320e239e36e1f16d577e8c9ed52bad67544530dbca3d846dc4b1f3f8eb6c7a6346172762f449be0d5bcfac35dde9a342db2e009d19c87facf05164b6a3ea257c5a687190b38ec8fd117bfc6a27d7da08abb980afb3aca40b71adbf1cf823b6a3b7bda583e3dc76f1e828bb991398c0b0ee96a2b6c5414c86f62e317286480850e80e8d6ab32718640ef44135f7a875b29e757566a823

ok THAT worked.

so it works with inline. let’s see what happens if we use that encrypted secret in the remote one

nope. still getting invalid code location. but at least we now know our encrypted remote hosted secret is working.

this is the working inline contract btw: https://sepolia.basescan.org/address/0x48db59de3cd7bc26affe739f6666c7ae3852dbb7#code

works with the above hex as encryptedSecret

https://functions.chain.link/base-sepolia/333#/side-drawer/request/0x2c83c674b5eb724e8bff91ecd37f1e4ee0b4c786cc29f46c9b5c1b4a17b9bcf4

this is the not working remote location contract: https://sepolia.basescan.org/address/0x2Aa15cA0d8997004765a33c7c09Ccc395a685754#writeContract

maybe lets see if automation will work for the inline contract we just deployed

ok registered the time based automation. let’s see if it does what it’s supposed to in 9 minutes time. (fingers crossed it sends a clf request to our proxy and then returns the optimal yield strategy)

we are still compromising on the code location, but made good progress on the remote hosted encrypted secret

nice automation successfully triggers the clf call and as long as we have the source code inline, then the remote encrypted secrets work and the callback is successful.

right how are we going to solve this remote invalid location error

wait a minute

if we have the url to our source code inline….. does that make it inline rather than remote??

should we be using inline and the inline code is our remotely hosted code? let’s find out…

now we get this error

Exec Error: syntax error, RAM exceeded, or other error

lets try a minimised script without long variable names or console logs and put it on gist then use that url as the inline source

nah got same error

i think maybe we need to wrap the url in some async func in the inline

string private constant CLF_JS_CODE = "try { const url = ''; const response = await fetch(url); if (!response.ok) throw new Error('Fetch failed: ' + response.status); const script = await response.text(); const execute = new Function(script + '; return (async () => { try { return await main(secrets); } catch (e) { return Functions.encodeString(e.message.slice(0, 255)); } })();'); const result = await execute(); return result; } catch (e) { throw new Error(e.message.slice(0, 255)); }";

string private constant CLF_JS_CODE = "(async () => { try { const url = ''; const response = await fetch(url); if (!response.ok) throw new Error('Fetch failed: ' + response.status); const script = await response.text(); return await eval('(async () => {' + script + '})()'); } catch (e) { return Functions.encodeString(e.message.slice(0, 255)); } })();";

string private constant CLF_JS_CODE = "(async () => { try { const url = ''; const response = await fetch(url); if (!response.ok) throw new Error('Fetch failed: ' + response.status); const script = await response.text(); const fn = new Function('secrets', 'Functions', script + '; return main(secrets);'); return await fn(secrets, Functions); } catch (e) { return Functions.encodeString(e.message.slice(0, 255)); } })();";

OK WE are successful if we use this inline: try { const r = await fetch(''); if (!r.ok) throw Error('F:' + r.status); return eval(await r.text()); } catch (e) { return Functions.encodeString(e.message.slice(0,99)); }

the remote url points here (async () => {if(!secrets.api)throw Error('API URL missing');const c={Arbitrum:'4949039107694359620',Ethereum:'5009297550715157269',Base:'15971525489660198786',Optimism:'3734403246176062136'};try{const r=await Functions.makeHttpRequest({url:secrets.api,method:'POST',headers:{'Content-Type':'application/json'},data:{symbol:'USDC',projects:['aave-v3','compound-v3'],chains:Object.keys(c)},timeout:9000});if(r.error||!r.data||!r.data.chain)return Functions.encodeString(JSON.stringify(r));const p=r.data;if(!Object.keys(c).includes(p.chain)||!['aave-v3','compound-v3'].includes(p.project)){const s=Functions.encodeUint256(BigInt(0)),e=Functions.encodeUint256(0),t=new Uint8Array(64);return t.set(s,0),t.set(e,32),t}const e=p.project==='aave-v3'?0:1,s=Functions.encodeUint256(BigInt(c[p.chain]||'0')),t=new Uint8Array(64);return t.set(s,0),t.set(e,32),t}catch(e){return Functions.encodeString(e.message)}})();

this was a lot of work to optimise our inline constant

let’s go back to our todo list

hang on this isnt working properly on our actual contract now

so the encrypted secret bytes isnt working as a constant, but it works if it’s read from storage….that’s inconvenient but its not the end of the world

if we cache encryptedSecret = ENCRYPTED_SECRET in the function call, that doesnt work either.

we could use custom logic automation to read from storage and pass it to the clf request when block.timestamp ≥ s_lastRebalance + 1 days.

ok all we had to do was make the constant look like this:

bytes internal constant ENCRYPTED_SECRET =
        hex"1b4e2d1a565a496c987dc6d8303c52370378b6dcecfd8c1a11b7141822be2b3cb96daba5632633858fe0f07fd5ac85b5293101588003a9f260b0c3d1134765de7b9b16bc1d9087affbf117c4b40a259bc618892ade4707190950fd320e239e36e1f16d577e8c9ed52bad67544530dbca3d846dc4b1f3f8eb6c7a6346172762f449be0d5bcfac35dde9a342db2e009d19c87facf05164b6a3ea257c5a687190b38ec8fd117bfc6a27d7da08abb980afb3aca40b71adbf1cf823b6a3b7bda583e3dc76f1e828bb991398c0b0ee96a2b6c5414c86f62e317286480850e80e8d6ab32718640ef44135f7a875b29e757566a823";

NOW lets go back to our to do list.

To Do list 2

string constant SOURCE_CODE pointing to code on github
src.js on github
should proxy api url be a secret? yes and it is
minimise src.js code
clean up peer contracts
clean up unit tests
onTokenTransfer SharePool ERC677Receiver
unit tests
rename Share to YieldCoin? YieldPool?
fees
implement other strategy protocols such as euler
invariant tests
certora
deploy on testnets
register with time-based automation
frontend
optional: SOLANA CCIP?? depends how much time we have
comprehensive natspec
demo video
detailed README
submit before 29th

YieldCoin crosschain tests

might change SHARE to YIELD or YieldCoin (”it only goes up!”)

TokenPool.sol:

/// @notice Checks if the pool address is configured on the remote chain.
  /// @param remoteChainSelector Remote chain selector.
  /// @param remotePoolAddress The address of the remote pool.
  function isRemotePool(uint64 remoteChainSelector, bytes calldata remotePoolAddress) public view returns (bool) {
    return s_remoteChainConfigs[remoteChainSelector].remotePools.contains(keccak256(remotePoolAddress));
  }
  
    /// @dev A set of allowed chain selectors. We want the allowlist to be enumerable to
  /// be able to quickly determine (without parsing logs) who can access the pool.
  /// @dev The chain selectors are in uint256 format because of the EnumerableSet implementation.
  EnumerableSet.UintSet internal s_remoteChainSelectors;
  mapping(uint64 remoteChainSelector => RemoteChainConfig) internal s_remoteChainConfigs;

i thought i already set this stuff in the base test. oh looks like we need to set the source chain in the config too. good thing i checked this because we were also setting the peers as allowed pools by mistake

have not cleaned up unit tests, but have got 100% unit coverage (except for 1 missing branch in a library which after hours of trying, im not going to worry about anymore)

7. implement other Yield Strategies

https://x.com/Route2FI/status/1929610156314067093

let’s research how to deposit and withdraw from euler

euler contract addresses: https://github.com/euler-xyz/euler-interfaces/tree/master/addresses

ok so looks like according to this page https://docs.euler.finance/concepts/core/evc/

we want to be interacting with the euler system via that evc contract

although we’re not going to be borrowing, just depositing usdc to lend. they are using proxies however for a few of these contracts so its probably safer to just go via the main one

actually i dont think we’ll need that, interacting directly with the vault looks more realistic https://etherscan.io/address/0xcBC9B61177444A793B85442D3a953B90f6170b7D#writeProxyContract

it has a deposit and a mint function. deposit says to consider using mint. we’d need to calculate the mint amount if there’s no getter for whatever amount we’d deposit

ok questions we need to ask:

where do we find the contract addresses for all chains for the usdc vault?
there’s a drop down menu on here: https://app.euler.finance/?network=base HOWEVER, it doesn’t support all of the chains we were planning.
how do we deposit usdc/mint shares?
how do we withdraw?

I’m beginning to doubt whether integrating euler is worth our finite time for this hackathon. it wont actually showcase more chainlink usage than we are already doing and it takes time and attention away from invariant tests and implementing fees.

let’s revisit the todo list and figure out our priorities

To Do List 3

fees
invariant tests
certora
deploy on testnets
register with time-based automation
frontend
comprehensive natspec
swap contract for swapping any crypto into usdc and then depositing for yieldcoin
demo video
detailed README
clean up unit tests
clean up peer contracts
optional: SOLANA CCIP?? depends how much time we have
optional: implement other strategy protocols such as euler
submit before 29th

Fees

let’s think about implementing fees.

we will take 0.1% or FEE_PERCENT from all deposits.

calculate fee based on depositAmount shareMintAmount and fee percent

should we be taking a fee from the deposited usdc or from the minted shares?

minted shares means we will earn yield on our fees too, rather than leaving collected usdc fees sitting around but the logic could get messy

No, invariants

no, you know what? let’s do invariants. invariants is smart contract development. fees can come later, and we’ve done fees before. let’s start really getting into the system.

we’ll need mocks for comet and aave. we can do something simple and just deal these pools extra usdc, but if we’re verifying with the certora prover, then we’d probably want to leave the mocks as simple deposit and withdraw with no interest rate (because we probably dont have time to implement that system)

hmm mocking aave maybe a little bit trickier with its aToken

if we’re using the ccip local simulator (not fork because fuzz tests and rpc = no thanks) then we’ll need to use the link token and the mock router from its configuration when deploying our peers

we also need to call supportNewTokenViaGetCCIPAdmin or one of the other functions that adds a token to its supported mapping with the usdc address we use

i’m guessing maaaaaybe we dont need to worry about hopping between chains with this local one?

there’s a big issue with this, in that if this thing has a constant chain selector and our peers are mapped uniquely to each blockchain’s chain selector, then what are we supposed to do? do we use an array or enumerable set of chain selectors in place of its constant?

Chromion hackathon: doing invariant fuzz runs for local ccip sim fork is not realistic with rpc calls to mainnets. the non-fork ccip sim has a constant chain selector, but we’re mapping peers to unique selectors so

crosschain invariant testing seems daunting but if you can get 100% coverage with forked mainnets its np. write a handler. it’s as simple as that

We need to fork CCIP Local sim and instead of having a CONSTANT chain selector, we need to have an array or enumerable set of chain selectors

looks like we’ll have to fork this import {MockCCIPRouter} from "@chainlink/contracts-ccip/src/v0.8/ccip/test/mocks/MockRouter.sol";

which is used in the chainlink-local non-fork ccip sim.

what’s happening here is the MockRouter from the old chainlink ccip contracts is hardcoding the src chain selector to be sepolia’s when we want it to be dynamic based on which peer is initiating the ccip message

we may also want to update this in the ccip local sim

function isChainSupported(uint64 chainSelector) public pure returns (bool supported) {
        supported = chainSelector == CHAIN_SELECTOR;
    }

but it probably wont have any affect on our invariants. it’s mostly the hardcoding in the mock router we need to fork, so let’s do that.

this may be tricky because the mockRouter.ccipSend doesn’t take a source chain selector as a param, it takes the dst selector and EVM2AnyMessage, which doesnt include source selector.

well the sender is abi.encoded in the ccipSend sender: abi.encode(msg.sender),

so im guessing what we need is a mapping inside the mockRouter of peers ⇒ selectors, and then we just replace the hardcoded sepolia selector with something like peerToSelector[msg.sender]

This is what I’ve added to the MockRouter:

mapping(address peer => uint64 chainSelector) s_peerToChainSelector;
  
  sourceChainSelector: s_peerToChainSelector[msg.sender],
  
  function setPeerToChainSelector(address peer, uint64 chainSelector) external {
    s_peerToChainSelector[peer] = chainSelector;
  }

To keep things, clean, I forked the MockRouter into its own mock file inside chainlink-local, and will replace the MockRouter used in local ccip sim with this new mock.

getting this revert [Revert] NotEnoughGasForCall()

it comes from the src/v0.8/shared/call/CallWithExactGas lib in chainlink-local’s chainlink/ccip-contracts dependancy

hm seems like setting a higher initial gas limit solved it, we need around twice as much in these local tests as we did for the mainnet fork for some reason

nvm fixed another error with bounded values and the not enough gas one is back

ok we increased the limit to 600_000 and now getting a erc20 transfer error. that should be easy to fix great getting the not enough gas error again wtf is this

the problem with this CallWithExactGas lib is most of it is in assembly, making it harder to figure out what is going on

in the MockRouter, we have:

function _routeMessage(
        Client.Any2EVMMessage memory message,
        uint16 gasForCallExactCheck,
        uint256 gasLimit,
        address receiver
    ) internal returns (bool success, bytes memory retData, uint256 gasUsed) {
        // There are three cases in which we skip calling the receiver:
        // 1. If the message data is empty AND the gas limit is 0.
        //          This indicates a message that only transfers tokens. It is valid to only send tokens to a contract
        //          that supports the IAny2EVMMessageReceiver interface, but without this first check we would call the
        //          receiver without any gas, which would revert the transaction.
        // 2. If the receiver is not a contract.
        // 3. If the receiver is a contract but it does not support the IAny2EVMMessageReceiver interface.
        //
        // The ordering of these checks is important, as the first check is the cheapest to execute.
        if (
            (message.data.length == 0 && gasLimit == 0) || receiver.code.length == 0
                || !receiver.supportsInterface(type(IAny2EVMMessageReceiver).interfaceId)
        ) {
            return (true, "", 0);
        }
        bytes memory data = abi.encodeWithSelector(IAny2EVMMessageReceiver.ccipReceive.selector, message);
        (success, retData, gasUsed) = CallWithExactGas._callWithExactGasSafeReturnData(
            data, receiver, gasLimit, gasForCallExactCheck, Internal.MAX_RET_BYTES
        );

and then in the lib:

/// @notice calls target address with exactly gasAmount gas and payload as calldata.
  /// Account for gasForCallExactCheck gas that will be used by this function. Will revert
  /// if the target is not a contact. Will revert when there is not enough gas to call the
  /// target with gasAmount gas.
  /// @dev Caps the return data length, which makes it immune to gas bomb attacks.
  /// @dev Return data cap logic borrowed from
  /// .
  /// @return success whether the call succeeded
  /// @return retData the return data from the call, capped at maxReturnBytes bytes
  /// @return gasUsed the gas used by the external call. Does not include the overhead of this function.
  function _callWithExactGasSafeReturnData(
    bytes memory payload,
    address target,
    uint256 gasLimit,
    uint16 gasForCallExactCheck,
    uint16 maxReturnBytes

well in the mockRouter.ccipSend, the gasLimit being passed to that comes from uint256 gasLimit = _fromBytes(message.extraArgs).gasLimit;

well i increased the limit to 5 milly and it’s working now

after an hour or so of setting up an invariant

WE GET THE NOT ENOUGH GAS ERROR AGAIN AAAAAAAAAAAAAGH THIS

[obscenities]

not enough gas with 10m this is ridiculous

// if g - g//64 <= gasLimit, revert
if iszero(gt(sub(g, div(g, 64)), gasLimit)) {
    mstore(0x0, NOT_ENOUGH_GAS_FOR_CALL_SIG)
    revert(0x0, 0x4)
}

this is cursor’s explanation of the assembly:

Let me break this down simply:
g is the available gas after subtracting gasForCallExactCheck (which is 5,000 gas)
The check is: g - (g/64) <= gasLimit
This is equivalent to: (63/64) * g <= gasLimit
So the revert happens when:
The amount of gas you want to use (gasLimit) is greater than 63/64ths of the available gas
This is due to EIP-150, which ensures that a contract can't use more than 63/64ths of the remaining gas in a call. The router is enforcing this limit to prevent gas bombs.
For example:
If you have 10,000,000 gas available
After subtracting gasForCallExactCheck (5,000), you have 9,995,000
63/64ths of that is ~9,839,648
So if your gasLimit is greater than ~9.84M, it will revert
To fix this, you need to set your gasLimit to be less than 63/64ths of the available gas. For 10M gas, that means setting it to around 9.8M or less.

this is so stupid

the ai’s logic here is i set it to something lower to bypass the condition based on the previous setting, as if that wont change the condition itself.

if i set it to 0 i get this

ParentCLF::ccipReceive(Any2EVMMessage({ messageId: 0x6693e7969f9b3792025bb3b11ed0da17093286c4c71d0e97c7e3fe42ea746108, sourceChainSelector: 2, sender: 0x000000000000000000000000f62849f9a0b5bf2913b396098f7c7019b51a820a, data: 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000009455ed678000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002, destTokenAmounts: [EVMTokenAmount({ token: 0x40b4863C923385D1632d640B097DDeA6EaB92e76, amount: 39818548856 [3.981e10] })] }))
    │   │   │   └─ ← [OutOfGas] EvmError: OutOfGas

so we need to send strictly less than the limit we are specifying. how do we find how much we are sending? isnt it going to be a different amount for different tx types……..

i guess we can just brute force the limit until we find the happy medium between out of gas and not enough gas

ok its somewhere between 167_000 and 168_000

this is insane. our mainnet fork tests were fine. i’ve never needed to account for this with ccip before

169_000 = out of gas

169_990 = not enough gas

169_500 = [Revert] panic: array out-of-bounds access (0x32)

….

https://www.rareskills.io/post/eip-150-and-the-63-64-rule-for-gas let’s at least read about this eip before we consider commenting out the gas check

even if we use 169_500, that still sometimes gives us the not enough gas error. if we comment out the check in the lib, then we get the array out of bounds, so lets debug that

i’ve commented out the check for now.

the out of bounds panic error is something to do with small fuzzed shareBurnAmount values that result in 0 usdc being withdrawn from the strategies and then sent and transferred…i think.

either way we have an issue with small values

maybe we should just make our share/yieldcoin have 6 decimals too……………

this is the current withdraw calculation logic: function _calculateWithdrawAmount(uint256 totalValue, uint256 totalShares, uint256 shareBurnAmount) internal pure returns (uint256) { return (shareBurnAmount * totalValue) / totalShares; }

Precision Issues: If the totalValue and totalShares are very large numbers, and shareBurnAmount is small, the multiplication might overflow or result in a very small number that gets rounded to 0 during division.

currently, our fuzz tests are making shareBurnAmount a small number and the amount to withdraw is 0 for instance, shareBurnAmount: 19639 totalValue: 1000000 totalShares: 1000000000000000000

emit ShareBurnUpdate(shareBurnAmount: 347847385716999999999998 [3.478e23], chainSelector: 1, totalShares: 2)

MockAavePool::balanceOf(ParentCLF: [0x2e234DAe75C793f67A35089C9d99245E1C58470b]) [staticcall] │ │ │ │ │ │ │ └─ ← [Return] 347847385717 [3.478e11]

theres another potential bug here where if a small amount of shares are left, how will that affect the totalValue?

so with that shareBurnAmount, we just withdrew 347847385716 from the aave pool, leaving the totalValue at 347847385717 - 347847385716 = 1

so we have totalShares = 2 and totalValue = 1 in this scenario. when someone new makes a deposit, their shareMintAmount will be (usdcDepositAmount * 2) / 1. That does not look good!

NOTE: THIS SCENARIO WAS HAPPENING WHEN I CONVERTED 0 WITHDRAWAMOUNT TO 1, NOW REMOVED (we should see if this is still the case later)

it’s a good thing to prioritise invariants because these issues would’ve been difficult to visualise with unit tests

what happens if someone withdraws the totalValue of 1 and then there is 1 share left?

maybe we shouldnt be burning any shares until after the correct usdc has been withdrawn

in an ideal world we would be able to calculate the usdc withdraw amount and revert if 0 based on shareBurnAmount. this would require multiple ccip txs just to read state

ok we need to seriously weigh up our options before continuing.

do we implement extra ccip tx types for fetching usdc withdraw amount before burning (or otherwise sending back to withdrawer) shares? basically the withdrawer would be sending a request to burn

im thinking you know what, if they send a small amount, then whatever, give em 0 back lmao

if _calculateWithdrawAmount returns 0, then…. just return? hehehehehehehe. i get there should be some protection for fatfingering idiots but is it really worth the extra logic of sending multiple ccip txs so someone can withdraw tiny fractions of a cent? This line of thinking is entirely due to the time constraints of the hackathon btw. if this was a legitimate project that would be deployed, this issue would be given serious and significant consideration on how to make it as fair as possible. the actual production answer would likely be to use concero.

i dunno im not so satisfied with this. a min shareburnamount check would be ideal but ccip [REDACTED]

I think this should be marked down as a KNOWN ISSUE: BURNING SMALL AMOUNTS OF SHARES RESULTS IN 0 USDC WITHDRAWN for now

that is really annoying. is there really nothing we can do to rectify this? using some solady math lib and reducing the decimals per share?

Let’s just properly document this known issue for now

Known Issue: Burning small amounts of shares can result in 0 usdc withdrawn

It can take up to 3 CCIP txs to calculate the usdcWithdrawAmount based on the shareBurnAmount

Consider this scenario:

shareBurnAmountwithdrawal initiated on child1
totalShares is on parent
totalValue is on child2 (strategy)

These 3 values are required to calculate the usdcWithdrawAmount. When the shareBurnAmount is significantly small, the calculation can return less than the minimum amount of USDC to 6 decimals $1.000000 (.000000). This value is a significantly small fraction of a cent. If we tried to calculate this amount, it would return 0. Then if we try to withdraw this amount (0) from a yield strategy and send it across ccip to be transferred to the withdrawer, it would cause issues such as the transfer failing because the transferAmount is 0.

Therefore the current, unfortunate solution (at least for the time constrained context of the hackathon) is to not withdraw or transfer anything if someone burns an amount of shares small enough that it is worth less than the 6th decimal after a $.

It is unlikely to expect anyone to want to withdraw such a small amount of dust, but this edge case still needs to be acknowledged, and is handled as such by simply allowing the small amount of shares to be burnt without any redemption of USDC.

We could add a min burn amount, and revert if this amount is not provided when a burn is attempted, but to do so would require the same above CCIP txs + extra ones just to tell the withdrawer that no, we cant burn your piddly amount of shares.

Back to invariants (oh yeah)

now we dont have 100% coverage on the YieldPeer

| src/peers/YieldPeer.sol | 98.55% (136/138) | 99.17% (120/121) | 100.00% (18/18) | 97.73% (43/44) |

annoying

oh that lack of coverage was just cus of a getter we added for the strategy pool. easypeasy

emit ShareMintUpdate(shareMintAmount: 0, chainSelector: 1, totalShares: 1)

this isnt very nice. so it looks like in the fuzz runs we’ve ended up with 1 totalShare which is likely contributing to the shareMintAmount being 0. i wonder what totalValue is in this scenario

looks like 484862598387

depositAmount: 194507369801

shareMintAmount = (194507369801 * 1) / 484862598387;

equals 0.401159772785261, so solidity is rounding it 0 of course.

this is a bad bug. how on earth do we handle crosschain precision? we can’t prevent someone with a big amount of shares burning all of them except for small amounts of wei. might have to spend the evening reading solodit

maybe if we have an admin mint the initial shares and then never withdraw, that could provide some sort of mitigation

ok that seems to be providing some mitigation. let’s increase the fuzz runs, see if we find anything weird. seems good.

Known issue: Share minting inflation attack

Mitigation: initial admin mint

Solana CCIP

https://app.kamino.finance/earn/lend this looks like an option for lending usdc on solana

Back to invariants/known issues

https://solodit.cyfrin.io/issues/using-atokenbalanceof-in-claggaaveadapter_compoundaccounting-allows-for-inflation-at-tacks-cantina-none-clave-pdf

this looks relevant

invariants are going very well. if i start certora now i’ll be about a week ahead of schedule. it’d be amazing if i have enough time to learn enough rust to implement ccip on solana and move usdc in and out of a lending protocol there, like that kamino thing

https://docs.chain.link/ccip/directory/testnet/token/USDC its a shame the solana testnet isnt on here. at least i dont have to worry about rushing to learn rust. good thing i checked this before spending a week trying to implement it

these invariants are looking pretty good. it’s been surprisingly simple and straight forward, this handler. im not sure if its because i’ve been doing invariants so much lately or because the external functions to handle are so few and simple. i expected the crosschain stuff to make this harder, but so much of it is abstracted away, it’s been easy to focus on overall system invariants

maybe lets get started with C E R T O R A

Certora

the most fun part of smart contract development is certora

ok i needed to make a new mock ccip router for certora. we’re not simulating crosschain like in the foundry invariants, just verifying functionality for each contract, so this is a much simpler mock router than the one that i forked from chainlink-local

im doing basic certora rules and the prover is giving timeouts which is not good. i suspect it has something to do with the libraries as i havent used certora much with custom libraries that interact with external protocols. i’ve linked all the correct immutables and storage contracts in the scene.

this command made everything pass after 13 mins:

certoraRun ./certora/conf/Parent.conf --prover_args '-summarizeExtLibraryCallsAsNonDetPreLinking true' --nondet_difficult_funcs

let’s try it like this certoraRun ./certora/conf/Parent.conf --nondet_difficult_funcs

and we’ll also try it without the flag just to double check the timeouts from earlier werent being caused by incorrect links in the scene.

whilst waiting for those lets have a look again at what --nondet_difficult_funcs is doing

https://docs.certora.com/en/latest/docs/prover/cli/options.html#nondet-difficult-funcs

ok so basically it just summarizes unsummarized complicated view functions

right so the reason we need that is because the CLF FunctionsRequest contains functions that do a lot with strings and bytes and seeing as strings and bytes can have a LOT of different possible values, the prover tries to explore all these possible paths, and for the purpose of our testing, we dont care about verifying a chainlink library because we already know chainlink code is good. we want to verify our own code.

that was probably the best thing i’ve learnt so far from this project.

it makes sense to verify the parent peer separately from the clf extension

im trying to verify the YieldPeer separately so I don’t end up copy and pasting all of the same logic between the Parent and Child specs. I made a YieldHarness and am verifying ccipReceive via that. also verified the internal functions for handling ccip tx, basic deposits and withdraws, as well as the decoding for withdrawal chain selector being an allowed chain

what about a Yield.spec and there are 2 confs pointing to it, each with child and parent. then the readme would just include the two commands to run each conf, checking the same rules and invariants for all peers. this would require the rules in this mutual spec to not contain specific helpers, unless both the childharness and parentharness inherited the same helper harness. this is making sense.

let’s figure out what files we need:

Yield.spec (specifies behaviour of the abstract YieldPeer contract, in particular exposed internal functions)
Yield.conf
ParentCLF.spec (chainlink functions/automation)
ParentCLF.conf
Parent.spec (behaviour specific to ParentPeer)
Parent.conf
Child.spec (behaviour specific to ChildPeer)
Child.conf
BasePeer.spec (behaviour shared by Parent and Child)
BaseParent.conf (for pointing ParentPeer.sol to BasePeer.spec)
BaseChild.conf (for pointing ChildPeer.sol to BasePeer.spec)

consider this

Feature idea DEPOSITS SHOULD HAVE THE OPTION TO SPECIFY WHICH CHAIN TO RECEIVE MINTED SHARES ON, SIMILAR TO HOW WITHDRAW FEATURES THAT

the contract level yield infrastructure is a crosschain network of contracts that facilitate usdc deposits and withdraws in exchange for minting and burning yieldcoin

To Do List 4

invariant tests
certora
deploy on testnets
register with time-based automation
get testnet link and eth on each chain
set crosschain vars including local peer for each chain
frontend
comprehensive natspec
demo video
diagrams
different tx types and scenarios flow
detailed README
fees (optional)
optional: swap contract for swapping any crypto into usdc and then depositing for yieldcoin
run slither and aderyn
double check for unused code such as old definition events in certora
clean up unit tests
clean up peer contracts
optional: implement other strategy protocols such as euler
submit before 29th

invariant strategyPool_consistency()
    getStrategy().chainSelector != getThisChainSelector() =>
	  getStrategyPool() == 0;

this is failing. why?

ParentHarness.getThisChainSelector() ↪ 0xe34

(ParentHarness.getStrategy()).chainSelector != ParentHarness.getThisChainSelector() => ParentHarness.getStrategyPool() == 0 ↪

false

(ParentHarness.getStrategy()).chainSelector != ParentHarness.getThisChainSelector() ↪

true

(ParentHarness.getStrategy()).chainSelector == ParentHarness.getThisChainSelector() ↪

false

(ParentHarness.getStrategy()).chainSelector ↪

0x4305

ParentHarness.getThisChainSelector() ↪

0xe34

ParentHarness.getStrategyPool() == 0 ↪

false

ParentHarness.getStrategyPool() ↪ 0x10

YieldPeer._handleCCIPRebalanceNewStrategy(data=bytes)

Evaluate branch condition

Declare newStrategy

keyboard_arrow_down

YieldPeer._updateStrategyPool(chainSelector=

0xe34

, protocol=

IYieldPeer.Protocol.Compound

) ↪

MockComet

Evaluate branch condition

keyboard_arrow_down

YieldPeer._getStrategyPoolFromProtocol(protocol=

IYieldPeer.Protocol.Compound

) ↪

MockComet

chevron_right

YieldPeer._getProtocolConfig() ↪ ProtocolOperations.ProtocolConfig

chevron_right

Global State #4

chevron_right

ProtocolOperations.getStrategyPoolFromProtocol(protocol=

IYieldPeer.Protocol.Compound

, config={usdc=

MockUsdc

, aavePoolAddressesProvider=

MockPoolAddressesProvider

, comet=

MockComet

}) ↪

MockComet

Evaluate branch condition

strategyPool ↪

0x10

chevron_right

Global State #5

Store at ParentHarness.s_strategyPool ↪

MockComet

chevron_right

Global State #6

newStrategyPool ↪ 0x10

it looks like ccipReceive is calling _handleRebalanceNewStrategy which calls this

/// @notice Internal helper to handle strategy pool updates
    /// @param chainSelector The chain selector for the strategy
    /// @param protocol The protocol for the strategy
    /// @return strategyPool The new strategy pool address
    function _updateStrategyPool(uint64 chainSelector, Protocol protocol) internal returns (address strategyPool) {
        if (chainSelector == i_thisChainSelector) {
            strategyPool = _getStrategyPoolFromProtocol(protocol);
            s_strategyPool = strategyPool;
        } else {
            s_strategyPool = address(0);
        }
        emit StrategyPoolUpdated(strategyPool);
    }

but the chainSelectors are different, as confirmed here

(ParentHarness.getStrategy()).chainSelector ↪

0x4305

ParentHarness.getThisChainSelector() ↪

0xe34

but look, the parent selector is getting passed to that function

YieldPeer._updateStrategyPool(chainSelector=0xe34, protocol=IYieldPeer.Protocol.Compound

well it looks like we have found a legitimate issue with our code, thanks to certora. the problem is we are updating the strategyPool twice in the scenario the old strategy is a child and the new strategy is a parent. this is the flow:

CLF fulfillRequest callback sets the new strategy on parent
This includes `_updateStrategyPool

hang on wait, nope, that’s not true. we are not updating the strategy pool on the parent during the clf callback

what’s happening is we are updating the s_strategy struct that contains the strategy chain selector and protocolEnum

and then updating the pool in the rebalance from old (child) to new (parent) callback

so basically the certora invariant is failing because it doesnt “know” the crosschain calltrace, and is assigning a random value to s_strategy.chainSelector so when the ccipReceive gets called, there is no prior context for the s_strategy being set during the clf callback, and then triggering the subsequent ccip txs that would result in this ccipReceive simulation. this is a good example of why it was useful to also test this invariant in foundry with the local ccip sim, and demonstrates the limitations of either certora or my own ability to use it

Trying to verify that parent.deposit mints shares. but it’s failing.

rule deposit_mintsShares_when_parent_is_strategy() {
    env e;
    calldataarg args;
    require getStrategy().chainSelector == getThisChainSelector();
    
    uint256 shareSupplyBefore = share.totalSupply();
    uint256 totalSharesBefore = getTotalShares();
    deposit(e, args);
    assert share.totalSupply() > shareSupplyBefore;
    assert getTotalShares() > totalSharesBefore;
}

ParentHarness.deposit(amountToDeposit=0x1)

YieldPeer._getTotalValueFromStrategy(strategyPool=MockComet) ↪ 0x2

ProtocolOperations._getTotalValueFromCompound(comet=MockComet) ↪ 0x2

so we’re deposting 0x1 worth of USDC and the totalValue in the system is 0x2

i think this is another interpretation of the inflation attack vulnerability we already uncovered with the foundry invariant tests and can likely be mitigated by requiring the totalValue to be > INITIAL_ADMIN_DEPOSIT

ok even when we require that, it still calculates a mint amount as 0

ParentPeer._calculateMintAmount(totalValue=

0xfff…270

, amount=

0x1

) ↪

0x0

Load from ParentHarness.s_totalShares ↪

0xfff…26f

totalShares ↪ 0xfff…26f

totalValue = 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe270

totalShares = 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe26f

usdcDepositAmount = 0x1

and this results in 0 minted shares, which is bad.

perhaps we should have a minimum 1usdc deposit amount

let’s try this

// _revertIfZeroAmount(amountToDeposit);
 if (amountToDeposit < 1e6) revert YieldPeer__NoZeroAmount();

even when doing that, calculateMintAmount is still returning 0. This is bad.

ParentPeer._calculateMintAmount(totalValue=0xde0…241, amount=0xf4240) ↪ 0x0

Load from ParentHarness.s_totalShares ↪ 0xe8d4a51001

well this is looking like a critical severity bug

totalValue: 0xde0b6b3a7734241

totalShares: 0xe8d4a51001

usdcDepositAmount: 0xf4240

these values return a 0 shareMintAmount. Which is very bad because we clearly have value and shares in the system and the depositor is providing a minimum of 1 usdc and yet is getting nothing in return. this is why we need to do formal verification — to catch edgecases like this.

HOW does this get fixed

i tried implementing solady’s fixedPointMathLib.fullMulDivUp and got a very quick certora timeout, something i havent seen before. https://docs.certora.com/en/latest/docs/user-guide/out-of-resources/timeout.html#high-nonlinear-op-count

“Nonlinear integer arithmetic is often the hardest part of the formulas that the Certora Prover is solving.” great.

Chromion hackathon: mitigating precision loss for a system that accepts and mints crosschain deposits and shares is trickier than simply requiring minimum amounts and enforcing an initial admin deposit.

remember to remove solady if not end up using it

right i’ll come back to deposit_mintsShares_when_parent_is_strategy - this is a serious critical edgecase uncovered, but i’ve got a ton of other stuff to get through today so im going to verify as much other stuff for the parent peer as possible first

reading precision loss findings on solodit whilst waiting for certora runs. this looks relevant: https://solodit.cyfrin.io/issues/m-01-the-value-of-lp-token-can-be-manipulated-by-the-first-minister-which-allows-the-attacker-to-dilute-future-liquidity-providers-shares-code4rena-elasticswap-elasticswap-git it sounds kindve similar to what i was already thinking with the initial admin mint. this suggests minting some lp (share) tokens to a locked address.

i think i just found another bug with certora. in _setStrategy (called by clf callback), the strategy is updated, right… and if the old strategy is on the parent chain, but the new strategy isn’t, it calls _handleStrategyMoveToNewChain

which gets the old strategyPool like so address oldStrategyPool = _getStrategyPool(), which returns s_strategyPool

nope nevermind, its just certora being weird.

im explicitly requiring oldStrategy.protocol != protocol; in the certora rule, and yet it’s withdrawing and depositing into the same pool

so why is it withdrawing from compound if the old strategy is aave? im thinking certora is assigning the s_strategyPool address to something it shouldnt be so maybe lets constrain that

lets see if it works with these lines

require oldStrategy.protocol == IYieldPeer.Protocol.Aave => currentContract.s_strategyPool == getAave();
    require oldStrategy.protocol == IYieldPeer.Protocol.Compound => currentContract.s_strategyPool == getCompound();

ok it worked.

just gonna leave this comment here:

// @review this is failing - doesnt "know" the crosschain calltrace
// this is breaking because we update the strategyPool if it's a RebalanceNewStrategy callback to the Parent from the old strategy Child
// CLF updates s_strategy on parent -> parent.rebalanceOldStrategy to old strategy child -> child.rebalanceNewStrategy back to parent, updating s_stratgyPool
invariant strategyPool_consistency()
    getStrategy().chainSelector != getThisChainSelector() => getStrategyPool() == 0;

i finished verifying ParentPeer, mostly. everything works as expected except for that edge case. i think once done with certora i should dedicate an entire day at least to this issue before doing the frontend

Important:

src.js/src.min.js will need to be updated with testnet selectors and whatever else that requires

i just noticed something that’s unfortunate for testnet deployments — aave v3 is only on eth sepolia, and cUSDCv3 (compound) is only on eth sepolia, base sepolia, and polygon mumbai

oh i hope the defi llama api works with testnets. better check that now. can always just use the mainnet values i suppose and acknowledge it wont be strictly correct, but just demonstrates the chainlink functionality

pretty annoyed this didnt occur to me earlier

let’s revisit todo list

To Do List 5

invariant tests
certora
precision loss issue
deploy on testnets
register with time-based automation
get testnet link and eth on each chain
set crosschain vars including local peer for each chain
frontend
comprehensive natspec
demo video
diagrams
different tx types and scenarios flow
detailed README
fees (optional)
optional: swap contract for swapping any crypto into usdc and then depositing for yieldcoin
run slither and aderyn
double check for unused code such as old definition events in certora
clean up unit tests
clean up peer contracts
optional: implement other strategy protocols such as euler
submit before 29th

im kinda burnt out from all the certora today. going to do some natspec

its all well and good copy and pasting this todo list. i really need to think and prioritise what needs to happen next.

precision loss bug
testnet deployments
defi llama api doesnt provide testnet data so the option im thinking is:
use mainnet apy values
acknowledge this unfortunate reality
demonstrate CLY system’s chainlink functionality
what chains?
eth sepolia
base sepolia
polygon mumbai
register with time-based automation on parent chain
get testnet link and eth on each chain
set crosschain vars including local peer for each chain
compound is on all those testnets, aave is only on eth. i can always deploy a mock aave contract that doesnt generate any yield for base and polygon…….

I think once these things are done, then I should get a frontend done asap, along with video, diagrams etc and basically have a “finished” submission so i dont have to stress out for the last week trying to do it. then spend the last week polishing my tests, maybe implement fees. something like that.

OH NICE ONE, COMPOUND. polygon mumbai isnt even the active testnet anymore, it’s amoy. i thought mumbai was old.

well i need at least 3 testnets. eth sepolia and base sepolia it is. im going to need to deploy mocks for both aave and compound on 3rd chain

eth sepolia
aave — Yes
compound — Yes
base sepolia
aave — No — mock it
compound — Yes
chain c
aave — No — mock it
compound — No — mock it

obviously the first thing to consider here is that we wont be generating any actual yield in our testnet strategy mocks BECAUSE we are not actually lending money out to any active markets and dont have enough testnet usdc. but thats ok, we can just deposit and withdraw the usdc we do have without any yield, it wont change anything about our system’s functionality

chain c will probably be optimism because i like the name, better than pessimism. could do avalanche seeing as they’re a sponsor…….. maybe its better off doing it with avalanche. i doubt they’d pick this project as a winner because its not avalanche centric. could even make avalanche the parent chain hehe

ok so next priority is make more mocks for aave and compound

Chromion hackathon: the (brief) invariant testing and formal verification only really highlighted one issue with precision loss. As this could end up being a long rabbithole, the current priority is to get a suitable submission done as quickly as possible, then spend the rest of the hackathon on the vulnerability.

we need to revisit this handleCCIPWithdrawToStrategy_withdrawsFromStrategy for ChildHarness

next steps:

unit test mock aave and compound (no yield) contracts
deploy them on relevant chains
get testnet eth and link
peers must be funded with link
peers must set allowed chains and peers (and their local selves)

Deploying testnet mocks

avalanche needs both the aave and compound

base just needs aave

https://solodit.cyfrin.io/issues/using-atokenbalanceof-in-claggaaveadapter_compoundaccounting-allows-for-inflation-at-tacks-cantina-none-clave-pdf

https://x.com/getreconxyz/status/1933177653961326623 leaving these here for later

alright going with avalanche fuji as the parent chain despite neither of the actual strategy contracts being deployed there. only cus they sponsoring, and you never know might get lucky with a prize.

will we need separate api keys for verifying contracts on snowtrace or whatever the avax explorer is or is etherscan now doing that thing where only one is needed overall?

forge script script/deploy/mocks/DeployMockCometNoYield.s.sol:DeployMockCometNoYield --rpc-url $AVALANCHE_FUJI_RPC_URL --account myKeystore --broadcast

i set access control on the withdraw funcs so nobody (unlikely to happen but just in case) withdraws our test usdc from an active strategy

so will need to remember to call setPeer on the mock pools after deploying the peer contract

https://testnet.snowtrace.io/verifycontract I. HATE. VERIFYING. ON. BLOCK. EXPLORERS.

ok compound mock is verified, but that was an easy one cus no constructor args https://testnet.snowtrace.io/address/0x43a5Ddb9561762D835B6c0f15Cb8a7ed02F6D958/contract/43113/code

forge script script/deploy/mocks/DeployMockAaveNoYield.s.sol --rpc-url $AVALANCHE_FUJI_RPC_URL --account myKeystore --broadcast

0: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3 1: contract MockAaveNoYield 0x546cb5Df0f97CD19b1242fa8cE24e51dA8665f7F 2: contract MockAToken 0x04c3339a6C72Cd783AC3E5C5ea8544D90e458A64

oh wait i forgot the aave addresses provider mock. eurhgghg

lets try that again

0: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3 1: contract MockAaveNoYield 0xc05be4dAf4DB98d061Dd769B685CA7EEF82Eb767 2: contract MockAToken 0x62926eE0AaC06c5378f7eDD2361393f10eC39B5b 3: contract MockPoolAddressesProvider 0xEA8176c28417A6FD2F2e40F871EA04dfFE1CAcd8

i hate flattening files and verifying manually. why cant it just work from the command line everytime

the stuff i already set up with chainlink functions and base sepolia may not work with avalanche. i dont know for definite but the secrets thing might be affected by different don ids or whatever. if it doesnt work, i’ll just use base as parent

why does snowtrace fuji not have the option to verify with an api key? am i just being stupid? do they really expect people to want to deploy on this chain when they cant verify on block explorers easily

fine i’ll just flatten everything and [REDACTED]

oh wow i verified and i didnt need to do ANYTHING with constructor args. i take it back, the verification on snowtrace fuji is actually decent. still a pain having to flatten and then drag and drop the file

~~https://testnet.snowtrace.io/address/0xEA8176c28417A6FD2F2e40F871EA04dfFE1CAcd8/contract/43113/code addresses provider~~

~~https://testnet.snowtrace.io/address/0x62926eE0AaC06c5378f7eDD2361393f10eC39B5b/contract/43113/code aToken~~

i am legit very impressed at the verification on snowtrace testnet. no issues whatsoever so far.

~~https://testnet.snowtrace.io/address/0xc05be4dAf4DB98d061Dd769B685CA7EEF82Eb767/contract/43113/code aavePool~~ ← this one needs to setPeer

could write a script for setting peers, but will probably just use cast send tbh

ok we need to deploy aave on base

forge script script/deploy/mocks/DeployMockAaveNoYield.s.sol --rpc-url $BASE_SEPOLIA_RPC_URL --account myKeystore --broadcast

0: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3 1: contract MockAaveNoYield 0x3C1A3FD4F5eb59c2746BA2BaFB10C4Ef8b745787 2: contract MockAToken 0x6fDbc908533d16983E3c0d91027eA78fd2A84E9B 3: contract MockPoolAddressesProvider 0xC88543241BE4A46Ca5AFC2d44100A0cc767D6B78

should probably double check im using the right usdc address for these. yes i am, but good to make sure.

forge verify-contract \\
 --chain-id 84532 \\
 --etherscan-api-key $BASESCAN_API_KEY \\
 --rpc-url $BASE_SEPOLIA_RPC_URL \\
 0xC88543241BE4A46Ca5AFC2d44100A0cc767D6B78 \\
 ./test/mocks/MockPoolAddressesProvider.sol:MockPoolAddressesProvider \\
 --constructor-args $(cast abi-encode "constructor(address)" "0x3C1A3FD4F5eb59c2746BA2BaFB10C4Ef8b745787") \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

much more dignified than flattening.

forge verify-contract \\
 --chain-id 84532 \\
 --etherscan-api-key $BASESCAN_API_KEY \\
 --rpc-url $BASE_SEPOLIA_RPC_URL \\
 0x6fDbc908533d16983E3c0d91027eA78fd2A84E9B \\
 ./test/mocks/MockAToken.sol:MockAToken \\
 --constructor-args $(cast abi-encode "constructor(address)" "0x3C1A3FD4F5eb59c2746BA2BaFB10C4Ef8b745787") \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

forge verify-contract \\
 --chain-id 84532 \\
 --etherscan-api-key $BASESCAN_API_KEY \\
 --rpc-url $BASE_SEPOLIA_RPC_URL \\
 0x3C1A3FD4F5eb59c2746BA2BaFB10C4Ef8b745787 \\
 ./test/mocks/testnet/MockAaveNoYield.sol:MockAaveNoYield \\
 --constructor-args $(cast abi-encode "constructor(address)" "0x036CbD53842c5426634e7929541eC2318f3dCF7e") \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

ok we’ve deployed and verified our mocks. lovely.

aavepool: https://sepolia.basescan.org/address/0x3c1a3fd4f5eb59c2746ba2bafb10c4ef8b745787#code

aToken: https://sepolia.basescan.org/address/0x6fdbc908533d16983e3c0d91027ea78fd2a84e9b#code

addressProvider: https://sepolia.basescan.org/address/0xc88543241be4a46ca5afc2d44100a0cc767d6b78#code

The next step is to deploy peer contracts

Deploy Peers on testnets

deploy child peer on eth sepolia
deploy child peer on base sepolia
setPeer on mock aave pool
deploy parentCLF on avalanche fuji
setPeer on mock aave pool
setPeer on mock compound pool
add clf consumer
set allowed chains (including local) on all chains
set allowed peers (including local) on all chains
change src.min.js to use testnet selectors

if CLF doesnt work with fuji,

deploy parent CLF on base sep
setPeer on mock aave
add clf consumer
deploy child on avafuji
setpeer aave
setpeer compound

Deploy child peer on eth sepolia

forge script script/deploy/DeployChild.s.sol --rpc-url $ETH_SEPOLIA_RPC_URL --account myKeystore --broadcast

0: contract Share 0x4Ff47A26E792E651e8F7AA055D918901fC9EdDc5 1: contract SharePool 0x6DE0DC29B6de3BEC203383c2d614c61750848BAf 2: contract ChildPeer 0xAF168497dFE7DC261881dd698159a814564ccd7c 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

oh right the shares.

peers need to be funded with link too.

forge verify-contract \\
 --chain-id 11155111 \\
 --etherscan-api-key $ETHERSCAN_API_KEY \\
 --rpc-url $ETH_SEPOLIA_RPC_URL \\
 0x4Ff47A26E792E651e8F7AA055D918901fC9EdDc5 \\
 ./src/token/Share.sol:Share \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

~~eth sep share: https://sepolia.etherscan.io/address/0x4ff47a26e792e651e8f7aa055d918901fc9eddc5#code~~

forge verify-contract \\
 --chain-id 11155111 \\
 --etherscan-api-key $ETHERSCAN_API_KEY \\
 --rpc-url $ETH_SEPOLIA_RPC_URL \\
 0x6DE0DC29B6de3BEC203383c2d614c61750848BAf \\
 ./src/token/SharePool.sol:SharePool \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

why is this not verifying now

seriously why is this not working

oh its missing constructor args duh

forge verify-contract \\
 --chain-id 11155111 \\
 --etherscan-api-key $ETHERSCAN_API_KEY \\
 --rpc-url $ETH_SEPOLIA_RPC_URL \\
 0x19aeA7614a7f2BAb5133F4cb7E0977a04e510677 \\
 ./src/token/SharePool.sol:SharePool \\
 --constructor-args $(cast abi-encode "constructor(address,address,address)" "0xcE287EAB90E809Af9a6d6288c9196e7eB4Fd9584" "0xba3f6251de62dED61Ff98590cB2fDf6871FbB991" "0x0BF3dE8c5D3e8A2B34D2BEeB17ABfCeBaf363A59") \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

still not working. possibly because the first param is of type IBurnMintERC677 and not actually an address….

i changed the sharePool. just gonna run deploy script again so i dont have to call the grantMintBurnRoles again

0: contract Share 0xcE287EAB90E809Af9a6d6288c9196e7eB4Fd9584 1: contract SharePool 0x19aeA7614a7f2BAb5133F4cb7E0977a04e510677 2: contract ChildPeer 0x3CaD05D15B436A4542660e596B59FAC8EB4B38Bd 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

~~eth share: https://sepolia.etherscan.io/address/0xcE287EAB90E809Af9a6d6288c9196e7eB4Fd9584#code~~

~~eth sharePool (NOW its verifying): https://sepolia.etherscan.io/address/0x19aea7614a7f2bab5133f4cb7e0977a04e510677#code~~

oh what did we set the parentChainSelector to for eth.. i bet its base sepolia. for crying out loud.

ok lets deploy child on eth again. third times the charm.

0: contract Share 0xdaB4AA006F411C5BCA2bF3D7561f3f00C1EB2717 1: contract SharePool 0x97cD63e0b8645A9a40B4a86327b9ed9e8EBFF8A0 2: contract ChildPeer 0xF07A080C018AC30a274CD5c9aDc1433078F9541B 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

at least the share and pool are auto verified now

forge verify-contract \\
 --chain-id 84532 \\
 --etherscan-api-key $ETHERSCAN_API_KEY \\
 --rpc-url $BASE_SEPOLIA_RPC_URL \\
 0x9eBa292a8933EA353364C7e5b16498941ac76319 \\
 ./src/peers/ChildPeer.sol:ChildPeer \\
 --constructor-args $(cast abi-encode "constructor(address,address,uint64,address,address,address,address,uint64)" "0x0BF3dE8c5D3e8A2B34D2BEeB17ABfCeBaf363A59" "0x779877A7B0D9E8603169DdbD7836e478b4624789" 16015286601757825753 "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238" "0x012bAC54348C0E635dCAc9D5FB99f06F24136C9A" "0xAec1F48e02Cfb822Be958B68C7957156EB3F0b6e" "0xdaB4AA006F411C5BCA2bF3D7561f3f00C1EB2717" 14767482510784806043) \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

and its not verifying. this is the bit i hate.

the constructor args look right to me

oh i was verifying the wrong contract address

here it is: https://sepolia.etherscan.io/address/0xf07a080c018ac30a274cd5c9adc1433078f9541b#code

Ethereum Sepolia Deployments:

Share/YieldCoin:

https://sepolia.etherscan.io/address/0xdaB4AA006F411C5BCA2bF3D7561f3f00C1EB2717#code

SharePool:

https://sepolia.etherscan.io/address/0x97cD63e0b8645A9a40B4a86327b9ed9e8EBFF8A0#code

ChildPeer:

https://sepolia.etherscan.io/address/0xf07a080c018ac30a274cd5c9adc1433078f9541b#code

I sent the Eth Child Peer 20 LINK. dont think i added a function to withdraw link so hopefully it won’t need to be redeployed. i dont think it will, will just have to set allowed peers

Deploy child peer on base sepolia

forge script script/deploy/DeployChild.s.sol --rpc-url $BASE_SEPOLIA_RPC_URL --account myKeystore --broadcast

0: contract Share 0xAb96743Df71874074628870C0951Bb54C300522c 1: contract SharePool 0x0fc34866bb8558DF68c1259FB04d62187C5A17d6 2: contract ChildPeer 0xe814080e30647a0E7Ce6f73bAAa66BFBDE748501 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

Base Sepolia Deployments

base share/yieldcoin: https://sepolia.basescan.org/address/0xab96743df71874074628870c0951bb54c300522c

base sharePool:

https://sepolia.basescan.org/address/0x0fc34866bb8558df68c1259fb04d62187c5a17d6#code

base ChildPeer:

https://sepolia.basescan.org/address/0xe814080e30647a0e7ce6f73baaa66bfbde748501

sent 20 link to that peer

will need to set ccipGasLimit on these contracts, as well as allowed peers.

Deploy Parent on Avalanche Fuji

aww no this is gonna require that lame flattening thing again

forge script script/deploy/DeployParent.s.sol --rpc-url $AVALANCHE_FUJI_RPC_URL --account myKeystore --broadcast

and now the keystore password is failing to decrypt.

………….

this kind of thing is exactly why im doing this 2 weeks before the submission deadline

WHY DID IT WORK WITH THE MOCKS ON AVALANCHE

Error: Failed to decode return value: 0x

else if (block.chainid == 43113) activeNetworkConfig = getAvalancheFujiConfig();

was missing this line in the helperConfig. worrying if we deployed on fuji earlier for the mock aave stuff, surely that means the correct usdc address wasnt included then.

how do we check

`cast storage

i think its a waste of time checking, i already know

0: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3 1: contract MockAaveNoYield 0x63fe7cd6a0c966ecE0ef94554c451F7a2714E13c 2: contract MockAToken 0x2324080D042eD9b818cA2e7a575c920002Bd2fAB 3: contract MockPoolAddressesProvider 0x5A7707c69738242CEEb22adEe0E24c8C8aff4d0E

at least these are verified now

https://testnet.snowtrace.io/address/0x63fe7cd6a0c966ecE0ef94554c451F7a2714E13c/contract/43113/code

back to deploying parent

0: contract Share 0x53C536023Df836289c44367C3A19e674d407C601 1: contract SharePool 0x3F96E517e33309835430d2cc07c0241Db1219e5C 2: contract ParentCLF 0xf5Ce3A71d39b1e493879b86B3e1e0d6906916a4e 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

oh snowtrace does have the api option for verification https://testnet.snowtrace.io/documentation/recipes/foundry-verification

https://testnet.snowtrace.io/documentation#api-plans cant figure this out though. they want $200 to verify a contract via api? someone needs to fix something here. either the entire thing needs to be redone or the documentation needs serious work because none of these pages are helping.

forge verify-contract — chain-id 43113 0x53C536023Df836289c44367C3A19e674d407C601 ./src/token/Share.sol:Share

https://build.avax.network/docs/dapps/toolchains/foundry#verifying-after-deployment

this didnt help either. why cant snowtrace just have an etherscan api key

forge verify-contract \\
 --chain-id 43113 \\
 --etherscan-api-key $ETHERSCAN_API_KEY \\
 --rpc-url $AVALANCHE_FUJI_RPC_URL \\
 0x53C536023Df836289c44367C3A19e674d407C601 \\
 ./src/token/Share.sol:Share \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

fine [obscenities] i’ll flatten it

ava share: https://testnet.snowtrace.io/address/0x53C536023Df836289c44367C3A19e674d407C601/contract/43113/code

now i need to flatten the share pool and parent clf

“Our API service is designed to provide developers with seamless access to blockchain data across multiple networks. Our free tier allows you to use the API without requiring an API key”

https://build.avax.network/docs/dapps/toolchains/foundry#compile-deploy-and-verify-with-forge

this bit talking about snowtrace api key is out of date

yep

ok let’s flatten the share pool

ok fair enough not having to do constructor args for these flattened files with snowtrace is very convenient

ava sharePool: https://testnet.snowtrace.io/address/0x3F96E517e33309835430d2cc07c0241Db1219e5C/contract/43113/readContract?chainid=43113

Parent:

https://testnet.snowtrace.io/address/0xf5Ce3A71d39b1e493879b86B3e1e0d6906916a4e/contract/43113/readContract?chainid=43113

Deployments (old)

Avalanche Fuji

ParentPeer (Avalanche)

https://testnet.snowtrace.io/address/0xf5Ce3A71d39b1e493879b86B3e1e0d6906916a4e/contract/43113/readContract?chainid=43113

0xf5Ce3A71d39b1e493879b86B3e1e0d6906916a4e

Ethereum Sepolia

ChildPeer (Eth)

https://sepolia.etherscan.io/address/0xf07a080c018ac30a274cd5c9adc1433078f9541b#code

Share/YieldCoin (Eth)

https://sepolia.etherscan.io/address/0xdaB4AA006F411C5BCA2bF3D7561f3f00C1EB2717#code

SharePool (Eth)

https://sepolia.etherscan.io/address/0x97cD63e0b8645A9a40B4a86327b9ed9e8EBFF8A0#code

Base Sepolia

ChildPeer (Base)

https://sepolia.basescan.org/address/0xe814080e30647a0e7ce6f73baaa66bfbde748501

Share/YieldCoin (Base)

https://sepolia.basescan.org/address/0xab96743df71874074628870c0951bb54c300522c

SharePool (Base)

https://sepolia.basescan.org/address/0x0fc34866bb8558df68c1259fb04d62187c5a17d6#code

Mock Aave Pool

https://sepolia.basescan.org/address/0x3c1a3fd4f5eb59c2746ba2bafb10c4ef8b745787#code

Mock Aave Addresses Provider

https://sepolia.basescan.org/address/0xc88543241be4a46ca5afc2d44100a0cc767d6b78#code

Mock aToken

https://sepolia.basescan.org/address/0x6fdbc908533d16983e3c0d91027ea78fd2a84e9b#code

All of these Peers have LINK tokens. now we need a script to set crosschain vars and probably remote token pool stuff

only the parent peer needs its own selector to be allowed i think because of the clf callback check

attack vector to think about:

ccip rebalance tx fails and funds are stuck on chain a
parent.strategy.selector points to chain b
next rebalance call

forge script script/interactions/SetCrosschain.s.sol --account myKeystore --broadcast --rpc-url $ETH_SEPOLIA_RPC_URL

the script works nicely, but its not able to be exactly tested because i cant prank my deployer before running it in unit test on forked fuji because prank and broadcast are incompatible

i need to update the chain selectors in the src.js/src.min.js scripts. then i need to deposit usdc into the parent and register chainlink automation

cast send 0xf5Ce3A71d39b1e493879b86B3e1e0d6906916a4e --rpc-url $AVALANCHE_FUJI_RPC_URL "deposit(uint256)” 20000000 --account myKeystore

cast send 0x5425890298aed601595a70AB815c96711a31Bc65 --rpc-url $AVALANCHE_FUJI_RPC_URL "approve(address,uint256)" 0xf5Ce3A71d39b1e493879b86B3e1e0d6906916a4e 20000000 --account myKeystore

now i cant even deposit into my parent contract

snowtrace frontend gives some wagmi error

and cast send returns

Error: Internal transport error: No such file or directory (os error 2) with /Users/anon/repos/work/contractlevel/hackathons-events/yield/0xb6b55f25

i tried with the selector 0xb6b55f25 and it still didnt work

i should probably go to bed

i think i need to set the peer on the mock aave and compound contracts

i set the peers manually on snowtrace and the peer for mock aave on base.

i just tried to deposit and it failed https://testnet.snowtrace.io/tx/0xff6ce5829cfbb6df371dc6a630b079ad635d4a7e618524edeebbc99cec88d427?chainid=43113

reverting here so the implication is MockAaveNoYield::i_usdc didnt get set correctly.

0xd9003177dc465aaa89e20678675dca7fa5f5cad5

this address isnt anything. is this what the mock aave pool thinks is usdc??? where did it come from?

this is from the mock pool deploy script and what i suspect is the cause of th issue

HelperConfig config = new HelperConfig();
 HelperConfig.NetworkConfig memory networkConfig = config.getActiveNetworkConfig();
 vm.startBroadcast();
 MockAaveNoYield mockAaveNoYield = new MockAaveNoYield(networkConfig.tokens.usdc);

i dont know for sure but i am assuming that because the networkConfig is getting cached BEFORE the broadcast, then the active network config is the local anvil settings, whereas we want the avalanche testnet

lets see what we get

vm.startBroadcast();
        HelperConfig.NetworkConfig memory networkConfig = config.getActiveNetworkConfig();
        console2.log("networkConfig.tokens.usdc", networkConfig.tokens.usdc);
        MockAaveNoYield mockAaveNoYield = new MockAaveNoYield(networkConfig.tokens.usdc);

0: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3 1: contract MockAaveNoYield 0xF07A080C018AC30a274CD5c9aDc1433078F9541B 2: contract MockAToken 0x7B90F28a6eF4597317B02b2805b89bDc07b7AcFA 3: contract MockPoolAddressesProvider 0xc314344EA3676CD43EAc7c9B02B00e6cfE1Af774

== Logs == networkConfig.tokens.usdc 0x5425890298aed601595a70AB815c96711a31Bc65

good this is more like it.

i guess we better

redeploy the parent clf on avalanche, add that as a consumer to clf,
set parent clf peer on new mock aave and old mock compound
redeploy child peer on base and new mock aave
set child peer on mock aave
set allowed chains and peers

we probably dont need to redeploy the shares and sharepools but whatever i cant be bothered rewriting the script

New Deployments

Avalanche Fuji:

0: contract Share 0xc84fAcbCEaaB9dbc27C14fB553b2c25C1b794497 1: contract SharePool 0xAFbfb8e05c865213FdF795eA520C6D2241537Cb1 2: contract ParentCLF 0x7406dBE173967a005585129Df7728caB243BF235 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3 1: contract MockAaveNoYield 0xF07A080C018AC30a274CD5c9aDc1433078F9541B 2: contract MockAToken 0x7B90F28a6eF4597317B02b2805b89bDc07b7AcFA 3: contract MockPoolAddressesProvider 0xc314344EA3676CD43EAc7c9B02B00e6cfE1Af774

Mock comet: 0x43a5Ddb9561762D835B6c0f15Cb8a7ed02F6D958

Base sepolia:

1: contract MockAaveNoYield 0x2Ed4E8435eFf62Eb48E613159a6a5Fe86b19fa16 2: contract MockAToken 0x2891C37D5104446d10dc29eA06c25C6f0cA233Ec 3: contract MockPoolAddressesProvider 0x9bf12E915461A48bc61ddca5f295A0E20BBBa5D7

0: contract Share 0x41a80C30B1DdC0752871393e68D4773E16Ae2fD2 1: contract SharePool 0xAF1B97Bb3f6809813a50cB99c892872b3F0B6EFb 2: contract ChildPeer 0x9eBa292a8933EA353364C7e5b16498941ac76319

forge verify-contract \\
 --chain-id 84532 \\
 --etherscan-api-key $ETHERSCAN_API_KEY \\
 --rpc-url $BASE_SEPOLIA_RPC_URL \\
 0x9eBa292a8933EA353364C7e5b16498941ac76319 \\
 ./src/peers/ChildPeer.sol:ChildPeer \\
 --constructor-args $(cast abi-encode "constructor(address,address,uint64,address,address,address,address,uint64)" "0xD3b06cEbF099CE7DA4AcCf578aaebFDBd6e88a93" "0xE4aB69C077896252FAFBD49EFD26B5D171A32410" 10344971235874465080 "0x036CbD53842c5426634e7929541eC2318f3dCF7e" "0x9bf12E915461A48bc61ddca5f295A0E20BBBa5D7" "0x571621Ce60Cebb0c1D442B5afb38B1663C6Bf017" "0xAb96743Df71874074628870C0951Bb54C300522c" 14767482510784806043) \\
 --compiler-version 0.8.26 \\
 --optimizer-runs 1000000

why is this not working……

oh wrong share address

Successful Deposit Transaction

I have successfully deposited usdc into the CLY system which has deposited it into the current strategy (on parent chain) and minted YieldCoin in return.

https://testnet.snowtrace.io/tx/0x9ac744d0e47176aef4df60b66e6e50901b6bc5bb97e75e722971185e0e13eb82?chainid=43113

Very cool. The next step is adjusting the src.js/src.min.js to use testnet chainselectors and register time based automation, and then we will be able to see if the automated rebalancing actually works

We need: Avalanche, Ethereum, and Base testnet chain selectors

YieldCoin branding

whatever the highest yield is for stablecoins across chains is what you can earn in one click with contract level yield

problem statement: i want to hold my stablecoin and earn the highest possible yield for it without having to monitor opportunities, then manually withdraw, bridge and deposit. YieldCoin abstracts ALL of that away. Deposit your stablecoin into the CLY system from your chain of choice to earn the highest yield from the safest, most reliable services across the web3 ecosystem.

Stablecoin depositors receive a share token in return for their deposits, representing their share of the total value (deposits + yield) in the system. Depositing a stablecoin can also be considered buying YieldCoin. YieldCoin is the share received for depositing into the system, with the basic idea being that a holder will be able to sell for a higher USD value than they bought it. This is because the stablecoin deposits will not go down in value, and reliable yield will be generated. Hence the name YieldCoin.

key invariant: a user must be able to withdraw the usdc amount they deposited — fees. this is definitely broken by the bug we already know

YieldCoin follows the ERC677 and CCT standards for maximum efficiency and interoperability. The YieldCoin CCIP pool is permissionless, allowing holders to move freely across chains.

The more fees CLY generates, ie the more YieldCoin is bought, the more frequent the checks for the highest APY can become, as Chainlink fees are covered.

“one click highest yield”

back to the project

i updated the script to use testnet selectors, i need to set crosschain vars again for every chain

ok did that

i think we’re ready for cla to see if rebalancing works

the automation call worked and the functions callback worked (although i dont see any CLFRequestSent events from my ParentPeer on snowtrace)

HOWEVER the functions computation failed, im pretty sure for the reason that occurred to me earlier which is that i didnt change the secrets in the parentPeer constant and the params used when encrypting that stuff includes the router address, so of course its base sepolia. maybe i’ll just make the parent base sepolia

const secretsManager = new SecretsManager({
      signer: wallet,
      functionsRouterAddress: routerAddress,
      donId: donId,
      // gatewayUrls: [''],
    });

the question right now is, what would be quicker?

deploying parentpeer on base and childpeer on avalanche, setting crosschain vars, and funding child and parent with link again

encrypting secrets with avalanche params, replacing constants in parentPeer, redeploying parentpeer on avalanche, setting crosschain vars, and funding parentpeer with link again

in the time spent thinking about this, one or the other couldve been done. lets just try encrypting secrets again with avalanche params and if too many issues come up from that, then go with the first

Base Secret:

bytes internal constant ENCRYPTED_SECRET =
        hex"1b4e2d1a565a496c987dc6d8303c52370378b6dcecfd8c1a11b7141822be2b3cb96daba5632633858fe0f07fd5ac85b5293101588003a9f260b0c3d1134765de7b9b16bc1d9087affbf117c4b40a259bc618892ade4707190950fd320e239e36e1f16d577e8c9ed52bad67544530dbca3d846dc4b1f3f8eb6c7a6346172762f449be0d5bcfac35dde9a342db2e009d19c87facf05164b6a3ea257c5a687190b38ec8fd117bfc6a27d7da08abb980afb3aca40b71adbf1cf823b6a3b7bda583e3dc76f1e828bb991398c0b0ee96a2b6c5414c86f62e317286480850e80e8d6ab32718640ef44135f7a875b29e757566a823";

Avalanche Secret:

bytes internal constant ENCRYPTED_SECRET = 
		hex"c37b08028a80330e0fb5c784f636424f03660be7ac1007bbdefe1a9456a3008634433ceccdb128bbd58b9c95125b3ad42751e7ba7b01f435833b30a07402ad44832b0110ad06a7c9f764cdb939292e1df97ee18ba46e93b3814ff7e205926ae072100aff074289c22d9eb342e8832790431accc8dd4e9dc868d21d944966f6c67a7574fa09c8d9c67119b0bec146f87f986d7ed9550cedef7e3c75b7feaee0722b4c82295f0c02eab7ecec08c1d22e27906179bc9dd2d11336b42793e13f24c43b2a9b993967551ff7fe619f0a31212538f973efd33d9955ac713b16717a899a17a58e8ee21160814b6464ebff934c35cdd5bd31b50a6074c08ecfb0330e435c2d";

0: contract Share 0xCa2B9703bE8E6188850c16e72d28269C11783486 1: contract SharePool 0x08aa5a8e751e4b04333d3defe3825c63a7bfF642 2: contract ParentCLF 0x7e60c39e5ecE77BC7a011A297F43775FcAbc8A88 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

i should try withdrawing the deposited usdc from the old deployment

Successful withdraw transaction on parent strategy

https://testnet.snowtrace.io/tx/0x42f3a838c9fe316a932eaa4d245d8394a98b0b9ca84049a527b4966dddca7fc1?chainid=43113

to be fair, besides the blockexplorer verification, i do like how fast avalanche’s testnet is

this again, in the interest of time im pretty close to saying disregard avalanche and changing the parent back to base sepolia, since we already know the secret works there

Deployment Steps:

deploy child script — eth
replace config constant eth addresses
fund with link
deploy child script — avax
replace config constant ava addresses
setPeer in aave mock and compound mock
fund with link
deploy parent script — base
replace config constant base addresses
setPeer in aave mock bae
fund with link
run set crosschain vars script for each chain
add functions consumer
approve peer usdc
deposit usdc
register automation

i forgot to change the parent chain selector. that means we need to deploy the eth contracts too

Eth Child Deployment

0: contract Share 0xFF86A7bf3faD9c09AD0BAD7C81FFF95704CA3fF8 1: contract SharePool 0x878782d1AA5E5C2F05acB3f78A63641eBd6FD3B9 2: contract ChildPeer 0xEF394A35140cfbcD0AdCD83334524688b327fD5d

Avalanche Child Deployment

0: contract Share 0x7396A6424479b5EfA37601ac90959e8e684750Cf 1: contract SharePool 0x69ddcF861d49C4d157332aa5854D69E11e0C2d8f 2: contract ChildPeer 0x0b87C25427da8bf1408642D5BC7DaA8246bf60c3

Base Parent Deployment

0: contract Share 0x9f02a7bD79Be3BeaFd1847BD6B308342D6201512 1: contract SharePool 0xC6c48022e8091A091fd0eFcce69234aF45dc9Fb4 2: contract ParentCLF 0x2eCAa0b9724C369EF913af8459561643eC78FAd8

New transactions

deposit into base parent: https://sepolia.basescan.org/tx/0x532ffe95018565ddf9ad058bdf1f2a9cea2a4e576f123451ccea33bc6686d2e9

automation call: https://sepolia.basescan.org/tx/0xe0e041dcd7fbe38025eb967c46d17bbbd1bdf43bce7dc017abd1926a32672584

oops, forgot to set the allowed chain selectors, but the functions callback and computation was a success.

automation call:

https://sepolia.basescan.org/tx/0xcacdfd47362a4fd038221d5c70880542e764d54b3e01c6fd367520071bd5502a

my first reaction to this is that the ccip tx was more gas than the clf callback allowed and that i’d have to implement custom logic or log trigger automation to execute the ccip tx based on the clf callback.

but tenderly is showing a revert happening in the usdc token pool

tx from clf ui: https://sepolia.basescan.org/tx/0xd3b5f26f847d3b1460c6d316b56dae8399766c3b9db534bc41003e025a78138b#eventlog

(
FunctionsRouter
 => 
ParentCLF
)
.
handleOracleFulfillment
(requestId = 0x0099…2a70
0x009984bba5f90090cdb07a86be07364df267ecb8f7bfaf73a12fe69a0bed2a70
, response = 0x0000…0000
0x000000000000000000000000000000000000000000000000de41ba4fc9d91ad90000000000000000000000000000000000000000000000000000000000000000
, err = 0x)
=>
()

why is the destination chain selector 16015286601757825000?

eth sepolia is 16015286601757825753, which is set to allowed in our parent, and the clf callback wouldve returned if the decoded response didnt match that

i made a post in the chainlink discord because this makes no sense

https://sepolia.etherscan.io/address/0x5931822f394babc2aacf4588e98fc77a9f5aa8c9#code

this contract is returned by Router=>EVM2EVMOnRamp).getPoolBySourceToken(0 = 16015286601757825000, sourceTokn =0x036cbd53842c5426634e7929541ec2318f3dcf7e)=(0x5931822f394babc2aacf4588e98fc77a9f5aa8c9)

that’s the weird selector with 0’s, and the address on eth mainnet is HybridLockReleaseUSDCTokenPool, but the sep one is unverified

“lockOrBurnIn = null”

hmmm why is that

the line above that is lockOrBurnIn =

{
"receiver":"0x000000000000000000000000ef394a35140cfbcd0adcd83334524688b327fd5d",
"remoteChainSelector":16015286601757825000,
"originalSender":"0x2ecaa0b9724c369ef913af8459561643ec78fad8",
"amount":"10000000",
"localToken":"0x036cbd53842c5426634e7929541ec2318f3dcf7e"
}

This sounds like my initial reaction was correct. I’ll try this:

comment out ccipSend and see if the rest of the clf callback is a success
ccipSend usdc directly(?)
implement log trigger or whatever automation and see if that fixes it. might just do this last one first

im already using the max clf callback gas limit so i doubt the 2nd reason is the one.

Steps:

deploy parentCLA on base
setPeer on mock aave
copy constants helper config
run set crosschain vars for all chains
approve, deposit usdc
fund with link
register time based auto, set upkeep address
add clf consumer
register log trigger auto, set forwarder

== Return ==
0: contract Share 0x626805176fF3CBB5A9CBA8d8529E972a954516AA
1: contract SharePool 0x216AB6622F264092aefEB759a6F0EF9d4A70C670
2: contract ParentCLA 0x9033781dE2fb23Bc66e8E2701cCCA84644BF7A99
3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3
4: uint64 333
Error: `Unknown1` is above the contract size limit (25375 > 24576).

this isnt good

i’d need to split up the parent contract if i want to implement more than what i’ve got with ParentCLF…….. arghgheheg lets try deploying parentCLF and doing the CLF and ccip separately

DEBUG TEST CONTRACTS:

0: contract Share 0x74eC127bAc1462FF639A12e3a7CB4601d5aB97DF 1: contract SharePool 0xE0C2598a1aC1D6ec120607F1e09caE229aaBD8c8 2: contract ParentCLF 0x2642E586c52E35A7C44995ea74a8A025651ba6BD 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

https://sepolia.basescan.org/tx/0xc0109b56cd996346575c9321af95e3eb4cc38bb28154b53e5adad4676d1f8c8b this tx confirms the CLF callback upto the CCIP tx works fine.

https://sepolia.basescan.org/tx/0x502ff28d3960ca399d610e52f4cb9e98c70f163af681bc25e999ae99ede188b2 this tx confirms the ccip send is working too. https://ccip.chain.link/#/side-drawer/msg/0xce2b94dc57dd5ea358a7d663ea018d609fc7bdbb2c50b7e8acdb017448593e34

soooo yeah looks like the parent needs to be split up into multiple contracts to handle:

CLF
CLA time based
CLA log trigger

these 3 should be 1 contract and then the other parent stuff should be in another

probably

i need to think about this

maybe the log trigger auto can be in a ParentHelper contract, and that calls the ParentCLF

alright ParentHelper is called ParentRebalancer and it implements the log trigger automation to call ccipSend for ParentCLF based on update strategy logs

base sepolia:

0: contract ParentRebalancer 0x14E698b4E5d2883B1Afb9383c0c864f7cf6a7a16

[obscenities]

LOG BASED TRIGGER AUTOMATION IS NOT AVAILABLE ON BASE SEPOLIA

WHY DO THEY DO THAT

The last few days have been a difficult experience

so stressful.

i am so over this hackathon. what a stressful experience.

this is [obscenities] too. everytime i try and look at an address on base sepolia explorer i get this.

manual execution on eth sepolia failed.

im so stressed out now. let’s list the current problems

original CLA → CLF → CCIP rebalance failed (probably cus of too much gas for CLF)
log trigger automation unavailable on base sepolia
ccip tx failing on destination

time constraints i hate time constraints let me work indefinitely

where do we start with these problems? well i applied for base sepolia log trigger automation. dont know why thats needed for testnet.

https://docs.chain.link/ccip/tutorials/evm/programmable-token-transfers-defensive should implement everything missed from this later. but i have bigger problems right now.

ccip tx failing on destination

WHY

https://dashboard.tenderly.co/tx/0xd23373305560114c0cfc1098719e37a373a13ff486f324f98d7768aacdf95f42?trace=0.1.9 tenderly trace

https://docs.chain.link/ccip/concepts/manual-execution#manual-execution

manual execution is failing with 3_000_000 gas limit, so im assuming theres an issue in the logic of the receiver implementation

i think the next step is to focus on the ccipReceive logic. i can keep using the last parent peer i deployed on base to test https://sepolia.basescan.org/address/0x2642e586c52e35a7c44995ea74a8a025651ba6bd

to test the usdc transfer works, im just going to set my eoa to the allowed peer, which should ignore the data and just send the token

https://ccip.chain.link/#/side-drawer/msg/0xc0c35c5125d4805980588e3eeac911165ba22b72d0643461560c7e98aa9953d8

this is the tx sending usdc to eoa from parent

ok lets just read through the defensive thing and see if handling ccipReceive reverts is going to help

i added this stuff in YieldPeer:

function _ccipReceive(Client.Any2EVMMessage memory message)
        internal
        override
        onlyAllowed(message.sourceChainSelector, abi.decode(message.sender, (address)))
    {
        // (CcipTxType txType, bytes memory data) = abi.decode(message.data, (CcipTxType, bytes));
        // emit CCIPMessageReceived(message.messageId, txType, message.sourceChainSelector);
        // _handleCCIPMessage(txType, message.destTokenAmounts, data);
        try this.processMessage(message) {
            // Intentionally empty in this example; no action needed if processMessage succeeds
        } catch (bytes memory err) {
            emit MessageFailed(message.messageId, err);
            return;
        }
    }
    event MessageFailed(bytes32 indexed messageId, bytes err);
    error OnlySelf();
    function processMessage(Client.Any2EVMMessage calldata message) external {
        if (msg.sender != address(this)) revert OnlySelf();
        (CcipTxType txType, bytes memory data) = abi.decode(message.data, (CcipTxType, bytes));
        emit CCIPMessageReceived(message.messageId, txType, message.sourceChainSelector);
        _handleCCIPMessage(txType, message.destTokenAmounts, data);
    }

going to deploy this on eth and try sending to it.

https://ccip.chain.link/#/side-drawer/msg/0x3d7e2b77b5f7662ec86290dfc6bb6752d91ae587f70558310d2071a7c4a083b8

this is the tx we see if that try catch in ccipReceive helps

….waiting for 30 mins………………

B O R I N G

i guess i can write some of the README or update natspec whilst waiting

ok THAT was a successful tx, lets see what happened on the receiver side. yes it emitted message failed https://sepolia.etherscan.io/address/0x02997361644e2dba90f0a2245e87577a0fc0bb2f#events

well this is good because at least we know where we are

The ccipReceive logic is failing

how does this get debugged

this is old eth child without try catch 0xEF394A35140cfbcD0AdCD83334524688b327fD5d

lets run that through tenderly

tenderly ccipreceive param:

{
  "messageId": "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
  "sourceChainSelector": "10344971235874465080",
  "sender": "0x0000000000000000000000002642e586c52e35a7c44995ea74a8a025651ba6bd",
  "data": "0x000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000de41ba4fc9d91ad90000000000000000000000000000000000000000000000000000000000000000",
  "destTokenAmounts": [
    {
      "token": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238",
      "amount": "1000000"
    }
  ]
}

think i accidentally used the try catch contract instead of the old one

but the tenderly trace revealed the error happening at the decoding bit

are we not encoding the txType or something?

function _buildCCIPMessage(
        address receiver,
        IYieldPeer.CcipTxType txType,
        bytes memory data,
        Client.EVMTokenAmount[] memory tokenAmounts,
        uint256 gasLimit,
        address link
    ) internal pure returns (Client.EVM2AnyMessage memory evm2AnyMessage) {
        evm2AnyMessage = Client.EVM2AnyMessage({
            receiver: abi.encode(receiver),
            data: abi.encode(txType, data),
            tokenAmounts: tokenAmounts,
            extraArgs: Client._argsToBytes(Client.GenericExtraArgsV2({gasLimit: gasLimit, allowOutOfOrderExecution: true})),
            feeToken: link
        });
    }

the data should definitely decode to (txType, bytes). our unit tests wouldve failed if this wasnt happening….

maybe this?

// (CcipTxType txType, bytes memory data) = abi.decode(message.data, (CcipTxType, bytes));
        (uint8 ccipTxTypeEnum, bytes memory data) = abi.decode(message.data, (uint8, bytes));
        CcipTxType txType = CcipTxType(ccipTxTypeEnum);
        emit CCIPMessageReceived(message.messageId, txType, message.sourceChainSelector);

wait no that cant be right, i passed the simulated tx the wrong data. i only encoded the strategy, not the tx type too. lets try that again.

it’s reverting in the same place with the correct data

function test_testTest() public {
        IYieldPeer.CcipTxType txType = IYieldPeer.CcipTxType.RebalanceNewStrategy;
        IYieldPeer.Strategy memory strategy =
            IYieldPeer.Strategy({chainSelector: 16015286601757825753, protocol: IYieldPeer.Protocol.Aave});
        bytes memory encodedStrategy = abi.encode(txType, strategy);
        console2.logBytes(encodedStrategy);
    }
    
 Logs:
  0x0000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000de41ba4fc9d91ad90000000000000000000000000000000000000000000000000000000000000000

maybe i should just decode as uint8 and wrap it

oops, was still not encoding properly in simulation. need to encode txType with the encoded strategy, not the txType with the strategy

well that tx was a success…… wtf

so whats the issue then?!?!?!

that simulation was a success because the contract had no usdc, so it didnt attempt to deposit anything in a strategy.

running the simulation with the correct data, shows a revert

so theres a problem with the aave stuff. at least im making progress and not just stuck.

aave thinks the asset is 0x1c7d4b19c6bc7b0d1743fb6116a902737c728 but the address is invalid on sepolia eth https://sepolia.etherscan.io/address/0x1c7d4b19c6bc7b0d1743fb6116a902737c728

usdc should be

0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238

so that address aave is trying is missing 0s

is something weird happening in the protocol operations lib?

if i try to supply manually on aave, i get an error

so the problem is not with my protocol, it is with aave. that’s good. i guess that means if i deploy mock aave contracts on eth and use those, it should work.

im executing this tx anyway so i can debug in tenderly

even when manually supplying usdc to aave on sepolia from an eoa, it results with the same revert. that’s good because it confirms the problem is not with my system.

Well this seems to be where we are at:

need to deploy mocks on eth
need to get approved for log trigger automation on base (if this doesnt happen, need to get the secrets to work for eth sepolia which is a huge pain)

im going to deploy mocks on eth

0: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3 1: contract MockAaveNoYield 0x143A881Dd65a9Ab510AD181A96532aFe97cCE8c5 2: contract MockAToken 0x3571301e1C9037D6E9CB349096e9ea8C1F920566 3: contract MockPoolAddressesProvider 0xf7869E9D4227c53AbCD5b4964fC7f502C2FC7A58

== Logs == networkConfig.tokens.usdc 0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238

i should probably test the compound works on base and eth sepolia

depositing and withdrawing with compound on eth sep works. ok compound works on base too.

i think now its time to redeploy the eth child with the new aave mock and attempt ccip send again

0: contract Share 0x94740bf86f6fAf65020D397968b53eD132f0974f 1: contract SharePool 0x0b87C25427da8bf1408642D5BC7DaA8246bf60c3 2: contract ChildPeer 0x6fDbc908533d16983E3c0d91027eA78fd2A84E9B 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

https://ccip.chain.link/#/side-drawer/msg/0x06ad7536486a4a29d9b43f18878f44420af08c93c0cdf9de2050211c1edb8cd7

ok this is the tx where we will see if ccipSend will successfully deposit into a strategy on the other side

what can i do for the next half hour? i’ll go to the toilet for a start then think about log trigger automation

I need access to log trigger automation on base sepolia. it makes no sense why they would restrict it for a testnet. it was like this over a year ago. i swear so many issues i’ve had with testing chainlink have remained the same for over a year, well usdc not being compatible with ccip local sim and no log trigger automation for base sepolia anyway.

https://sepolia.etherscan.io/address/0x6fdbc908533d16983e3c0d91027ea78fd2a84e9b#events

amazing, the ccipReceive successfully deposited into the aave strategy on eth sepolia from base sepolia

ok so literally all i need is log trigger automation to trigger ccipSend based on CLF callback.

as soon as that is working, i can start the frontend (urgh)

Chromion hackathon: YieldCoin is powered by the Contract Level Yield system, a network of contracts maximizing the highest (and securely reliable) yield for stablecoins across chains, powered entirely by Chainlink

Chromion hackathon: YieldCoin is powered by Contract Level Yield, a system that rebalances stablecoin deposits to maximize yield as securely and reliably as possible, powered entirely by Chainlink

Waiting for Loggo (log trigger auto access)

there is not much time left to get a polished submission (and fix the precision loss bug)

lets assume that chainlink wont grant access to log trigger automation in time, so i need to:

get the encrypted secrets working with eth sepolia
deploy infra with parent on eth sepolia
README
frontend
demo video
submit by 29th

Encrypted secrets on eth sepolia

(for the purpose of using log trigger automation because relying on chainlink to grant access in time is not a good way to work)

i need

basic CLF request contract
rerun encryption scripts with eth sepolia values

ok that worked first time. nice.

Eth encrypted secret is:

Encrypted Secrets (hex): 0x519ffb85c8bd90ed9f422f733082d43d03332a97459dec67e5922c64af61f22c8e0f872f324c884dc55d40cade8d28e111668f614eedb48adb5519e6f1c59cdea63470052378d9d51609209505c061e5c7d5c9a703b1d27f40697c944672b6d917ad539cc5bb5da1d1de79cc4508f4c82a3fb2cd8c8f20589039a372bc419ecdda561f94472033e3fd7d43610d639592653576f506c1d9185077ac3533333998538cfb478885da3ced87752b5bb213adb918d58791e083c59d94a580f2f568c2c35345815d3722f4675f18e4286a851f757e3f8582078c321dbf1193e30112540182260fef5bf97b08ab5565a0de2d0fc3

s_encryptedSecret =
            hex"519ffb85c8bd90ed9f422f733082d43d03332a97459dec67e5922c64af61f22c8e0f872f324c884dc55d40cade8d28e111668f614eedb48adb5519e6f1c59cdea63470052378d9d51609209505c061e5c7d5c9a703b1d27f40697c944672b6d917ad539cc5bb5da1d1de79cc4508f4c82a3fb2cd8c8f20589039a372bc419ecdda561f94472033e3fd7d43610d639592653576f506c1d9185077ac3533333998538cfb478885da3ced87752b5bb213adb918d58791e083c59d94a580f2f568c2c35345815d3722f4675f18e4286a851f757e3f8582078c321dbf1193e30112540182260fef5bf97b08ab5565a0de2d0fc3";
    }

alright what do we need now?

That encrypted secret is in ParentCLF

== Return ==
0: contract Share 0x2Ed4E8435eFf62Eb48E613159a6a5Fe86b19fa16
1: contract SharePool 0x2891C37D5104446d10dc29eA06c25C6f0cA233Ec
2: contract ParentCLF 0xAF1B97Bb3f6809813a50cB99c892872b3F0B6EFb
3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3
4: uint64 5026
Error: `Unknown1` is above the contract size limit (25081 > 24576).
Do you wish to continue? no
Error: User canceled the script.

sigh.

0: contract ParentRebalancer 0x2Ed4E8435eFf62Eb48E613159a6a5Fe86b19fa16

oof

== Return ==
0: contract Share 0x2891C37D5104446d10dc29eA06c25C6f0cA233Ec
1: contract SharePool 0x9bf12E915461A48bc61ddca5f295A0E20BBBa5D7
2: contract ParentCLF 0xc19688E191dEB933B99cc78D94c227784c8062F9
3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3
4: uint64 5026
Error: `Unknown1` is above the contract size limit (24836 > 24576).
Do you wish to continue? [y/n]

Error: Unknown1 is above the contract size limit (24786 > 24576).

slowly getting there….

Error: Unknown1 is above the contract size limit (24776 > 24576).

…

Error: Unknown1 is above the contract size limit (24907 > 24576).

HOW??

Error: Unknown1 is above the contract size limit (24776 > 24576).

ok getting rid of the try catch from the ccipReceive fixed this.

deploy ParentRebalancer on Eth sepolia
update config
deploy ParentCLF
verify contracts on block explorer
update config constants
set peer on mock aave
fund with link
approve and deposit usdc
add CLF consumer
register time based automation
set upkeep address on parent
register log trigger automation
set forwarder on rebalancer
set parentPeer on rebalancer
deploy Child on base
verify on explorer
update config constants
set peer on mock aave
fund with link
deploy avax child too (had to change i_parentSelector)
set crosschain vars script

ParentCLF eth sepolia:

0: contract Share 0x63B99C7a940b6bEf45BcA91cC0f211f0915a05Dd 1: contract SharePool 0x027B7015E7E6C82cEFB99829f4F6FF68C134F650 2: contract ParentCLF 0xBCa5B2baFcEeFc9e3F5aEf3c723dcDc494868dE0 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3 4: uint64 5026

verification not working..why not,….

wrong addressProvider address that’ll be why

forgot to add a setter for parentPeer in parentRebalancer. great.

mock aave pool not withdrawing usdc…… this is a hard project. im so tired. i cant wait for july.

nevermind i guess i set the wrong peer. glad i dont have to spend 40 mins deploying and setting stuff again. didnt even finish the last time

oh wait i do have to redeploy everything cus of the rebalancer thing. well at least i dont have to redeploy the mock aave. my brain. i need rest.

0: contract ParentRebalancer 0x107C9A78c447c99289B84476f53620236114AbAa

0: contract Share 0x37D13c62D2FDe4A400e2018f2fA0e3da6b15718D 1: contract SharePool 0x9CF6491ace3FDD614FB8209ec98dcF98b1e70e4D 2: contract ParentCLF 0xBE679979Eaec355d1030d6f117Ce5B4b5388318E 3: contract HelperConfig 0x5aAdFB43eF8dAF45DD80F4676345b7676f1D70e3

ok now we’re back where we were

Base sep child:

0: contract Share 0x2DF8c615858B479cBC3Bfef3bBfE34842d7AaA90 1: contract SharePool 0xEF13904800eFA60BB1ea5f70645Fc55609F00320 2: contract ChildPeer 0x94563Bfe55D8Df522FE94e7D60D2D949ef21BF1c

Ava fuji child:

0: contract Share 0x2891C37D5104446d10dc29eA06c25C6f0cA233Ec 1: contract SharePool 0x9bf12E915461A48bc61ddca5f295A0E20BBBa5D7 2: contract ChildPeer 0xc19688E191dEB933B99cc78D94c227784c8062F9

Moment of truth

everything is set (i hope) now we wait for the cron job to hopefully trigger CLF which (if better strategy is on different chain) will trigger loggo to ccip rebalance…..

we need to wait 10 minutes. it took like an hour and a half just to deploy and set up all this stuff.

my script on playground is returning base on compound so as long as that doesnt change 10 mins from now we will HOPEFULLY see CLA trigger CLF trigger CLA trigger CCIP aave on eth → compound on base

which is the most important functionality for the entire system

if this gets nailed, i can integrate testnet contracts with frontend, finish that, readme and demo video, and diagrams. we’re close but there’s still a long way to go.

im bracing for this not working. no way will it work.

AAAAAAAND nothing happened.

the time based automation did nothing.

oh wait it was a little bit late

time based auto worked https://sepolia.etherscan.io/tx/0xc8159327d9c76b118c2caa10c9db513cc38c2c7a00e3c2f026df12d2b5e6190a

clf request worked https://sepolia.etherscan.io/tx/0x2521aea1c73c8ace2b5630b74c60857788944479e8dcd8a7a8362a74f8970a8b

log trigger auto worked https://sepolia.etherscan.io/tx/0x1099dbd2cd04403635b820cd17508aa7c56929bc99187b39a543a7b36cd50e4d

ccip rebalance sending….. expected: 21 mins https://ccip.chain.link/#/side-drawer/msg/0xb01894363f416f83171ee994cd043eacf4cc487bc2d8a589229d02c2649ed10b

wew please god let this work

success….

dst tx: https://sepolia.basescan.org/tx/0x35f97388d654b63d80f4d9b88eab11fb4ee16a909862dd19338c8a758565a70c

it didnt deposit to compound, but it did deposit to aave. i guess the strategy changed between my script but hey it worked

it’s alive. IT’S ALIVE. IT FINALLY WORKS. phew that was tough

right what needs to be done now?

finish frontend
integrate onchain testnet contracts
deploy on contractlevel.com
readme
diagrams
demo video
submit
precision loss bug (will probably last til end of hackathon)
fees
additional strategies
svm compatability

Deposit tx from avalanche (chain c) → parent (eth) → strategy (base)

deposit tx: https://testnet.snowtrace.io/tx/0x68b8118e9e9115e8f8956cc05edc06d8fe281f0955a762c830d98a7f87230a06?chainid=43113

deposit to parent: https://ccip.chain.link/#/side-drawer/msg/0x2a996da193b64a4c4c719921655e5fe57d8292914a48572cfafec02c5349bfc7

dst tx: https://sepolia.etherscan.io/tx/0x6685ae8f7c883ab2f83ea43afe838f51b1b8270eab16ebb26cc1782012766fc4

deposit to parent and deposit to strategy: https://ccip.chain.link/tx/0x6685ae8f7c883ab2f83ea43afe838f51b1b8270eab16ebb26cc1782012766fc4

strategy chain deposit: https://sepolia.basescan.org/tx/0x75e0f2ec96dde84126c8ec36f1bc5467c69bdb0b41e5c211e8ab99c65189baa3

deposit callback parent: https://ccip.chain.link/tx/0x75e0f2ec96dde84126c8ec36f1bc5467c69bdb0b41e5c211e8ab99c65189baa3

parent callback:

https://sepolia.etherscan.io/tx/0x905c386823c1bceeb07a51c4d67effff82f8db7e1d16f2349fe2ffd053263f8f

deposit callback child: https://ccip.chain.link/tx/0x905c386823c1bceeb07a51c4d67effff82f8db7e1d16f2349fe2ffd053263f8f

final tx minting yieldcoin/shares based on totalValue from strategy chain and totalShares from parent chain: https://testnet.snowtrace.io/tx/0x4c02081f317a22bc7c2d2768ae8e2e1144e0ad0b36a605fc2158a5b34d903123

Withdraw tx from chain c (avalanche) → parent (eth) → strategy (base)

withdraw initiate with transferAndCall: https://testnet.snowtrace.io/tx/0x1c635d115f41651df0bb29559629e30e82ec8e51f564d73d2bba0a564d8efb0b?chainid=43113

withdraw to parent: https://ccip.chain.link/#/side-drawer/msg/0xc8ebdd6da9a925a7b7e24001f1fc95b8bb650ebee3cbe1cbb9135ed68240d9e7

parent tx where shares are updated: https://sepolia.etherscan.io/tx/0xd6c19a86d0afbd1367cfff0262be838cbfdcf87356767c3b272b0a447269667f

withdraw to strategy: https://ccip.chain.link/tx/0xd6c19a86d0afbd1367cfff0262be838cbfdcf87356767c3b272b0a447269667f#/side-drawer/msg/0xef446fc7fba9cb80ac96fc5fdc69f00fce8a374991828949cdd673373a8bb31b

withdraw from strategy: https://sepolia.basescan.org/tx/0x67271c1cf24250bb942c4e3bc3179ecda9b5bdaa46bda7671a3b4b9415953f70

withdraw callback:

https://ccip.chain.link/tx/0x67271c1cf24250bb942c4e3bc3179ecda9b5bdaa46bda7671a3b4b9415953f70#/side-drawer/msg/0x1e5b3ddf52d453d81d4e1c0ec3c0532c90de025391a7f10b483f3c1083b497a0

withdraw success:

https://testnet.snowtrace.io/tx/0xbf9a7952bfda2561dcc92e07fe0ca58fd50bc2e88f2920fc9f22a0e96f394162

Rebalance old strategy

time based auto: https://sepolia.etherscan.io/tx/0x6c497c76167540e9dadded43c58d2ac29e6ace5a3ed052fcdffa6d9a454e209e

clf callback: https://sepolia.etherscan.io/tx/0x3329aa6610892afcb93ac78d45f0a6b728daa68de4cb4e4920c76a31a5fae7bd

Contract addresses:

Eth Sepolia

ParentRebalancer: https://sepolia.etherscan.io/address/0x107C9A78c447c99289B84476f53620236114AbAa#code

ParentCLF: https://sepolia.etherscan.io/address/0xBE679979Eaec355d1030d6f117Ce5B4b5388318E#code

YieldCoin/share token: https://sepolia.etherscan.io/address/0x37D13c62D2FDe4A400e2018f2fA0e3da6b15718D#code

SharePool (YieldCoin CCIP pool): https://sepolia.etherscan.io/address/0x9CF6491ace3FDD614FB8209ec98dcF98b1e70e4D#code

Base Sepolia

Child: https://sepolia.basescan.org/address/0x94563Bfe55D8Df522FE94e7D60D2D949ef21BF1c#code

YieldCoin/share token: https://sepolia.basescan.org/address/0x2DF8c615858B479cBC3Bfef3bBfE34842d7AaA90#code

SharePool (YieldCoin CCIP pool): https://sepolia.basescan.org/address/0xEF13904800eFA60BB1ea5f70645Fc55609F00320#code

Avalanche Fuji

Child: https://testnet.snowtrace.io/address/0xc19688E191dEB933B99cc78D94c227784c8062F9/contract/43113/code

YieldCoin/share token: https://testnet.snowtrace.io/address/0x2891C37D5104446d10dc29eA06c25C6f0cA233Ec/contract/43113/code

SharePool (YieldCoin CCIP pool): https://testnet.snowtrace.io/address/0x9bf12E915461A48bc61ddca5f295A0E20BBBa5D7/contract/43113/code

Subscriptions:

Time based Automation: https://automation.chain.link/sepolia/31117210370906282501102204715287401599839953899288328641123779399532585169445

Functions: https://functions.chain.link/sepolia/5026#/side-drawer/request/0x80b52e0d902531797ec402eed7dde17f5a3b141de683da3575075785ea3c548a

Log trigger auto: https://automation.chain.link/sepolia/58209442837245803699033621562586311107604180040493444241355605315377029566350

Frontend v0.dev: [REDACTED]

Frontend test txs:

deposit from parent eth to strategy base: https://ccip.chain.link/#/side-drawer/msg/0x4a87ee13ba09e2fc250d96a4c476e03d98f302e375a1b259a48a82bc156a3816

Next steps

finish listing all working deployed contract addresses above
test rebalance old strategy ccipTx
integrate contracts with frontend
frontend background image?
bridge functionality — the frontend will likely have to build the ccip message
readme
diagrams
demo video
ai dramatic cinematic trailer?
successful tests
frontend demo
slideshow presentation

Frontend bridge functionality

ok lets get the frontend to move YieldCoin between chains, so i guess we need it to build a ccip message in the background and use native so dont have to approve link for spending. will probably have to approve the router to spend the yieldcoin because didnt implement transferAndCall for this on the current deployments

/// @dev build CCIP message
Client.EVMTokenAmount[] memory tokenAmounts = new Client.EVMTokenAmount[](1);
tokenAmounts[0] = Client.EVMTokenAmount({token: address(yieldCoin), amount: tokenAmount});
yieldCoin.approve(ccipRouter, tokenAmount);
Client.EVM2AnyMessage memory evm2AnyMessage = Client.EVM2AnyMessage({
            receiver: abi.encode(msg.sender),
            data: "",
            tokenAmounts: tokenAmounts,
            extraArgs: Client._argsToBytes(Client.GenericExtraArgsV2({gasLimit: 3000000, allowOutOfOrderExecution: true})),
            feeToken: address(0)
});
IRouterClient(ccipRouter).ccipSend(destinationChainSelector, evm2AnyMessage);

Yieldcoin bridge tx (executed from frontend) https://ccip.chain.link/tx/0xd0c3e338c66bad81412c92ad7b76681b977464fa85350201b9830bfaf5250956#/side-drawer/msg/0x7f91c48fe14b5d9c6f472afa45551be29d4ff930e51711c99c8e61a980f0ed58

“You know what sucks? Having to do things to make money. YieldCoin solves that by using Chainlink to make money for you.”

i need to clean my laptop its got smudges all over

wew this readme is going to be huge

i think i need to break up what i need for the README and the demo video.

Demo Video

frontend demo
tests passing
certora
pitch deck presentation
brand animation

ReadMe

intro
table of contents
overview
yieldcoin
strategy
contracts/architecture
yieldpeer
libraries
ccip
protocol operations
data structures
iyieldpeer
parent peer
parent clf
parent rebalancer
child peer
chainlink integrations
automation
time-based
log-trigger
functions
src.js (src.min.js)
proxy api
encrypted secrets

video pitch deck

chrome

finish readme

check ai credits for demo video and frontend

IMPORTANT NOTE: AT VERY END, CHECK README CODEBASE LINKS HAVENT CHANGED

See [Parent Withdraw]() and [Child Withdraw]().

even if this project doesn’t win a prize, it’s difficult to think of a better opportunity to spend one’s time than focusing on Chainlink Automation, Functions, CCIP, stablecoins, invariant testing, and Certora formal verification.

many github repos proudly announce they are “built with ❤” — without getting into the validity of such claims, this project definitely wasn’t. this project was built with frustration, stress, intense time management, and towards the end, satisfaction.

“one click highest yield”

unit tests need to be fixed, some of them arent passing. the readme is done for a first draft, took like 7 hours.

Submission todo list:

fix unit tests and invariants
get full coverage on all new code
demo video
run test suite
run certora
finish pitch deck
female ai voice
record voice for frontend demo

review

test_mockAaveNoYield_supply_updatesBalance

Encountered 6 failing tests in test/unit/withdraw/ChildWithdraw.t.sol:ChildWithdrawTest

test_yield_child_onTokenTransfer_revertsWhen_withdrawChainNotAllowed

test_yield_child_withdraw_strategyIsChainC_aave

test_yield_child_withdraw_strategyIsChainC_compound

test_yield_child_withdraw_strategyIsChild_aave

test_yield_child_withdraw_strategyIsChild_aave_withdrawToDifferentChain

test_yield_child_withdraw_strategyIsChild_compound

Encountered 2 failing tests in test/unit/withdraw/ParentWithdraw.t.sol:ParentWithdrawTest

test_yield_parent_withdraw_strategyIsNotParent_aave

test_yield_parent_withdraw_strategyIsNotParent_compound

Encountered 2 failing tests in test/unit/deposit/ParentDeposit.t.sol:ParentDepositTest

test_yield_parent_deposit_strategyIsChild_aave

test_yield_parent_deposit_strategyIsChild_compound

Encountered 4 failing tests in test/unit/deposit/ChildDeposit.t.sol:ChildDepositTest

test_yield_child_deposit_strategyIsChainC_aave

test_yield_child_deposit_strategyIsChainC_compound

test_yield_child_deposit_strategyIsChild_aave

test_yield_child_deposit_strategyIsChild_compound

i imagine this is happening because some previous functionality was commented out and replaced with the rebalancer (i was rushing to get a working testnet demo for submission and so didnt refactor any tests)

lets go through these 1 by 1

i uncommented the old code that was replaced with the rebalancer and all tests are passing again, so yeah of course it was that

this invariant is breaking though invariant_withdrawCompleted_shareBurnUpdate_consistency

well it just did 3000 runs and passed. irritating

i think i need a break before refactoring unit tests. the readme was mentally tiring

Deployed Rebalancer: 0x107C9A78c447c99289B84476f53620236114AbAa

YieldCoin

Introduction

YieldCoin is an automated, crosschain, stablecoin yield optimizer.

It’s built with Chainlink Automation, Functions, and CCIP.

Provides users with the highest yield across chains.

“One click highest yield”

Problem Statement

Monitoring opportunities, withdrawing, bridging, and depositing is time consuming (sucks)
“I want to be able to click one button, and for my stablecoins to securely earn the highest reliable yield.”

Solution

YieldCoin abstracts all of that away, giving users the simplest experience possible to earn the highest yield on their stablecoins

How does it work?

Chainlink Time-based Automation sends a request through Chainlink Functions to get the chain and protocol with the highest APY,

then Chainlink Log-trigger Automation uses CCIP to move funds to where it can earn the highest yield, based on the Chainlink Functions fulfilled request (callback)

YieldCoin

In exchange for depositing stablecoins, users receive YieldCoin

represents their share of the total value in the system

(total value == total deposits + generated yield)

follows ERC677 and CCT standards

Smart Contracts

YieldPeers deployed on every chain

Users can deposit and withdraw on any chain
Interact with Yield generating strategy protocols (ie Aave, Compound)
Communicate via CCIP

Future Developments and Roadmap

support for additional stablecoins (automatic swapping to stablecoins with highest yield)
expansion to more chains
integration of more yield strategies
implementation of fees (and automated chainlink services payments)
SVM compatibility (to access yield opportunities on Solana with CCIP)
CCIP calldata compression (implement solady.lipZip)
DEX integration (allow users to buy yieldcoin with any asset)

FINISH THAT SCRIPT ABOVE

Create presentation/pitch deck

rebalance old strategy

time based: https://sepolia.etherscan.io/tx/0xfb4413c2b8aeb0f2b849c2c962da3407334af3693d63b2112d005438eb1e114b

functions: https://sepolia.etherscan.io/tx/0x99a22014821e742f247cfae3c66b363eae0022b1b8dd5516415ec26ee8389028

log trigger: https://sepolia.etherscan.io/tx/0x90af2045da5f9c65037f8337409cb2c369b1bfd084db965bbc5685e07bcf5d3f

rebalance old strategy: https://ccip.chain.link/#/side-drawer/msg/0x86a09a3f8c59d325703a8d7936834641fdf1b4cab3c25e1a64e38bf5e63d4210

rebalance new strategy: https://ccip.chain.link/tx/0x08689dcb0cb6cc6149788a107e089d811f598ed79867536105280f01d12f8abe#/side-drawer/msg/0xe219bc33fbd5b23d4a564ca3bc0cc917be75cd52d16a850a23a85fbf619ebe86

Pitch deck voice script

Yield coin is an automated, cross-chain, stablecoin yield optimizer. Yield coin has been built with Chainlink Automation, Functions, and CCIP. And offers users the simplest possible experience to maximise their stablecoin yield, in just one click.

Here’s the problem statement: Monitoring opportunities, then manually withdrawing, bridging, and depositing is time consuming.

Yield coin solves that by abstracting it all away, enabling users to consistently and securely earn the highest yield on their stablecoins across the Web3 ecosystem, without any manual input.

So how does it work? There are two simple steps to this process. First, Chainlink time-based automation sends a request through Chainlink Functions to fetch the chain and protocol with the highest APY. Next, Chainlink log-trigger automation uses CCIP to move funds to where it can earn the most yield, based on the fulfilled Chainlink functions request.

In exchange for depositing stablecoins, users receive yield coin, a token that represents their share of the total value in the system, and follows the ERC677 and CCT standards.

A Yield Peer smart contract is deployed on each chain. These contracts allow users to deposit and withdraw their stablecoins on any chain, communicate with each other via CCIP, and interact with yield generating strategy protocols.

None of this would be possible without Chainlink’s reliable services. Automation eliminates the need for human intervention, Functions enables the secure retrieval of optimal yield data, and CCIP facilitates robust crosschain communication and value transfer.

There are a number of planned future developments, such as, support for additional stablecoins, expansion to more chains, integration of more yield strategies, implementation of fees and automation of Chainlink service payments, SVM compatability, CCIP calldata compression, and dex integration.

Thank you for your consideration and the opportunity to build with Chainlink.

Ok, so here is the frontend. These live protocol metrics, are um, demo values, heh. We’ve got a basic introduction, how it works. This page is still missing stuff, like uh.. header and footer, but to be honest.. we um.. there are still things with the actual contracts to improve, so that stuff is taking precedence. We can go into the app, and connect our… uh wallet. I will be using metamask because old habits die hard. Then we are gonna need to approve the contract to spend our USDC. We can see the transaction on the block explorer. Nice. And then we deposit…ahem… then if we go to block explorer… we can see the transaction on the CCIP explorer too. Ok whilst that’s happening, let’s see what else we’ve got. We can withdraw our stablecoin, and we can bridge yield coin with CCIP. The current testnets being used are ethereum, base and avalanche. So yep, we need to approve the CCIP router to transfer the Yield coin….and um..then we can bridge. The UI shows the transaction is now pending, and provides links to the source chain explorer, and the CCIP explorer. So the yield coin is being transferred from ethereum to, uh, avalanche. …and it was a success. On the avalanche explorer, we can see we have received yield coin. Cool. Thanks

The pitch deck video demo is done and so is the frontend demo. Next I need to clean up tests and record a bit of those passing, then I can spend the rest of next week focused on the bug. This project is coming along nicely.

the only thing in my unit coverage that i havent done is the SetCrosschain script. the problem here is it uses vm.startBroadcast and i cant do a prank during a broadcast, so i think i have to deploy all the infrastructure all over again (locally?) and then run it

i am so tired this was a tough week

i’ve reached the last week and, well 9 more days actually and im starting to think the architecture needs overhaul (parent peer split up) — this is in relation to dex/pricefeed integration

ultimately i think that the yield peers should all do protocol operations and ccip operations

parent peer should track state

parent helper/rebalancer does clf/cla

swap peer should do the dex/pricefeed (also deployed across chains)

Unpopular opinion: [REDACTED]

IDEA: USERS SHOULD BE ABLE TO CHOOSE THE YIELD STRATEGIES THEIR STABLECOINS ARE ALLOCATED TO — PROBABLY WOULDNT WORK BECAUSE IT’D BE A NIGHTMARE GETTING TOTAL VALUE — THINK ABOUT THIS

Submission

The problem it solves

describe what can people use it for, or how it makes existing tasks easier/safer e.t.c

There have been numerous times where I have held stablecoins in a wallet, on various chains, and wanted to “put them to work” to earn yield, instead of just sitting there. I end up struggling to find the time to keep up with the best (and safe) opportunities to position my stablecoins (whilst retaining full control and liquidity), then withdrawing, bridging and depositing again. This process is time consuming, burdensome, and boring.

Chainlink’s Automation, Functions, and CCIP components can be combined into the “Contract Level Yield” infrastructure, or “YieldCoin”, to abstract this process away — giving users the simplest possible experience to consistently and securely earn the highest yield on their stablecoins without any manual input.

Please see the README for details on the architecture, Chainlink integrations, deployment, testing, testnet transactions, and more.

Challenges I ran into

tell us about any specific bug or hurdle you ran into while building this project. how did you get over it?

There were many roadblocks of varying size for this submission. The most significant of which is a precision loss/calculation logic bug that became apparent during invariant testing and formal verification.

Precision Loss/Share Calculation Logic Bug

The invariant testing (which began after initially achieving full unit coverage) revealed cases where the amount of YieldCoin minted in exchange for USDC deposits was significantly less than it should have been.

I thought the issue was mitigated with “initial admin deposits” which would go untouched, something like dead shares inflation attack mitigation because the invariant tests were then passing. (I actually need to try minting to address(0) — note to self for after this submission is done).

The issue came up again during formal verification with Certora. Even though initial admin shares were minted, there were still scenarios where the total value of the system and the total shares (YieldCoin) minted (values used to calculate the shareMintAmount of YieldCoin, in exchange for USDC deposits) resulted in 0 YieldCoin minted despite the user depositing USDC - breaking a key invariant of the system: “user’s should always be able to withdraw their deposited amount (minus any fees) shortly after depositing into the system”.

This issue has so far gone unresolved (today is 21st) because of how much a deep rabbit hole it could be, I wanted to get an eligible submission done before focusing on it — because there really is no way to know what other issues would’ve appeared during the testnet deployments and transactions phase.

Other than this bug, the testnet deployments and transactions behaved as intended. All of the Chainlink integrations performed their roles correctly.

Once this submission is done, the rest of the hackathon will be spent on this bug (and hopefully have solved it by the 29th).

Burning small amounts of shares (YieldCoin) can result in no USDC redeemed

I don’t know how closely related the root cause of this is to the previous bug described, but it’s definitely similar, and was made apparent during testing.

The issue is this: if an amount of YieldCoin (18 decimals) worth less than the lowest possible value of USDC (6 decimals) is burned in an attempt to withdraw USDC, no USDC will be withdrawn even though the YieldCoin has been burned.

It’s debatable how critical this issue is, given the unlikelyhood of someone attempting a withdrawal of such a small amount, and ends up benefiting other YieldCoin holders. However it is still unintended behavior of the system, and results in (an insignificant) loss of value.

Further research is required — it may end up being resolved with the previous issue, or it may have a different root cause. Either way, it is a top priority once this submission is done.

USDC chainlink-local fork

This is actually an issue I’ve had with writing ccip tests before. The current chainlink-local ccip simulator is amazing, but unfortunately doesn’t have support for USDC — the stablecoin with the most lanes on CCIP.

To fully test the system on forked mainnets, additional functionality in the CCIPLocalSimulatorFork was required to get past the additional CCTP checks for USDC. CCTP is Circle’s crosschain infrastructure for USDC that works alongside CCIP onchain.

Ultimately the additional functionality required was the monitoring for a CCTP event and pranking the CCTP attesters.

Proxy API

Information pertaining to the “strategy” with the highest yield (ie the chain and the protocol) is fetched from the DefiLlama API which returns a HUGE response. The response was too much for Chainlink Functions, so a proxy API to filter for the relevant data was required.

I made one and deployed it to AWS Lambda. The url for the API could have been abused (unlikely for a hackathon project, but a required consideration for a production ready project) so the url had to be properly encrypted with the functions-toolkit and then stored as a constant in the YieldCoin FunctionsClient contract. This value needed to be different for different chains due to the chain-specific parameters required when executing the encrypted secrets process.

Time management/knowing what to prioritize

There were a lot of parts to this project and knowing which bit to prioritize and when was a challenge. Once the unit coverage was complete I played around with adding more yield strategies and implementing fees, before deciding to focus on invariant tests. More yield strategies wasn’t exactly essential to demonstrate the full functionality of the system itself, and implementing fees was much the same.

As security is so integral to smart contract development, I decided more testing of the system so far was a higher priority than additional features that wouldn’t showcase any more Chainlink use and could be added later.

As previously mentioned, juggling the precision loss/share calculation logic bug and getting an eligible submission done was a time management/priority challenge too.

I didn’t get to implement everything I would’ve liked due to the time constraints, but that just means this project now has a roadmap of future developments.

Functions callback with max gas limit not being able to execute ccip sends

This was a big issue that didn’t become apparent until the testnet stage. The original idea for the rebalancing process went like this: Time-based Automation sends request via Chainlink Functions to fetch yield strategy with highest APY, and then the fulfillRequest callback triggers CCIP rebalance messages.

I suspected the Functions max gas limit may have been the cause of the issue, however the Tenderly calltrace showed the transaction failing on an unrelated revert — very confusing! I ended up asking in the discord hackathon support channel and received a response which led to the confirmation of my initial suspicions.

Solving this issue required a second Automation implementation, to trigger the CCIP rebalance messaged based on the Functions request callback. This could have been done with Custom Logic Automation, but that likely would’ve meant using additional, redundant storage slots, so I opted for Log-trigger Automation. The idea for this being when a better strategy was returned by Chainlink Functions, an event detailing this would be emitted, and then Log-trigger Automation would listen for this event, and execute CCIP rebalance messages based on it.

The chain that would have required the Log-trigger Automation was Base Sepolia, because that is where the ParentPeer/CLF contract (the one that interacts with Chainlink Functions) was deployed.

Log-trigger Automation on Base Sepolia required approval from the Chainlink team, which I applied for and was granted (thanks). However efficiently using the time between needing this functionality and being granted access to it was crucial. I redeployed the entire infrastructure, so that the Parent peer contract was now on Ethereum Sepolia because Log-trigger Automation on that chain did not require preapproval. A few hours after successfully executing the full rebalance transaction, I was granted access on Base Sepolia. I appreciated the fast approval from Chainlink, but the project needed to move ahead.

Certora Formal Verification of contracts that use Chainlink FunctionsRequest library

The Certora prover is a formal verification tool that attempts to explore all paths of a transaction, however it has its limitations — particularly when verifying contracts with “high path count”, because it causes the prover to “timeout” and the verification job stops, incomplete.

In the past I mostly ran into this problem using it on contracts with significant assembly usage, but due to the heavy use of strings and bytes in FunctionsRequest::encodeCBOR(), the prover timed out.

This was solved by adding the nondet_difficult_funcs flag when running Certora, which automatically summarized view/pure functions that were previously non-summarized and difficult for the Prover to verify.

Yield generating strategy protocols either not working on testnet or not existing

Aave and Compound were the protocols chosen as yield generating strategies for this initial prototype. Unfortunately they were not fully available across all required testnets, so I had to use mocks in their place on testnets. These mocks function identically to their official production equivalents, but do not actually generate any yield. They are merely used to demonstrate depositing and withdrawing from these strategies.

DefiLlama API not providing testnet data

Mainnet data was used for the strategy with the highest APY and testnet transactions were based on this.

Incorrect placement of networkConfig cache before vm.startBroadcast in deploy script

This issue caused the wrong USDC address to be set in the constructor for a testnet deployment and was fixed by moving the line caching the networkConfig to after the vm.startBroadcast.

YieldCoin: Crosschain Stablecoin Yield Optimizer

Introduction to YieldCoin

Automated, crosschain, stablecoin yield optimization
Built with Chainlink Automation, Functions and CCIP
One Click Highest Yield

Problem

Monitoring opportunities, then manually withdrawing, bridging and depositing is time consuming

Solution

YieldCoin abstracts all of that away

Users enjoy one-click access to maximum yields across chains and protocols, without any of the headache or time involved with manually managing positions

How does it work?

Step 1:

Chainlink Time-based Automation sends a request through Chainlink Functions to get the chain and protocol with the highest APY

Step 2:

Chainlink Log-trigger Automation uses CCIP to move funds to where it can earn the highest yield, based on the Chainlink Functions fulfillRequest() callback

YieldCoin Token

In exchange for depositing stablecoins, users receive YieldCoin
Represents their share of the total value in the system
Follows ERC677 and CCT standards

Smart Contracts

YieldPeer contracts deployed on every chain
Users can deposit and withdraw stablecoins on any chain
Communicate via CCIP
Interact with yield generating strategy protocols (ie Aave, Compound)

Chainlink Integrations

Chainlink Automation

Enables automated on-chain functions such as yield strategy rebalancing triggered by time schedules and blockchain event logs, ensuring responsive and timely protocol operations.

ALT: Chainlink Automation streamlines yield strategy rebalancing, allowing protocols to adjust strategies automatically based on predefined time schedules and blockchain event logs. This leads to enhanced efficiency and responsiveness in yield optimization processes.

Chainlink Functions

Fetches and processes offchain data from external APIs like DefiLlama via a proxy API, enabling secure retrieval of optimal stablecoin yield strategies for the system.

Cross-Chain Interoperability Protocol (CCIP)

Facilitates robust crosschain communication and value transfers, allowing seamless deposits, withdrawals, and yield allocations across multiple blockchains with robust decentralized security measures.

Future Developments & Roadmap

Support for Additional Stablecoins

Enable automatic swapping to the stablecoin offering the highest yield for greater flexibility.

Expansion to More Chains

Extend multi-chain presence to increase accessibility and diversification opportunities.

Integration of More Yield Strategies

Incorporate additional yield-generating protocols to optimize returns and manage risk.

Implementation of Fees

Introduce automated fee mechanisms including Chainlink subscription top-ups for seamless service.

SVM Compatibility

Develop compatibility with Solana Virtual Machine to access emerging blockchain ecosystems.

CCIP Calldata Compression

Enhance cross-chain communication efficiency by compressing calldata.

Dex Integration

Enable buying YieldCoin with any asset via DEX swaps.

Thank You

@contractlevel

….

CCIP Calldata Compression & Dex Integration

Enhance cross-chain communication efficiency and enable buying YieldCoin with any asset via DEX swaps.

Chromion hackathon: User deposited stablecoins are periodically rotated into the highest yield generating strategy, an automated, crosschain process, secured entirely by the combination of Chainlink services. In return for deposits, users are minted YieldCoin.

Final week

0xf4240 deposit amount

0xde0b6b3a7640001 total value

0xe8d4a51000 total shares

these are the amounts resulting in 0 yield coin minted

so this is still breaking

// @review this is uncovering a critical edgecase bug and needs to be revisited.
rule deposit_mintsShares_when_parent_is_strategy() {
    env e;
    calldataarg args;
    require getStrategy().chainSelector == getThisChainSelector();
    
    uint256 shareSupplyBefore = share.totalSupply();
    uint256 totalSharesBefore = getTotalShares();
    /// @notice simulating initial admin deposit to mitigate inflation attack
    require getTotalValue(e) >= 1000000 && totalSharesBefore >= 1000000000000; // 1 usdc
    deposit(e, args);
    assert share.totalSupply() > shareSupplyBefore;
    assert getTotalShares() > totalSharesBefore;
}

even with something like this in the parent constructor _mintShares(address(0), 1e18);

let’s look at

deposit()

/// @notice Users can deposit USDC into the system via this function
    /// @notice As this is the ParentPeer, we handle two deposit cases:
    /// 1. This Parent is the Strategy
    /// 2. This Parent is not the Strategy
    /// @param amountToDeposit The amount of USDC to deposit into the system
    /// @dev Revert if amountToDeposit is 0
    function deposit(uint256 amountToDeposit) external override {
        _initiateDeposit(amountToDeposit);
        Strategy memory strategy = s_strategy;
        // 1. This Parent is the Strategy. Therefore the deposit is handled here and shares can be minted here.
        if (strategy.chainSelector == i_thisChainSelector) {
            uint256 totalValue = _depositToStrategyAndGetTotalValue(amountToDeposit);
            uint256 shareMintAmount = _calculateMintAmount(totalValue, amountToDeposit);
            s_totalShares += shareMintAmount;
            /// @dev mint share tokens (YieldCoin) to msg.sender based on amount deposited and total value of the system
            _mintShares(msg.sender, shareMintAmount);
            emit ShareMintUpdate(shareMintAmount, i_thisChainSelector, s_totalShares);
        }
        // 2. This Parent is not the Strategy. Therefore the deposit must be sent to the strategy and get totalValue.
        else {
            DepositData memory depositData = _buildDepositData(amountToDeposit);
            _ccipSend(strategy.chainSelector, CcipTxType.DepositToStrategy, abi.encode(depositData), amountToDeposit);
            emit DepositForwardedToStrategy(amountToDeposit, strategy.chainSelector);
        }
    }

certora calltrace

require (ParentHarness.getStrategy()).chainSelector == ParentHarness.getThisChainSelector()

ParentHarness.getStrategy() ↪ {chainSelector=0x2711, protocol=IYieldPeer.Protocol.Aave}

ParentHarness.getThisChainSelector() ↪ 0x2711

(ParentHarness.getStrategy()).chainSelector == ParentHarness.getThisChainSelector() ↪ true

so we’re on the right chain selector, our require is working

ParentPeer._calculateMintAmount(totalValue=0xde0b6b3a7640001, amount=0xf4240) ↪ 0x0

Load from ParentHarness.s_totalShares ↪ 0xe8d4a51000

totalShares ↪ 0xe8d4a51000

i dont know what those numbers are but this is very bad that there is a scenario when someone deposits an amount of stablecoin and get no yieldcoin back when there is also value in the system and other yieldcoin in existence

lets check the numbers

uint256 totalYieldCoin = 0xe8d4a51000;
➜ a
Type: uint256
├ Hex: 0xe8d4a51000
├ Hex (full word): 0x000000000000000000000000000000000000000000000000000000e8d4a51000
└ Decimal: 1000000000000

uint256 totalValue = 0xde0b6b3a7640001;
➜ totalValue
Type: uint256
├ Hex: 0xde0b6b3a7640001
├ Hex (full word): 0x0000000000000000000000000000000000000000000000000de0b6b3a7640001
└ Decimal: 1000000000000000001

uint256 deposit = 0xf4240;
➜ deposit
Type: uint256
├ Hex: 0xf4240
├ Hex (full word): 0x00000000000000000000000000000000000000000000000000000000000f4240
└ Decimal: 1000000

wew this very bad too so

when there’s

1000000000000 many yield coins
1000000000000.000001 this much $ value
$1 this much deposit

that $1 deposit will just disappear

function _calculateMintAmount(uint256 totalValue, uint256 amount) internal view returns (uint256 shareMintAmount) {
        uint256 totalShares = s_totalShares;
        // @review if totalShares isn't 0, then totalValue shouldn't be either.
        if (totalShares == 0 || totalValue == 0) shareMintAmount = amount * INITIAL_SHARE_PRECISION;
        else shareMintAmount = (amount * totalShares) / totalValue;
    }

the sense of who we are is about to change rapidly. humanity, identity, ai, and smart contracts. truly noone understands how bonkers this is about to get.

the rule passes with this:

uint256 numerator = amount * totalShares;
        shareMintAmount = numerator / totalValue;
        if (numerator % totalValue != 0) {
            shareMintAmount += 1; // Round up if there's a remainder
        }

but im not sure im satisfied with that. i had an issue on the testnet with one of the deposits worth $1 was getting less back when withdrawing. maybe problem in withdraw

will really need to verify withdrawals based on the shareBurnAmount $ worth

calculate it somehow

should each of these be using fixedpointmath?

uint256 numerator = amount * totalShares;
shareMintAmount = numerator / totalValue;

trying the solady fixedpointmathlib to see if it does anything

i still suspect the underlying issue is with the calculation itself

this is what NEEDS to happen for this protocol: when a user deposits usdc, they should ALWAYS be able to redeem that same amount (shortly after — some wei difference may occur when depositing in strategy protocols if attempting to withdraw straight after) (and minus any fees)

ok so minting dead shares in the constructor is not possible because the parent peer has not been granted a mint role for the shares until after it is deployed.

using solady.fixedpointmathlib results in a timeout cus of the assembly……….

unit tests arent passing now

trying fixpoint with nondet flag

ok well using full mul div up breaks the unit tests so cant use that

Chromion hackathon: when a user deposits stablecoins, they should ALWAYS be able to redeem that same amount (shortly after — some wei difference may occur when depositing in strategy protocols if attempting to withdraw straight after) (and minus any fees). This invariant is critical to YieldCoin

the mental process of understanding the bug’s relation to the invariant was made quicker with writing certora rules than had it been done in foundry

certora gives you more time for thinking about your system whereas with foundry invariants, so much time is spent setting up the handler, that a lot of the thinking on this side is spent on everything external to your system, then gradually progressing through the entry points

Disclaimer

These smart contracts and code are being provided as is. No guarantee, representation or warranty is being made, express or implied, as to the safety or correctness of the user interface or the smart contracts and code. They have not been audited and as such there can be no assurance they will work as intended, and users may experience delays, failures, errors, omissions or loss of transmitted information. THE SMART CONTRACTS AND CODE CONTAINED HEREIN ARE FURNISHED AS IS, WHERE IS, WITH ALL FAULTS AND WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT OR FITNESS FOR ANY PARTICULAR PURPOSE. Further, use of any of these smart contracts and code may be restricted or prohibited under applicable law, including securities laws, and it is therefore strongly advised for you to contact a reputable attorney in any jurisdiction where these smart contracts and code may be accessible for any questions or concerns with respect thereto. Further, no information provided in this repo should be construed as investment advice or legal advice for any particular facts or circumstances, and is not meant to replace competent counsel. Contract Level is not liable for any use of the foregoing, and users should proceed with caution and use at their own risk.

there is a limit to the things we can think about, and that limit is time, the end of all things

chainlink is digital lego but maths is spiritual lego

i’ll try asking grok:

In the problematic scenario, you provided the following values:

totalShares = 0xe8d4a51000 (decimal: 1,000,000,000,000 or 1e12)
totalValue = 0xde0b6b3a7640001 (decimal: 1,000,000,000,000,000,001 or 1e18 + 1)
amount = 0xf4240 (decimal: 1,000,000 or 1e6, representing 1 USDC with 6 decimals)

The calculation becomes:

shareMintAmount = (amount * totalShares) / totalValue
                = (1,000,000 * 1,000,000,000,000) / 1,000,000,000,000,000,001
                = 1,000,000,000,000,000,000 / 1,000,000,000,000,000,001
                ≈ 0 (due to integer division in Solidity)

Since Solidity performs integer division and discards the remainder, the result is 0. This means a user depositing 1 USDC receives no shares, which violates your protocol’s requirement: users should always be able to redeem their deposited USDC amount (shortly after deposit, barring minor strategy-related differences or fees).

Root Cause

The issue arises because:

Integer Division: When amount * totalShares is less than totalValue, the division yields a quotient less than 1, which Solidity rounds down to 0.
Precision Loss: The large difference in scale between totalShares (1e12) and totalValue (1e18 + 1), combined with a relatively small amount (1e6), exacerbates the problem, making the result vanish in integer arithmetic.

This edge case is critical because it breaks the fundamental invariant of your system: a deposit should mint a proportional number of shares, ensuring users can later withdraw their funds.

what about putting invariant checks in the calculation logic?

in _calculateShareMintAmount the result is compared against _calculateUsdcWithdrawAmount

maybe i should write this invariant in foundry

you know i think we’re gonna need an event for tracking usdc deposits via other chains

DepositUpdate(uint256 amount, uint64 chainSelector) - the sum of amounts emitted by this event should be the total usdc deposited across chains

WithdrawUpdate(uint256 amount, uint64 chainSelector) - the sum of amounts emitted by this event should be the total usdc withdrawn across chains

oh right i dont think we can actually write this in certora due to the crosschain nature of how state is updated in this system and how certora havocs values. this would require significant architectural additions to the certora spec

// invariant totalValue_consistency(env e)
//     getStrategy().chainSelector == getThisChainSelector() => 
//         getTotalValue(e) >= ghost_totalUsdcDeposited - ghost_totalUsdcWithdrawn;

not ideal

[0] VM::startPrank(0x00000000000000004D672A669bC7E8E68E958068)
    │   └─ ← [Return]
    ├─ [24686] MockUsdc::approve(ChildPeer: [0xc7183455a4C133Ae270771860664b6B7ec320bB1], 781452050345 [7.814e11])
    │   ├─ emit Approval(owner: 0x00000000000000004D672A669bC7E8E68E958068, spender: ChildPeer: [0xc7183455a4C133Ae270771860664b6B7ec320bB1], value: 781452050345 [7.814e11])
    │   ├─  storage changes:
    │   │   @ 0x98e02edba7e97f9fb0987e2108e274778fabe1dd804a067e29568f6c02a57774: 0 → 0x000000000000000000000000000000000000000000000000000000b5f22bffa9
    │   └─ ← [Return] true
    ├─ [301302] ChildPeer::deposit(781452050345 [7.814e11])
    │   ├─ [25832] MockUsdc::transferFrom(0x00000000000000004D672A669bC7E8E68E958068, ChildPeer: [0xc7183455a4C133Ae270771860664b6B7ec320bB1], 781452050345 [7.814e11])
    │   │   ├─ emit Transfer(from: 0x00000000000000004D672A669bC7E8E68E958068, to: ChildPeer: [0xc7183455a4C133Ae270771860664b6B7ec320bB1], value: 781452050345 [7.814e11])

so this guy is depositing 781452.050345 USDC and getting 0 shares minted in return. very bad.

thats with this in mint calc

uint256 numerator = amount * totalShares;
        shareMintAmount = (numerator + totalValue - 1) / totalValue; // Ceiling division

ok i got past that bit

if (totalShares == 0) { _mintShares(address(1), 1e18); totalShares = 1e18; // was missing this line } uint256 numerator = amount * totalShares; shareMintAmount = (numerator + totalValue — 1) / totalValue; // Ceiling division

this is where we are now

still dont know if this is the right direction. im just kinda aiming in the dark right now

im pretty sure that logic is not where we want to be going

i think i should go through the invariant calltrace, perhaps add some console logs for deposits and withdraws

TODO:

this didnt work:

// ------------------------------------------------------------//
        /// @notice rule passes with this, but im not satisfied with it
        // if (totalShares == 0 || totalValue == 0) {
        //     shareMintAmount = amount * INITIAL_SHARE_PRECISION;
        // } else {
        //     uint256 numerator = amount * totalShares;
        //     shareMintAmount = numerator / totalValue;
        //     if (numerator % totalValue != 0) {
        //         shareMintAmount += 1; // Round up if there's a remainder
        //     }
        // }
        // ------------------------------------------------------------//
        /// @notice this breaks the unit tests
        // FixedPointMathLib.fullMulDivUp(amount, totalShares, shareMintAmount);
        // shareMintAmount = FixedPointMathLib.fullMulDivUp(amount, totalShares, totalValue);
        // ------------------------------------------------------------//
        // if (totalShares == 0 || totalValue == 0) {
        //     shareMintAmount = amount * INITIAL_SHARE_PRECISION; // e.g., 1e18 for initial mint
        // } else {
        //     uint256 numerator = amount * totalShares;
        //     shareMintAmount = (numerator + totalValue - 1) / totalValue; // Ceiling division
        // }
        // ------------------------------------------------------------//
        // if (totalShares == 0) {
        //     _mintShares(address(1), 1e18);
        //     totalShares = 1e18;
        // }
        // uint256 numerator = amount * totalShares;
        // shareMintAmount = (numerator + totalValue - 1) / totalValue; // Ceiling division
        // ------------------------------------------------------------//
        // // uint256 totalShares = s_totalShares;
        // uint256 virtualShares = 1e12; // Small virtual shares pool
        // uint256 virtualAssets = 1e6; // 1 USDC
        // if (totalShares == 0) {
        //     // Initial case: no admin mint needed, rely on virtual shares
        //     totalShares = virtualShares;
        //     totalValue += virtualAssets;
        // } else {
        //     totalValue += virtualAssets;
        //     totalShares += virtualShares;
        // }
        // uint256 numerator = amount * totalShares;
        // shareMintAmount = (numerator + totalValue - 1) / totalValue; // Ceiling division
        //     // s_totalShares += shareMintAmount; // Update storage

i’ve added some decimal conversion logic and that isnt fixing the issue

/// @param totalValue The total value of the system to 6 decimals
    /// @param amount The amount of USDC deposited
    /// @return shareMintAmount The amount of SHAREs to mint
    /// @notice Returns amount * (SHARE_DECIMALS / USDC_DECIMALS) if there are no shares minted yet
    function _calculateMintAmount(uint256 totalValue, uint256 amount) internal view returns (uint256 shareMintAmount) {
        uint256 totalShares = s_totalShares;
        // @review if totalShares isn't 0, then totalValue shouldn't be either.
        // if (totalShares != 0) shareMintAmount = (amount * totalShares) / totalValue;
        // else shareMintAmount = amount * INITIAL_SHARE_PRECISION;
        // ------------------------------------------------------------
        // uint256 crossChainBalanceConverted = _convertToLPTokenDecimals(totalCrossChainLiquidity);
        // uint256 amountDepositedConverted = _convertToLPTokenDecimals(_amountToDeposit);
        // return
        //     (((crossChainBalanceConverted + amountDepositedConverted) * _totalLPSupply) /
        //         crossChainBalanceConverted) - _totalLPSupply;
        // ------------------------------------------------------------
        if (totalShares == 0) {
            shareMintAmount = amount * INITIAL_SHARE_PRECISION;
        } else {
            uint256 totalValueConverted = _convertUsdcToShare(totalValue);
            uint256 amountDepositedConverted = _convertUsdcToShare(amount);
            shareMintAmount =
                (((totalValueConverted + amountDepositedConverted) * totalShares) / totalValueConverted) - totalShares;
        }
    }

/// @notice Helper function to calculate the USDC withdraw amount
    /// @param totalValue The total value in the Contract Level Yield system
    /// @param totalShares The total shares in the Contract Level Yield system
    /// @param shareBurnAmount The amount of shares the withdrawer burned
    /// @return usdcWithdrawAmount The USDC withdraw amount
    // @review should we be converting decimals here?
    function _calculateWithdrawAmount(uint256 totalValue, uint256 totalShares, uint256 shareBurnAmount)
        internal
        pure
        returns (uint256 usdcWithdrawAmount)
    {
        // usdcWithdrawAmount = (shareBurnAmount * totalValue) / totalShares;
        // ------------------------------------------------------------
        /**
         * function _calculateWithdrawableAmount(
         *     uint256 _childPoolsBalance,
         *     uint256 _clpAmount,
         *     uint256 _lpSupply
         * ) internal view returns (uint256) {
         *     uint256 parentPoolLiquidity = i_USDC.balanceOf(address(this)) +
         *         s_loansInUse +
         *         s_depositsOnTheWayAmount -
         *         s_depositFeeAmount;
         *     uint256 totalCrossChainLiquidity = _childPoolsBalance + parentPoolLiquidity;
         *
         *     //USDC_WITHDRAWABLE = POOL_BALANCE x (LP_INPUT_AMOUNT / TOTAL_LP)
         *     uint256 amountUsdcToWithdraw = (((_convertToLPTokenDecimals(totalCrossChainLiquidity) *
         *         _clpAmount) * PRECISION_HANDLER) / _lpSupply) / PRECISION_HANDLER;
         *
         *     return _convertToUSDCTokenDecimals(amountUsdcToWithdraw);
         * }
         */
        uint256 shareWithdrawAmount =
            (((_convertUsdcToShare(totalValue) * shareBurnAmount) * 1e18) / totalShares) / 1e18;
        usdcWithdrawAmount = _convertShareToUsdc(shareWithdrawAmount);
    }
    function _convertUsdcToShare(uint256 amountInUsdc) internal pure returns (uint256 amountInShare) {
        amountInShare = amountInUsdc * 1e12;
    }
    function _convertShareToUsdc(uint256 amountInShare) internal pure returns (uint256 amountInUsdc) {
        // amountInUsdc = amountInShare / INITIAL_SHARE_PRECISION;
        amountInUsdc = (amountInShare * 1e6) / 1e18;
    }

total value 0xde0b6b3a7640001

deposit amount 0xf4240

total shares 0xe8d4a51000

cant believe still stuck on this

this results in 0 shares minted.

im trying to do a basic unit test just to see if a third depositor can withdraw their amount

function test_withdrawIntegrity_multipleUsers() public {
        address user1 = makeAddr("user1");
        address user2 = makeAddr("user2");
        address user3 = makeAddr("user3");
        deal(address(baseUsdc), user1, DEPOSIT_AMOUNT);
        deal(address(baseUsdc), user2, DEPOSIT_AMOUNT);
        deal(address(baseUsdc), user3, DEPOSIT_AMOUNT);
        _changePrank(user1);
        baseUsdc.approve(address(baseParentPeer), DEPOSIT_AMOUNT);
        baseParentPeer.deposit(DEPOSIT_AMOUNT);
        uint256 expectedShareBalance = DEPOSIT_AMOUNT * INITIAL_SHARE_PRECISION;
        assertEq(baseShare.balanceOf(user1), expectedShareBalance);
        _changePrank(user2);
        baseUsdc.approve(address(baseParentPeer), DEPOSIT_AMOUNT);
        baseParentPeer.deposit(DEPOSIT_AMOUNT);
        _changePrank(user3);
        baseUsdc.approve(address(baseParentPeer), DEPOSIT_AMOUNT);
        baseParentPeer.deposit(DEPOSIT_AMOUNT);
        uint256 shareBalance = baseShare.balanceOf(user3);
        baseShare.transferAndCall(address(baseParentPeer), shareBalance, "");
        assertEq(baseUsdc.balanceOf(user3), DEPOSIT_AMOUNT);
    }

[71371] Share::transferAndCall(ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809], 499999999833333333388 [4.999e20], 0x) │ ├─ emit Transfer(from: user3: [0xc0A55e2205B289a967823662B841Bd67Aa362Aec], to: ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809], value: 499999999833333333388 [4.999e20]) │ ├─ emit Transfer(from: user3: [0xc0A55e2205B289a967823662B841Bd67Aa362Aec], to: ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809], value: 499999999833333333388 [4.999e20], data: 0x) │ ├─ [42773] ParentCLF::onTokenTransfer(user3: [0xc0A55e2205B289a967823662B841Bd67Aa362Aec], 499999999833333333388 [4.999e20], 0x) │ │ ├─ emit SharesBurned(from: user3: [0xc0A55e2205B289a967823662B841Bd67Aa362Aec], amount: 499999999833333333388 [4.999e20]) │ │ ├─ [5100] Share::burn(499999999833333333388 [4.999e20]) │ │ │ ├─ emit Transfer(from: ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809], to: 0x0000000000000000000000000000000000000000, value: 499999999833333333388 [4.999e20]) │ │ │ └─ ← [Stop] │ │ ├─ emit ShareBurnUpdate(shareBurnAmount: 499999999833333333388 [4.999e20], chainSelector: 15971525489660198786 [1.597e19], totalShares: 1500000000000000000000 [1.5e21]) │ │ ├─ emit WithdrawInitiated(withdrawer: user3: [0xc0A55e2205B289a967823662B841Bd67Aa362Aec], amount: 499999999833333333388 [4.999e20], thisChainSelector: 15971525489660198786 [1.597e19]) │ │ ├─ [469] 0xe20fCBdBfFC4Dd138cE8b2E6FBb6CB49777ad64D::getPool() [staticcall] │ │ │ └─ ← [Return] 0xA238Dd80C259a72e81d7e4664a9801593F98d1c5 │ │ ├─ [5223] 0xA238Dd80C259a72e81d7e4664a9801593F98d1c5::getReserveData(0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) [staticcall] │ │ │ ├─ [4540] 0x6EF6B6176091F94A8aD52C08e571F81598b226A2::getReserveData(0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) [delegatecall] │ │ │ │ ├─ [546] 0xe20fCBdBfFC4Dd138cE8b2E6FBb6CB49777ad64D::getAddress(0x4d4f434b5f535441424c455f4445425400000000000000000000000000000000) [staticcall] │ │ │ │ │ └─ ← [Return] 0xaED3b56FeA82E809665f02AcBcDEc0816c75f4d9 │ │ │ │ └─ ← [Return] ReserveData({ configuration: ReserveConfigurationMap({ data: 7237005577332262213973186568752004950073150606504593676736434993981981990220 [7.237e75] }), liquidityIndex: 1093298078607243051141944794 [1.093e27], currentLiquidityRate: 38446223936621012526437616 [3.844e25], variableBorrowIndex: 1126994287780805171877382416 [1.126e27], currentVariableBorrowRate: 52358795901662810505078528 [5.235e25], currentStableBorrowRate: 0, lastUpdateTimestamp: 1750706507 [1.75e9], id: 4, aTokenAddress: 0x4e65fE4DbA92790696d040ac24Aa414708F5c0AB, stableDebtTokenAddress: 0xaED3b56FeA82E809665f02AcBcDEc0816c75f4d9, variableDebtTokenAddress: 0x59dca05b6c26dbd64b5381374aAaC5CD05644C28, interestRateStrategyAddress: 0x86AB1C62A8bf868E1b3E1ab87d587Aba6fbCbDC5, accruedToTreasury: 1039981578 [1.039e9], unbacked: 0, isolationModeTotalDebt: 0 }) │ │ │ └─ ← [Return] ReserveData({ configuration: ReserveConfigurationMap({ data: 7237005577332262213973186568752004950073150606504593676736434993981981990220 [7.237e75] }), liquidityIndex: 1093298078607243051141944794 [1.093e27], currentLiquidityRate: 38446223936621012526437616 [3.844e25], variableBorrowIndex: 1126994287780805171877382416 [1.126e27], currentVariableBorrowRate: 52358795901662810505078528 [5.235e25], currentStableBorrowRate: 0, lastUpdateTimestamp: 1750706507 [1.75e9], id: 4, aTokenAddress: 0x4e65fE4DbA92790696d040ac24Aa414708F5c0AB, stableDebtTokenAddress: 0xaED3b56FeA82E809665f02AcBcDEc0816c75f4d9, variableDebtTokenAddress: 0x59dca05b6c26dbd64b5381374aAaC5CD05644C28, interestRateStrategyAddress: 0x86AB1C62A8bf868E1b3E1ab87d587Aba6fbCbDC5, accruedToTreasury: 1039981578 [1.039e9], unbacked: 0, isolationModeTotalDebt: 0 }) │ │ ├─ [3334] 0x4e65fE4DbA92790696d040ac24Aa414708F5c0AB::balanceOf(ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809]) [staticcall] │ │ │ ├─ [2729] 0x98F409Fc4A42F34AE3c326c7f48ED01ae8cAeC69::balanceOf(ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809]) [delegatecall] │ │ │ │ ├─ [1450] 0xA238Dd80C259a72e81d7e4664a9801593F98d1c5::getReserveNormalizedIncome(0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) [staticcall] │ │ │ │ │ ├─ [845] 0x6EF6B6176091F94A8aD52C08e571F81598b226A2::getReserveNormalizedIncome(0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) [delegatecall] │ │ │ │ │ │ └─ ← [Return] 1093298078607243051141944794 [1.093e27] │ │ │ │ │ └─ ← [Return] 1093298078607243051141944794 [1.093e27] │ │ │ │ └─ ← [Return] 3000000001 [3e9] │ │ │ └─ ← [Return] 3000000001 [3e9] │ │ ├─ [469] 0xe20fCBdBfFC4Dd138cE8b2E6FBb6CB49777ad64D::getPool() [staticcall] │ │ │ └─ ← [Return] 0xA238Dd80C259a72e81d7e4664a9801593F98d1c5 │ │ ├─ [15987] 0xA238Dd80C259a72e81d7e4664a9801593F98d1c5::withdraw(0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913, 750000000062499999983 [7.5e20], ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809]) │ │ │ ├─ [15363] 0x6EF6B6176091F94A8aD52C08e571F81598b226A2::withdraw(0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913, 750000000062499999983 [7.5e20], ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809]) [delegatecall] │ │ │ │ ├─ [2577] 0xe20fCBdBfFC4Dd138cE8b2E6FBb6CB49777ad64D::getPriceOracle() [staticcall] │ │ │ │ │ └─ ← [Return] 0x2Cc0Fc26eD4563A5ce5e8bdcfe1A2878676Ae156 │ │ │ │ ├─ [6588] SupplyLogic::186dea44(00000000000000000000000000000000000000000000000000000000000000340000000000000000000000000000000000000000000000000000000000000036000000000000000000000000000000000000000000000000000000000000003734f9527f09ec799b9026a09dda4338c753ef75fd021c6ce2cfc8bc6671f628fd000000000000000000000000833589fcd6edb6e08f4c7c32d4f71b54bda02913000000000000000000000000000000000000000000000028a8574262f44250ef000000000000000000000000deb1e9a6be7baf84208bb6e10ac9f9bbe1d70809000000000000000000000000000000000000000000000000000000000000000d0000000000000000000000002cc0fc26ed4563a5ce5e8bdcfe1a2878676ae1560000000000000000000000000000000000000000000000000000000000000000) [delegatecall] │ │ │ │ │ ├─ [1021] 0x59dca05b6c26dbd64b5381374aAaC5CD05644C28::scaledTotalSupply() [staticcall] │ │ │ │ │ │ ├─ [419] 0x2425A746911128c2eAA7bEBDc9Bc452eE52208a1::scaledTotalSupply() [delegatecall] │ │ │ │ │ │ │ └─ ← [Return] 0x000000000000000000000000000000000000000000000000000072a1de61950e │ │ │ │ │ │ └─ ← [Return] 0x000000000000000000000000000000000000000000000000000072a1de61950e │ │ │ │ │ ├─ [1296] 0x4e65fE4DbA92790696d040ac24Aa414708F5c0AB::scaledBalanceOf(ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809]) [staticcall] │ │ │ │ │ │ ├─ [691] 0x98F409Fc4A42F34AE3c326c7f48ED01ae8cAeC69::scaledBalanceOf(ParentCLF: [0xDEb1E9a6Be7Baf84208BB6E10aC9F9bbE1D70809]) [delegatecall] │ │ │ │ │ │ │ └─ ← [Return] 0x00000000000000000000000000000000000000000000000000000000a38dfa88 │ │ │ │ │ │ └─ ← [Return] 0x00000000000000000000000000000000000000000000000000000000a38dfa88 │ │ │ │ │ └─ ← [Revert] 32

https://github.com/concero/contracts-v1/blob/master/contracts/ParentPoolCommon.sol

https://github.com/concero/contracts-v1/blob/master/contracts/ParentPool.sol

_calculateLPTokensToMint

_calculateWithdrawableAmount

im following the logic from these exactly

right now im depositing the same usdc amount from 3 users

user 1 gets:

emit SharesMinted(to: user1: [0x29E3b139f4393aDda86303fcdAa35F60Bb7092bF], amount: 1000000000000000000000 [1e21])

user2:

emit SharesMinted(to: user2: [0x537C8f3d3E18dF5517a58B3fB9D9143697996802], amount: 500000000000000000000 [5e20])

user3:

emit SharesMinted(to: user3: [0xc0A55e2205B289a967823662B841Bd67Aa362Aec], amount: 499999999833333333388 [4.999e20])

be aware of:

ParentPeer::_calculateMintAmount()

YieldPeer::_calculateWithdrawAmount()

YieldPeer::_depositToStrategyAndGetTotalValue:

/// @notice Deposits USDC to the strategy and returns the total value of the system
    /// @param amount The amount of USDC to deposit
    /// @return totalValue The total value of the system
    function _depositToStrategyAndGetTotalValue(uint256 amount) internal returns (uint256 totalValue) {
        address strategyPool = _getStrategyPool();
        // @review swapped these lines to get totalValue first
        _depositToStrategy(strategyPool, amount);
        totalValue = _getTotalValueFromStrategy(strategyPool);
        // @review this event
        // is this event only emitted when a user deposits, and not a rebalance?
        // we should have some rebalance events
        emit DepositCompleted(strategyPool, amount, totalValue);
    }

if these lines are in this order:

_depositToStrategy(strategyPool, amount);
totalValue = _getTotalValueFromStrategy(strategyPool);

then invariant_totalValue_integrity passes

if they are swapped (which seems better for share mint amount calc)

the invariant fails because total usdc withdrawn ends up being more than deposited

and on a locally mocked environment with no actual yield generation, the total usdc withdrawn should not be more than the total usdc deposited

if those lines get swapped around, then test_withdrawIntegrity_multipleUsers passes, still not sure about the aprox eq though

also test_yield_parent_deposit_multipleDeposits logic was changed in here, it now works for those 2 lines getting the value before depositing,

but maybe i should just change it so that the calc func uses totalValue — amount instead of totalValue

if (totalShares != 0) {
            shareMintAmount = 
(_convertUsdcToShare(amount) * totalShares) 
/ 
_convertUsdcToShare(totalValue - amount);

i changed the totalValue to totalValue — amount and the invariant fails like that too. its

i forge cleaned lets see if it happens again

It’s a bit alarming [REDACTED]

[24561] Invariant::invariant_totalValue_integrity() ├─ [19306] Handler::forEachChainSelector(0x7fa9385be102ac3eac297483dd6233d62b3e14969b981774) │ ├─ [13994] Invariant::checkTotalValuePerChainSelector(1) │ │ ├─ [2674] ParentCLF::getStrategy() [staticcall] │ │ │ └─ ← [Return] Strategy({ chainSelector: 1, protocol: 0 }) │ │ ├─ [2350] Handler::ghost_event_totalUsdcWithdrawn() [staticcall] │ │ │ └─ ← [Return] 1000135990584 [1e12] │ │ ├─ [2372] Handler::ghost_state_totalUsdcDeposited() [staticcall] │ │ │ └─ ← [Return] 1000099004420 [1e12] │ │ └─ ← [Revert] panic: arithmetic underflow or overflow (0x11)

how is this caused by subtracting the deposit amount from the totalValue in mint calc?

coasting off past glories is a one way ticket to stagnation. nobody cares what you achieved yesterday.

[56349] Invariant::invariant_stablecoinRedemptionIntegrity() ├─ [51101] Handler::forEachUser(0x7fa9385be102ac3eac297483dd6233d62b3e14963cb6a470) │ ├─ [45776] Invariant::checkRedemptionIntegrityPerUser(0x00175C08A08D6247FF697b2532C5ceDe3b60489B) │ │ ├─ [2577] Handler::ghost_state_totalUsdcDepositedPerUser(0x00175C08A08D6247FF697b2532C5ceDe3b60489B) [staticcall] │ │ │ └─ ← [Return] 895935326107 [8.959e11] │ │ ├─ [2554] Handler::ghost_event_totalUsdcWithdrawnPerUser(0x00175C08A08D6247FF697b2532C5ceDe3b60489B) [staticcall] │ │ │ └─ ← [Return] 895935326105 [8.959e11] │ │ ├─ [2580] Share::balanceOf(0x00175C08A08D6247FF697b2532C5ceDe3b60489B) [staticcall] │ │ │ └─ ← [Return] 1 │ │ ├─ [2674] ParentCLF::getStrategy() [staticcall] │ │ │ └─ ← [Return] Strategy({ chainSelector: 1, protocol: 1 }) │ │ ├─ [2552] Handler::chainSelectorsToPeers(1) [staticcall] │ │ │ └─ ← [Return] ParentCLF: [0xF62849F9A0B5Bf2913b396098F7c7019b51A820a] │ │ ├─ [13257] ParentCLF::getTotalValue() [staticcall] │ │ │ ├─ [7431] MockComet::balanceOf(ParentCLF: [0xF62849F9A0B5Bf2913b396098F7c7019b51A820a]) [staticcall] │ │ │ │ └─ ← [Return] 1281036577119 [1.281e12] │ │ │ └─ ← [Return] 1281036577119 [1.281e12] │ │ ├─ [2380] ParentCLF::getTotalShares() [staticcall] │ │ │ └─ ← [Return] 1280159578194766111579939 [1.28e24] │ │ ├─ [380] ParentCLF::getTotalShares() [staticcall] │ │ │ └─ ← [Return] 1280159578194766111579939 [1.28e24] │ │ ├─ [0] VM::assertTrue(false, “Invariant violated: User should be able to withdraw what they deposited”) [staticcall] │ │ │ └─ ← [Revert] Invariant violated: User should be able to withdraw what they deposited

(runs: 1299, calls: 19485, reverts: 0)

quite a few runs, definitely making small progress

[2577] Handler::ghost_state_totalUsdcDepositedPerUser(0x00175C08A08D6247FF697b2532C5ceDe3b60489B) [staticcall] │ │ │ └─ ← [Return] 895935326107 [8.959e11] │ │ ├─ [2554] Handler::ghost_event_totalUsdcWithdrawnPerUser(0x00175C08A08D6247FF697b2532C5ceDe3b60489B) [staticcall] │ │ │ └─ ← [Return] 895935326105 [8.959e11] │ │ ├─ [2580] Share::balanceOf(0x00175C08A08D6247FF697b2532C5ceDe3b60489B) [staticcall] │ │ │ └─ ← [Return] 1

these values are very close. maybe i should account for slippage

function invariant_stablecoinRedemptionIntegrity() public {
        handler.forEachUser(this.checkRedemptionIntegrityPerUser);
    }

function checkRedemptionIntegrityPerUser(address user) external view {
        uint256 deposited = handler.ghost_state_totalUsdcDepositedPerUser(user);
        uint256 withdrawn = handler.ghost_event_totalUsdcWithdrawnPerUser(user);
        uint256 netDeposits = deposited > withdrawn ? deposited - withdrawn : 0;
        uint256 userShares = share.balanceOf(user);
        uint256 totalValue =
            IYieldPeer(handler.chainSelectorsToPeers(parent.getStrategy().chainSelector)).getTotalValue();
        if (parent.getTotalShares() > 0) {
            uint256 withdrawable = (userShares * totalValue) / parent.getTotalShares();
            uint256 minWithdrawable = netDeposits * 99 / 100; // Allow 1% slippage
            assertTrue(
                withdrawable >= minWithdrawable,
                "Invariant violated: User should be able to withdraw what they deposited"
            );
        } else {
            assertTrue(netDeposits == 0, "Invariant violated: User should be able to withdraw what they deposited");
        }
    }

oh i already am.

[Return] 1351340984566 [1.351e12] │ │ ├─ [2554] Handler::ghost_event_totalUsdcWithdrawnPerUser(0x00000000000000000007289B355b95C50D2A6bB6) [staticcall] │ │ │ └─ ← [Return] 1351340984564 [1.351e12] │ │ ├─ [2580] Share::balanceOf(0x00000000000000000007289B355b95C50D2A6bB6) [staticcall] │ │ │ └─ ← [Return] 3

(runs: 2267, calls: 34005, reverts: 0)

lets try again with conversions and console logs:

function checkRedemptionIntegrityPerUser(address user) external view {
        uint256 deposited = handler.ghost_state_totalUsdcDepositedPerUser(user);
        uint256 withdrawn = handler.ghost_event_totalUsdcWithdrawnPerUser(user);
        uint256 netDeposits = deposited > withdrawn ? deposited - withdrawn : 0;
        uint256 userShares = share.balanceOf(user)
        uint256 totalValue =
            IYieldPeer(handler.chainSelectorsToPeers(parent.getStrategy().chainSelector)).getTotalValue();
        uint256 totalValueConverted = _convertUsdcToShare(totalValue);
        if (parent.getTotalShares() > 0) {
            uint256 withdrawable = (userShares * totalValueConverted) / parent.getTotalShares();
            uint256 withdrawableConverted = _convertShareToUsdc(withdrawable);
            uint256 minWithdrawable = netDeposits * 999 / 1000; // Allow 1% slippage
            if (withdrawableConverted < minWithdrawable) {
                console2.log("User:", user);
                console2.log("Deposited:", deposited);
                console2.log("Withdrawn:", withdrawn);
                console2.log("Net Deposits:", netDeposits);
                console2.log("User Shares:", userShares);
                console2.log("Total Value:", totalValue);
                console2.log("Total Shares:", totalShares);
                console2.log("Withdrawable:", withdrawable);
                console2.log("Min Withdrawable:", minWithdrawable);
            }
            assertTrue(
                withdrawableConverted >= minWithdrawable,
                "Invariant violated: User should be able to withdraw what they deposited"
            );
        } else {
            assertTrue(netDeposits == 0, "Invariant violated: User should be able to withdraw what they deposited");
        }
    }

[77933] Invariant::invariant_stablecoinRedemptionIntegrity() ├─ [72685] Handler::forEachUser(0x7fa9385be102ac3eac297483dd6233d62b3e14963cb6a470) │ ├─ [67360] Invariant::checkRedemptionIntegrityPerUser(0xFfFfFfFFfFFFFfffffFfFfFffffffFFfFFFfFFfc) │ │ ├─ [2577] Handler::ghost_state_totalUsdcDepositedPerUser(0xFfFfFfFFfFFFFfffffFfFfFffffffFFfFFFfFFfc) [staticcall] │ │ │ └─ ← [Return] 1000000047700 [1e12] │ │ ├─ [2554] Handler::ghost_event_totalUsdcWithdrawnPerUser(0xFfFfFfFFfFFFFfffffFfFfFffffffFFfFFFfFFfc) [staticcall] │ │ │ └─ ← [Return] 1000000047698 [1e12] │ │ ├─ [2580] Share::balanceOf(0xFfFfFfFFfFFFFfffffFfFfFffffffFFfFFFfFFfc) [staticcall] │ │ │ └─ ← [Return] 3 │ │ ├─ [2674] ParentCLF::getStrategy() [staticcall] │ │ │ └─ ← [Return] Strategy({ chainSelector: 1, protocol: 0 }) │ │ ├─ [2552] Handler::chainSelectorsToPeers(1) [staticcall] │ │ │ └─ ← [Return] ParentCLF: [0xF62849F9A0B5Bf2913b396098F7c7019b51A820a] │ │ ├─ [25666] ParentCLF::getTotalValue() [staticcall] │ │ │ ├─ [154] MockPoolAddressesProvider::getPool() [staticcall] │ │ │ │ └─ ← [Return] MockAavePool: [0x5366ba85D9F7FF951548a0B990E6cc4e56f5A976] │ │ │ ├─ [3955] MockAavePool::getReserveData(MockUsdc: [0x40b4863C923385D1632d640B097DDeA6EaB92e76]) [staticcall] │ │ │ │ └─ ← [Return] ReserveData({ configuration: ReserveConfigurationMap({ data: 0 }), liquidityIndex: 0, currentLiquidityRate: 0, variableBorrowIndex: 0, currentVariableBorrowRate: 0, currentStableBorrowRate: 0, lastUpdateTimestamp: 0, id: 0, aTokenAddress: 0xA8156Cbca2b79bb568d251F44eF88b9EcAF697C4, stableDebtTokenAddress: 0x0000000000000000000000000000000000000000, variableDebtTokenAddress: 0x0000000000000000000000000000000000000000, interestRateStrategyAddress: 0x0000000000000000000000000000000000000000, accruedToTreasury: 0, unbacked: 0, isolationModeTotalDebt: 0 }) │ │ │ ├─ [8291] MockAToken::balanceOf(ParentCLF: [0xF62849F9A0B5Bf2913b396098F7c7019b51A820a]) [staticcall] │ │ │ │ ├─ [7531] MockAavePool::balanceOf(ParentCLF: [0xF62849F9A0B5Bf2913b396098F7c7019b51A820a]) [staticcall] │ │ │ │ │ └─ ← [Return] 100000002 [1e8] │ │ │ │ └─ ← [Return] 100000002 [1e8] │ │ │ └─ ← [Return] 100000002 [1e8] │ │ ├─ [2380] ParentCLF::getTotalShares() [staticcall] │ │ │ └─ ← [Return] 100000000000000000003 [1e20] │ │ ├─ [380] ParentCLF::getTotalShares() [staticcall] │ │ │ └─ ← [Return] 100000000000000000003 [1e20] │ │ ├─ [0] console::log(“User:”, 0xFfFfFfFFfFFFFfffffFfFfFffffffFFfFFFfFFfc) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [0] console::log(“Deposited:”, 1000000047700 [1e12]) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [0] console::log(“Withdrawn:”, 1000000047698 [1e12]) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [0] console::log(“Net Deposits:”, 2) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [0] console::log(“User Shares:”, 3) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [0] console::log(“Total Value:”, 100000002 [1e8]) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [380] ParentCLF::getTotalShares() [staticcall] │ │ │ └─ ← [Return] 100000000000000000003 [1e20] │ │ ├─ [0] console::log(“Total Shares:”, 100000000000000000003 [1e20]) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [0] console::log(“Withdrawable:”, 3) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [0] console::log(“Min Withdrawable:”, 1) [staticcall] │ │ │ └─ ← [Stop] │ │ ├─ [0] VM::assertTrue(false, “Invariant violated: User should be able to withdraw what they deposited”) [staticcall] │ │ │ └─ ← [Revert] Invariant violated: User should be able to withdraw what they deposited

does this mean theres something wrong with my min withdrawable calc

ok this invariant is passing when allowing dust

time to fix the totalValue invariant

well how is this happening

Handler::ghost_event_totalUsdcWithdrawn() [staticcall] │ │ │ └─ ← [Return] 1000135986976 [1e12] │ │ ├─ [2372] Handler::ghost_state_totalUsdcDeposited() [staticcall] │ │ │ └─ ← [Return] 1000099000812

the total withdrawn is more than the total deposited? this is impossible because we arent generating any yield from local deployments

this invariant was passing when the total value in the mint calc included the deposit amount

Logs: total deposited: 100000000 shareMintAmount: 100000000000000000000 Bound result 96979600946188821296820120169 Bound result 999999007606 Bound result 2 depositor: 0x0000000000000001395ba54DA1bb07301C85eA69 depositAmount: 999999007606 total deposited: 1000099007606 shareMintAmount: 999999007606000000000000 Bound result 3 Bound result 0 Bound result 0 Bound result 999999007606000000000000 Bound result 3 Bound result 2 withdrawer: 0x0000000000000001395ba54DA1bb07301C85eA69 shareBurnAmount: 999999007606000000000000 usdc withdraw amount: 1000135993771 total withdrawn: 1000135993771

how are we withdrawing more than we deposited (when no yield is being generated)

the shareBurnAmount is the same as the shareMintAmount so clearly there is some sort of discrepancy between the calculations for minting and withdrawing

stablecoin redemption integrity passes with this withdraw logic:

shareWithdrawAmount = 
(((_convertUsdcToShare(totalValue) * shareBurnAmount) * 1e18) 
/ totalShares) / 1e18;
usdcWithdrawAmount = _convertShareToUsdc(shareWithdrawAmount);

total value integrity passes with this:

(((totalValue * _convertShareToUsdc(shareBurnAmount)) * 1e18) 
/ _convertUsdcToShare(totalShares)) / 1e18;

the invariants need to pass with the same logic

Logs: total deposited: 100.000000 shareMintAmount: 100000000000000000000 depositor: 0x0000000000000000000000000000000000000016 depositAmount: 999999.018749 total deposited: 1000099.018749 shareMintAmount: 999999.018749000000000000 withdrawer: 0x0000000000000000000000000000000000000016 shareBurnAmount: 13506 usdc withdraw amount: 0 total withdrawn: 0 withdrawer: 0x0000000000000000000000000000000000000016 shareBurnAmount: 999999.018748999999986493 usdc withdraw amount: 1000136.004915 total withdrawn: 1000136.004915 totalValue 100.013699 deposited 1000099.018749 withdrawn 1000136.004915

Logs: total deposited: 100000000 shareMintAmount: 100000000000000000000 Bound result 1159529525519484852166244857971432224692093622042 Bound result 999999009307 Bound result 3 depositor: 0xCb1B1a292645f197a1786771c6A613545550971A depositAmount: 999999009307 total deposited: 1000099009307 shareMintAmount: 999999009307000000000000 Bound result 3 Bound result 1 Bound result 0 Bound result 999999009306999999999998 Bound result 2 Bound result 3 inside _calculateWithdrawAmount totalValue 1000236009171 shareBurnAmount 999999009306999999999998 totalShares 1000099009307000000000000 shareWithdrawAmount 1000135995472369891873852 usdcWithdrawAmount 1000135995472 withdrawer: 0xCb1B1a292645f197a1786771c6A613545550971A shareBurnAmount: 999999009306999999999998 usdc withdraw amount: 1000135995472 total withdrawn: 1000135995472 totalValue 100013699 deposited 1000099009307 withdrawn 1000135995472

emit DepositCompleted(strategyPool: MockPoolAddressesProvider: [0x794aC86b74c89e4c4f5722e8cdB15e982ecD1C92], amount: 712274906849 [7.122e11], totalValue: 712374906849 [7.123e11])

[0] console::log(“inside _calculateWithdrawAmount”) [staticcall] │ │ │ │ │ │ │ └─ ← [Stop] │ │ │ │ │ │ ├─ [0] console::log(“totalValue”, 712570091423 [7.125e11]) [staticcall] │ │ │ │ │ │ │ └─ ← [Stop] │ │ │ │ │ │ ├─ [0] console::log(“shareBurnAmount”, 712274906848999999999999 [7.122e23]) [staticcall] │ │ │ │ │ │ │ └─ ← [Stop] │ │ │ │ │ │ ├─ [0] console::log(“totalShares”, 712374906849000000000000 [7.123e23]) [staticcall] │ │ │ │ │ │ │ └─ ← [Stop] │ │ │ │ │ │ ├─ [0] console::log(“shareWithdrawAmount”, 712470064023863376372028 [7.124e23]) [staticcall] │ │ │ │ │ │ │ └─ ← [Stop] │ │ │ │ │ │ ├─ [0] console::log(“usdcWithdrawAmount”, 712470064023 [7.124e11]) [staticcall]

712374906849, 712570091423 why is total value changing here?????

MockComet::balanceOf(ChildPeer: [0xc7183455a4C133Ae270771860664b6B7ec320bB1]) [staticcall] │ │ │ │ │ │ │ └─ ← [Return] 712570091423 [7.125e11]

oh its because i actually am applying an interest rate on the mock comet

function _calculateInterest(address account) internal view returns (uint256) {
        uint256 balance = s_balances[account];
        if (balance == 0) return 0;
        uint256 timeElapsed = block.timestamp - s_lastUpdateTimestamp[account];
        // Calculate interest: balance * rate * time / (365 days * 10000)
        return (balance * s_interestRate * timeElapsed) / (365 days * 10000);
    }

wew what a huge waste of time.

so what the only thing we got from all this was the totalValue including amount prior to being used for share mint calc was a bug

theres still precision edge cases uncovered with certora, but at least users get the correct yieldcoin amount for their stablecoin

great tests arent passing now

great even more tests failing now

why didnt i commit

ALWAYS COMMIT WHEN TESTS PASS

this is very bad.

i dont know what i’ve done

i dont know how to undo this

i tried fixing the totalValue — amount thing across all instances

that caused tests to fail

i tried to undo it

that caused more tests to fail

i tried to undo more

tests still failing

i shouldve committed when they all passed

i was converting the total value before subtracting the amount by mistake

alright back to the edgecase……..

depositAmount 0xf4240–1000000

depositAmountConvertedToShare: 0xde0b6b3a7640000–1000000000000000000

totalValue: 0x56bc75e2d631f4241–100000000000001000001

totalValueConvertedToShare: 0x4ee2d6d415b85acf069d4a51000–100000000000000000001000000000000

totalShares: 0x5af3107a4000–100000000000000

humanity is being held back by [REDACTED]

Edgecase

When someone deposits 1 USDC (1.000000) and there are already 100000000000001.000001 USDC in the system and 100000000000000

wait why is total shares only 0.000100000000000000 yield coin??

uint256 shareSupplyBefore = share.totalSupply();
 uint256 totalSharesBefore = getTotalShares();
 
 require getTotalValue(e) >= 100000000 && 
	 totalSharesBefore >= 100000000000000;
 require share.balanceOf(0) == 10000000000000000000;

    deposit(e, args);

total value should be at least 100 USDC for initial admin deposit

total shares should be whatever that is * 1e12

usd = 100000000

shares = 100000000000000000000

failing

totalShares 0x56bc75e2d63100000 100.000000000000000000

totalValue 0x52b7d2dcc80cd2e40f4241 100000000000000000001.000001

deposit 0xf4240 1.000000

there should never be a case when someone deposits any amount of usdc and gets 0 yieldcoin back

the rule passes if the required values are == to those admin values

but if they are ≥ it fails with the edgecases.

https://medium.com/media/3cefaf9242277598cd49dc8781fbe00c/href

Thing to do before hackathon end

fix video (its got a black bar at the top, probably doesnt matter)
finish all @review comments
refactor rebalancer tests for full rebalancer flow
would need to refactor invariants
formally verify rebalancer

im gonna mitigate the edgecase by rounding up 0 to 1. simple

i verified that the edge case mitigation withdrawal can withdraw 1 usdc. however surely this means that if someone deposits the smallest value of usdc in this instance, they would be able to withdraw 1 usdc in exchange? well we are enforcing a minimum deposit of 1 usdc…..so perhaps that is already mitigated

alright mitigated. let’s think about what needs to happen in the next few days for this hackathon submission to be where it should be.

refactor rebalancer tests for full flow
refactor invariants
finish @review comments
natspec everywhere

ok these are the unit tests that fail when commenting out the old logic the rebalancer replaces:

Failing tests: Encountered 4 failing tests in test/unit/deposit/ChildDeposit.t.sol:ChildDepositTest test_yield_child_deposit_strategyIsChainC_aave test_yield_child_deposit_strategyIsChainC_compound test_yield_child_deposit_strategyIsChild_aave test_yield_child_deposit_strategyIsChild_compound

Encountered 2 failing tests in test/unit/deposit/ParentDeposit.t.sol:ParentDepositTest test_yield_parent_deposit_strategyIsChild_aave test_yield_parent_deposit_strategyIsChild_compound

Encountered 4 failing tests in test/unit/rebalance/Rebalance.t.sol:RebalanceTest test_yield_rebalance_oldChild_newChainC test_yield_rebalance_oldChild_newChild test_yield_rebalance_oldChild_newParent test_yield_rebalance_oldParent_newChild

Encountered 6 failing tests in test/unit/withdraw/ChildWithdraw.t.sol:ChildWithdrawTest test_yield_child_onTokenTransfer_revertsWhen_withdrawChainNotAllowed test_yield_child_withdraw_strategyIsChainC_aave test_yield_child_withdraw_strategyIsChainC_compound test_yield_child_withdraw_strategyIsChild_aave test_yield_child_withdraw_strategyIsChild_aave_withdrawToDifferentChain test_yield_child_withdraw_strategyIsChild_compound

Encountered 2 failing tests in test/unit/withdraw/ParentWithdraw.t.sol:ParentWithdrawTest test_yield_parent_withdraw_strategyIsNotParent_aave test_yield_parent_withdraw_strategyIsNotParent_compound

we can see the common theme between these tests is the parent ones have a remote strategy, child deposit is remote strategy, and all child withdraw is not parent strategy and rebalance is obvious

lets start with the rebalance tests.

4 tests in and i made a new git branch for first time in this project so i dont get all messed up.

im tired i should finish all of this tomorrow

currently on main, switch back

well the good news is the 4 rebalance tests i refactored last night appeared to have solved the issues with the other tests too. very nice. that’s most of todays planned work already done and its only been 5 mins

[FAIL: ParentRebalancer__OnlyForwarder()] test_yield_performUpkeep_rebalanceNewStrategy() (gas: 313628) [FAIL: ParentRebalancer__OnlyForwarder()] test_yield_performUpkeep_rebalanceOldStrategy() (gas: 314992)

next thing to do is refactor the invariant handler to account for the rebalancer

will need to record logs and trigger perform upkeep based on StrategyUpdated(uint64,uint8,uint64)or whatever the event is

alright whats happening here

MockCCIPRouter::ccipSend(1, EVM2AnyMessage({ receiver: 0x000000000000000000000000f62849f9a0b5bf2913b396098f7c7019b51a820a, data: 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000036f90000000000000000000000000000000000000000000000000000000085572ffa000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002, tokenAmounts: [EVMTokenAmount({ token: 0x40b4863C923385D1632d640B097DDeA6EaB92e76, amount: 2237083642 [2.237e9] })], feeToken: 0xc37700132630A8667b38d340d438fce88a8EE7ac, extraArgs: 0x181dcf1000000000000000000000000000000000000000000000000000000000000f42400000000000000000000000000000000000000000000000000000000000000001 })) │ │ ├─ [7604] LinkToken::transferFrom(ChildPeer: [0x5991A2dF15A8F6A256D3Ec51E99254Cd3fb576A9], MockCCIPRouter: [0xde930CFb7f7d3b0daEA517CACf0e9ba25740EDe3], 0) │ │ │ ├─ emit Approval(owner: ChildPeer: [0x5991A2dF15A8F6A256D3Ec51E99254Cd3fb576A9], spender: MockCCIPRouter: [0xde930CFb7f7d3b0daEA517CACf0e9ba25740EDe3], value: 0) │ │ │ ├─ emit Transfer(from: ChildPeer: [0x5991A2dF15A8F6A256D3Ec51E99254Cd3fb576A9], to: MockCCIPRouter: [0xde930CFb7f7d3b0daEA517CACf0e9ba25740EDe3], value: 0) │ │ │ └─ ← [Return] true │ │ ├─ [25832] MockUsdc::transferFrom(ChildPeer: [0x5991A2dF15A8F6A256D3Ec51E99254Cd3fb576A9], ParentCLF: [0xF62849F9A0B5Bf2913b396098F7c7019b51A820a], 2237083642 [2.237e9]) │ │ │ ├─ emit Transfer(from: ChildPeer: [0x5991A2dF15A8F6A256D3Ec51E99254Cd3fb576A9], to: ParentCLF: [0xF62849F9A0B5Bf2913b396098F7c7019b51A820a], value: 2237083642 [2.237e9]) │ │ │ ├─ storage changes: │ │ │ │ @ 0xb3024e141922907eb80bf787d622b0c592108908135c35e38e6ebb7d5636f1e4: 0 → 0x0000000000000000000000000000000000000000000000000000000085572ffa │ │ │ │ @ 0xf1157ff065e42696f046943c33a24ea6ea46f75c9e546ff6f6f449afdd65d2e4: 0x0000000000000000000000000000000000000000000000000000000085572ffa → 0 │ │ │ │ @ 0x6aabb5e3159f63e459180f984db14c38dd83524ae5f05f37086f1b3a53e50715: 0x0000000000000000000000000000000000000000000000000000000085572ffa → 0 │ │ │ └─ ← [Return] true │ │ ├─ [413] ParentCLF::supportsInterface(0x01ffc9a7) [staticcall] │ │ │ └─ ← [Return] true │ │ ├─ [413] ParentCLF::supportsInterface(0xffffffff) [staticcall] │ │ │ └─ ← [Return] false │ │ ├─ [396] ParentCLF::supportsInterface(0x85572ffb) [staticcall] │ │ │ └─ ← [Return] true │ │ ├─ [14710] ParentCLF::ccipReceive(Any2EVMMessage({ messageId: 0x2cc206d4306516d763869c8e287e2d231440722a22ae8354ca1f094999da4772, sourceChainSelector: 2, sender: 0x0000000000000000000000005991a2df15a8f6a256d3ec51e99254cd3fb576a9, data: 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000036f90000000000000000000000000000000000000000000000000000000085572ffa000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002, destTokenAmounts: [EVMTokenAmount({ token: 0x40b4863C923385D1632d640B097DDeA6EaB92e76, amount: 2237083642 [2.237e9] })] })) │ │ │ ├─ emit CCIPMessageReceived(messageId: 0x2cc206d4306516d763869c8e287e2d231440722a22ae8354ca1f094999da4772, txType: 0, sourceChainSelector: 2) │ │ │ └─ ← [Revert] panic: arithmetic underflow or overflow (0x11)

i think the 0 tx type is deposit to parent

yeah

hm. i think this is caused by subtracting the amount from total value

lets see if we can just address the root of this issue

Failing tests: Encountered 1 failing test in test/invariant/Invariant.t.sol:Invariant [FAIL: Invariant violated: User should be able to withdraw what they deposited, except for left over dust]

invariant_stablecoinRedemptionIntegrity() (runs: 4, calls: 60, reverts: 0)

Encountered 2 failing tests in test/unit/deposit/ChildDeposit.t.sol:ChildDepositTest [FAIL: assertion failed: 1 != 1000000000000000000000] test_yield_child_deposit_strategyIsChild_aave() (gas: 1329910) [FAIL: assertion failed: 1 != 1000000000000000000000] test_yield_child_deposit_strategyIsChild_compound() (gas: 1182148)

Encountered 4 failing tests in test/unit/withdraw/ChildWithdraw.t.sol:ChildWithdrawTest [FAIL: assertion failed: 1 != 1000000000000000000000] test_yield_child_onTokenTransfer_revertsWhen_withdrawChainNotAllowed() (gas: 1330020) [FAIL: ERC20: transfer amount exceeds balance] test_yield_child_withdraw_strategyIsChild_aave() (gas: 1469167) [FAIL: ERC20: transfer amount exceeds balance] test_yield_child_withdraw_strategyIsChild_aave_withdrawToDifferentChain() (gas: 1469567) [FAIL: ERC20: transfer amount exceeds balance] test_yield_child_withdraw_strategyIsChild_compound() (gas: 1330161)

interesting

what did we break here

i think maybe this may fix….?

if (totalShares != 0 || (totalShares != 0 && totalValue != 0)) {
            // if (totalShares != 0 || totalValue != 0) {

invariant_stablecoinRedemptionIntegrity() (runs: 9, calls: 135, reverts: 0)

Encountered a total of 1 failing tests, 132 tests succeeded

interesting.

alright finished refactoring unit and invariant tests for the rebalancer

time to refactor certora

ToDO: update readme

back to certora

certoraRun ./certora/conf/child/BaseChild.conf
certoraRun ./certora/conf/parent/BaseParent.conf

certoraRun ./certora/conf/parent/Parent.conf
certoraRun ./certora/conf/child/Child.conf

certoraRun ./certora/conf/Yield.conf

certoraRun ./certora/conf/parent/ParentCLF.conf --nondet_difficult_funcs

certoraRun ./certora/conf/parent/Parent.conf --rule setStrategy_movesStrategyToNewChain setStrategy_forwardsRebalanceToOldStrategy

certoraRun ./certora/conf/child/Child.conf --rule handleCCIPWithdrawToStrategy_withdrawsFromStrategy

i think maybe these can be deleted and replaced with rebalance/r rules

// @review refactor
rule setStrategy_movesStrategyToNewChain() {
    env e;
    uint64 chainSelector;
    IYieldPeer.Protocol protocol;
    IYieldPeer.Strategy oldStrategy = getStrategy();
    require oldStrategy.chainSelector != chainSelector &&
            oldStrategy.chainSelector == getThisChainSelector();
    uint256 totalValue = getTotalValue(e);
    require totalValue > 0;
    address strategyPool = getStrategyPool();
    uint256 compoundBalanceBefore = usdc.balanceOf(getCompound());
    uint256 aaveBalanceBefore = usdc.balanceOf(addressesProvider.getPool());
    require strategyPool == getCompound() => compoundBalanceBefore - totalValue >= 0;
    require strategyPool == getAave() => aaveBalanceBefore - totalValue >= 0;
    require usdc.balanceOf(currentContract) == 0;
    require ghost_strategyUpdated_eventCount == 0;
    require ghost_ccipMessageSent_eventCount == 0;
    setStrategy(e, chainSelector, protocol);
    assert ghost_strategyUpdated_eventCount == 1;
    assert ghost_ccipMessageSent_eventCount == 1;
    assert ghost_ccipMessageSent_txType_emitted == 8; // RebalanceNewStrategy
    assert ghost_ccipMessageSent_bridgeAmount_emitted == totalValue;
    assert strategyPool == getCompound() => usdc.balanceOf(getCompound()) == compoundBalanceBefore - totalValue;
    assert strategyPool == getAave() => usdc.balanceOf(addressesProvider.getPool()) == aaveBalanceBefore - totalValue;
}
// @review refactor
rule setStrategy_forwardsRebalanceToOldStrategy() {
    env e;
    uint64 chainSelector;
    IYieldPeer.Protocol protocol;
    IYieldPeer.Strategy oldStrategy = getStrategy();
    require oldStrategy.chainSelector != getThisChainSelector() &&
            oldStrategy.chainSelector != chainSelector;
    require ghost_ccipMessageSent_eventCount == 0;
    setStrategy(e, chainSelector, protocol);
    assert ghost_ccipMessageSent_eventCount == 1;
    assert ghost_ccipMessageSent_txType_emitted == 7; // RebalanceOldStrategy
    assert ghost_ccipMessageSent_bridgeAmount_emitted == 0;
}

doing the child spec

handleCCIPWithdrawToStrategy_withdrawsFromStrategy

withdraw amount is 0x2713

but this says withdraw amount is 0

probably because this is a dummy value

need to calculate expected withdraw

usdcWithdrawAmount =
_calculateWithdrawAmount(totalValue, totalShares, shareBurnAmount);

nice already had a harness helper function for this

oh this rule shouldnt be considering the user balance because its just verifying the function withdraws from the strategy we have other rules for the next 2 behaviours

not sure why this rule wasnt flagged earlier

certoraRun ./certora/conf/parent/Parent.conf

alright thats done what next

should push this, merge the branch, and start a new branch for more certora

actually i’ll just continue on this branch for a bit and verify the rebalancer behaves as intended

certoraRun ./certora/conf/parent/Rebalancer.conf

ADD THAT TO README!!!111

ToDo:

rebalancer verify
@review comments
natspec
mutation testing
readme update (maybe mention frontend code)
video fix (maybe)
improve frontend

i could fix the black bar at the top of the video or improve the frontend or I could do some mutation testing.

working through things in the codebase flagged for review. this habit was inspired by cyfrin’s security/auditing course

// @review this event
        // is this event only emitted when a user deposits, and not a rebalance?
        // we should have some rebalance events
        emit DepositToStrategyCompleted(strategyPool, amount, totalValue);

perhaps the withdraw update should only emit the chain selector since we cant get the amount usdc

Coverage report

HOW is ParentRebalancer not being hit??????

oh its because cannotExecute.

Uncovered for src/modules/ParentRebalancer.sol:

Line (location: source ID 162, lines 57..58, bytes 3085..3159, hits: 0)
Statement (location: source ID 162, lines 57..58, bytes 3085..3159, hits: 0)
Statement (location: source ID 162, lines 57..58, bytes 3110..3159, hits: 0)
Line (location: source ID 162, lines 58..59, bytes 3169..3202, hits: 0)
Statement (location: source ID 162, lines 58..59, bytes 3169..3202, hits: 0)
Line (location: source ID 162, lines 59..60, bytes 3212..3285, hits: 0)
Statement (location: source ID 162, lines 59..60, bytes 3212..3285, hits: 0)
Statement (location: source ID 162, lines 59..60, bytes 3239..3285, hits: 0)
Line (location: source ID 162, lines 60..61, bytes 3295..3326, hits: 0)
Statement (location: source ID 162, lines 60..61, bytes 3295..3326, hits: 0)
Line (location: source ID 162, lines 62..63, bytes 3341..3400, hits: 0)
Statement (location: source ID 162, lines 62..63, bytes 3341..3400, hits: 0)
Statement (location: source ID 162, lines 62..63, bytes 3341..3365, hits: 0)
Statement (location: source ID 162, lines 62..63, bytes 3369..3400, hits: 0)
Branch (branch: 0, path: 0) (location: source ID 162, lines 62..90, bytes 3402..4687, hits: 0)
Branch (branch: 0, path: 1) (location: source ID 162, lines 62..91, bytes 3337..4703, hits: 0)
Line (location: source ID 162, lines 63..64, bytes 3416..3469, hits: 0)
Statement (location: source ID 162, lines 63..64, bytes 3416..3469, hits: 0)
Line (location: source ID 162, lines 64..65, bytes 3483..3533, hits: 0)
Statement (location: source ID 162, lines 64..65, bytes 3483..3533, hits: 0)
Line (location: source ID 162, lines 65..66, bytes 3547..3603, hits: 0)
Statement (location: source ID 162, lines 65..66, bytes 3547..3603, hits: 0)
Line (location: source ID 162, lines 67..68, bytes 3622..3697, hits: 0)
Statement (location: source ID 162, lines 67..68, bytes 3622..3697, hits: 0)
Statement (location: source ID 162, lines 67..68, bytes 3622..3656, hits: 0)
Statement (location: source ID 162, lines 67..68, bytes 3660..3697, hits: 0)
Branch (branch: 1, path: 0) (location: source ID 162, lines 67..72, bytes 3699..3838, hits: 0)
Line (location: source ID 162, lines 68..69, bytes 3717..3733, hits: 0)
Statement (location: source ID 162, lines 68..69, bytes 3717..3733, hits: 0)
Line (location: source ID 162, lines 69..70, bytes 3751..3771, hits: 0)
Statement (location: source ID 162, lines 69..70, bytes 3751..3771, hits: 0)
Line (location: source ID 162, lines 70..71, bytes 3789..3823, hits: 0)
Statement (location: source ID 162, lines 70..71, bytes 3789..3823, hits: 0)
Line (location: source ID 162, lines 73..75, bytes 3852..4005, hits: 0)
Statement (location: source ID 162, lines 73..75, bytes 3852..4005, hits: 0)
Line (location: source ID 162, lines 75..76, bytes 4019..4047, hits: 0)
Statement (location: source ID 162, lines 75..76, bytes 4019..4047, hits: 0)
Line (location: source ID 162, lines 76..77, bytes 4061..4127, hits: 0)
Statement (location: source ID 162, lines 76..77, bytes 4061..4127, hits: 0)
Statement (location: source ID 162, lines 76..77, bytes 4087..4127, hits: 0)
Line (location: source ID 162, lines 77..78, bytes 4141..4159, hits: 0)
Statement (location: source ID 162, lines 77..78, bytes 4141..4159, hits: 0)
Line (location: source ID 162, lines 79..80, bytes 4178..4253, hits: 0)
Statement (location: source ID 162, lines 79..80, bytes 4178..4253, hits: 0)
Statement (location: source ID 162, lines 79..80, bytes 4178..4215, hits: 0)
Statement (location: source ID 162, lines 79..80, bytes 4219..4253, hits: 0)
Branch (branch: 2, path: 0) (location: source ID 162, lines 79..83, bytes 4255..4408, hits: 0)
Branch (branch: 2, path: 1) (location: source ID 162, lines 79..84, bytes 4174..4417, hits: 0)
Line (location: source ID 162, lines 80..81, bytes 4273..4324, hits: 0)
Statement (location: source ID 162, lines 80..81, bytes 4273..4324, hits: 0)
Line (location: source ID 162, lines 81..82, bytes 4342..4393, hits: 0)
Statement (location: source ID 162, lines 81..82, bytes 4342..4393, hits: 0)
Line (location: source ID 162, lines 83..84, bytes 4432..4483, hits: 0)
Statement (location: source ID 162, lines 83..84, bytes 4432..4483, hits: 0)
Line (location: source ID 162, lines 86..88, bytes 4512..4643, hits: 0)
Statement (location: source ID 162, lines 86..88, bytes 4512..4643, hits: 0)
Line (location: source ID 162, lines 88..89, bytes 4657..4676, hits: 0)
Statement (location: source ID 162, lines 88..89, bytes 4657..4676, hits: 0)
Line (location: source ID 162, lines 90..91, bytes 4707..4723, hits: 0)
Statement (location: source ID 162, lines 90..91, bytes 4707..4723, hits: 0)
Line (location: source ID 162, lines 91..92, bytes 4737..4757, hits: 0)
Statement (location: source ID 162, lines 91..92, bytes 4737..4757, hits: 0)

Uncovered for src/peers/ChildPeer.sol:

Uncovered for src/peers/ParentPeer.sol:

Branch (branch: 25, path: 0) (location: source ID 165, lines 444..445, bytes 26066..26085, hits: 0)
Statement (location: source ID 165, lines 444..445, bytes 26066..26085, hits: 0)

Uncovered for src/peers/YieldPeer.sol:

Branch (branch: 11, path: 0) (location: source ID 166, lines 444..445, bytes 23661..23693, hits: 0)
Statement (location: source ID 166, lines 444..445, bytes 23661..23693, hits: 0)

the parentPeer unhit line is

if (shareMintAmount == 0) shareMintAmount = 1; which is covered in certora

YieldPeer:

/// @dev Revert if the amount is 0
    /// @param amount The amount to check
    function _revertIfZeroAmount(uint256 amount) internal pure {
        if (amount == 0) revert YieldPeer__NoZeroAmount();
    }

this is only used for checking onTokenTransfer isnt 0, but im not sure if that isnt already handled with the actual transferAndCall. will have to double check.

RUN ALL CERTORA CONFS AGAIN AFTER REVIEWS

come back to DepositData.amount and WithdrawData.usdcWithdrawAmount after hackathon

the problem with emitting withdraw update on parent in an attempt to track total withdraws is that there will be scenarios when the withdraw amount is never passed through the parent

in that case maybe i should just get rid of it

i think i can get rid of the deposit and withdraw updates. they are adding clutter and not really helping to test

reviews are done and certora is passing.

can probably start mutation testing although i know the certora specs are missing some event param verification

set crosschain vars script is not tested as well as i would like

[obscenities] this script test

i know the script works perfectly. i’ve used it repeatedly on testnets. but i cant test it to get to 100% unit coverage because pranking and broadcast are incompatible. i cant prank the owner of the contracts before broadcast to transfer ownership to the test because the networkconfig changes the owner for broadcasts. [obscenities]

this is not happening

theres no way to do it

i only want it because in coverage it shows 0%, standing out in my sea of 100%. how likely is it that any judge is going to git clone, forge install, forge coverage and also care?

i care.

cant fork mainnets and deploy there because the network config is cached in the script. reassigning it in test doesnt work.

[FAIL: assertion failed: 2000000000000000000000 != 1999999999500000000249] test_yield_parent_deposit_multipleDeposits()

Another list

reupload video
frontend header
get rid of artifact
add frontend to repo
improve frontend (?) display and balance loading
redeploy bug free infra on testnets?
write article on bug

post hackathon idea

consider doing articles on findings ie the total value — amount thing, why it was happening

the incorrect order of operations

depositing
then getting value

what the affect was

this might sound like a simple mistake, but this incorrect order of operations buried deep in an abstract contract’s helper function was the cause of a critical invariant breaking during this hackathon. maths is the most important thing.

final checklist

run all tests
run all certora confs
update readme
update submission
check @review

wew we are close to a polished submission. let’s do some certora

! v63 of the v0.dev is what is deployed ! (dependencies edited in repo)

i could redeploy the entire infra…….. how much of a difference to the submission would that make…… lets just stick with more certora for now.

or i could write my article

Chromion hackathon: YieldCoin mint calculation bug

YieldCoin is an automated crosschain stablecoin yield optimizer, built for the Chainlink Chromion hackathon. In this article we will be discussing the most significant part of the development, a critical invariant breaking bug.

Context

The YieldCoin architecture allows users to deposit stablecoins from their chain of choice, to earn the highest yield available. YieldCoin smart contracts use Chainlink to find the highest APY across chains and protocols, then rebalance the funds to where that is.

In exchange for depositing USDC, users receive YieldCoin, a token representing the user’s share of the YieldCoin TVL. The basic usecase of YieldCoin offered to stablecoin holders is that they can deposit their money, earn the maximum amount over time on it without any input or risk, then withdraw their deposit and earned yield at their leisure.

The Invariant

A key invariant of this sytem, perhaps the key invariant, is users should always be able to withdraw the stablecoin amount they deposited (minus any fees, or immediate short term wei differences). If this invariant breaks then users can’t withdraw their money. So it’s important to not mess it up.

Bug Discovery

Once full unit coverage was achieved for the YieldCoin codebase, invariant tests in Foundry were started. Testing other invariants such as the integrity of the total crosschain supply of YieldCoin and YieldCoin TVL inadvertently exposed cracks in the YieldCoin minting logic.

/// @notice Total Shares Accountancy: The total shares tracked by ParentPeer should be equal to total minted minus total burned system wide.
    function invariant_totalShares_integrity() public view {
        assertEq(
            parent.getTotalShares(),
            handler.ghost_event_totalSharesMinted() - handler.ghost_state_totalSharesBurned(),
            "Invariant violated: Total shares tracked by ParentPeer should be equal to total minted minus total burned system wide."
        );
    }

/// @notice Total Value Accountancy: The total value in the system should be more than or equal to total USDC deposited minus total USDC withdrawn
    function invariant_totalValue_integrity() public {
        handler.forEachChainSelector(this.checkTotalDepositsAgainstTotalValuePerChainSelector);
    }
    function checkTotalDepositsAgainstTotalValuePerChainSelector(uint64 chainSelector) external view {
        uint256 totalDeposited = handler.ghost_state_totalUsdcDeposited();
        uint256 totalWithdrawn = handler.ghost_event_totalUsdcWithdrawn();
        uint256 netDeposits = totalDeposited > totalWithdrawn ? totalDeposited - totalWithdrawn : 0;
        if (chainSelector == parent.getStrategy().chainSelector) {
            assertTrue(
                IYieldPeer(handler.chainSelectorsToPeers(chainSelector)).getTotalValue() >= netDeposits,
                "Invariant violated: Total value in the system should be more than or equal to total USDC deposited minus total USDC withdrawn"
            );
        }
    }

(These may not have been the exact implementations at the time).

The issue was initially chalked down to the same inflation attack experienced by ERC4626 vaults, and the issue remained hidden during the rest of this invariant testing phase.

Bug Reemergence

The bug resurfaced when writing unit test style rules with Certora.

rule deposit_mintsShares_when_parent_is_strategy() {
    env e;
    calldataarg args;
    require getStrategy().chainSelector == getThisChainSelector();
    
    uint256 shareSupplyBefore = share.totalSupply();
    uint256 totalSharesBefore = getTotalShares();

    require inflationAttackMitigation();
    deposit(e, args);
    assert share.totalSupply() > shareSupplyBefore;
    assert getTotalShares() > totalSharesBefore;
}

This simple rule, that merely expects the YieldCoin total supply to increase whenever stablecoins are deposited, was failing.

Certora was revealing cases where addresses were depositing amounts of USDC and not receiving any YieldCoin minted in exchange. This confirmed the YieldCoin minting calculation bug had not been mitigated as previously assumed and a critical invariant was broken.

Back to Foundry Invariants

Given the way the Certora Prover explores paths and havocs variables, verifying crosschain invariants like YieldCoin’s integrity of deposit redemption can be tricky. Why? Maybe it could be done by linking a Mock CCIP router in the Certora scene and requiring certain behaviours. This needs to be revisited because it might be possible.

Anyway the invariant needed to be clearly defined and doing it in Foundry was ironically quicker because the crosschain infrastructure had already been deployed locally, so no time needed to be spent on that idea I just came up with in the last paragraph.

Defining the invariant

Getting the precise definition of the invariant required tweaking and acknowledgement of limitations and scenarios. There was already a known issue where burning insignificantly small amounts of YieldCoin (worth less than the lowest denomination of USDC, 6 decimals) redeemed 0 USDC. So accounting for that had to be taken into consideration.

1% slippage tolerance was also applied, although maybe not entirely necessary.

/// @notice Users should always be able to withdraw what they deposited (minus fees, but those arent implemented yet)
    /// @dev this is a critical invariant that ensures the integrity of user deposit redemption
    function invariant_stablecoinRedemptionIntegrity() public {
        handler.forEachUser(this.checkRedemptionIntegrityPerUser);
    }

function checkRedemptionIntegrityPerUser(address user) external view {
        uint256 deposited = handler.ghost_state_totalUsdcDepositedPerUser(user);
        uint256 withdrawn = handler.ghost_event_totalUsdcWithdrawnPerUser(user);
        uint256 netDeposits = deposited > withdrawn ? deposited - withdrawn : 0;
        uint256 userShares = share.balanceOf(user);
        uint256 totalValue =
            IYieldPeer(handler.chainSelectorsToPeers(parent.getStrategy().chainSelector)).getTotalValue();
        uint256 totalValueConverted = _convertUsdcToShare(totalValue);
        uint256 minUsdcValueInShares = _convertUsdcToShare(1);
        uint256 totalShares = parent.getTotalShares();
        if (totalShares > 0) {
            uint256 withdrawable = (userShares * totalValueConverted) / totalShares;
            uint256 withdrawableConverted = _convertShareToUsdc(withdrawable);
            uint256 minWithdrawable = netDeposits * 990 / 1000; // Allow 1% slippage
            if (withdrawableConverted < minWithdrawable) {}
            assertTrue(
                withdrawableConverted >= minWithdrawable || netDeposits < minUsdcValueInShares,
                "Invariant violated: User should be able to withdraw what they deposited, except for left over dust"
            );
        } else {
            assertTrue(netDeposits == 0, "Invariant violated: User should be able to withdraw what they deposited");
        }
    }

This invariant asserts that any YieldCoin holder can always withdraw 99% of the USDC amount they deposited, or the amount of YieldCoin dust they hold is worth less than the lowest denomination of USDC.

And it was breaking, but in doing so, led us to where in the codebase the issue was happening.

Adding console logs in the invariant gave greater insight into what was happening.

console2.log("User:", user);
console2.log("Deposited:", deposited);
console2.log("Withdrawn:", withdrawn);
console2.log("Net Deposits:", netDeposits);
console2.log("User Shares:", userShares);
console2.log("Total Value:", totalValue);
console2.log("Total Shares:", totalShares);
console2.log("Withdrawable:", withdrawable);
console2.log("Min Withdrawable:", minWithdrawable);

This made it easier to see the discrepancies between how much USDC a user could withdraw and how much they should’ve been able to withdraw.

Unit test checks

To see what was happening as simply as possible, I wrote a unit test where 3 users deposited the same amount of USDC into the contracts, one after the other. In theory they should have received (roughly) the same amount of YieldCoin in exchange for their USDC deposits because their deposits were equal.

These were the results:

emit SharesMinted(to: user1: [0x29E3b139f4393aDda86303fcdAa35F60Bb7092bF], amount: 1000000000000000000000 [1e21])

emit SharesMinted(to: user2: [0x537C8f3d3E18dF5517a58B3fB9D9143697996802], amount: 500000000000000000000 [5e20])

emit SharesMinted(to: user3: [0xc0A55e2205B289a967823662B841Bd67Aa362Aec], amount: 499999999833333333388 [4.999e20])

Now the problem was very clear.

Breaking the invariant

So what was happening?

In most cases when a user deposited USDC into the YieldCoin contracts, the following function would be called to:

deposit their USDC to the yield generating strategy
return the totalValue of the system to calculate their YieldCoin mint amount

/// @notice Deposits USDC to the strategy and returns the total value of the system
/// @param amount The amount of USDC to deposit
/// @return totalValue The total value of the system
function _depositToStrategyAndGetTotalValue(uint256 amount) internal returns (uint256 totalValue) {
    address strategyPool = _getStrategyPool();
    _depositToStrategy(strategyPool, amount);
    totalValue = _getTotalValueFromStrategy(strategyPool);
    emit DepositCompleted(strategyPool, amount, totalValue);
}

The totalValue, or “YieldCoin TVL”, is all of the deposits + generated yield in the system. This value is used alongside the user’s usdcDepositAmount and the totalShares, or YieldCoin total crosschain supply, to calculate the shareMintAmount - the amount of YieldCoin to mint for a user.

The incorrect order of these lines meant that the usdcDepositAmount was being included with the totalValue because the _depositToStrategy() call was happening before the _getTotalValueFromStrategy() call.

_depositToStrategy(strategyPool, amount);
totalValue = _getTotalValueFromStrategy(strategyPool);

This means the totalValue being returned by this function, used to calculate the amount of YieldCoin to mint to a depositor, was more than it should’ve been, resulting in a lower YieldCoin mint amount, losing user funds - very bad!

Fixing the invariant

The obvious (and correct) solution was to swap the lines around.

totalValue = _getTotalValueFromStrategy(strategyPool);
_depositToStrategy(strategyPool, amount);

Even though this had been done, the invariant continued breaking.

This is the line that performs the calculation:

shareMintAmount = 
	(_convertUsdcToShare(usdcDepositAmount) * totalShares) 
		/ _convertUsdcToShare(totalValue);

The immediate fix was to subtract usdcDepositAmount from the totalValue like so:

shareMintAmount = 
	(_convertUsdcToShare(usdcDepositAmount) * totalShares) 
		/ _convertUsdcToShare(totalValue - usdcDepositAmount);

Not a particularly efficient or aesthetic fix.

Digging through the contracts revealed a single instance of the incorrect deposit and total value fetch operations also happening outside the helper function used everywhere else.

These repetitive lines of code were replaced with a call to the _depositToStrategyAndGetTotalValue() function, with the correct order of operations. The invariant was now fixed and the usdcDepositAmount no longer needed to be subtracted from the totalValue in the calculation.

Conclusion

The key takeaways from this are the importance of:

using multiple tools for fuzzing and verification
full unit coverage is only the beginning of testing
maths
DRY code

YieldCoin was built for the Chainlink Chromion hackathon 2025 — see the project here.

Yieldcoin’s certora specs are fragmented due to its crosschain architecture, but all bugs introduced by the first certoraMutate are caught between two of them! — double check this

the 2nd certoraMutate run is revealing 3 pathways that are not covered by our specs.

1. ChildPeer::deposit:

function deposit(uint256 amountToDeposit) external override {
        _initiateDeposit(amountToDeposit);
        address strategyPool = _getStrategyPool();
        DepositData memory depositData = _buildDepositData(amountToDeposit);
        // 1. This Child is the Strategy
        /// IfStatementMutation(`strategyPool != address(0)` |==> `true`) of: `if (strategyPool != address(0)) {`
        if (true) {
            /// @dev deposit USDC in strategy pool and get totalValue
            depositData.totalValue = _depositToStrategyAndGetTotalValue(amountToDeposit);
            /// @dev send a message to parent contract to request shareMintAmount
            _ccipSend(
                i_parentChainSelector, CcipTxType.DepositCallbackParent, abi.encode(depositData), ZERO_BRIDGE_AMOUNT
            );
        }
        // 2. This Child is not the Strategy
        else {
            /// @dev send a message to parent contract to deposit to strategy and request shareMintAmount
            _ccipSend(i_parentChainSelector, CcipTxType.DepositToParent, abi.encode(depositData), amountToDeposit);
        }
    }

2. ChildPeer::deposit

function deposit(uint256 amountToDeposit) external override {
        _initiateDeposit(amountToDeposit);
        address strategyPool = _getStrategyPool();
        DepositData memory depositData = _buildDepositData(amountToDeposit);
        // 1. This Child is the Strategy
        if (strategyPool != address(0)) {
            /// @dev deposit USDC in strategy pool and get totalValue
            /// AssignmentMutation(`_depositToStrategyAndGetTotalValue(amountToDeposit)` |==> `1`) of: `depositData.totalValue = _depositToStrategyAndGetTotalValue(amountToDeposit);`
            depositData.totalValue = 1;
            /// @dev send a message to parent contract to request shareMintAmount
            _ccipSend(
                i_parentChainSelector, CcipTxType.DepositCallbackParent, abi.encode(depositData), ZERO_BRIDGE_AMOUNT
            );
        }
        // 2. This Child is not the Strategy
        else {
            /// @dev send a message to parent contract to deposit to strategy and request shareMintAmount
            _ccipSend(i_parentChainSelector, CcipTxType.DepositToParent, abi.encode(depositData), amountToDeposit);
        }
    }

3. ChildPeer::_handleCCIPMessage

function _handleCCIPMessage(
        CcipTxType txType,
        Client.EVMTokenAmount[] memory tokenAmounts,
        bytes memory data,
        uint64 /* sourceChainSelector */
    ) internal override {
        if (txType == CcipTxType.DepositToStrategy) _handleCCIPDepositToStrategy(tokenAmounts, data);
        if (txType == CcipTxType.DepositCallbackChild) _handleCCIPDepositCallbackChild(data);
        if (txType == CcipTxType.WithdrawToStrategy) _handleCCIPWithdrawToStrategy(data);
        /// DeleteExpressionMutation(`_handleCCIPWithdrawCallback(tokenAmounts, data)` |==> `assert(true)`) of: `if (txType == CcipTxType.WithdrawCallback) _handleCCIPWithdrawCallback(tokenAmounts, data);`
        if (txType == CcipTxType.WithdrawCallback) assert(true);
        if (txType == CcipTxType.RebalanceOldStrategy) _handleCCIPRebalanceOldStrategy(data);
        if (txType == CcipTxType.RebalanceNewStrategy) _handleCCIPRebalanceNewStrategy(data);
    }

there is a DepositToStrategy event and a DepositToStrategyCompleted event

sometimes 1 of these events is emitted. sometimes both.

/// @notice Internal helper to deposit to the strategy
    /// @param strategyPool The strategy pool to deposit to
    /// @param amount The amount of USDC to deposit
    /// @dev Emit DepositToStrategy event
    function _depositToStrategy(address strategyPool, uint256 amount) internal {
        ProtocolOperations._depositToStrategy(strategyPool, _getProtocolConfig(), amount);
        emit DepositToStrategy(strategyPool, amount);
    }

/// @notice Deposits USDC to the strategy and returns the total value of the system
    /// @param amount The amount of USDC to deposit
    /// @return totalValue The total value of the system // _getTotalValueAndDepositToStrategy
    function _depositToStrategyAndGetTotalValue(uint256 amount) internal returns (uint256 totalValue) {
        address strategyPool = _getStrategyPool();
        totalValue = _getTotalValueFromStrategy(strategyPool);
        _depositToStrategy(strategyPool, amount);
        emit DepositToStrategyCompleted(strategyPool, amount, totalValue);
    }

this is confusing and a clear area for improvement

Penultimate day

REVIEW ALL LINKS IN README
REVIEW SUBMISSION
RUN ALL TESTS AND CERTORA

with certora rules, you’re verifying behaviour down a particular pathway, whereas with invariants you’re verifying it down all the pathways

could use chainlink price feeds to calculate minimum share burnt amount but difficult due to the crosschain nature of the usdcWithdrawAmount calculation

all great businesses and innovations of the future will be built with chainlink. there is no better opportunity than spending one’s time on chainlink services, smart contract security

of all the other projects i’ve seen so far this has the best tests: https://devfolio.co/projects/emerald-dao-d924

Reflections

after getting an eligible submission complete, progress on the project could’ve gone 1 of 2 ways: additional features or additional testing. The choice was made to prioritize security of the existing protocol before considering new features. Security is the most important thing when it comes to smart contract development. Nobody wants to use a contract that will break and lose their money.

The bare minimum for each feature should be something akin to this list (cyfrin tweet)

Plus once you have the extensive testing infrastructure, you reuse it for every feature addition, to see if anything is now breaking.

An ideal team would have 50% of the team always extending the test suite, ie once invariants are done in foundry, move on to certora, halmos, chimera, etc. The aim should be for the codebase to be as covered/layered with testing infrastructure as possible. A smart contract codebase is far from finished if the behavior of any pathways have not been verified.

if the attack vector exists, it will be exploited

getting good at writing/securing smart contracts will be the best way to have a lasting impact

With the way AI is going, it’s easy to see how this process of extensive testing for every feature will get quicker. But you still have to know what you are doing. Anyone can know what they are doing, as long as they put in consistent time.

The testing infrastructure for YieldCoin’s current state is still incomplete because there are pathways that haven’t been explored. More time must be spent considering states.

The DepositToStrategyCompleted and DepositToStrategy events must be reviewed further due to their confusing uses and names. I will do that now.

oh right DepositToStrategyCompleted is used for when a user deposits, but DepositToStrategy is emitted when both a user deposits and the system rebalances tvl by depositing. that’s confusing.

we probably need rebalance events

to make it clear when a rebalance deposit completes

When it comes to verifying paths in certora, you can be as granular as you like. Harnesses can expose everything so the path trace can begin and end where you like

mutating the parent rebalancer has confirmed my thesis that reverting instead of returning false for chainlink automation is better for security because valid paths can be more confidently verified.

i should really change it. i’d have to refactor unit tests, invariant tests will probably not need refactoring. certora specs would need refactoring too

If a user is providing input to your system then you need to verify all the possible pathways result in valid states

ok im replacing the return false with reverts

do we need implication operator to pass the local rebalance revert check

require newSelector ≠ parentSelector ⇒ oldSelector ≠ parentSelector;

and vice versa? maybe?

or something like

require newSelector == parent ⇒ old ≠ parent?

require old == parent ⇒ new ≠ parent

Why did this call revert?

REVERT CAUSE

keyboard_arrow_down

See \”log.topics[1]\” @ src/modules/ParentRebalancer.sol: line 64

CANON95<=0x1

what does this mean

i am tired and this hackathon has 24 hours left

Final day

ok today is the final day. i hope it doesnt get extended, dont think it will

just published the article on the bug, now lets see if we can finish this certora spec for the new checkLog

mfs in discord asking for extension. bruh i just put in like 12 hours a day for the last month. gtfo

so we are requiring the topics inside this cvl func

require topics[0] == eventSignature;
    require topics[1] == uint64ToBytes32(newChainSelector);
    require topics[2] == uint8ToBytes32(protocolEnum);
    require topics[3] == uint64ToBytes32(oldChainSelector);

yet these bits of the certora calltrace:

Why did this call revert?

REVERT CAUSE
See \\"log.topics[1]\\" @ src/modules/ParentRebalancer.sol: line 64

CANON95<=0x1

RebalancerHarness.checkLog(log={index=0x197d, timestamp=0xbc1, txHash=0x0, blockNumber=0x9a9, blockHash=0x0, source=ParentPeer,
topics=[0=0xcb3...ac7] (length=1),
data=bytes (length=0x0)}, param_1=bytes (length=0x0)) ↪ ..., ...

topics=[0=0xcb3…ac7] (length=1)

is implying that the other topics are not there

the event sig looks correct so theres that

definition StrategyUpdatedEvent() returns bytes32 =
// keccak256(abi.encodePacked("StrategyUpdated(uint64,uint8,uint64)"))
    to_bytes32(0xcb31617872c52547b670aaf6e63c8f6be35dc74d4144db1b17f2e539b5475ac7);

i fixed that by requiring the topics.length == 4 (to include each emitted param)

that made the rules vacuous, so no difference between returning false and reverting when upkeep not needed.

i’ll probably just run all the tests again, leave a note acknowledging this in the readme, merge the pr and that’ll be it for this hackathon entry.

final coverage:

all invariants pass with 3000 runs and certora rules pass too (except vacuous ones with sanity)

unit coverage doesnt include set crosschain vars script because i spent ages trying to make it work without adjusting the broadcast and pranking but it wasnt worth it. already works perfectly on testnets.

there’s 14 hours left to go. i dont think there’s much more to do. the only thing that arguably needs improving is changing the name of one of those deposit events but its so minor

I don’t know if anyone is actually going to read through all of these notes. i’ll read them again in a few years.

I should run all tests a final time as well as certora specs, and slither and aderyn. hmm aderyn showing unchecked return values for some approve calls…………

gm to everyone who writes articles about finding and fixing bugs with certora and invariant tests in their chainlink hackathon project

Chromion hackathon: YieldCoin mint calculation bug

Contract Level — Sun, 29 Jun 2025 10:09:04 GMT

Context

The Invariant

Bug Discovery

/// @notice Total Shares Accountancy: The total shares tracked by ParentPeer should be equal to total minted minus total burned system wide.
function invariant_totalShares_integrity() public view {
    assertEq(
        parent.getTotalShares(),
        handler.ghost_event_totalSharesMinted() - handler.ghost_state_totalSharesBurned(),
        "Invariant violated: Total shares tracked by ParentPeer should be equal to total minted minus total burned system wide."
    );
}

/// @notice Total Value Accountancy: The total value in the system should be more than or equal to total USDC deposited minus total USDC withdrawn
function invariant_totalValue_integrity() public {
    handler.forEachChainSelector(this.checkTotalDepositsAgainstTotalValuePerChainSelector);
}

function checkTotalDepositsAgainstTotalValuePerChainSelector(uint64 chainSelector) external view {
    uint256 totalDeposited = handler.ghost_state_totalUsdcDeposited();
    uint256 totalWithdrawn = handler.ghost_event_totalUsdcWithdrawn();
    uint256 netDeposits = totalDeposited > totalWithdrawn ? totalDeposited - totalWithdrawn : 0;
    if (chainSelector == parent.getStrategy().chainSelector) {
        assertTrue(
            IYieldPeer(handler.chainSelectorsToPeers(chainSelector)).getTotalValue() >= netDeposits,
            "Invariant violated: Total value in the system should be more than or equal to total USDC deposited minus total USDC withdrawn"
        );
    }
}

The issue was initially chalked down to the same inflation attack experienced by ERC4626 vaults, and the issue remained hidden during the rest of this invariant testing phase with an “initial admin donation deposit”.

Bug Reemergence

The bug resurfaced when writing unit test style rules with Certora.

rule deposit_mintsShares_when_parent_is_strategy() {
    env e;
    calldataarg args;

    require getStrategy().chainSelector == getThisChainSelector();
    
    uint256 shareSupplyBefore = share.totalSupply();
    uint256 totalSharesBefore = getTotalShares();

    require inflationAttackMitigation();

    deposit(e, args);

    assert share.totalSupply() > shareSupplyBefore;
    assert getTotalShares() > totalSharesBefore;
}

This simple rule, that merely expects the YieldCoin total supply to increase whenever stablecoins are deposited, was failing.

Back to Foundry Invariants

Defining the invariant

1% slippage tolerance was also applied.

/// @notice Users should always be able to withdraw what they deposited (minus fees, but those arent implemented yet)
/// @dev this is a critical invariant that ensures the integrity of user deposit redemption
function invariant_stablecoinRedemptionIntegrity() public {
    handler.forEachUser(this.checkRedemptionIntegrityPerUser);
}

function checkRedemptionIntegrityPerUser(address user) external view {
    uint256 deposited = handler.ghost_state_totalUsdcDepositedPerUser(user);
    uint256 withdrawn = handler.ghost_event_totalUsdcWithdrawnPerUser(user);
    uint256 netDeposits = deposited > withdrawn ? deposited - withdrawn : 0;
    uint256 userShares = share.balanceOf(user);

    uint256 totalValue =
        IYieldPeer(handler.chainSelectorsToPeers(parent.getStrategy().chainSelector)).getTotalValue();
    uint256 totalValueConverted = _convertUsdcToShare(totalValue);
    uint256 minUsdcValueInShares = _convertUsdcToShare(1);
    uint256 totalShares = parent.getTotalShares();

    if (totalShares > 0) {
        uint256 withdrawable = (userShares * totalValueConverted) / totalShares;
        uint256 withdrawableConverted = _convertShareToUsdc(withdrawable);
        uint256 minWithdrawable = netDeposits * 990 / 1000; // Allow 1% slippage
        if (withdrawableConverted < minWithdrawable) {}
        assertTrue(
            withdrawableConverted >= minWithdrawable || netDeposits < minUsdcValueInShares,
            "Invariant violated: User should be able to withdraw what they deposited, except for left over dust"
        );
    } else {
        assertTrue(netDeposits == 0, "Invariant violated: User should be able to withdraw what they deposited");
    }
}

And it was breaking, but in doing so, led us to where in the codebase the issue was happening.

Adding console logs in the invariant gave greater insight into what was happening.

console2.log("User:", user);
console2.log("Deposited:", deposited);
console2.log("Withdrawn:", withdrawn);
console2.log("Net Deposits:", netDeposits);
console2.log("User Shares:", userShares);
console2.log("Total Value:", totalValue);
console2.log("Total Shares:", totalShares);
console2.log("Withdrawable:", withdrawable);
console2.log("withdrawableConverted:", withdrawableConverted);
console2.log("Min Withdrawable:", minWithdrawable);

This made it easier to see the discrepancies between how much USDC a user could withdraw and how much they should’ve been able to withdraw.

Unit test checks

To see what was happening as simply as possible, I wrote a unit test where 3 users deposited the same amount of USDC into the contracts, one after the other. In theory they should have received (at least roughly) the same amount of YieldCoin in exchange for their USDC deposits because their deposits were equal.

These were the results:

emit SharesMinted(to: user1: [0x29E3b139f4393aDda86303fcdAa35F60Bb7092bF], amount: 1000000000000000000000 [1e21])

emit SharesMinted(to: user2: [0x537C8f3d3E18dF5517a58B3fB9D9143697996802], amount: 500000000000000000000 [5e20])

emit SharesMinted(to: user3: [0xc0A55e2205B289a967823662B841Bd67Aa362Aec], amount: 499999999833333333388 [4.999e20])

Now the problem was very clear.

Breaking the invariant

So what was happening?

In most cases when a user deposited USDC into the YieldCoin contracts, the following function would be called to:

deposit their USDC to the yield generating strategy
return the totalValue of the system to calculate their YieldCoin mint amount

/// @notice Deposits USDC to the strategy and returns the total value of the system
/// @param amount The amount of USDC to deposit
/// @return totalValue The total value of the system
function _depositToStrategyAndGetTotalValue(uint256 amount) internal returns (uint256 totalValue) {
    address strategyPool = _getStrategyPool();
    _depositToStrategy(strategyPool, amount);
    totalValue = _getTotalValueFromStrategy(strategyPool);
    emit DepositCompleted(strategyPool, amount, totalValue);
}

_depositToStrategy(strategyPool, amount);
totalValue = _getTotalValueFromStrategy(strategyPool);

Fixing the invariant

The obvious (and correct) solution was to swap the lines around.

totalValue = _getTotalValueFromStrategy(strategyPool);
_depositToStrategy(strategyPool, amount);

Even though this had been done, the invariant continued breaking.

This is the line that performs the calculation:

shareMintAmount = 
	(_convertUsdcToShare(usdcDepositAmount) * totalShares) 
		/ _convertUsdcToShare(totalValue);

The immediate fix was to subtract usdcDepositAmount from the totalValue like so:

shareMintAmount = 
	(_convertUsdcToShare(usdcDepositAmount) * totalShares) 
		/ _convertUsdcToShare(totalValue - usdcDepositAmount);

Not a particularly efficient or aesthetic fix.

Digging through the contracts revealed a single instance of the incorrect deposit and total value fetch operations also happening outside the helper function used everywhere else.

Conclusion

The key takeaways from this are the importance of:

using multiple tools for fuzzing and verification
full unit coverage never being enough
maths
DRY code

YieldCoin was built for the Chainlink Chromion hackathon 2025 — see the project here.

Dev notes: Debugging and vibe coding the Lens hackathon

Contract Level — Fri, 16 May 2025 19:20:56 GMT

This is not meant to be a polished article, these are unedited notes taken whilst participating in the Lens hackathon.

First I wanted to build a content competition smart contract and I wanted the prize distribution to be automated when the votingDeadline was reached. Unfortunately Chainlink Automation was not yet available on Lens (or Lens Sepolia). Luckily CCIP is available on Lens Sepolia.

So the idea was to send messages across ccip to a chain with Automation when a new competition is created, including the competition’s votingDeadline. And then when the votingDeadline is met, chainlink automation would send a message back through ccip to distribute the prizePool, concluding the relevant competition on lens.

I wanted to make the automation chain Base or Arbitrum because they are cheap and fast, but the only CCIP lane for Lens Sepolia was to Eth Sepolia. That’s ok, Automation is on eth sepolia.

So I built the contracts and deploy scripts, but Eth Sepolia is evm and lens is zksync evm, which means they are compiled differently and use different versions of foundry. (soon changing, zksync is now supporting/going to support classic foundry).

the project wouldnt compile in foundryup-zksync because Chainlink’s AutomationCompatible includes the cannotExecute modifier which uses tx.origin. Foundry zksync projects refused to compile with tx.origin.

So for even basic unit testing the project had to be scaled back. Initial approach is to comment out all of the CCAutomation and ccipLocalSimulator stuff, in favour of a much more basic unit test approach.

unit testing ContentCompetition::createCompetition()

All the revert checks went fine (except for individual tests needing local instead of state variables but whatever), and then the ccipSend() call failed.

Why?

The CCIPRouter calls the OnRamp.

onRamp.forwardFromRouter() calls this ARMProxy:

https://explorer.testnet.lens.xyz/address/0x1C6e13153FdFC78793E211f557820ed86B10c36B#contract

which calls the implementation

The ARMProxy calls RMN.isCursed(bytes16 subject) - https://explorer.testnet.lens.xyz/address/0x6D89bfFCEf0661bA485AAc97F3f1B339d8F65CEF#contract

This is where the revert was happening, implying the lane was not operational, even though the ccip explorer said otherwise https://ccip.chain.link/status?networkType=testnet&search=lens

https://explorer.testnet.lens.xyz/address/0x211BF55bFA331e4149bdF624722CbCDB862Ff51D#contract OnRamp.forwardFromRouter:

/// @inheritdoc IEVM2AnyOnRampClient
  function forwardFromRouter(
    uint64 destChainSelector,
    Client.EVM2AnyMessage calldata message,
    uint256 feeTokenAmount,
    address originalSender
  ) external returns (bytes32) {
    if (IRMN(i_rmnProxy).isCursed(bytes16(uint128(destChainSelector)))) revert CursedByRMN();

we assert that we have set the correct chain selector

function test_allowedSelector() public {
        assertEq(comp.getAllowedChainSelector(), 16015286601757825753);
    } // eth sepolia selector

then we chisel bytes16(uint128(16015286601757825753)) and get 0x0000000000000000de41ba4fc9d91ad900000000000000000000000000000000

however when this gets put in the explorer for isCursed via https://explorer.testnet.lens.xyz/address/0x6D89bfFCEf0661bA485AAc97F3f1B339d8F65CEF#read we get “value is invalid”

This is a bytes32 value, if we shorten it to 0x0000000000000000de41ba4fc9d91ad9, isCursed returns false, which is what we want. buuuuuut the onchain ccip contracts (which we cant change) in our fork test are passing the bytes32 value. Maybe this is just an issue with foundry-zksync

Deployment/Verification Issues

forge create wouldn’t work because it kept trying to do something with localhost:8545. I don’t know why. changing the rpc urls didnt work.

Fortunately the deploy script worked.

Unfortunately the lens testnet block explorers don’t have api keys like etherscan so I couldnt forge verify . One of the explorers had a login with google option, but still no api key.

This testnet has a page for manually verifying: https://explorer.testnet.lens.xyz/contracts/verify?address=0xd2550fCb1C389401E9F8802e68b093fcc0595993

So I flattened my contract and encoded the constructor args and got this error zksolc error: solc versions >0.8.24 are not supported, found 0.8.26.

So I tried re-building the contracts with 0.8.24 and this didnt work because the Lens IFeed interface is 0.8.26.

abi-encode constructor args 00000000000000000000000031232cb7de0dce17949ffa58e9e38eeeb367c8710000000000000000000000007f1b9ee544f9ff9bb521ab79c205d79c55250a36000000000000000000000000f5aa9fe2b78d852490bc4e4fe9ab19727dd102980000000000000000000000000000000000000000000000000000000000030d40

This was the point I gave up trying to write a “masterpiece” codebase, left the deployed contracts unverified and proceeded to vibe up a sweet neon-gaming style frontend.

Testnet testing

Testing on testnets introduced additional frustrations. These are the steps I took:

deployed CCAutomation on Eth Sepolia
registered with chainlink automation
funded CCAutomation with LINK
deployed ContentCompetition on Lens Sepolia
set crosschain vars (CCAutomation address and eth sepolia selector)

Then I realised there is no LINK token on Lens Sepolia, presumably this means CCIP fees are paid in native/GRASS. This means the crosschain functionality used for ContentCompetition needs to be rewritten. It’s annoying because an abstract CrossChain contract was used as the base for both chains, including an immutable i_link.

Redeploy ContentCompetition with an underlying forked LensCrossChain and set the crosschain vars again.

I then wrote a script for creating competitions. Everytime I ran this, i got a REVERT: zk vm halted error. I found no results online with this error, neither did ai deepsearch, but assuming its some unsupported opcode causing the error. I kept getting this error even when commenting out the entire createCompetition function. Instead of running the script, I used cast send. That worked for the alternatively deployed contract with a commented out function, but when I tried to cast send with the actual implementation I got this error: 0x7839f485000000000000000000000000000000000000000000000000042a2b5c29184000000000000000000000000000000000000000000000000000043d3c7bf8b47dfb. I’m hoping this is some CCIP related error. How hilarious would it be if it turned out to be the same error from earlier’s fork tests where it isCursed ? I bet it’s that the CCIP fee is too much for how much GRASS we are able to obtain from the faucet…

Ok let’s go through the errors in CCIP and chisel them.

we can get the error selector with bytes4(keccak256("ErrorName()"))

bytes4(keccak256("InsufficientFee(uint256,uint256)"))
Type: bytes4
└ Data: 0xa458261b00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InsufficientFeeTokenAmount()"))
Type: bytes4
└ Data: 0x07da6ee600000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidMsgValue()"))
Type: bytes4
└ Data: 0x1841b4e100000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("UnsupportedDestinationChain(uint64)"))
Type: bytes4
└ Data: 0xae236d9c00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidChainSelector(uint64)"))
Type: bytes4
└ Data: 0xd9a9cd6800000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("CursedByRMN(uint64)"))
Type: bytes4
└ Data: 0xfdbd6a7200000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InsufficientFee(uint256,uint256)"))
Type: bytes4
└ Data: 0xa458261b00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidFeeTokenAmount()"))
Type: bytes4
└ Data: 0x23e7378500000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidFeeTokenAmount(uint256,uint256)"))
Type: bytes4
└ Data: 0x2c75cab400000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidExtraArgs(bytes)"))
Type: bytes4
└ Data: 0xffec404a00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidMessage(uint256,uint256)"))
Type: bytes4
└ Data: 0xeff5312c00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidFeeToken(address)"))
Type: bytes4
└ Data: 0xeddf07f500000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("FailedToSendValue()"))
Type: bytes4
└ Data: 0xe417b80b00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidRecipientAddress(address)"))
Type: bytes4
└ Data: 0x26a78f8f00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("OffRampMismatch(uint64,address)"))
Type: bytes4
└ Data: 0x4964779000000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("BadARMSignal()"))
Type: bytes4
└ Data: 0xc148371500000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("UnsupportedDestinationChain(uint64)"))
Type: bytes4
└ Data: 0xae236d9c00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InsufficientFeeTokenAmount()"))
Type: bytes4
└ Data: 0x07da6ee600000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidMsgValue()"))
Type: bytes4
└ Data: 0x1841b4e100000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("OnlyOffRamp()"))
Type: bytes4
└ Data: 0xd2316ede00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidExtraArgsTag()"))
Type: bytes4
└ Data: 0x5247fdce00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("ExtraArgOutOfOrderExecutionMustBeTrue()"))
Type: bytes4
└ Data: 0xee433e9900000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("OnlyCallableByOwnerOrAdmin()"))
Type: bytes4
└ Data: 0xfbdb8e5600000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("OnlyCallableByOwnerOrAdminOrNop()"))
Type: bytes4
└ Data: 0x195db95800000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidWithdrawParams()"))
Type: bytes4
└ Data: 0x232cb97f00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("NoFeesToPay()"))
Type: bytes4
└ Data: 0x8d0f71d800000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("NoNopsToPay()"))
Type: bytes4
└ Data: 0x990e30bf00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InsufficientBalance()"))
Type: bytes4
└ Data: 0xf4d678b800000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("TooManyNops()"))
Type: bytes4
└ Data: 0xb5a10cfa00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("MaxFeeBalanceReached()"))
Type: bytes4
└ Data: 0xe5c7a49100000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("MessageTooLarge(uint256,uint256)"))
Type: bytes4
└ Data: 0x8693378900000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("MessageGasLimitTooHigh()"))
Type: bytes4
└ Data: 0x4c4fc93a00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("UnsupportedNumberOfTokens()"))
Type: bytes4
└ Data: 0x4c056b6a00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("UnsupportedToken(address)"))
Type: bytes4
└ Data: 0xbf16aab600000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("MustBeCalledByRouter()"))
Type: bytes4
└ Data: 0x1c0a352900000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("RouterMustSetOriginalSender()"))
Type: bytes4
└ Data: 0xa4ec747900000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidConfig()"))
Type: bytes4
└ Data: 0x35be3ac800000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("CursedByRMN()"))
Type: bytes4
└ Data: 0x53ad11d800000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("LinkBalanceNotSettled()"))
Type: bytes4
└ Data: 0x02075e0000000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidNopAddress(address)"))
Type: bytes4
└ Data: 0x4de938d100000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("NotAFeeToken(address)"))
Type: bytes4
└ Data: 0xa7499d2000000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("CannotSendZeroTokens()"))
Type: bytes4
└ Data: 0x5cf0444900000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("SourceTokenDataTooLarge(address)"))
Type: bytes4
└ Data: 0x36f536ca00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidChainSelector(uint64)"))
Type: bytes4
└ Data: 0xd9a9cd6800000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("GetSupportedTokensFunctionalityRemovedCheckAdminRegistry()"))
Type: bytes4
└ Data: 0x9e7177c800000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidDestBytesOverhead(address,uint32)"))
Type: bytes4
└ Data: 0x24ecdc0200000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("PriceNotFoundForToken(address)"))
Type: bytes4
└ Data: 0x9a655f7b00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("OnlyCallableByAdminOrOwner()"))
Type: bytes4
└ Data: 0xf6cd562000000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("BucketOverfilled()"))
Type: bytes4
└ Data: 0x9725942a00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("RateLimitExceeded()"))
Type: bytes4
└ Data: 0xa74c1c5f00000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("MessageTooLarge(uint256,uint256)"))
Type: bytes4
└ Data: 0x8693378900000000000000000000000000000000000000000000000000000000

didn’t find the error from that. let’s look at Tenderly.

Tenderly shows the tx reverting a few steps after interacting with the PriceRegistry and what is presumably the native token (GRASS).

Well I increased the amount of GRASS balance the content competition contract has and the createCompetition function worked. Never found out exactly what the custom error corresponded too but whatever.

The amount of GRASS needed to send a message from Lens to Eth Sepolia via CCIP was 0.3. This was annoying because without sybil-attacking the alchemy GRASS faucet, only 0.5 GRASS could be dripped per 72 hours. There’s another faucet that requires google login which wasn’t working, but only gave 0.1 per 24 hours. And another that required solving an intricate maze for 0.1 per 24 hours too. I would’ve used realistic values for the deadlines for the first tx had I considered this a bit more, because now we need to wait to get more testnet funds to execute a bidirectional crosschain competition completion.

Lens Mainnet Deployment

Someone asked in the discord if submissions needed to be deployed on lens mainnet or if the testnet was fine. The mod responded that submissions were required to be on mainnet. Seems like a bad idea because obviously projects won’t be sufficiently audited for bugs in time. It also makes reliably automating prize distribution impossible because CCIP is only available on lens testnet and not on lens mainnet. Oh well maybe I’ll just deploy on the mainnet anyway — .

Refactoring for mainnet/single chain deployment

Forked Lens Mainnet and removed all of the CCIP stuff from Competitions.sol.

Now we’re writing some tests and actually trying to create a post on the Lens mainnet global Feed contract. This is how it’s going:

function _createPost() internal returns (uint256 postId) {
        CreatePostParams memory postParams = CreatePostParams({
            author: author,
            contentURI: "",
            repostedPostId: 0,
            quotedPostId: 0,
            repliedPostId: 0,
            ruleChanges: new RuleChange[](0),
            extraData: new KeyValue[](0)
        });
        KeyValue[] memory customParams = new KeyValue[](0);
        RuleProcessingParams[] memory feedRulesParams = new RuleProcessingParams[](0);
        RuleProcessingParams[] memory rootPostRulesParams = new RuleProcessingParams[](0);
        RuleProcessingParams[] memory quotedPostRulesParams = new RuleProcessingParams[](0);

        postId = IFeed(feed).createPost(
            postParams, customParams, feedRulesParams, rootPostRulesParams, quotedPostRulesParams
        );
    }

This is reverting with this custom error 0x3bfe162b. So now we’re back to looking through another contract and chiseling errors.

➜ bytes4(keccak256("UnexpectedValue()"))
Type: bytes4
└ Data: 0x123146a600000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("CannotHaveRules()"))
Type: bytes4
└ Data: 0x3793ca3000000000000000000000000000000000000000000000000000000000
➜ bytes4(keccak256("InvalidMsgSender()"))
Type: bytes4
└ Data: 0x3bfe162b00000000000000000000000000000000000000000000000000000000

Haha, that was easy. D’oh. Creating the post worked after adding _changePrank(author) before the call.

The contract was successfully deployed to Lens Mainnet but because we are using the Lens Feed, which is using 0.8.26, it couldn’t be verified on the explorer https://explorer.lens.xyz/contracts/verify?address=0xd2550fCb1C389401E9F8802e68b093fcc0595993 and it definitely wasn’t for lack of trying.

Verifying smart contracts on block explorer is always the worst part of development.

Doesn’t look like lenscan even has an option for verifying https://lenscan.io/address/0xd2550fCb1C389401E9F8802e68b093fcc0595993?tab=contract

Conclusion

This project was built for fun and a lot of it ended up not being very fun. I just submitted and then realised the video included an outdated bit of code missing a crucial revert check in the distributePrizePool() func. See the video here: https://www.youtube.com/watch?v=uFq8fUUIt0g&t=138s Meh. Doesn’t look like the submission can be edited and the code in the actual contract isnt missing the check, and the logic has been verified with Certora. Hopefully noone will notice. If everything had to be absolutely perfect, then nothing would get done. There are always improvements to make.

The Problem with Contract Level Compliance

Contract Level — Sun, 30 Mar 2025 16:54:56 GMT

In our previous article, we discussed the identity data requirements for Contract Level Compliance (CLC). To briefly recap: the data that enables Contract Level Compliance must be Absolutely Sybil-resistant and provided by a licensed entity. Absolute Sybil-resistance refers to the impossibility of one person posing as multiple, and a licensed entity refers to an entity that is authorized by regulators to facilitate KYC. Now, we will discuss the problem with how CLC can currently be implemented, due to the availability of required data.

As of now, Everest is the only known provider of such data to smart contracts. If anyone knows another data provider to the Chainlink network that meets the same requirements as Everest, please get in touch! contractlevel@proton.me

The Risk of Dependency

What happens if Everest ceases operations or declines to provide its data?

Contract Level Compliance is currently beholden to a single source for Absolutely Sybil-resistant and compliant identity data. This reliance introduces a single point of failure, meaning there is no guarantee of 100%, 24/7 access to the required data for CLC. Compromises can be made, but ultimately this reality is holding the full potential of smart contracts back, and raises a critical question:

How can we decentralize Absolute Sybil-resistance and regulatory compliance?

The following is an incomplete and hypothetical thought-experiment based on the problem of having to rely on Everest’s current form to enable Contract Level Compliance.

An Absolute Sybil-resistance (ASR) network of nodes guaranteeing that the private key of an address is formed from the unique biometric data of a user is evidently required.

This address could then be linked to an onchain registry of licensed entities that facilitate KYC compliance, each potentially offering their specific “level” of regulation (e.g., jurisdiction, license type, etc.). Participating providers would be required to verify their authorization by regulators, and end users would be free to complete KYC with their qualifying entity of choice.

The execution of compliant smart contracts would still be facilitated by CLC infrastructure. Requests for confirmation of a user’s compliance status could be fulfilled by whichever participating licensed entity the user chose.

Hypothetical high level overview. Maybe the end user wouldn’t interact directly with the Registry, but instead sign a message of confirmation, via the ASR Network, for their provider.

CLC Registered Providers would essentially bear the legal responsibility of approving a user’s participation in regulated DeFi. Devs wanting to build regulated smart contracts would restrict their logic to a chosen tier of compliance available from one or more providers. End users would complete KYC with their chosen provider, confirming with the CLC Registry via the ASR Network.

The ASR Network must be similar to traditional wallets in that multiple public addresses can be derived from the base (biometric based) private key, allowing users to maintain privacy between regulated contracts. Nodes in the network would increasingly adopt new forms of biometric scans as the technology progresses.

All participating addresses in regulated contracts would be (privately) ASR linked back to a single, unique human, who has completed KYC with at least one licensed entity.

“If you want to participate in X smart contract, you must have been confirmed by the CLC Registry as having completed KYC with Y entity, via the ASR Network.”

Compensation for CLC Registered Providers and ASR Network node operators would be necessary, with fees sourced either from end users or the regulated contracts interacting with the CLC Registry.

The Problem with this Approach

Consider the following scenario: There is a unique human verified by the ASR Network. This person completes KYC with Provider A and Provider B, using the passports of different people. How, then, does the CLC Registry know with 100% certainty that the uniquely verified human completed KYC correctly? Would the KYC provider need its own biometric verification system linked to the ASR Network with ZKPs? Perhaps this indicates an inherent, required inseparability of Sybil-resistance and licensed KYC checks that the above proposition fails to reconcile.

Regardless of regulatory compliance, Absolute Sybil-resistance (ASR) by Consensus needs to be solved — if only to restore order from the chaos of AI participation in society.

An Honest Reflection

Decentralizing Absolute Sybil-resistance (and regulatory compliance) is not only key to reliably achieving compliance at the (public) contract level, but it is also a much deeper problem than Contract Level Compliance initially set out to solve.

CLC was conceived and built with the current tooling available to smart contracts. While it can be completed and launched, its dependency on Everest’s current form prevents it from guaranteeing 100%, 24/7 reliability without additional tools resembling what has been discussed.

The Path to ASR by Consensus

Everest

The fastest path to Absolute Sybil-resistance by Consensus could be reached by Everest. Its identity infrastructure already achieves Absolute Sybil-resistance; the next step is decentralization, establishing itself as indispensable to smart contract ecosystems like CLC.

This is obviously not a path that can be relied upon. Therefore if Everest does not pursue this, others must — because ASR by Consensus is critical for Contract Level Compliance to be a viable, long-term product.

Fuzzy Extractors

A more reliable path may be rebuilding the entire identity infrastructure from scratch. Preliminary research indicates the use of fuzzy extractors, a cryptographic technique for deriving keys from biometrics, as a potential starting point.

Moving Forward

Research into Absolute Sybil-resistance (ASR) by Consensus and ideas discussed will be ongoing. Meanwhile, the crosschain vision for Contract Level Compliance, as laid out in the whitepaper, will be completed with full, comprehensive test suites and formal verification. Proof-of-concept demonstrations showcasing use of CLC’s current form are also in progress.

If you have any thoughts on how Contract Level Compliance can be improved or how the concepts discussed in this article can be achieved, please don’t hesitate to get in touch!

contractlevel@proton.me | x.com/contractlevel

The Problem with Contract Level Compliance was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.

Identity Data Requirements for Contract Level Compliance

Contract Level — Tue, 18 Mar 2025 15:02:03 GMT

This article refers to compliant identity data requirements from the perspective of publicly-accessible smart contracts on a public chain, as distinguished from private bank chains that have their own internal compliance procedures, and/or siloed, institutional smart contracts on public chains that have pre-approved clientele, also via their own internal compliance procedures.

For Contract Level Compliance (CLC) to function as intended (ie securely enable KYC checks at the contract level publicly), the data used by the system must meet certain requirements. These requirements are dictated by both the open, public nature of blockchains, and the regulating authorities from the outside world.

Public-chain compliant identity data requires three things:

Absolute Sybil-resistance
Licensed Provider
Chainlink

Absolute Sybil-resistance

Sybil-resistance refers to the limiting of a single actor’s ability to pose as multiple actors in a system. There are many so-called onchain identity solutions masquerading as “Sybil-resistant,” that are in fact nothing more than a series of extra steps a sufficiently determined attacker has to take to exploit. This is why we are using the term Absolute Sybil-resistance to explain what is required of identity data for Contract Level Compliance.

Absolute Sybil-resistance means it is as impossible for a single actor to pose as multiple actors in a system, as it is to reverse time. For Contract Level Compliance, this means an onchain user account must be non-transferable. For public chains, the only way to ensure this is using biometric data (and a secret PIN) as a private key. Biometrics are unique to each individual, making them the most reliable way to ensure one person corresponds to one private key/account. Otherwise someone could share their private key, enabling money laundering or identity fraud. This means biometrics must be scanned everytime an onchain action is performed, otherwise the transaction cannot be considered compliant at the contract level.

To illustrate this further, an example of a broken solution is one that labels an onchain user account “Sybil-resistant” based on “activity” like number of transactions executed by that account. This is broken for two reasons: the first being a single actor could create multiple accounts with activity that meets whatever arbitrary threshold determines “Sybil-resistance” in such a system. The second reason is that the private key for such a broken-system-approved account can literally be copy and pasted to somebody else. That somebody else can then use that account, determined “Sybil-resistant” based on the first person’s activity, alongside their own, thus nullifying any notion of Sybil-resistance.

Another broken solution is one that scans a user’s biometrics once to create an account or mint a “soulbound” NFT. This is broken for exactly the same reason as the second given for the previous example.

These credential-based methods of “Sybil-resistance” cannot be considered Absolutely Sybil-resistant because they are not. They also, as previously mentioned, enable identity fraud and money laundering, so they definitely cannot be used for Contract Level Compliance.

Licensed Provider

The identity data must be provided by an entity that is licensed by regulators to facilitate Know Your Customer (KYC) processes. A simple “yes” to the question “Has this user completed KYC?” is meaningless unless the entity providing that answer has been officially authorized by financial regulators to conduct such checks and proven to comply with all relevant legal obligations, including:

Regulatory Compliance: Adherence to Anti-Money Laundering (AML) regulations and Financial Action Task Force (FATF) recommendations.
Customer Identification: Verification of identities through the collection of personal data.
Risk-Based Approach: Assessment of customer risk and application of enhanced due diligence (EDD) for high-risk cases.
Ongoing Monitoring: Continuous tracking of transactions to identify suspicious activity.
Record Keeping: Retaining KYC data and transaction records for the legally required time.
Suspicious Activity Reporting: Reporting suspicious behavior to authorities.
Data Protection: Ensuring security and customer rights in compliance with privacy laws like GDPR.
Internal Controls: Establishment of KYC policies and staff training.
Sanctions Screening: Checking customers against sanctions lists.
Customer Due Diligence: Performing standard or simplified due diligence based on risk.

These obligations ensure that identity data is not only accurate but also legally defensible, meeting the standards regulators require for financial transactions on public chains.

Data provided by a licensed entity ensures these obligations are met, otherwise the transaction cannot be considered compliant at the contract level.

Chainlink

The offchain to onchain delivery mechanism of the identity data must be performed by Chainlink because Chainlink is the most secure, decentralized method of doing so.

Chainlink’s decentralized oracle network eliminates single points of failure, ensuring that identity data remains trustworthy and untampered during its transition from offchain to onchain. If Chainlink is not used to get the data onchain, then the possibility of the data being compromised during the delivery process goes from zero to more than zero. Any shred of doubt in the integrity of the data means it cannot be considered compliant.

Conclusion

All of these requirements — Absolute Sybil-resistance, Licensed Provider, and Chainlink— must be met to preserve the integrity of the identity data and the CLC system itself. These are high-level invariants; compromising any one of them renders the data non-compliant, and undermines the ability of Contract Level Compliance to fulfill its mission statement. Together, they pave the way for broader adoption of smart contracts in regulated industries.

Identity Data Requirements for Contract Level Compliance was originally published in CoinsBench on Medium, where people are continuing the conversation by highlighting and responding to this story.