Onyx, also referred to as the XCN Ledger, is a highly scalable Layer 3 blockchain network that is architected for performance, security, and cost efficiency. It is deployed using the Arbitrum Orbit stack and benefits from the robust security foundation of Coinbase’s Base Layer 2 blockchain. This unique architecture enables Onyx to inherit the modular scalability of Arbitrum while maintaining the security assurances provided by Base, offering an optimized environment for developers building next-generation decentralized applications (dApps).

Onyx is fully Ethereum Virtual Machine (EVM) compatible, allowing seamless deployment of smart contracts and interoperability with existing Ethereum-based applications and tooling. Developers can build and deploy decentralized finance (DeFi) protocols, payment solutions, governance frameworks, and other blockchain-based services while leveraging Onyx’s high throughput and low transaction costs.

With an institutional-grade infrastructure, Onyx is designed to support large-scale applications and enterprise adoption, ensuring high availability, robust security mechanisms, and scalability optimizations.

The Onyx Documentation Hub is the central resource for institutions and developers looking to build, integrate, and leverage the full potential of Onyx This comprehensive documentation provides in-depth technical details, architecture specifications, and implementation guidelines for developers aiming to utilize Onyx’s blockchain infrastructure efficiently.

Beyond just technical references, this hub serves as a developer-centric knowledge base, offering code samples, API references, SDK integration guides, and best practices for optimizing smart contract deployments and blockchain interactions. Whether you are designing custom dApps, implementing scalable payment systems, or integrating Onyx into multi-chain architectures, the documentation provides a structured approach to understanding transaction finality, network security, gas optimizations, and governance mechanisms within the Onyx ecosystem.

By leveraging the resources provided, institutions and developers can streamline development workflows, enhance security practices, and maximize the performance of their blockchain-based applications on Onyx.

Quick Start Below:

The following smart contract addresses are integral to the Onyx blockchain infrastructure. These addresses correspond to core protocol contracts and token bridge contracts, which facilitate transaction processing, cross-chain interoperability, and protocol governance. Developers building on Onyx should reference these addresses for contract interactions, cross-chain asset transfers, and network-specific implementations.

Layer 1 Governance & Staking

The smart contracts for Onyx on Ethereum are below:

Layer 3 Core Protocol Contracts

The core smart contracts of Onyx define the network’s fundamental operations, including transaction finalization, message passing, and state synchronization.

Token Bridge Contracts

The Token Bridge Contracts enable seamless asset transfers between Onyx and external networks. These contracts are responsible for asset locking, minting, and validation in both Layer 2 (L2) and Layer 3 (L3) environments.

L2 Token Bridge Contracts:

L3 Token Bridge Contracts

Onyxcoin (XCN) is the native cryptocurrency of the Onyx Protocol, a next-generation Web3 blockchain platform specifically designed to power decentralized financial services. As the cornerstone of the Onyx ecosystem, XCN plays a dual role as both a utility token and a governance asset, underpinning the protocol’s core operations and community-led development.

Within the ecosystem, XCN enables a wide range of functionalities. It is essential for participating in protocol governance, where token holders can propose and vote on critical updates, changes to the network’s parameters, and allocation of treasury funds—ensuring a decentralized and transparent decision-making process. In addition, XCN acts as a payment mechanism for accessing Onyx’s suite of financial applications and premium services, including Chain.com and other infrastructure products.

XCN is also the native gas token for the Onyx Ledger, a high-performance Layer-3 blockchain built atop Ethereum and Base. This means that all transactions and smart contract executions on the Onyx Ledger are powered by XCN, with a portion of each transaction fee being burned to introduce a deflationary mechanism and support long-term value appreciation.

Overall, Onyxcoin (XCN) functions as the economic engine driving innovation, security, and user engagement across the entire Onyx Protocol—empowering users, developers, and stakeholders in a truly decentralized financial ecosystem.

Onyx AI: Autonomous Blockchain Intelligence on the XCN Ledger

Onyx AI is a next-generation, blockchain-native autonomous agent engineered to interface directly with decentralized infrastructure on the XCN Ledger. It combines on-chain execution capabilities with off-chain artificial intelligence reasoning, enabling intelligent automation of complex tasks across decentralized finance (DeFi), token management, and cross-chain operations. This hybrid agent is designed to operate with programmable autonomy, execute smart contract interactions, and respond to user prompts with contextual awareness and transaction precision.

At its core, Onyx AI functions as a self-directed, modular smart agent deployed natively on the XCN Ledger, leveraging XCN as the sole gas asset for computation, execution, and value transfer. XCN is required to purchase Credits that enable the user to utilize prompts with the Agent.

The agent is architected to bridge the gap between AI-driven logic systems and the deterministic nature of EVM-compatible smart contract environments. It operates under a permissionless framework but utilizes embedded security policies to ensure safe execution across trusted protocols and wallet environments. The agent operates on a gas-free basis on supported chains therefore there is no requirement for native gas on the blockchain.

Onyx AI marks a pivotal shift in the evolution of decentralized automation. By tightly integrating artificial intelligence with blockchain-native execution, it enables a future where agents—not just humans—can reason, transact, and operate autonomously within secure, deterministic environments. With Onyx AI, intelligent on-chain automation becomes accessible, programmable, and trustless.

The Onyx Governance API provides programmatic access to governance data, proposal tracking, and voting details within the Onyx protocol. Developers and governance participants can use this API to fetch real-time governance data, submit transactions, and monitor proposal statuses.

The Governance API Base URL is: govapi.onyx.org

Release Schedule

XCN is released monthly from two smart contracts.

• 200 million from XCN Timelock

• 200 million from

XCN Timelock

The XCN Timelock release is governed by a time-locked smart contract designed to release a fixed amount of tokens over time in a predictable and transparent manner. Specifically, 200 million XCN tokens are unlocked every 30 days—defined as one epoch—until the scheduled conclusion of the emission period in March 1, 2030.

XCN DAO

The XCN DAO operates through a separate smart contract that governs the distribution of tokens tied to community governance and user rewards. Like the Treasury, the DAO is subject to the same 200 million XCN per month release cap. However, the actual release of tokens from this contract is conditional:

• Tokens are only distributed when users claim staking or governance rewards, or

• When an Onyx Improvement Proposal (OIP) is deployed and executed onchain.

Importantly, any unused allocation rolls over into the next month. For example, if only 100 million XCN are claimed or utilized in June, the remaining 100 million will be added to July’s allocation, allowing up to 300 million XCN to be distributed that month.

This structure ensures controlled token emissions while allowing flexibility for ecosystem participation and governance engagement to scale over time.

The unlock schedule illustration below guides users to a predictable emission schedule:

Current Distribution

The illustration below shows the current XCN distribution figures and market capitalization as of August 18th, 2025.

This section provides essential technical details regarding Onyx’s publicly available Remote Procedure Call (RPC) endpoints, allowing developers to interact with the Onyx blockchain network. These RPC endpoints facilitate smart contract deployments, transaction broadcasting, data querying, and state synchronization with the Onyx blockchain. Developers and infrastructure providers can integrate these endpoints into their applications, wallets, or blockchain indexing services to ensure seamless interaction with the Onyx network.

Public RPC Endpoints

Onyx provides both HTTPS and WebSocket (WSS) RPC endpoints, enabling developers to connect to the network for executing transactions and retrieving blockchain state data. The WebSocket endpoint is particularly useful for applications requiring real-time event subscriptions, such as monitoring contract events or transaction confirmations. The available endpoints are:

You can access the MiCA whitepaper by following the provided link below. The document, titled “MiCA Whitepaper,” serves as a comprehensive guide to the Markets in Crypto-Assets (MiCA) regulation, outlining its objectives, framework, and implications for the cryptocurrency and digital asset sectors.

