Cross-chain with LayerZero V2

Positions stay on their home chains while Gemas, Debt, Matches and Backings live on Solana, so four messages cross chains. ADR 0002 picks LayerZero V2 on Solana devnet, Ethereum Hoodi and HyperEVM testnet: the only transport verified to reach all three with managed relaying. A trusted Tesoro relayer was rejected in favour of real infrastructure.

The four messages

Wire format (identical in Solidity and Rust, abi.encodePacked, big-endian): header msgType u8 | sourceChain u32 (eid) | positionId bytes32 | seq u64 (45 bytes), then the body. The positionId is the vault address (20 bytes), the vault's Position id (u64) and 4 zero bytes, so two vaults on one chain never collide and a vault can speak only for its own Positions. Every handler is idempotent per sequence number.

Pieces

Flow and who pays

1. Link, once. The Account's Solana wallet calls tesoro_bridge::link_evm with an EIP-191 signature from the EVM wallet over Tesoro: link EVM address to Account <TesoroAccount PDA>. The bridge recovers the signer on chain with secp256k1_recover, so nobody can claim someone else's address.
2. Inbox record. Anyone creates the record with init_position(eid, positionId) before the message (about 0.003 SOL), because the default executors cap the native drop to Solana at 0 and rent cannot be paid inside lz_receive.
3. openPosition(lstAmount, months). The caller pays the LayerZero fee in the chain's native coin (the app reads quotePositionLocked() and adds about 20%; the excess is refunded).
4. apply_locked. Permissionless: the bridge CPIs open_position_from_source, signed by its PDA. PeerConfig per vault supplies decimals and rate. Principal must fit u64, so up to about 18 ETH; the vault refuses larger deposits.
5. Advance. The oracle path in tesoro_core: the owner and the oracle co-sign, the oracle supplies the issuance price.
6. reportYield, then apply_yield. The vault accrues first, so the cumulative figure includes everything earned up to that block. Debt falls automatically.
7. Redeem. The holder calls tesoro_bridge::redeem_to_evm, which CPIs redeem_from_source and records the units in a Claim. Anyone then calls send_pay_yield, which advances units_sent in the same transaction so a unit is paid once. Plain redeem refuses EVM-sourced Sources (audit F-07).
8. Unlock. After tesoro_core::unlock, anyone calls send_unlock. Yield still owed to redeemers stays in the vault.

lz_receive deliberately only records the fact: its account list is derived from the message alone and cannot include the Account, the open Source or rent-funded accounts. Applying is a second, permissionless transaction.

Endpoints and latency

The default pathway configuration uses LayerZero Labs as the single required DVN. Fees seen: about 0.0001 ETH per Hoodi send, about 0.0074 HYPE per HyperEVM send (so a wallet needs roughly 0.02 HYPE to open a Position), and about 0.0003 SOL per Solana send.

HyperEVM testnet gas

There is no HYPE faucet to relay, so the app server sends a small top-up (0.03 HYPE if the wallet holds under 0.02, once a day per wallet, with a global hourly limit) from a low-balance relayer key.

Failure behaviour

• An out-of-order delivery could once strand an Unlock or PayYield (audit F-04). Vaults now record each sequence as handled, so order does not matter, and the vaults were redeployed.
• A PayYield larger than the vault's accrued yield reverts, and a reverted receive rolls back its handled mark, so LayerZero can retry it once yield catches up (F-13).
• The vault always caps a payout at its own accrued yield, so a lying DVN could report false yield but could not drain Principal through PayYield.