Curvance
  • Protocol Overview
    • Click Less, Earn More
    • Protocol Architecture
    • Asset Types
    • Liquidity Markets
      • Borrowing
      • Liquidations
      • Interest Rates
      • Oracles
      • Collateral Caps
      • Bad Debt Socialization
    • Application Specific Sequencing
    • New Age Liquidity Mining
      • Protocols
    • How Are New Assets Integrated
    • Plugin System
    • Universal Account Balance
    • Token Approval Management
    • Lending Risks
  • Security
    • Security and Audits
  • Miscellaneous
    • RPCs and Testnet Stability
    • Glossary
    • TL;DR
      • Customer Types and Benefits
    • Brand Assets
    • Weblinks
    • Disclaimer
    • Frequently Asked Questions
  • Developer Docs
    • Overview
    • Quick Start Guides
      • Atlas Fastlane Auctions (coming soon)
      • Plugin Integration
        • List of Delegable Actions
      • Loans & Collateral
        • Lend Assets
        • Deposit into pTokens
        • Withdraw Loans
        • Withdraw pTokens
      • Borrowing & Repayment
        • Borrow
        • Repaying Debt
      • Leverage
        • Leveraging
        • Deleveraging
    • Lending Protocol
      • Market Manager
      • Position Tokens (pToken)
      • Earn Tokens (eTokens)
      • Dynamic Interest Rate Model
      • Universal Balance
    • Position Management
      • Leverage
      • Deleverage / Fold
    • Dynamic Liquidation Engine (DLE)
      • Orderflow Auction System
      • Bad Debt Socialization
    • Plugin & Delegation System
      • Transfer Lock Mechanism
      • Delegable Actions
    • Cross-Chain Functionality
      • Messaging Hub
      • Fee Manager
      • Reward Manager
    • Auxiliary Functionality
Powered by GitBook
On this page
  • Overview
  • Core Architecture Components
  • Cross-Chain Communication
  • Primary Data Flows
  • State Machine
  • Fault Tolerance & Security Measures
  • Consistency Model
  • In Conclusion
Export as PDF
  1. Developer Docs

Cross-Chain Functionality

PreviousDelegable ActionsNextMessaging Hub

Last updated 14 days ago

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. Governance message propagation

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

  4. RewardManager: Distributes rewards to entitled parties.

  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 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 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 point accumulators proportionally.

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

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 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 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.