Access the MiCA whitepaper .

XCN Supply Details

Onyxcoin has a fixed max supply of 68,892,071,756 units which 20,489,639,348 is currently burned on the Ethereum blockchain giving total supply of 48,402,437,326 XCN.

Summary

Onyx Points is a user-centric rewards mechanism integrated into the Onyx XCN Ledger, specifically engineered to incentivize liquidity provision and active engagement within the broader Onyx blockchain infrastructure. This program is designed to reinforce ecosystem stability, promote organic asset utilization, and position Onyx as a premier protocol hub for institutional blockchain and bank applications, decentralized finance practitioners, capital allocators, and yield-maximizing participants.

Participants can accrue Onyx Points by holding and transacting with approved (whitelisted) digital assets across a curated selection of decentralized applications (dApps) that will be available by Season Two within the Onyx ecosystem. These interactions are tracked and quantified through an on-chain metric system that reflects real economic activity and protocol contribution. Onyx Points serve as non-transferable, reward-bearing credentials to the associated wallet addresses connected to the system.

Seasons

The distribution of Onyx Points is decentralised and organized into discrete epochs known as “Seasons.” Each Season is finite and governed by predefined block height parameters to ensure deterministic issuance and prevent inflationary supply shocks. Points earned are tokenized in the form of NFT-based positions, enabling composability, future utility layering, and provable ownership while also enhancing the gamification layer of user engagement.

Season One of the Onyx Points Program commenced with the protocol’s initial deployment at Onyx XCN Ledger mainnet block height #8305000, marking the official launch of the incentives framework. This inaugural Season will run through August 2025 (Adjusted from September 2025 following OIP-61), culminating in a retroactive allocation of Onyx Points to eligible participants based on their cumulative on-chain activity since the program’s genesis block. This retroactive model ensures that early adopters and contributors are equitably rewarded for their foundational support of the Onyx protocol.

Season Two of the Onyx Points Program officially launched in August 2025, introducing a refreshed incentive structure designed to further reward community engagement. A total of 10 million Onyx Points are distributed daily, split evenly between two key groups of contributors: XCN Stakers and XCN Ledger participants. Each group receives 5 million points per day, with rewards allocated proportionally based on individual participation levels within that group. This balanced approach ensures that both stakers and ledger participants are recognized and rewarded fairly.

Passive Points — Asset Holding Incentives

The Passive Points mechanism is designed to reward users simply for maintaining eligible digital assets in their self-custodied Web3 wallets. This approach incentivizes long-term alignment with the Onyx ecosystem by recognizing and rewarding passive asset holders who contribute to ecosystem stability without requiring active trading or liquidity deployment.

Eligibility Criteria & Wallet Scope

To qualify for Passive Points accrual, users must hold whitelisted assets—a curated list of tokens approved by the Onyx DAO for point rewards—within non-custodial Web3 wallets. Supported wallets include widely-used browser-based solutions such as MetaMask, WalletConnect-compatible interfaces, and secure hardware wallets like Ledger and Trezor.

Importantly, any assets held within centralized exchange (CEX) accounts are categorically ineligible for point accumulation. This restriction ensures that all qualifying holdings are verifiably on-chain, transparent, and cryptographically linked to user-owned wallet addresses. This design choice also encourages decentralized custody practices and aligns user incentives with the ethos of DeFi sovereignty.

Mechanism of Point Accrual

Onyx utilizes a snapshot-based system to periodically capture wallet balances of whitelisted assets. These snapshots are taken at each block allowing the protocol to calculate time-weighted holdings for each address. This means that the longer a user holds a qualifying asset, the more Passive Points they accumulate, scaled proportionally to the quantity held.

For example:

• A wallet that holds 1,000 units of a whitelisted token for 30 continuous days will receive significantly more points than a wallet that intermittently holds the same token across a fragmented period.

• Short-term balance spikes intended to game the system (e.g., flash loans or momentary transfers) are neutralized by time-weighted averages and minimum holding thresholds.

Security and Anti-Sybil Protections

To maintain integrity, the system incorporates Sybil resistance mechanisms such as minimum balance thresholds, wallet linkage detection, and inactivity filters. Additionally, asset verification and tracking are performed using on-chain indexers and Merkle-proof-backed registries, ensuring that all point calculations are fully auditable and verifiable through trustless infrastructure.

Whitelisting Governance and Future Expansion

The list of eligible assets is governed by the Onyx DAO and can evolve over time based on community votes, market relevance, and strategic partnerships. New assets may be added to the whitelist through a formal proposal and review process, which considers liquidity, token utility, smart contract security, and ecosystem alignment.

By rewarding users for simply holding assets in decentralized wallets, the Passive Points system promotes secure custody, reduces sell pressure, and reinforces a culture of long-term value alignment within the Onyx XCN Ledger ecosystem.

The Onyx Governor follows a structured governance model that balances decentralization with security and efficiency. The Timelock contract prevents sudden, unauthorized modifications to the protocol, ensuring all decisions undergo rigorous scrutiny before being enacted. Additionally, the on-chain governance mechanism provides an immutable and transparent record of all proposals, votes, and implementations, reinforcing accountability and trust within the community.

By leveraging Ethereum-based smart contract governance, the Onyx Governor facilitates an efficient and transparent decision-making process that aligns with the interests of long-term stakeholders, ultimately promoting protocol sustainability and robust security standards.

XCN Utility and Governance

🔧 Utility & Gas

• Gas token: Used to pay for all transactions and smart contract executions across the Onyx L3 blockchain. A portion of every transaction fee is burned, making XCN total supply deflationary.

• Service payments & discounts: Required to access and pay for Onyx Cloud (RPC/API) and Sequence ledger services, with XCN holders receiving discounted or premium access.

🗳️ Governance & Staking

• Governance token: XCN holders can stake tokens in the Onyx DAO to propose and vote on protocol changes, emissions, treasury allocations, and more. This ensures protocol security.

• Staking rewards: Stakers secure the network and gain governance power, while also earning periodic staking rewards.

💱 Payment Instrument

• Means of payment: XCN is used within the ecosystem to pay commercial fees and access premium features.

Mechanisms for Earning Onyx Points

The Onyx Points incentive framework provides users with three distinct, yet synergistic, methods through which they can actively participate in the Onyx ecosystem and accrue points. These earning pathways are not arbitrarily defined; rather, they are strategically constructed to align with the foundational principles and operational capabilities of the XCN Ledger. This ensures that the accrual of Onyx Points reflects meaningful engagement, protocol-enhancing behavior, and sustainable economic activity governed by Onyx DAO.

Each method has been optimized to reward users for interacting with core decentralized finance primitives—liquidity provision, asset management, and on-chain utility—while reinforcing protocol security, stability, and user growth. The design intention is to embed incentive structures directly into behaviors that the XCN Ledger is uniquely equipped to support at the protocol level.

The propose function allows eligible stakeholders to create governance proposals that can introduce changes to Onyx. Proposals may include modifications to the staking interest rate model, risk parameters within the protocol, or other governance-directed alterations to protocol parameters.

Once a proposal is submitted, it enters the voting phase, where token holders can vote for or against the proposed changes. If the proposal meets the required quorum and is approved, it is queued and executed via the Onyx Timelock contract after the predefined waiting period.

Proposal Submission Requirements

• The proposer must hold more XCN than the current proposal threshold (proposalThreshold()) as of the immediately preceding block.

• The proposer cannot create a new proposal if they already have an active or pending proposal.

• Due to Timelock restrictions, a proposal cannot contain duplicate actions within the same block.

• Identical actions across different proposals must be queued in separate blocks to avoid execution conflicts.

Function Implementation in CHNGovernance

