Cross-Chain Functionality

Overview

The Curvance Protocol implements a sophisticated cross-chain architecture that enables seamless operation across multiple blockchains while maintaining protocol-wide consistency. This architecture enables unified governance, shared incentives, and the efficient distribution of rewards across the entire ecosystem.

Core Architecture Components

The cross-chain system consists of several specialized components that work together:

Key Components

1. CentralRegistry: Serves as a single source of truth for each chain, containing protocol configuration and contract addresses.

2. MessagingHub: The unified communication layer that enables cross-chain message passing. It handles:

   1. Epoch coordination

   2. Fee distribution

   3. Token bridging

   4. veCVE lock migration

   5. Governance message propagation

3. FeeManager: Collects protocol fees and prepares them for cross-chain distribution.

4. RewardManager: Distributes rewards to veCVE holders based on their proportional lock amounts.

5. VotingHub: Coordinates token emission allocation across all chains based on governance decisions.

Cross-Chain Communication

Curvance's cross-chain architecture relies on two primary technologies:

1. Wormhole

   1. Facilitates generic message passing between chains

   2. Provides Cross-Chain Query (CCQ) capability for state verification

   3. Powers the system's VAA (Verifiable Action Approval) verification

2. Circle's CCTP (Cross-Chain Transfer Protocol)

   1. Handles token transfers between chains

   2. Primarily used for fee and reward token movements

Primary Data Flows

The Curvance Protocol has several critical cross-chain data flows:

1. Epoch Execution and Fee Distribution

This diagram illustrates the bi-weekly process of distributing protocol fees across all chains in the Curvance ecosystem:

1. A privileged operator initiates the process on one chain by querying veCVE lock points across all other chains using Wormhole CCQ.

2. After verification of chain data, the system pulls accumulated fees from the local FeeManager.

3. The protocol calculates each chain's share of fees based on the proportion of total veCVE points on that chain.

4. Fees are then transferred to destination chains using CCTP for the token transfer, alongside a Wormhole message carrying distribution instructions.

5. Each receiving chain's MessagingHub routes the received tokens to its RewardManager for distribution to veCVE holders proportionally.

This mechanism ensures fair fee distribution based on governance participation across all chains in the ecosystem.

2. CVE / veCVE Cross-Chain Migration

CVE Bridging

1. User initiates bridge on source chain

   1. Calls bridge(recipient, dstChainId, amount, gasLimit) on CVE contract

   2. Pays required message fee

2. Accounting & Message Prep

   1. CVE contract burns user's tokens (_burn(msg.sender, amount))

   2. CVE calls MessagingHub's bridgeToken() with payloadType 5

   3. MessagingHub validates parameters (chain support, recipient address)

   4. MessagingHub calls Wormhole to send cross-chain message

3. Wormhole Message

   1. Wormhole network relays the message to destination chain

   2. Message contains recipient address and token amount

4. Accounting & Validation

   1. MessagingHub receives and validates the Wormhole message

   2. Checks that message hasn't been processed before (prevents replay)

   3. For payloadType 5, calls completeBridge() on destination CVE

   4. Destination CVE mints tokens to recipient

5. Result

   1. User now has equivalent CVE tokens on destination chain

   2. Total supply across chains remains constant (burned on source, minted on destination)

veCVE Bridging

1. User initiates lock bridge on source chain

   1. Calls bridgeLock(lockIndex, bridgeData, rewardsData, params, aux) on veCVE

   2. Provides destination chain info and continuousLock status preference

   3. Pays required message fee

2. Accounting & Message Prep

   1. Claims any pending rewards for user

   2. Updates user's points to reflect removed lock

   3. Burns user's veCVE tokens

   4. Removes lock entry from storage

   5. Calls burnLockedTokens() on CVE to burn underlying tokens

   6. veCVE calls MessagingHub's bridgeToken() with payloadType 4

   7. Encodes lock parameters (amount, continuous lock status)

   8. MessagingHub validates and sends Wormhole message

3. Wormhole Message

   1. Wormhole network relays the message to destination chain

   2. Message contains original owner, amount, and lock properties

4. Accounting & Validation

   1. MessagingHub receives and validates the Wormhole message

   2. For payloadType 4, calls mintLockedTokens() on destination CVE

   3. CVE mints tokens to MessagingHub

   4. MessagingHub approves veCVE to spend the tokens

   5. Calls createLockFor() on veCVE with same properties

5. Result

   1. User has equivalent veCVE lock on destination chain

   2. Lock maintains same continuous status as selected

   3. Total veCVE supply across chains remains consistent

3. Todo: Emissions & Gauge flow

State Machine

The Curvance cross-chain architecture implements several key states:

Epoch State Machine

This diagram outlines the state transitions during a Curvance protocol epoch:

• Epoch Start: A new epoch begins based on the timestamp defined by genesisEpoch + (epochNumber * EPOCH_DURATION).

• Fee Collection & Trading Activity: During the epoch, fees accumulate from protocol activity across all chains independently.

• Cross-Chain Coordination: Near epoch end, the protocol aggregates veCVE points across all chains using Wormhole CCQ to determine reward distribution.

• Fee Distribution: Collected fees are distributed pro-rata to each chain based on its proportion of total veCVE points, with tokens bridged using CCTP.

• Epoch Completion: The nextEpochToDeliver counter is incremented, allowing the system to track epochs sequentially and ensure proper distribution.

The epoch system operates in a strictly sequential manner to ensure consistency across chains.

Fault Tolerance & Security Measures

The cross-chain architecture implements several safety mechanisms:

1. Message Hash Verification: Each cross-chain message is tracked by its hash to prevent replay attacks.

2. Messaging Status Controls: The messaging hub can be put into various states to control message creation and execution:

   • Status 1: Full operation (create and execute messages)

   • Status 2: Execute-only mode (no new messages)

   • Status 3: Complete pause (no operations)

3. Guardian Validation: Uses Wormhole guardians to validate cross-chain messages through VAA signatures.

4. Chain Verification: Messages are only accepted from known, registered chains configured in the Central Registry.

5. Fallback Mechanisms: If the system gets stuck, administrative overrides exist to ensure continued operation.

Consistency Model

The Curvance Protocol maintains cross-chain consistency through:

1. Synchronized Epochs: All chains share a common epoch schedule, defined by the genesisEpoch and epochDuration values.

2. Cross-Chain Queries: The system uses Wormhole's CCQ to verify the state of remote chains before making critical decisions.

3. Sequential Epoch Processing: Each epoch must be processed in order, and all chains must catch up sequentially (tracked via nextEpochToDeliver).

4. Verifiable Messages: All cross-chain communications are verified through cryptographic signatures from Wormhole guardians.

In Conclusion

The Curvance cross-chain architecture creates a unified, multi-chain DeFi protocol that maintains consistency and shared state across all supported networks. This design enables protocol-wide coordination for token emissions, fee distribution, and governance while allowing users to interact with the protocol on their preferred blockchain.