Skip to content

NEST OVERVIEW

Cross-Chain Architecture

Nest vaults are designed to operate across multiple chains while preserving one consistent vault accounting model. When Nest extends a vault to an EVM chain, the full vault architecture can be deployed on that chain: vault entrypoints, share tokens, accounting contracts, authorization controls, and cross-chain messaging configuration. This lets users interact with a vault from the chain they already use while the vault system preserves consistent share accounting across deployments.

Each vault uses an accountant to determine the share price and enforce accounting guardrails such as rate bounds, update timing, and pause controls. For cross-chain vaults, Nest uses a hub-and-spoke accountant model: the hub accountant acts as the canonical accounting source, while spoke accountants on connected chains expose the accounting state needed for local deposits, redemptions, and share conversions. Integrations should read the accountant configured for the chain where they transact; Nest operations update configured accountant state so conversions remain aligned across supported chains.

Cross-chain communication is handled through LayerZero’s OFT infrastructure. Nest share tokens are omnichain tokens, so moving shares between supported chains uses burn/mint style OFT messaging rather than wrapping a separate bridge receipt token. The same messaging layer is used by Nest’s cross-chain vault infrastructure to coordinate vault actions and move share state across chains.

On EVM chains, users interact with Nest through the same core vault contracts they would use on Plume. Deposits and redemptions are executed against local Nest vault infrastructure, and share movement between EVM chains is handled through the Nest share OFT. This means an EVM integrator usually does not need to reason about a separate bridge flow: the vault contracts and share OFT expose the relevant deposit, redeem, and transfer surfaces.

When a user moves vault shares between EVM chains, the source-chain share representation is burned or debited and the destination-chain representation is minted or credited through LayerZero OFT messaging. The vault’s accounting model remains tied to the Nest accountant state rather than to the chain where the user happens to hold shares.

Solana support uses a different flow because Solana assets and programs do not call the EVM vault contracts directly. The user can start from Solana and the tokens are natively minted on Solana, but Plume Network is used as the underlying settlement layer for the assets. The vault deposit or redemption settles through Plume-side Nest contracts, where the accountant, composer, and relayer infrastructure coordinate the final vault action.

For Solana minting, the user deposits Solana USDC. USDC is transferred to Plume through Circle CCTP, and the Nest CCTP relayer receives the CCTP message and executes the configured hook into the NestVaultComposer. The cross-chain flow is cryptographically enforced onchain: offchain keepers can relay valid messages, but they cannot mint shares or settle vault actions outside the configured CCTP, OFT, and composer rules. The composer deposits the USDC into the Plume-side Nest vault, receives vault shares, and sends those shares back to the user on Solana through LayerZero OFT messaging.

For Solana redemptions, the user sends Solana Nest tokens through the OFT path. The corresponding vault shares settle back through Plume, where the composer redeems against the vault and the resulting USDC is returned to Solana through CCTP.

The default fast Solana mint and redeem path uses Circle’s fast CCTP finality mode. That path is designed to complete in under one minute and includes a 1 bp CCTP fee. This is the default behavior in the Nest UI and API. The API can also support a slower CCTP path without the fast-finality fee for integrations that prefer lower cost over speed.