Function Signature:

Parameters

• targets: An ordered array of target addresses for function calls that will be executed upon proposal approval.

• values: An ordered array of values (i.e., msg.value) to be passed to the respective function calls. This array must match the length of all other array parameters.

• signatures: An ordered array containing function signatures that will be executed as part of the proposal.

Example Solidity Implementation

To submit a proposal using Solidity, the propose() function can be called from an instance of the CHNGovernance contract:

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to submit a proposal:

Technical Considerations

• The propose function is state-modifying and will incur gas costs.

• The proposal threshold may be subject to governance modifications, dynamically altering the eligibility criteria.

• The proposal queueing mechanism ensures execution order integrity and prevents conflicting transactions.

By enforcing structured proposal submission requirements and leveraging the Onyx Timelock, the Onyx governance system ensures that protocol changes are implemented in a transparent, decentralized, and secure manner.

The proposal threshold represents the minimum number of votes required for an account to create and submit a governance proposal within the Onyx governance framework. This requirement ensures that only stakeholders with a significant vested interest in the protocol can initiate changes, preventing spam or frivolous proposals.

Function Implementation in CHNGovernance

In the CHNGovernance contract, the proposalThreshold() function is implemented to enforce the required voting power threshold before a proposal can be submitted.

Function Signature

RETURN: This function returns an unsigned integer (uint) representing the minimum number of votes required for an account to be eligible to create a proposal.

Example Solidity Implementation

To retrieve the proposal threshold in a Solidity environment, the proposalThreshold()function can be called using an instance of the CHNGovernance contract.

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to retrieve the proposal threshold:

Technical Considerations

• The proposalThreshold()function is a view function, meaning it does not modify blockchain state and can be executed without incurring gas costs.

• The required proposal threshold may be modified through governance proposals, allowing the community to adjust the threshold based on network dynamics and participation levels.

• The retrieved threshold value should be used to validate off-chain governance tracking systems and frontend governance dashboards, ensuring real-time compliance with protocol governance rules.

The proposal threshold is a critical governance parameter that maintains the integrity of the Onyx governance process by ensuring that proposals originate from accounts with meaningful voting power, thereby upholding decentralization and effective protocol management.

The cancel() function allows the Guardian or any eligible participant to cancel a governance proposal that has not yet been executed. This mechanism provides a safeguard against malicious or outdated proposals that no longer align with the protocol’s best interests.

A proposal can be canceled under the following conditions:

• If the Guardian invokes the cancel function, the proposal will be immediately revoked.

• If the proposer no longer holds the required delegated voting power (i.e., less than the proposal threshold), then any address may call cancel() to remove the proposal from governance consideration.

Function Implementation in CHNGovernance

The cancel() function ensures that only valid, unexecuted proposals can be removed, maintaining governance security and integrity.

Function Signature:

Parameters

• proposalId: The unique identifier of the governance proposal to be canceled. The proposal must not have been executed.

• RETURN: The function does not return a value. If the proposal is invalid, already executed, or unauthorized for cancellation, the transaction reverts with an error.

Example Solidity Implementation

To cancel a proposal using Solidity, the cancel() function can be called from an instance of the CHNGovernance contract:

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to cancel a proposal:

Technical Considerations

• The cancel() function is state-modifying and will incur gas costs.

• The proposal must not have been executed for it to be eligible for cancellation.

• If the Guardian initiates cancellation, it is immediately effective.

The getReceipt function retrieves the ballot receipt for a specific voter in relation to a particular governance proposal. This function enables governance participants and developers to track and verify voting activity, ensuring transparency in the decision-making process.

Function Implementation in CHNGovernance

The getReceipt() function is implemented in the CHNGovernance contract to return structured voting details for a given voter’s participation in a proposal.

Function Signature

Parameters

• proposalId: The unique identifier of the governance proposal being queried.

• voter: The Ethereum address of the voter whose receipt is requested.

• RETURN: If the function call is successful, it returns a Receipt struct, containing:

If the proposal ID is invalid, or the voter has not participated, the function reverts with an error.

Example Solidity Implementation

To retrieve a voter's ballot receipt using Solidity, the getReceipt() function can be called from an instance of the CHNGovernance contract:

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to retrieve a voter's receipt:

Technical Considerations

• The getReceipt() function is a view function, meaning it does not modify blockchain state and can be executed without incurring gas costs.

• If the voter has not participated in the proposal, the function may return a default empty receipt or revert with an error.

• This function is useful for governance dashboards, allowing stakeholders to track who voted, how they voted, and how many votes were cast.

Onyxcoin (XCN) is, and always will be, native to the Ethereum blockchain. XCN is deployed on other blockchains through onchain bridging where one XCN is locked on the Ethereum blockchain and one is made availble or minted on a subsequent blockchain.

Contract Addresses

XCN on Ethereum (Native XCN): 0xA2cd3D43c775978A96BdBf12d733D5A1ED94fb18

XCN on Base: 0x9c632e6aaa3ea73f91554f8a3cb2ed2f29605e0c

XCN on Onyx Ledger: N/A

XCN on BNB Chain: 0x7324c7C0d95CEBC73eEa7E85CbAac0dBdf88a05b

Explorers

Ethereum: Base: Onyx Ledger: https://explorer.onyx.org BNB Chain:

Bridge Links

The voting period defines the duration for which a governance proposal remains open for voting, measured in Ethereum blocks. During this period, eligible token holders can cast their votes to either support or reject the proposal. Once the voting period ends, the results determine whether the proposal advances to execution or is dismissed.

Function Implementation in CHNGovernance

In the CHNGovernance contract, the votingPeriod() function establishes the length of time a proposal remains open for voting.

Function Signature

RETURN: The function returns an unsigned integer (uint) representing the number of Ethereum blocks during which voting is active for a given proposal.

Example Solidity Implementation

To retrieve the voting period in a Solidity environment, the votingPeriod() function can be called using an instance of the CHNGovernance contract.

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to retrieve the voting period:

Technical Considerations

• The votingPeriod() function is a view function, meaning it does not modify blockchain state and can be executed without incurring gas costs.

• The duration of the voting period impacts governance participation, allowing stakeholders ample time to review proposals and cast votes.

• This parameter may be adjusted through governance proposals, ensuring adaptability as governance activity and network participation evolve.

The castVoteBySig function allows an offline signer to participate in Onyx governance voting by submitting a digitally signed vote. Unlike the castVote function, which requires the voter to be online and execute the transaction, this function enables voting via an EIP-712-compliant signature, making it useful for delegated and gasless voting.

Function Implementation in CHNGovernance

The castVoteBySig()

ACTIVITY POINTS ARE NOT ACTIVE YET

Activity Points — Liquidity Deployment and On-Chain Engagement

The execute function is responsible for applying changes from a successfully approved and queued proposal to the designated target contracts within the Onyx protocol. Once a proposal has passed the governance process and completed the Timelock delay period, it can be executed, implementing the proposed modifications.

Function Implementation in CHNGovernance

The execute() function ensures that only successful and properly queued proposals can be executed, enforcing governance integrity and protocol security.

The Timelock contract is a governance-controlled smart contract that facilitates secure, time-delayed upgrades to system parameters, logic, and contracts within the Onyx protocol. This contract ensures that all governance actions are transparent and auditable, preventing instantaneous or unauthorized modifications.

Key Features

• Implements a time-delayed, opt-out upgrade pattern to enhance protocol security.

The queue function is responsible for moving a successful proposal into the Onyx Timelock queue. Once a proposal has been approved by the governance process, it must be queued before it can be executed. Only proposals that have met the required voting threshold and have been successfully passed can be queued.

Function Implementation in CHNGovernance

In the CHNGovernance contract, the queue()

