> For the complete documentation index, see [llms.txt](https://valuex.gitbook.io/valuex-whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://valuex.gitbook.io/valuex-whitepaper/value-x-whitepaper/4.-value-x-chain.md). # 4. Value X Chain Infrastructure A dedicated EVM chain is operated so that environmental transactions are processed separately from outside traffic and fees stay predictable.
### 4.1 Current Operating Status Value X Chain is an independent, Avalanche-based EVM application chain and is currently live. Because Value X Chain is an EVM-compatible chain, it uses Ethereum development tools and wallet standards without modification. Value X Chain has adopted the Avalanche L1 validation structure introduced under ACP-77. ![](https://4111024654-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fw7YoFCbsDz1NbkOTHoHH%2Fuploads%2FPfnqiWvunglfCk6GhONf%2FChatGPT%20%EC%9D%B4%EB%AF%B8%EC%A7%80%202026%EB%85%84%209%EC%9B%94%2028%EC%9D%BC%20%EC%98%A4%ED%9B%84%2003_56_57.png?alt=media\&token=d1cd9985-3d7c-43e8-a102-2717859a91a7) **Value X Chain is an independent EVM execution chain based on Subnet-EVM, separate from the C-Chain of the Avalanche mainnet.** Value X Chain has its own asset ecosystem, and its native asset is **VLX (EVM Chain ID: 90000)**. Coin issuance and transfers, as well as smart contract execution, are processed on Value X Chain's own EVM execution layer, not on the Avalanche mainnet. The Avalanche P-Chain functions as the layer that manages Avalanche L1 metadata and validator registration. Detailed parameters, including the RPC endpoint, block explorer, Subnet ID and Blockchain ID, Genesis configuration and VM version, are planned to be made public through disclosure. ### 4.2 Why a Dedicated Chain There are three reasons for running a dedicated chain. First, fees must be predictable, because small point accruals and IoT commits stop being economical when gas prices rise. Second, processing capacity must hold steady regardless of outside traffic. Third, network usage turns directly into token demand only when VLX is used as the gas token. ### 4.3 Smart Contract Scope The core contract groups that run on Value X Chain are listed in the table below.
Contract groupHow it operatesCurrent status
Asset exchange (swap)Creating and managing exchange pools between registered assets; checking signed quotes for validity, expiry and reuse; executing exchangesContracts deployed; preparing to open trading
Asset bridgeMoving assets between external chains and Value X Chain; managing payout inventory per chain and limits per assetDeployed on 6 chains; routes inactive
Fee distribution logicSplitting fees that accrue to the protocol into a burn share, a sponsorship and ecosystem contribution share, and an operations shareExecution method not yet finalized
Card payment settlementOn-chain recording of settlement events from payment partnersTo be designed after the card program structure is finalized
Point issuance and burnIssuing Carbon Points based on MRV verification results; burning them when they are used or retiredTo be introduced when on-chain MRV opens
Verification rule registryOn-chain registration and lookup of methodology versions and parametersTo be introduced when on-chain MRV opens
Each contract group is deployed independently. The deployed contracts implement function-level controls: owner permission checks, pausing, signature verification, blocking of expired or reused quotes, supported-asset checks and payout limits. The deployment, quoting, settlement and transfer roles are kept operationally separate. The configuration of the wallets that hold administrative permissions, the scope and thresholds of multisig, and the deployment addresses are publicly disclosed. Notice on contract upgradeability. The deployed core management contracts are implemented with an upgradeable proxy structure (UUPS), and the exchange pool contracts share a single implementation through a common Beacon. Under this structure, a party with the required permissions can replace the execution logic while the contract addresses that users and services refer to stay the same. When a contract is upgraded, the storage layout and initialization conditions are verified to confirm compatibility with the existing state. Contract code can change after deployment, and a party with change permissions can alter logic that affects user assets. The holders of upgrade permissions and the approval process are managed under the parameter change procedure, and the permission configuration and change history are disclosed on official channels. ### 4.4 Cross-Chain Interoperability AetherFlow Wallet offers asset exchange over two routes. One uses third-party integrations for exchanges and transfers between external networks. The other, which VLX operates directly, handles exchanges between Value X Chain and external chains. ![Figure 4. Transaction processing sequence for AetherFlow cross-chain asset exchange](https://4111024654-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fw7YoFCbsDz1NbkOTHoHH%2Fuploads%2FrGuWSfJHbHKETUq4HoBU%2FChatGPT%20%EC%9D%B4%EB%AF%B8%EC%A7%80%202026%EB%85%84%209%EC%9B%94%2028%EC%9D%BC%20%EC%98%A4%ED%9B%84%2003_32_50-2.png?alt=media\&token=3ba2d332-529b-45a2-a074-195e11cb3ada) The app displays assets on Value X Chain and on Avalanche, Arbitrum, Base, Ethereum, Polygon and BNB Chain. Payouts are made only up to the inventory already prepared, and payout limits and reference prices for each asset are registered in advance. This route does not issue new assets, so using the bridge neither increases nor decreases the total supply of VLX. When an order is created, inventory on the destination chain is reserved first, and the payout is approved only after the deposit on the source chain and its finality status have been confirmed. The contents and hash of each payout transaction are recorded before it is sent, which prevents duplicate payouts caused by communication errors or job restarts. An order is marked complete only after the payout result on the destination chain has also been confirmed. The preview shown when a user enters an amount does not reserve inventory. The signed quote and the inventory reservation are created when the user proceeds with the transaction. Bridge custody contracts have been deployed on 6 chains (Value X Chain, Arbitrum, Avalanche, Base, BNB Chain and Polygon), and bidirectional connections have been completed. A total of 20 directional routes have been registered between VLX and the external chains' native assets and USDC. However, these routes open only after the payout inventory on both sides, per-asset limits and finality conditions have been configured and a round trip with real funds has been verified. They are currently inactive. Asset lookup in the app covers 7 networks: the 6 chains above plus Ethereum. Ethereum is not among the deployment targets of the in-house bridge. Limit policies are kept conservative. The exchange feature of AetherFlow Wallet follows an "inventory-based exchange" model, swapping assets prepared in advance on each chain (inventory) at a reference price. It is not a typical "cross-chain bridge" that issues new tokens. Limit policies and an advance reservation procedure are in place, but because of how the service is structured, users must review the following risks before using it. 1. **Operator credit risk:** This service runs on the asset management and settlement systems of the operating entity. 2. **Inventory shortage and delay risk:** Payouts may be delayed if real-time asset inventory on the destination chain is insufficient, or if the blockchain network is congested or finality is delayed. 3. **Price fluctuation risk:** Amounts are converted at a pre-registered reference price, so they may differ somewhat from real-time market prices. 4. **Settlement signer risk: The settlement signer nodes that approve and verify transactions carry operational risk.** ### 4.5 Security Model and Limitations The initial validators consist of the operating entity and selected partners, and the current level of decentralization is limited compared with mature public chains. Permissions for upgrades, parameters and the sponsorship wallet are each managed by a separate multisig. The signer composition and thresholds are disclosed on official channels. Bridge payouts are approved by the operator's settlement signer after it checks the deposit and finality status on the source chain; the contracts do not verify the consensus of external chains directly. The bridge therefore depends on trust in the operator's signer and its finality judgments, and it is not a trustless structure that works without trusting outside parties. As mitigations, per-asset payout limits and finality waiting periods are in place, and the deployment, quoting, settlement and transfer roles are kept separate. The exchange and bridge contracts implement owner permission checks, pausing, signature verification, blocking of expired or reused quotes, supported-asset checks and payout limits, and they have gone through automated testing and verification in local EVM and fork environments. This does not mean, however, that an external independent security audit has been completed; no external independent security audit has been completed. External audits and the bug bounty are scoped separately, and their plans and results are disclosed on official channels. Even after an audit is completed, the risk does not fall to zero. ***