# 04 core infrastructure Auvin Chain has two core financial primitives built in at the protocol level: a self-developed cross-chain bridge and a DEX based on the Ve(3,3) model. Together they form the liquidity heart and secure foundation for asset interoperability across the ecosystem. ## 4.1 Self-Developed Cross-Chain Bridge: ZK + TSS Hybrid Architecture In the multi-chain Web3 era, cross-chain bridges are the only conduit for value transfer between different blockchains. Yet cross-chain bridges are also the most security-incident-prone sector in Web3. Cumulative bridge hacks exceeded $2.8 billion by end of 2024, accounting for 40% of all Web3 security exploit losses. ### Industry Security Pain Points In 2022 alone: * **Ronin Bridge** lost $624M (5/9 validator keys compromised) * **Wormhole** lost $326M (signature verification vulnerability) * **Nomad Bridge** lost $190M (contract upgrade introduced vulnerability) The root cause is architectural—traditional bridges are essentially "multi-sig wallets" where private keys exist in complete form at some point; hackers who compromise enough nodes can steal all locked assets. Auvin Chain's self-developed cross-chain bridge adopts a ZK+TSS hybrid architecture that fundamentally eliminates this structural flaw. ### ZK Verification Layer—Responsible for "Verification" When assets need to cross from one chain to another, Zero-Knowledge Proofs verify the authenticity of cross-chain messages. The process: 1. A prover generates a ZK-SNARK proof on the source chain proving that an asset lock/burn event occurred in a valid block, including transaction Merkle proof and block header verification 2. The proof is relayed to the destination chain via a decentralized relay network 3. The destination chain's verifier contract validates the mathematical correctness of the ZK proof—verification relies purely on cryptographic computation without trust assumptions 4. Upon verification, corresponding assets are released on the destination chain ### TSS Signature Layer—Responsible for "Signing" Threshold Signature Scheme (TSS) based on Multi-Party Computation (MPC) fragments private keys across multiple independent nodes. Implementation: * Shamir's Secret Sharing splits the private key into n fragments distributed across n independent nodes * Any t fragments can reconstruct a valid signature (t-of-n threshold), but fewer than t fragments reveal zero private key information * The signing process completes via MPC protocol without ever reconstructing the private key—each node participates in distributed signing computation, outputting a valid signature while the private key never exists in complete form at any moment ### Table 4-1: TSS Threshold Configurations and Security Levels | Configuration | Security Level | Fault Tolerance | Application Scenario | | ------------- | ------------------ | ------------------------------ | ------------------------------ | | 2-of-3 | Minimum redundancy | 1 node offline or compromised | Testnet; low-risk assets | | 3-of-5 | Medium security | 2 nodes offline or compromised | Medium-scale asset transfers | | 5-of-9 | High security | 4 nodes offline or compromised | Mainnet daily operations | | 8-of-11 | Extreme security | 3 nodes offline or compromised | Large transfers; emergency ops | ### Cross-Chain Bridge Architecture Flow ``` ┌─────────────────────────────────────────────────────────────────────────┐ │ CROSS-CHAIN BRIDGE FLOW │ ├─────────────────────┬─────────────────────┬─────────────────────────────┤ │ SOURCE CHAIN │ RELAY NETWORK │ DESTINATION CHAIN │ ├─────────────────────┼─────────────────────┼─────────────────────────────┤ │ 1. User initiates │ │ │ │ cross-chain │ │ │ │ transfer │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ 2. Asset lock/burn │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ 3. Generate │ │ │ │ ZK-SNARK proof │ │ │ │ │ │ │ │ │ └──────────►│ 4. ZK proof relay │ │ │ │ + TSS distributed │ │ │ │ signing │ │ │ │ │ │ │ │ │ └──────────►│ 5. ZK Verification Layer │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ 6. TSS Signature Layer │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ 7. Asset release to │ │ │ │ target address │ └─────────────────────┴─────────────────────┴─────────────────────────────┘ ``` ### Hybrid Architecture Security Logic ZK verifies cross-chain message authenticity (cryptographic guarantee); TSS authorizes asset release on the destination chain (distributed control). Neither can be bypassed: even if ZK proof is verified, TSS signature is still required for asset release; even if TSS nodes are partially compromised, without a valid ZK proof cross-chain events cannot be forged. An attacker must simultaneously breach two independent trust lines—the cryptographic proof system and the distributed key management system—making successful attack mathematically nearly impossible. ## 4.2 Ve(3,3) Decentralized Exchange The DEX is the liquidity heart of any public chain. To fundamentally solve the liquidity drain problem of traditional AMMs, Auvera Chain adopts the Ve(3,3) model—widely recognized as the most advanced tokenomics architecture in DeFi. ### Origin and Validation of Ve(3,3) Ve(3,3) was pioneered by DeFi visionary Andre Cronje (Yearn Finance founder) in 2022, applied to the Solidly project. It elegantly combines Curve's Vote-Escrow mechanism with OlympusDAO's (3,3) game theory. The model was brought to prominence on Coinbase's Base chain through Aerodrome: * $200M TVL in 72 hours post-launch * TVL peak of $1.02B * Cumulative trading volume of $238B * Capturing 47%–63% of Base's DEX market share * 2024 annual revenue of $119M made it the highest-revenue DEX globally—2.4x that of Uniswap The Ve(3,3) model has been validated on 6+ public chains. ### Four Core Mechanisms of Auvin Chain's Ve(3,3) DEX {% stepper %} {% step %} ### 1. Concentrated Liquidity LPs can concentrate funds within specific price ranges, dramatically improving capital utilization and reducing slippage. Modeled after Aerodrome's Slipstream module, concentrated liquidity contributes 85% of Aerodrome's trading volume post-launch. {% endstep %} {% step %} ### 2. Gauge Weight Voting System Users lock AUV DEX platform tokens for extended periods (minimum 1 week, maximum 4 years) to receive veToken (vote-escrowed Token). veToken grants holders voting rights in the Gauge system to determine per-cycle Emissions allocation. Each liquidity pool has a Gauge; veToken holders vote proportionally to determine each Gauge's emission weight. New protocols can "bribe" to acquire liquidity incentives—paying $10K in bribes typically yields \~$20K in emissions return. {% endstep %} {% step %} ### 3. Dynamic Emissions and Rebase Anti-Dilution The model incorporates strict emission curves and Rebase supply adjustment: ``` weeklyEmissions = baseEmission × (1 - veTokenRatio) ``` Where `veTokenRatio = total veToken supply / total Token circulating supply` As total lock rate increases, emissions proportionally decrease. Rebase protects long-term lockers from dilution: ``` rebase = weeklyEmissions × (1 - veTokenRatio)² × 0.5 ``` {% endstep %} {% step %} ### 4. 100% Fee Rebate Users who lock liquidity and participate in voting receive 100% of trading fees from pools they vote for, plus external protocol "bribes." Fee allocation: ``` userFees = poolTotalFees × (userVotes / totalVotesInPool) ``` Aerodrome has distributed over $295M in fees to veAERO holders. {% endstep %} {% endstepper %} ### Liquidity Flywheel Effect The ultimate goal of Ve(3,3) is a self-reinforcing liquidity flywheel: ``` ┌──────────────────────────────────────────────────────────────┐ │ LIQUIDITY FLYWHEEL │ │ │ │ New protocols need liquidity │ │ │ │ │ ▼ │ │ Purchase liquidity via Bribes │ │ │ │ │ ▼ │ │ Receive AUV Emissions │ │ │ │ │ ▼ │ │ Attract LPs ───────► Deeper liquidity │ │ │ │ │ ▼ │ │ Lower slippage │ │ │ │ │ ▼ │ │ More trading volume │ │ │ │ │ ▼ │ │ More fees │ │ │ │ │ ▼ │ │ ┌───────────────── More ve locking ◄─────────────────────┐ │ │ │ Reduced circulating supply │ │ │ │ Price support │ │ │ └───────────── Attract new protocols ◄──────────────────┘ │ │ │ │ Once launched, the flywheel self-reinforces. │ └──────────────────────────────────────────────────────────────┘ ``` ### Table 4-2: Ve(3,3) vs Traditional AMM Comparison | Dimension | Traditional AMM (Uniswap V2) | Ve(3,3) (Aerodrome) | | -------------------- | ------------------------------------ | ---------------------------------------------- | | Liquidity Incentives | Fixed allocation to all LPs | Dynamically determined by veToken holder votes | | Fee Distribution | 0.3% mostly to LPs, protocol retains | 100% to veToken voters | | Liquidity Stickiness | Low; "mercenary capital" migrates | High; via bribes + vote locking | | Governance | Token-weighted voting | Lock duration-weighted voting | | Capital Efficiency | Low; full-range liquidity | High; concentrated + dynamic | | Ecosystem Incentives | No native protocol incentives | Bribes mechanism incentivizes new protocols | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://auverachain.gitbook.io/auvinchain/english/auvin-chain-collection/white-paper/04-core-infrastructure.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.