The Onyx SDK is a powerful TypeScript library that facilitates seamless interaction with Onyx networks. It provides robust tools for bridging assets, passing messages across networks, and interfacing with smart contracts through an intuitive and developer-friendly API.

Key Features

• Token Bridging: Effortlessly transfer assets between Base and Onyx.

The state function retrieves the current state of a specified governance proposal. The function returns an enumerated value representing one of the possible states defined in the CHNGovernance contract. This function allows governance participants to track the progress and outcome of any proposal.

Function Implementation in CHNGovernance

The state() function ensures that governance participants can query and verify the status of proposals, maintaining transparency in decision-making.

Function Signature

Parameters

• proposalId: The unique identifier of the proposal whose state is being queried.

• RETURN: If the function call is successful, it returns an enumerated type ProposalState, which may have one of the following values:

  • Pending

Example Solidity Implementation

To retrieve the state of a proposal using Solidity, the state() function can be called from an instance of the CHNGovernance contract:

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to retrieve a proposal’s state:

Technical Considerations

• The state() function is a view function, meaning it does not modify blockchain state and can be executed without incurring gas costs.

• The proposal state helps governance participants track where a proposal stands in the decision-making process.

• Proposals that expire before execution need to be resubmitted if they are still relevant.

AI Agent Wallet Architecture

Each instance of Onyx AI is provisioned with a dedicated on-chain wallet, referred to as an agent wallet. These wallets are permissionless and have no centralized control. These wallets serve as the execution layer for autonomous tasks. Users can:

• Fund the agent wallet with any ERC20 token or Ethereum on Onyx, Ethereum, Base, and BNB Chain.

• Predefine operational rules (e.g., budget limits, whitelisted dApps, risk thresholds).

• Allow the agent to execute autonomously within those constraints, using AI to interpret prompts and derive task sequences.

Wallets are deterministic, derived via cryptographic hashing of user identifiers and secured by permissionless layers that enforce non-custodial ownership. Additionally, agent wallets can integrate time locks, multisig guards, and circuit breakers to ensure execution safety.

Deployment Environment and Ecosystem Integration

• Blockchain: Onyx, Ethereum, Base, BNB

• Gas Token: All computational and transaction costs are paid in XCN, the native token of the Onyx Ledger which are converted to Credits . There is no gas required as the agent is gas-free.

• dApp Support: Onyx AI is extensible and continuously updated with support for top-tier dApps in categories including DeFi, NFT marketplaces, staking, and governance.

Example Architecture

The voting delay represents the number of Ethereum blocks that must elapse before voting can begin on a newly created proposal. This delay is added to the current block number at the time of proposal creation and serves as a buffer period, allowing stakeholders to become aware of the proposal before voting starts.

Function Implementation in CHNGovernance

In the CHNGovernance contract, the votingDelay() function is implemented to enforce this rule, ensuring that there is a defined waiting period before a proposal is open for voting.

Function Signature

RETURN: The function returns an unsigned integer (uint) representing the number of Ethereum blocks that must pass before voting on a proposal can commence.

Example Solidity Implementation

To retrieve the voting delay in a Solidity environment, the votingDelay() function can be called using an instance of the CHNGovernance contract.

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to retrieve the voting delay:

Technical Considerations

• The votingDelay() function is a view function, meaning it does not modify blockchain state and can be executed without incurring gas costs.

• The voting delay period is intended to give token holders time to review and analyze proposals before casting their votes, increasing informed participation in governance.

• This parameter may be adjusted through governance proposals, allowing the community to dynamically modify the delay based on governance needs and activity levels.

The quorum votes represent the minimum number of affirmative votes required for a proposal to be successfully executed within the Onyx governance framework. This threshold is critical in ensuring that governance decisions reflect a sufficient level of participation from the voting community and are not subject to manipulation by a small number of token holders.

Implementation in CHNGovernance

To enforce this quorum requirement, the CHNGovernance contract implements the quorumVotes() function, which returns the predefined vote threshold necessary for a proposal to pass.

Signature:

RETURN: The function returns an unsigned integer (uint) representing the minimum number of votes required for a proposal to achieve quorum and be successfully executed.

Example Solidity Implementation

In Solidity, the quorumVotes() function can be invoked using the CHNGovernance contract instance, ensuring that governance mechanisms adhere to the required voting thresholds.

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to retrieve the quorum vote requirement:

Technical Considerations

• The quorumVotes() function is a pure function, meaning it does not modify blockchain state and can be executed without incurring gas costs.

• The required quorum threshold may be subject to governance modifications, meaning that in future iterations of the protocol, proposals may be introduced to dynamically adjust the quorum requirement based on network participation levels.

• The retrieved quorum value should be used to validate voting participation in any off-chain governance tracking systems or frontend governance dashboards, ensuring real-time compliance with protocol governance rules.

The quorum vote requirement ensures that governance actions reflect a collective decision of the Onyx community, thereby enhancing decentralization and security within the Onyx governance ecosystem.

Web3 Libraries and Tools for Onyx Development

Developers building on Onyx, an EVM-compatible Layer 3 blockchain, can leverage various libraries and SDKs to interact with smart contracts, manage wallets, and streamline blockchain development. Below is a list of essential frameworks for Web3 development on Onyx.

Essential Web3 Libraries and Tools

GET: /voter/accounts

VoterAccountRequest

The Voter Accounts API retrieves information about all accounts that have participated in governance voting.

Core Capabilities of Onyx AI

Onyx AI supports a wide spectrum of on-chain interactions, with dynamic routing logic that enables it to choose optimal execution paths based on real-time conditions. Key supported features include:

✅ Token Minting

Core API Endpoints

Fetch Governance Proposals

Retrieve a list of active and past governance proposals.

At Onyx, security is fundamental to our mission. We highly value the contributions of ethical hackers who help us uphold the highest standards of security across the Onyx ecosystem. While Onyx has undergone rigorous professional audits and formal verification, it operates on evolving technology that may still contain undiscovered vulnerabilities.

We encourage the community to actively audit our smart contracts and infrastructure and responsibly disclose any security concerns. This program is designed to incentivize responsible security research, outlining the expectations for ethical vulnerability disclosure and the rewards available for eligible findings.

Rewards

Onyx offers substantial rewards for vulnerabilities that could lead to the loss or freezing of assets or otherwise cause harm to users. The reward amount is determined based on the severity and exploitability of the vulnerability. Eligible discoveries may receive rewards ranging from $500 to $150,000, in accordance with the terms outlined below.

APP POINTS ARE NOT ACTIVE YET

App Points — Optimizing Rewards via Partner Application Incentives

The App Points program represents a powerful layer of optional, developer-directed incentives within the broader Onyx Points architecture. It introduces a modular, app-specific mechanism in which partnered decentralized applications (dApps) are allocated a share of the total Onyx airdrop budget—known as Onyx App Points—and are granted full autonomy in designing their own internal reward frameworks.

This subsystem fosters a competitive environment among integrated applications, where each app competes to attract and retain user liquidity by offering unique and potentially lucrative point-based incentives. App Points are thus an extension of the core Onyx Points system, tailored to promote innovation and deepen protocol integrations across the DeFi composability stack.

Developer-Centric Allocation and Autonomy

Under this model, the Onyx Foundation pre-allocates a fixed quantity of Onyx airdrop tokens (e.g., XCN or other relevant distribution assets) to partnered applications. These applications—ranging from DEXs and lending platforms to staking services and DeFi aggregators—are given full discretion over:

• How the App Points are distributed,

• What user actions are rewarded, and

• Which asset pairs or contracts are eligible.

Each app independently launches its own App Points program, which may mirror or diverge from the core Onyx Points logic. For example, an app might reward:

• Longer liquidity provision periods more heavily than short-term deployments.

• Specific pools (e.g., XCN-native pairs) with bonus multipliers.

• Staking behavior over traditional LP engagement.

• Governance participation or cross-chain activity.

This developer-led incentive model ensures that application teams have the flexibility to align rewards with their own KPIs, drive user behavior in desired directions, and build loyal liquidity communities—all while remaining interoperable with the Onyx ecosystem.

User Strategy and Optimization Challenge

As a participant, you will earn baseline Passive and Activity Points by simply holding or deploying whitelisted assets. However, App Points introduce an additional layer of strategic optimization. Since each application has its own logic, criteria, and point allocation cadence, the onus is on the user to:

1. Identify which apps are running competitive App Points programs,

2. Evaluate their reward mechanics, and

3. Deploy liquidity in a way that maximizes aggregate return—both in yield and airdrop value.

This creates a dynamic “meta-game” within the Onyx ecosystem, where users can gain an edge by staying informed, diversifying across protocols, or concentrating capital into high-leverage pools managed by top-performing apps.

To assist users, the Onyx Points Dashboard will provide a centralized interface summarizing:

• Which apps are eligible for App Point allocation,

• How much airdrop capital is at stake per app,

• Public information about each app’s points program,

• Real-time estimates of potential point yield based on liquidity deployment decisions.

Liquidity Yield + App Points = Stacked Rewards

The real power of the App Points system lies in reward stacking. By participating in an app that offers its own points incentives, users may simultaneously earn:

• Yield (e.g., trading fees, staking APY),

• Core Onyx Passive and Activity Points, and

• App Points, convertible into future airdrops from the app itself or bonus Onyx distributions.

This stacked approach encourages long-term, intelligent capital deployment and reinforces the mutual growth of both Onyx and its partner applications. It also lays the foundation for cross-incentivization, where apps may offer governance rights, utility tokens, or boosted multipliers to users who actively engage through the Onyx Points program.

The App Points framework unlocks developer-led innovation and empowers users to engage with the ecosystem in a more strategic, research-driven manner. By evaluating participating apps and adapting your liquidity strategy accordingly, you can significantly enhance your reward profile and deepen your involvement in the evolving Onyx DeFi economy.

Quickstart: Building a Decentralized Application (dApp) on Onyx (Solidity)

Introduction

This guide is designed for web developers seeking to build decentralized applications (dApps) on Onyx. No prior knowledge of Ethereum, Onyx, or Solidity is required, but a basic understanding of JavaScript and Yarn is expected. If you are new to Ethereum, it may be beneficial to review the Ethereum documentation before proceeding.

Learning Objectives

In this tutorial, developers will learn:

• The differences between Ethereum’s decentralized architecture and traditional client-server models.

• The fundamentals of Solidity smart contracts.

• How to compile and deploy a smart contract on Onyx.

• The functionality of an Ethereum-compatible Web3 wallet.

To demonstrate these concepts, we will create a decentralized token dispenser using Solidity smart contracts. This dispenser will operate under the following constraints:

1. A user can receive a token only if they have not received one recently.

2. The contract rules are immutable and cannot be modified after deployment.

This guide will walk through transitioning from a centralized Web2 implementation to a decentralized Web3 version on Onyx.

Prerequisites

Before starting, ensure you have the following installed:

• VS Code (or any preferred IDE)

• A Web3-compatible wallet (e.g., MetaMask)

• Yarn

• Foundry (for smart contract development)

Additional dependencies will be introduced throughout the guide.

Overview of Ethereum and Onyx

Ethereum

Ethereum is a decentralized network that maintains a shared blockchain ledger across a global network of nodes. Smart contracts execute within the Ethereum Virtual Machine (EVM) and facilitate trustless, programmable transactions.

Key features include:

• Smart contracts: Self-executing programs that enforce business logic.

• Decentralized identity and data portability: Users retain control over their assets and identities.

• Transaction fees: Users pay gas fees in ETH to incentivize network validators.

However, Ethereum transactions can become costly during high network congestion, necessitating scaling solutions such as Onyx.

Onyx

Onyx is an advanced Layer 3 blockchain built using Arbitrum Orbit and secured by Coinbase’s Base Layer 2. It provides developers with:

• EVM compatibility, enabling Solidity smart contracts to run seamlessly.

• Higher transaction throughput and lower fees compared to Ethereum.

• Optimistic rollup technology for efficient data processing.

Transitioning from a Web2 to a Web3 Application

A conventional Web2 application relies on centralized servers, leading to risks such as downtime, censorship, and security vulnerabilities. By migrating to Web3, smart contract logic is executed on the Onyx blockchain, ensuring:

• Immutable business logic

• Decentralized data storage

• Trustless interactions between users

Example: Token Dispenser Implementation

We will first examine a JavaScript-based token dispenser and then implement its Web3 equivalent using Solidity.

Web2 Implementation:

Compiling and Deploying the Smart Contract

Smart contracts need to be compiled into bytecode before they can be deployed on-chain. We will use Remix, a browser-based IDE, for this step.

1. Open Remix:

2. Create a new workspace.

3. Copy the Solidity contract into a new file.

4. Compile the contract in Remix.

Essential Development Tools for Onyx dApp Development

Developing and testing decentralized applications (dApps) on Onyx requires a robust set of tools. Below is an overview of essential development environments, testing frameworks, and SDKs that streamline the process of building, deploying, and debugging smart contracts on the Onyx blockchain.

Hardhat

Hardhat is a comprehensive development environment tailored for Ethereum, Onyx, and other EVM-compatible networks. It simplifies the creation, compilation, deployment, testing, and debugging of smart contracts while providing an extensible framework.

Key Features:

• Built-in console for interactive debugging.

• Advanced Solidity debugging capabilities with stack traces and error messages.

• Task automation for streamlined workflows.

• Plugin support to integrate additional tooling and extend functionalities.

Hardhat is widely adopted for its flexibility and is an excellent choice for Onyx developers looking to manage complex projects efficiently.

Foundry

Foundry is a high-performance, portable, and modular toolkit built for EVM smart contract development, leveraging the Rust programming language. It is optimized for efficiency, flexibility, and seamless testing.

Key Features:

• Solidity-first development experience, with support for fast unit and integration testing.

• High-performance execution, reducing compilation and test runtimes.

• Local Ethereum node for rapid testing.

• Solidity REPL (Read-Eval-Print Loop) for interactive debugging and rapid contract iterations.

Foundry’s lightweight and modular nature makes it a powerful alternative to Hardhat for Onyx developers who require high-speed smart contract interactions.

Truffle

Truffle is a full-fledged development framework for smart contract creation, offering an end-to-end solution for building, testing, debugging, and deploying contracts on Ethereum, Onyx, and other EVM-compatible networks.

Key Features:

• Integrated smart contract compilation and testing with a structured project setup.

• Advanced debugging tools, providing better insights into contract execution.

• Ganache support for local blockchain simulation and quick contract testing.

Truffle’s rich ecosystem and developer tooling make it a great choice for teams building scalable and production-ready dApps on Onyx.

thirdweb

thirdweb provides a comprehensive SDK that covers all aspects of web3 development, enabling Onyx developers to build, deploy, and interact with smart contracts effortlessly.

Key Features:

• Blockchain connectivity: Simplifies interaction with the Onyx blockchain.

• Wallet authentication and management: Built-in UI components for seamless user interactions.

• Decentralized storage: Native support for IPFS with pinning services.

thirdweb is ideal for developers looking for an out-of-the-box infrastructure to quickly launch dApps on Onyx with minimal blockchain-specific overhead.

Brownie

Brownie is a Python-based smart contract framework designed for EVM-compatible blockchains, including Onyx.

Key Features:

• Full support for Solidity and Vyper smart contract development.

• pytest integration for automated and property-based contract testing.

• Trace-based coverage evaluation, helping developers optimize contract execution.

For Python developers, Brownie is an excellent choice to integrate traditional software development methodologies into Onyx smart contract development.

Choosing the Right Tool for Your Onyx dApp

Each tool offers unique advantages, and the choice depends on your development workflow:

• Hardhat: Best for complex EVM projects requiring deep debugging and plugin support.

• Foundry: Ideal for performance-focused developers seeking high-speed testing and modular tooling.

• Truffle: Suitable for teams that prefer an integrated framework with rich testing and security features.

By leveraging these tools, Onyx developers can build efficient, secure, and scalable decentralized applications while maintaining seamless blockchain interactions.

The getActions function retrieves the details of a specified proposal by providing its unique proposal ID. This function allows governance participants and developers to inspect the actions of a given proposal, including:

1. The contract addresses that the proposal intends to call.

2. The values (ETH amounts) associated with each call.

3. The function signatures that define which contract functions will be executed.

4. The calldata payloads that encode function arguments for execution.

This function enables transparent governance by allowing any participant to review a proposal’s execution details before casting votes or executing the proposal.

Function Implementation in CHNGovernance

The getActions() function is implemented in the CHNGovernance contract to return a structured breakdown of the proposal's execution plan.

Function Signature

Parameters

• proposalId: The unique identifier of the proposal whose actions need to be retrieved.

• RETURN:If the function call is successful, it returns the following arrays:

1. targets[]: An array of contract addresses the proposal intends to interact with.

2. values[]: An array of unsigned integers specifying the ETH value associated with each action.

3. signatures[]: An array of function signatures that describe the functions to be executed.

If the proposal ID is invalid, the function reverts with an error.

Example Solidity Implementation

To retrieve the details of a proposal using Solidity, the getActions() function can be called from an instance of the CHNGovernance contract:

Web3.js Implementation (v1.2.6)

For interacting with the CHNGovernance contract using Web3.js, the following example demonstrates how to retrieve the proposal actions:

Technical Considerations

• The getActions() function is a view function, meaning it does not modify blockchain state and can be executed without incurring gas costs.

• This function is useful for off-chain governance interfaces, allowing participants to inspect proposals before voting.

• If a proposal ID is invalid, the function will revert, ensuring that only valid proposals are queried.

GET: /voter/:proposalId

VoterProposalRequest

The request to the Voter Proposal API allows filtering by specific accounts and voting support status.

This guide is intended for developers and users seeking to understand gas calculations on Onyx, including how gas fees are determined and estimated before submitting transactions. This document provides a detailed breakdown of Onyx's gas estimation methods, practical ways to calculate fees, and code examples for implementation.

Practical Gas Estimation on Onyx

For most practical applications, gas estimation can be done via a standard process by calling an Onyx node’s eth_estimateGas method. This method provides a gas limit that should sufficiently cover the entire transaction fee at the given L2 gas price.

Running a Full Node for Onyx

This guide provides step-by-step instructions for running an Onyx full node using Arbitrum Nitro. It incorporates the exact parameters and chain configuration for the conduit-orbit-deployer Orbit chain.

Overview

• Chain Name: Onyx

• Chain ID: 80888

• Parent Chain ID: 8453

• Chain Type: Arbitrum Orbit (AnyTrust enabled)

This setup runs a non-sequencer full node that syncs from an external sequencer.

Prerequisites

Hardware Requirements

Minimum recommended configuration:

• RAM: 8–16 GB

• CPU: 2–4 cores (AWS equivalent: t3.xlarge)

• Storage: 50 GB (SSD strongly recommended)

Software Requirements

• Docker (latest stable version)

• Access to a parent chain RPC endpoint (Base / chain ID 8453)

Required Parameters

1. Parent Chain Parameters

The parent chain is Base (chain ID 8453). You must provide a standard EVM RPC endpoint:

⚠️ Note: Public RPC endpoints may be rate-limited. For reliable sync performance, use a dedicated RPC provider or a self-hosted Base node.

2. Child Chain (Orbit) Parameters

a. Chain Info JSON

This parameter defines the Orbit chain configuration and deployed contracts:

For Onyx, the chain info includes:

• Chain ID: 80888

• Parent Chain ID: 8453

• ArbOS Version: 32

• Data Availability Committee: Enabled (AnyTrust)

You may either inline the JSON or pass a file path.

b. Chain Name

The chain name must exactly match the name defined in chain.info-json:

c. Execution Forwarding Target

Since this node is not a sequencer, it must forward transactions to the sequencer endpoint:

AnyTrust (Data Availability) Configuration

This chain uses AnyTrust, so data availability must be explicitly enabled.

Required flags:

You must also specify one of the following:

Option A: Static DAS URLs

Option B: Dynamic DAS URL List

RPC and WebSocket Ports

Expose HTTP and WebSocket endpoints as needed:

Default exposed ports:

• HTTP RPC: 8547

• WebSocket: 8548

Docker Setup

Persistent Data Directory

Create a local directory for persistent chain data:

The directory must be mounted to:

Full Docker Command

⚠️ Ensure the mounted directory exists before running Docker to avoid permission errors.

Sequencer Feed (Recommended)

To stay in sync with the latest state, enable the sequencer feed:

If you operate the sequencer, ensure it is started with:

Graceful Shutdown

Always stop the node gracefully to avoid database corruption:

Additional Parameters

For a complete list of available Nitro flags:

Summary

This document describes a production-ready configuration for running a non-sequencer Onyx full node on an AnyTrust Arbitrum Orbit chain, using the exact deployed contracts and chain metadata for conduit-orbit-deployer.

Terms of Service

Updated: March 1, 2023

The app.onyx.org website (the “Interface” or “App”) is an open-source and public website hosted on GitHub by Onyx DAO (“we”, “our”, or “us”). The Interface provides access to a decentralized protocol on the Ethereum blockchain that allows suppliers and borrowers of certain digital assets to participate in autonomous interest rate markets (the “Protocol”).

This Terms of Service Agreement (the “Agreement”) explains the terms and conditions by which you may access and use the Interface. You must read this Agreement carefully. By accessing or using the Interface, you signify that you have read, understand, and agree to be bound by this Agreement in its entirety. If you do not agree, you are not authorized to access or use the Interface.

1. Modification of this Agreement

We reserve the right, in our sole discretion, to modify this Agreement from time to time. If we make any modifications, we will notify you by updating the date at the top of the Agreement and by maintaining a current version of the Agreement at. All modifications will be effective when they are posted, and your continued use of the Interface will serve as confirmation of your acceptance of those modifications. If you do not agree with any modifications to this Agreement, you must immediately stop accessing and using the Interface.

2. Eligibility

To access or use the Interface, you must be able to form a legally binding contract with us. Accordingly, you represent that you are at least eighteen years old and have the full right, power, and authority to enter into and comply with the terms and conditions of this Agreement on behalf of yourself and any company or legal entity for which you may access or use the Interface. You further represent that you are not a citizen, resident, or member of any jurisdiction or group that is subject to economic sanctions by the United States or the United Kingdom, or where your use of the Interface would be illegal or otherwise violate any applicable law. You further represent that your access and use of the Interface will fully comply with all applicable laws and regulations, and that you will not access or use the Interface to conduct, promote, or otherwise facilitate any illegal activity.

3. Proprietary Rights

We own all intellectual property and other rights in the Interface and its contents, including (but not limited to) software, text, images, trademarks, service marks, copyrights, patents, and designs. Unless expressly authorized by us, you may not copy, modify, adapt, rent, license, sell, publish, distribute, or otherwise permit any third party to access or use the Interface or any of its contents. Provided that you are eligible, you are hereby granted a single, personal, limited license to access and use the Interface. This license is non-exclusive, non-transferable, and freely revocable by us at any time without notice or cause. Use of the Interface or its contents for any purpose not expressly permitted by this Agreement is strictly prohibited. Unlike the Interface, the Protocol is comprised entirely of open-source software running on the public Ethereum blockchain and is not our proprietary property.

4. Privacy

We care about your privacy. Although we will comply with all valid subpoena requests, we will carefully consider each request to ensure that it comports with the spirit and letter of the law, and we will not hesitate to challenge invalid, overbroad, or unconstitutional requests as appropriate. We use commercially reasonable safeguards to preserve the integrity and security of your personally identifiable information (“PII”) and aggregate data. However, we cannot guarantee that unauthorized third parties will never be able to obtain or use your PII or aggregate data for improper purposes. You acknowledge that you provide your PII and aggregate data at your own risk. By accessing and using the Interface, you understand and consent to our collection, use, and disclosure of your PII and aggregate data.

5. Prohibited Activity

You agree not to engage in, or attempt to engage in, any of the following categories of prohibited activity in relation to your access and use of the Interface:

· Intellectual Property Infringement. Activity that infringes on or violates any copyright, trademark, service mark, patent, right of publicity, right of privacy, or other proprietary or intellectual property rights under the law.

· Cyberattack. Activity that seeks to interfere with or compromise the integrity, security, or proper functioning of any computer, server, network, personal device, or other information technology system, including (but not limited to) the deployment of viruses and denial of service attacks.

· Fraud and Misrepresentation. Activity that seeks to defraud us or any other person or entity, including (but not limited to) providing any false, inaccurate, or misleading information in order to unlawfully obtain the property of another.

· Market Manipulation. Activity that violates any applicable law, rule, or regulation concerning the integrity of trading markets, including (but not limited to) the manipulative tactics commonly known as spoofing and wash trading.

· Any Other Unlawful Conduct. Activity that violates any applicable law, rule, or regulation of the United States or another relevant jurisdiction, including (but not limited to) the restrictions and regulatory requirements imposed by U.S. law.

6. No Professional Advice

All information provided by the Interface is for informational purposes only and should not be construed as professional advice. You should not take, or refrain from taking, any action based on any information contained in the Interface. Before you make any financial, legal, or other decisions involving the Interface, you should seek independent professional advice from an individual who is licensed and qualified in the area for which such advice would be appropriate.

7. No Warranties

The Interface is provided on an “AS IS” and “AS AVAILABLE” basis. To the fullest extent permitted by law, we disclaim any representations and warranties of any kind, whether express, implied, or statutory, including (but not limited to) the warranties of merchantability and fitness for a particular purpose. You acknowledge and agree that your use of the Interface is at your own risk. We do not represent or warrant that access to the Interface will be continuous, uninterrupted, timely, or secure; that the information contained in the Interface will be accurate, reliable, complete, or current; or that the Interface will be free from errors, defects, viruses, or other harmful elements. No advice, information, or statement that we make should be treated as creating any warranty concerning the Interface. We do not endorse, guarantee, or assume responsibility for any advertisements, offers, or statements made by third parties concerning the Interface.

8. No Fiduciary Duties

This Agreement is not intended to, and does not, create or impose any fiduciary duties on us. To the fullest extent permitted by law, you acknowledge and agree that we owe no fiduciary duties or liabilities to you or any other party, and that to the extent any such duties or liabilities may exist at law or in equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and eliminated. You further agree that the only duties and obligations that we owe you are those set out expressly in this Agreement.

9. Compliance Obligations

The Interface may not be available or appropriate for use in other jurisdictions. By accessing or using the Interface, you agree that you are solely and entirely responsible for compliance with all laws and regulations that may apply to you. You may not use the Interface if you are a citizen, resident, or member of any jurisdiction or group that is subject to economic sanctions by the United States of the United Kingdom, or if your use of the Interface would be illegal or otherwise violate any applicable law. The Interface and all of its contents are solely directed to individuals, companies, and other entities located within the United States or the United Kingdom.

10. Assumption of Risk

By accessing and using the Interface, you represent that you understand the inherent risks associated with using cryptographic and blockchain-based systems, and that you have a working knowledge of the usage and intricacies of digital assets such as bitcoin (BTC), ether (ETH), and other digital tokens such as those following the Ethereum Token Standard (ERC-20). You further understand that the markets for these digital assets are highly volatile due to factors including (but not limited to) adoption, speculation, technology, security, and regulation. You acknowledge that the cost and speed of transacting with cryptographic and blockchain-based systems such as Ethereum are variable and may increase dramatically at any time. You further acknowledge the risk that your digital assets may lose some or all of their value while they are supplied to the Protocol. If you borrow digital assets from the Protocol, you will have to supply digital assets of your own as collateral. If your collateral declines in value such that it is no longer sufficient to secure the amount that you borrowed, others may interact with the Protocol to seize your collateral in a liquidation event. You further acknowledge that we are not responsible for any of these variables or risks, do not own or control the Protocol, and cannot be held liable for any resulting losses that you experience while accessing or using the Interface. Accordingly, you understand and agree to assume full responsibility for all of the risks of accessing and using the Interface and interacting with the Protocol.

11. Third-Party Resources and Promotions

The Interface may contain references or links to third-party resources, including (but not limited to) information, materials, products, or services, that we do not own or control. In addition, third parties may offer promotions related to your access and use of the Interface. We do not endorse or assume any responsibility for any such resources or promotions. If you access any such resources or participate in any such promotions, you do so at your own risk, and you understand that this Agreement does not apply to your dealings or relationships with any third parties. You expressly relieve us of any and all liability arising from your use of any such resources or participation in any such promotions.

12. Release of Claims

You expressly agree that you assume all risks in connection with your access and use of the Interface and your interaction with the Protocol. You further expressly waive and release us from any and all liability, claims, causes of action, or damages arising from or in any way relating to your use of the Interface and your interaction with the Protocol. If you are a California resident, you waive the benefits and protections of California Civil Code § 1542, which provides: “[a] general release does not extend to claims that the creditor or releasing party does not know or suspect to exist in his or her favor at the time of executing the release and that, if known by him or her, would have materially affected his or her settlement with the debtor or released party.”

13. Indemnity

You agree to hold harmless, release, defend, and indemnify us and our officers, directors, employees, contractors, agents, affiliates, and subsidiaries from and against all claims, damages, obligations, losses, liabilities, costs, and expenses arising from: (a) your access and use of the Interface; (b) your violation of any term or condition of this Agreement, the right of any third party, or any other applicable law, rule, or regulation; and (c) any other party’s access and use of the Interface with your assistance or using any device or account that you own or control.

14. Limitation of Liability

Under no circumstances shall we or any of our officers, directors, employees, contractors, agents, affiliates, or subsidiaries be liable to you for any indirect, punitive, incidental, special, consequential, or exemplary damages, including (but not limited to) damages for loss of profits, goodwill, use, data, or other intangible property, arising out of or relating to any access or use of the Interface, nor will we be responsible for any damage, loss, or injury resulting from hacking, tampering, or other unauthorized access or use of the Interface or the information contained within it. We assume no liability or responsibility for any: (a) errors, mistakes, or inaccuracies of content; (b) personal injury or property damage, of any nature whatsoever, resulting from any access or use of the Interface; (c) unauthorized access or use of any secure server or database in our control, or the use of any information or data stored therein; (d) interruption or cessation of function related to the Interface; (e) bugs, viruses, trojan horses, or the like that may be transmitted to or through the Interface; (f) errors or omissions in, or loss or damage incurred as a result of the use of, any content made available through the Interface; and (g) the defamatory, offensive, or illegal conduct of any third party. Under no circumstances shall we or any of our officers, directors, employees, contractors, agents, affiliates, or subsidiaries be liable to you for any claims, proceedings, liabilities, obligations, damages, losses, or costs in an amount exceeding the amount you paid to us in exchange for access to and use of the Interface, or $100.00, whichever is greater. This limitation of liability applies regardless of whether the alleged liability is based on contract, tort, negligence, strict liability, or any other basis, and even if we have been advised of the possibility of such liability. Some jurisdictions do not allow the exclusion of certain warranties or the limitation or exclusion of certain liabilities and damages. Accordingly, some of the disclaimers and limitations set forth in this Agreement may not apply to you. This limitation of liability shall apply to the fullest extent permitted by law.

15. Dispute Resolution

We will use our best efforts to resolve any potential disputes through informal, good faith negotiations. If a potential dispute arises, you must contact us by sending an email to [email protected] so that we can attempt to resolve it without resorting to formal dispute resolution. If we aren’t able to reach an informal resolution within sixty days of your email, then you and we both agree to resolve the potential dispute according to the process set forth below.

Any claim or controversy arising out of or relating to the Interface, this Agreement, or any other acts or omissions for which you may contend that we are liable, including (but not limited to) any claim or controversy as to arbitrability (“Dispute”), shall be finally and exclusively settled by arbitration under the LCIA Arbitration Procedures. You understand that you are required to resolve all Disputes by binding arbitration. The arbitration shall be held on a confidential basis before a single arbitrator, who shall be selected pursuant to LCIA rules. The arbitration will be held in London, United Kingdom, unless you and we both agree to hold it elsewhere. Unless we agree otherwise, the arbitrator may not consolidate your claims with those of any other party. Any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction.

16. Class Action and Jury Trial Waiver

You must bring any and all Disputes against us in your individual capacity and not as a plaintiff in or member of any purported class action, collective action, private attorney general action, or other representative proceeding. This provision applies to class arbitration. You and we both agree to waive the right to demand a trial by jury.

17. Governing Law

You agree that the laws of the London, United Kingdom without regard to principles of conflict of laws, including criminal or civil, that govern this Agreement and any Dispute between you and us. You further agree that the Interface shall be deemed to be based solely in London, United Kingdom, and that although the Interface may be available in other jurisdictions, its availability does not give rise to general or specific personal jurisdiction in any forum outside of London. Any arbitration conducted pursuant to this Agreement shall be governed by the LICA Arbitration procedures. You agree that London is the proper forum for any appeals of an arbitration award or for court proceedings in the event that this Agreement’s binding arbitration clause is found to be unenforceable.

Season Two: Whitelisted Asset Allocation & Point Distribution Framework

The following digital assets have been officially whitelisted for Season Two of the Onyx Points Program. Each asset is associated with a specific Ethereum contract address and contributes a defined percentage of the total point emission rate, based on its strategic value and utility within the Onyx XCN Ledger ecosystem. Staked XCN on Etheruem for XCN Stakers is also included.

Whitelisted Assets & Allocated Point Weights

Ethereum

Onyx Ledger (XCN Ledger)

Note: Assets on Onyx Ledger and staked XCN must be held in a self-custodied wallet (e.g., MetaMask, Ledger) and must be enrolled in the points program to qualify for emissions. Centralized exchange balances are not eligible.

Point Emissions & Distribution Mechanics

• Total Points Emitted: 10,000,000 per day (Split 5,000,000 for XCN Stakers and 5,000,000 for Onyx Ledger participants)

• Each asset earns a percentage of the block rewards, based on the allocation table above.

• Points are distributed proportionally based on total participants in both categories (Staking and XCN Ledger)

For example if points were 10,000 per block:

• The XCN token, with a 25% allocation, receives 2,500 points per block.

• These 2,500 points are proportionally distributed to users based on their relative stake of the total eligible XCN enrolled in the program.

XCN Example: Proportional Point Distribution

If a user holds 1,000 XCN, the rewards were 10,000 per block, and the total amount of XCN enrolled in the points program is 10,000 XCN, then:

• User’s share of XCN pool = 1,000 / 10,000 = 10%

• User’s point allocation = 10% of 2,500 = 250 points per block

This proportional calculation is applied per block and assumes continuous enrollment via a smart contract-based “Enroll” function secured by off-chain signature authentication to validate user participation.

Technical Considerations

• Enrollment Mechanism: A cryptographic signature-based enroll() function must be executed to formally participate in the Onyx Points program. This enables gas-efficient user verification and ensures sybil resistance.

• Snapshot Frequency: Wallet balances for point calculations are recorded at deterministic intervals or block heights to prevent manipulation via short-term asset transfers.

• Dynamic Participation: Users may join or exit the program at any time, but point rewards will only accrue for actively enrolled and eligible balances held during snapshot windows.

The proposal max operations parameter defines the maximum number of executable actions that can be included in a single governance proposal within the Onyx governance framework. Each action represents a function call that will be executed if the proposal is approved and successfully implemented. This limitation ensures governance proposals remain manageable and do not introduce excessive complexity or execution risks.

Function Implementation in CHNGovernance

In the CHNGovernance contract, the

The Onyx Governor, also known as the Chain Governor, serves as the governance module of Onyx, enabling a decentralized, on-chain decision-making process that ensures protocol upgrades, parameter adjustments, and policy implementations are collectively determined by the Onyx community. This governance framework is designed to provide transparency, security, and adaptability, allowing token holders to actively participate in the protocol's evolution while maintaining the integrity of its decentralized architecture.

Governance Proposal Requirements

• Governance proposals can only be initiated by addresses that hold more than 100,000,000 XCN tokens at the time of submission. This requirement ensures that only stakeholders with a significant vested interest in the protocol can propose changes, thereby maintaining governance integrity and preventing frivolous proposals.

• The governance system determines voting eligibility based on the voting weight at the proposal's initiation, which is retrieved using the getPriorVotes function. This function ensures that only those who held sufficient XCN before the proposal’s introduction can participate in the voting process, preventing manipulation by acquiring tokens post-proposal.

Voting and Decision-Making Process

1. Proposal Submission: A qualifying address submits a proposal detailing the intended changes, including smart contract modifications, governance parameter adjustments, or new integrations.

2. Voting Period: Once submitted, the proposal enters a mandatory 3-day voting period, during which all eligible token holders can cast their votes.

3. Vote Calculation and Quorum:

• A proposal requires a majority of affirmative votes to pass.

• It must accumulate a minimum of 200,000,000 votes in favor to be considered for execution.

• Votes are weighted based on XCN holdings, ensuring equitable representation of stakeholder interests.

1. Proposal Queueing: If the required quorum is met and the proposal is approved, it is automatically added to the Timelock contract, a governance safeguard mechanism that enforces a delay before execution.

2. Implementation Delay and Execution:

• Approved proposals remain in the Timelock for a mandatory 2-day delay before they can be executed.

• This delay provides a safeguard period for security audits, community scrutiny, and, if necessary, reconsideration or intervention by stakeholders.

• After the delay expires, the proposal can be executed, finalizing the governance decision and implementing the changes on-chain.

GET: /proposal/:proposalId

ProposalResponse

The API response provides detailed governance proposal data for the specified proposal ID.

Response Structure

Proposal Object

A detailed structure representing a governance proposal.

Usage Notes

• Retrieving Proposal Details: Use this endpoint to fetch detailed information on a specific proposal using its unique proposal ID.

• Tracking Proposal Progress: The response provides full lifecycle tracking, from proposal creation to execution or expiration.

• Filtering by Proposal State: The state field can be used to filter and categorize proposals into active, executed, canceled, or expired states.