The OnyxWhitepaper

Onyx is creating a secure and inclusive digital infrastructure that empowers individuals and enterprises to interact, build, and transact with confidence. From financial-grade products to creative and commercial applications, the ecosystem is built for privacy, trust, and equitable access.

Distributed ledger technologies can transform industries at scale, but mainstream adoption still depends on five capabilities that most public networks do not deliver together: high transactional performance, formally verified security, decentralized and expert-driven governance, enforceable mechanisms for systemic stability, and robust tools for regulatory compliance. This whitepaper sets out those requirements and how Onyx addresses them.

To support trillions in digital value transfer, a public ledger must withstand persistent adversarial threats with mathematically proven consensus, without sacrificing decentralization. Compliance with evolving regulations, including GDPR and sanctions enforcement, requires built-in identity and data governance. Enterprise applications need throughput in the hundreds of thousands of transactions per second and finality within seconds. Governance must be decentralized, globally representative, and equipped with legal, technical, and economic expertise. Long-term stability depends on resilient infrastructure and enforceable decisions that uphold consensus and policy integrity.

Onyx is a public network and decentralized governance framework architected for those requirements. The network is governed by the Onyx DAO, made up of XCN holders. Holders shape the DAO and the network through Onyx Improvement Proposals (OIPs). Decision-making authority is distributed among XCN holders, with voting weight proportionate to the tokens they hold, rather than concentrated in a single operator.

The ledger is engineered for near-optimal bandwidth efficiency, so a single shard — a tightly connected mesh of peer-to-peer nodes — can process hundreds of thousands of transactions per second. Upon launch, Onyx is projected to handle approximately 100,000 cryptocurrency transactions per second, with final consensus reached in seconds.

Security is foundational. Onyx achieves asynchronous Byzantine Fault Tolerance (aBFT), the strongest commonly recognized guarantee for distributed consensus. Unlike protocols that rely on a leader or on timeouts, the leaderless model stays resilient under distributed denial-of-service pressure. Transactions are ordered by the times the network actually receives them.

Two further controls keep the platform coherent. A shared-state mechanism lets software clients verify Onyx before they use it, so nodes cannot fork the official platform and pass off an unauthorized copy. Coordinated, deterministic updates let the DAO specify exactly what changes and when they take effect. When an update is released, it is applied to participating nodes together. A node that does not implement the authorized update is excluded from consensus and cannot propagate an alternative ledger.

The codebase is governed by XCN holders through the DAO and is made publicly available for review. Using the platform does not require a license, including for applications, integrations, or smart contracts. Developers can ship open-source or proprietary software without permission from the DAO.

The architecture also supports controlled mutability and the attachment of supplementary data to transactions, including identity certificates. Those capabilities enable optional features such as deletion of personal data and verified identity, governed by the end user’s consent. Together, they give the DAO the tools to enforce governance, keep the protocol coherent, and support the regulatory stability required for broad adoption.

The Onyx data structure and consensus algorithm are a framework for distributed consensus among participants who do not trust one another. The goal is agreement on the chronological order of transactions. Onyx reaches that agreement without the pruning and discarded work that define a conventional blockchain.

A blockchain is a linear structure that is continually pruned so that only one chain of blocks remains. When several blocks are produced at once, consensus keeps one branch and discards the others. If blocks are produced too quickly, the number of branches can exceed what the system can resolve, which is why mechanisms such as proof-of-work artificially slow block production.

Onyx keeps every block of transactions. Concurrent events are merged into the ledger instead of being thrown away, so valid contributions remain part of consensus. There is no artificial limit on how fast events can be submitted. Because potential forks are incorporated rather than discarded, the protocol can offer stronger formal guarantees: Byzantine fault tolerance and fairness in transaction ordering at the same time. The result is a consensus framework that is fair, Byzantine, high-performance, ACID-compliant, efficient, timestamped, and resistant to denial-of-service attacks.

Throughput

Throughput is limited mainly by network bandwidth, not by wasted computation. If each node has enough bandwidth to send and receive a given volume of transactions per second, the network can process a comparable load. A standard high-speed residential connection can support a node handling volumes in the range of global card networks such as Visa.

Cost

Operating costs are lower than on proof-of-work blockchains because consensus does not depend on energy-intensive mining. Nodes run on ordinary commercial hardware. There is no capital outlay for specialized mining equipment, and the energy cost of consensus is the cost of ordinary networked computers.

Efficiency

In the sense used in the blockchain literature, Onyx is fully efficient: no computational effort is spent on blocks that are later orphaned. Bandwidth overhead beyond disseminating the transactions themselves is limited to what is required for consensus timestamps and order. Once a transaction is submitted, every node agrees on its place in history within seconds, with finality. Each node also has common knowledge of that agreement — it knows that the others have reached the same conclusion — so the effects can be applied immediately. Unless a record must be kept for audit or regulation, the transaction payload itself need not be retained. In a minimal cryptocurrency, nodes can store the current balances of non-empty accounts rather than every transfer back to genesis.

Staking and proxy staking

XCN remains an ERC-20 on Ethereum, where it is used for DAO governance. On Onyx it also has native utility: consensus is proof-of-stake, and a node’s influence is proportional to the XCN staked to it. A transaction reaches consensus when nodes representing more than two-thirds of total stake have validated it. A meaningful share of supply must therefore be staked for the network to stay live and intact.

The network is designed to decentralize in stages. It begins with trusted node operators and moves toward a permissionless set. At first, the DAO treasury proxy-stakes XCN to DAO-operated nodes, and users may delegate stake to those nodes. As more operators join, and as supply is distributed widely enough that no person or group can gather one-third of it, the default is permissionless: anyone may host a node. Anonymous operators do not receive treasury proxy stake or default wallet delegation unless a later OIP says otherwise. Third-party wallets may still offer that delegation.

To participate, a node declares one or more accounts it controls and proves ownership of the corresponding keys. The combined balance of those accounts is its voting weight, and compensation follows that weight. Staked XCN stays liquid. It can be spent at any time, which avoids the lockups common in bonded proof-of-stake.

Proxy staking lets someone who does not run a node still contribute stake and earn rewards. They assign XCN to a node, increasing that node’s weight. Rewards on the combined stake are shared between the operator and the proxy staker. Proxied XCN remains under the owner’s control: they can withdraw, reassign, or spend it, and the node never receives spending authority. Every node must also keep a non-zero XCN balance in order to take part in consensus and to pay fees when it submits messages.

Onyx is a layered, modular network. Each layer has a distinct job, from secure message delivery through consensus, file storage, and programmable logic. Underneath, nodes use ordinary internet infrastructure while avoiding shared points of failure such as DNS. Above that, consensus establishes a deterministic, timestamped order for every transaction. The services layer then exposes native cryptocurrency, smart contracts, distributed file storage, and a consensus service through one API, governed by the DAO and therefore by XCN holders. Sharding and a consensus-node network spread work and read access so the system can stay fast as it grows.

Internet layer

Nodes are internet-connected computers speaking TCP/IP. Traffic is protected with TLS using ephemeral keys, so a session’s keys are discarded when it ends. That provides perfect forward secrecy: a later compromise of a long-term private key does not expose past communications.

A node is identified by IP address and port, not by a domain name. Skipping DNS removes a common point of hijacking, poisoning, and takedown. The network is harder to censor, surveil, or knock offline through name resolution.

Consensus layer

Nodes both receive transactions and spread them. When a client submits a transaction to any node, that node disseminates it to peers with a fast, fault-tolerant algorithm, so a valid transaction reaches the network even if some nodes fail or a partition appears. Each node then runs the consensus algorithm on its own and arrives at the same timestamp and the same total order. After that, every node applies the transactions to its local state in that order. Within a shard, nodes therefore hold the same view of the current state.

Services layer

The services layer is the set of network-native capabilities built on consensus: decentralized execution, storage, digital assets, and trustless ordering. Each service inherits the performance, fairness, and security of the consensus engine, and can be used for public or enterprise applications.

Native currency

The native cryptocurrency is XCN. The bridged implementation on Onyx is built for high throughput and low latency, with fees low enough that small payments are practical. Anyone may run a node and be paid for contributing to consensus. An account is a public-private key pair. No name or address is required. Where a jurisdiction requires Know Your Customer or anti-money-laundering controls, a user can optionally attach a hash of an identity certificate issued by an authority they choose.

Smart contracts

Smart contracts are written in Solidity. Existing Ethereum code, libraries, and contracts can be deployed without rewriting them, so teams keep their current tools and gain Onyx finality and throughput.

File storage

The file system stores data with network-wide agreement on both the contents and the existence of each file. Every node in a shard keeps the same copies, so the loss of one node does not lose the file. Deletion is controlled by an access policy: only authorized parties can remove stored data. That makes the file system usable as a revocation service. A certification body and an engineer can co-sign a hash of a credential and record it. Either party can later remove the hash. A verifier checks whether the hash is still present. If the engineer resubmits the hash without the certifier’s signature, the entry is visibly unauthorized.

Files are Merkle trees. Developers work with them through a conventional interface of directories and files; the platform maps those operations onto the tree. Changes can be proved to be part of the consensus state. Merkle DAGs also deduplicate identical byte ranges, so shared segments are stored once.

• Access by hash is immutable, because the hash is the contents.
• Access by File ID is mutable. The owner can point the same ID at a newer version.

The Onyx Mesh

Onyx Mesh is a network service for decentralized ordering when the application logic and the sensitive data should stay off the public ledger. Clients submit messages on a thread ID — bids, logs, notifications, or other events. Mainnet nodes timestamp them, assign a sequence number, and fold them into a running hash for that thread. The ordered stream is then delivered to consensus nodes.

Consensus nodes are read-only. They can keep full records, selected threads, or everything, depending on configuration. Applications process data off-chain and use Onyx only for trusted order. A commercial network can subscribe to a thread, decrypt what it is entitled to decrypt, and keep control of keys and sensitive payloads.

That split matters for privacy rules such as GDPR. Personal data is encrypted before it is submitted. The public network holds the ciphertext only briefly, about three minutes, while consensus nodes may retain it longer. Only the commercial nodes have the decryption keys. If deletion is required, those nodes can delete the data and the keys. The encrypted consensus history remains, but the plaintext is no longer recoverable.

Consensus network

Consensus nodes mirror validation and state tracking without influencing consensus or submitting transactions. They speak the peer-to-peer protocol, verify signatures, and compute outcomes, but they do not create events, so they do not change the structure of the ledger. They can still expose custom APIs. A decentralized application can run its own consensus node, watch for the events it cares about, and react in near real time without adding load to the nodes that vote.

Sharding

Onyx starts as a single shard with a limited set of nodes. As more nodes join, the network can split into shards that reach consensus independently. Each node processes only the transactions for its shard, so capacity grows with the number of shards. A shard holds accounts and files and runs smart contracts. A transaction that stays inside one shard is final as soon as that shard agrees.

Cross-shard activity uses ordered, authenticated messages. Each shard keeps an outbound queue with sequence numbers. Randomly selected nodes in the source shard push a message to the destination shard together with proof that the source shard reached consensus on it. The destination checks the proof and the sequence number, ignores duplicates, and applies messages strictly in order. When the destination confirms processing, the source drops the message from its queue.

Multi-shard transfers that must succeed or fail together use holds. A payment drawn from two accounts in different shards places a hold on each source. Balances move only if every hold succeeds. If one fails, all holds are released. A master shard assigns nodes so stake stays balanced, and it periodically moves nodes so no single node can dominate a shard’s stake. For a simple one-source transaction, finality is as fast as consensus in the originating shard. Multi-shard flows wait for the inter-shard confirmations, and each message carries proof back to the consensus state of its source, so asynchronous Byzantine fault tolerance holds across the whole network.

Tokenization turns assets or rights into records on a ledger so they can be fractionalized, transferred, and settled with less friction. Onyx supports that with two models: native tokens on the public Layer 1, and permissioned token networks that take their order from Onyx Mesh.

Fungible tokens, NFTs, and other forms

Fungible tokens — stablecoins, governance tokens, and other interchangeable units — behave like balances. Each unit is equivalent, so they fit account-based models and high-volume uses such as payments, rewards, and liquidity. Non-fungible tokens are unique. A name, serial number, or other metadata makes each one distinct, so they fit a token-based model in which every token has an owner. They suit lower-throughput, higher-value records: art, property, or proof of a specific asset.

Utility tokens grant access to a product or service. Security tokens represent ownership in an asset such as equity or real estate and are subject to securities law. Memecoins are often issued for community or culture; some have still reached meaningful economic scale. A token contract is the code that defines roles, rules, and behavior. It is published, either as open source or as a contract on a public network, so the rules can be checked directly.

Onyx Layer 1

Issuers define, issue, and manage tokens directly on mainnet. Those tokens inherit aBFT consensus, finality in seconds, and low fees fixed in USD. The interface is an API. Tokens are native objects, identified like other Onyx entities with the shard.realm.num form. An account can hold XCN and many token types, but it must sign an association before it can hold or transfer a given token. XCN transfers do not depend on those associations.

A token definition includes a name and symbol, decimals, optional administrative keys for freeze, wipe, KYC, and supply, an initial supply, auto-renew settings, and a treasury account that holds the initial supply. Lifecycle operations include create, update, mint, and burn; wipe and freeze or unfreeze; KYC and association; and atomic transfers that move several tokens and XCN together.

The Layer 1 API is defined with protocol buffers and is the public interface to network services. Keys can be a single key, a list, a threshold, or a nested structure, so issuance and transfer permissions can be split finely. Receipts, records, and state proofs carry the fields third parties need to verify token operations under the same aBFT model: fair ordering, no leader, and finality in seconds. Consensus nodes receive record streams and balance files that include token balances and transfers, which gives wallets, custodians, and exchanges a deployment path and a base for later bridges.

Onyx Mesh for permissioned tokens

Mesh tokenization is for networks that need tighter control, privacy, or a specific jurisdiction — regulated markets and central-bank digital currencies among them. Clients submit messages, such as transfers, to a Mesh thread. Mainnet timestamps, orders, and verifies them. Consensus nodes relay the stream. Permissioned nodes apply the token contract and update their own state.

The contract can be fully custom. It listens to one Thread ID, checks signatures, enforces restrictions, and updates balances. It can also implement atomic swaps, event triggers, or oracle calls. The Token Message Standard is the common shape of those messages: structured, tamper-evident, and enough for nodes to stay in sync. It supports atomic swaps, hold-and-release, and automated commercial logic.

Roles in the Token Message Standard

Roles are optional. A deployment enables only the ones its governance and regulation require. The set mirrors Layer 1 and extends it for permissioned use.

Running token nodes

Token nodes keep ledger state, expose APIs, and stay synchronized through Mesh. A new node deploys the contract and subscribes to the thread. It can rebuild state from historical Mesh messages delivered by consensus nodes. Operators get custom behavior without mainnet constraints, encryption of sensitive data on trusted nodes only, high throughput with decentralized ordering, and control over who may join.

Layer 1 is the simpler public path: stablecoins, loyalty points, and governance tokens that wallets can hold directly. Mesh is the path for private marketplaces, regulated financial networks, and supply-chain consortia that need their own onboarding, compliance, and data residency. Both rest on the same finality, aBFT security, and predictable pricing.

All network communication uses TLS 1.2, and every transaction is authenticated with a digital signature. The ledger structure itself is built from cryptographic hashes. Algorithms and key lengths follow the Commercial National Security Algorithm (CNSA) Suite, the set specified for protecting U.S. government Top Secret information.

Asynchronous Byzantine fault tolerance

aBFT means that no single node, and no colluding minority, can stop consensus or change it after it is final. Each honest node reaches a point at which it knows consensus has been achieved across the network. Weaker uses of the term “BFT” sometimes mean only limited resistance to bad behavior. Onyx uses the stronger definition: consensus still completes when some participants collude to distort it and when adversaries can delay or obstruct messages. Every node eventually knows that agreement was reached.

That holds if malicious entities control less than one-third of staked XCN. They cannot halt consensus, choose the order of transactions, or bias timestamps. Asynchronous BFT assumes no bound on message delay. It assumes only that more than two-thirds of stake is honest and that messages retransmitted between nodes are eventually delivered. Partially synchronous protocols that assume a maximum delay can fail under botnets, DDoS, or hostile firewalls, because those attacks break the timing assumption. Onyx does not rely on that assumption.

Blockchains, by contrast, do not offer Byzantine agreement in this sense. Their consensus is probabilistic and can be reorganized. Isolated groups of miners can extend conflicting chains during a partition.

ACID compliance

Used as the ordering layer for a distributed database, Onyx is ACID compliant: atomicity, consistency, isolation, and durability. Nodes agree on order, then each applies transactions to its local database in that order. If the local databases are ACID, the network behaves as one ACID system. A blockchain cannot make the same claim, because its consensus can still be reversed.

Denial of service

A denial-of-service attack floods a node so it cannot do its job. A distributed attack uses many compromised machines to do the same at larger scale. On a ledger, the dangerous version targets the nodes that are required for consensus.

Onyx has no leader, coordinator, or round-robin role whose absence stops the protocol. As with Bitcoin’s open set of participants, knocking individual nodes offline does not halt the network. An attacker would have to disable a large fraction of stake at once. Protocols that elect a leader can be stalled by attacking one node at a time and moving to whoever is elected next. Onyx removes that role, and it does so without proof-of-work.

Users pay fees for transfers, storage, and other transactions. Because throughput is high and consensus is not proof-of-work, those fees are expected to be far lower than on many public ledgers. Nodes are paid for the computation, bandwidth, and storage they contribute. Fees fall into distinct categories that match distinct costs.

The expensive work — file storage and contract execution — is prepaid. Storing a file for 30 days means paying for those 30 days when the file is created. The smaller costs of propagation and consensus are covered by the network fee.

When a node receives a transaction, it checks that the account can cover the fees. There is a small window in which the balance could fall before finality, so some work might go unpaid. The client sets a maximum fee. The node estimates the actual fee from a published schedule that multiplies expected bandwidth, CPU, and storage by published coefficients. If the balance and the maximum are both sufficient, the transaction continues. After consensus, nodes apply it if payment is confirmed and distribute the fees.

• Nodes are paid for processing transactions correctly.
• Clients pay for services that are actually delivered.
• Work is not performed on the assumption that payment might arrive later.

XCN is structured for a long-lived economy: a known supply, utility on the network, and incentives for the people who secure and govern it. The token was issued with a fixed maximum at genesis so supply cannot be expanded without bound. What remains in circulation is then shaped by governance, staking, and burns.

Emissions to stakers and ecosystem contributors are governed so the rate stays predictable until the supply schedule is met. XCN exists natively on Ethereum and can be bridged to other networks, including Base via Superbridge and BNB Smart Chain via Wormhole. Bridged tokens are valid only against an equivalent amount locked on the source side, so the bridged supply cannot drift away from the canonical total.

Treasury

A portion of supply sits in the Onyx treasury, controlled by the DAO. On-chain votes decide how it is used. The intended uses are ecosystem grants for developers, research, and infrastructure; protocol upgrades, including security audits; liquidity incentives for integrated markets; and strategic partnerships with institutions and decentralized-finance teams.

Staking rewards, treasury allocations, and burns are all DAO parameters. The supply mechanics can change when the network’s economics require it, while the cap and the public process stay in place. The aim is to keep validators, stakers, and builders pointed at the same long-term outcome.

Onyx is governed as a DAO. XCN, as an ERC-20 on Ethereum, is the governance token: holders propose, vote, and execute changes to the DAO and, through it, to the network. A public ledger’s governance has to cover how node software evolves, how the native token is allocated, and how participants are paid. It also has to balance node operators, developers, enterprises, users, and regulators.

Voting weight follows the amount of XCN a holder has committed. Major changes are ratified as Onyx Improvement Proposals. The process runs in smart contracts on Ethereum, so proposal creation, voting, and execution are enforced by code rather than by an operator’s discretion.

1. 01

   Propose

   Any address with at least 100,000,000 XCN of governance weight can submit a proposal through propose(). The payload names the target contracts, calls, parameters, and rationale. Scope includes upgrades, economic parameters, treasury allocations, and contract changes.

2. 02

   Vote

   Voting lasts three days. Weight is staked XCN. Holders call castVote() and choose For, Against, or Abstain. Tallies are recorded on-chain.

3. 03

   Quorum

   A proposal passes when at least 200,000,000 XCN votes in favor and a majority is reached. It then moves to execution.

4. 04

   Timelock

   Passed proposals wait two days. After the timelock, execute() applies the change. The delay is there to prevent an immediate takeover.

function propose(
  address[] memory targets,
  uint256[] memory values,
  string[] memory signatures,
  bytes[] memory calldatas,
  string description
) external returns (uint256);

function castVote(uint256 proposalId, uint8 support) external;
function queue(uint256 proposalId) external;
function execute(uint256 proposalId) external;

Those functions carry a proposal from submission to execution. Holders participate by staking XCN for weight, voting, and, when they have the threshold, submitting proposals. The DAO’s decisions include protocol upgrades, economic policy such as staking parameters, fees, and node incentives, and changes to node rules, consensus policy, and related configuration.

Open consensus

Consensus is separate from DAO governance. At launch, consensus nodes are operated by the DAO so the early network stays consistent. Operation then opens to external operators, who are paid for running the network. The long-term target is a large, globally distributed set of nodes. Influence inside consensus is stake-weighted XCN, which raises the cost of collusion, double-spends, and capture of transaction ordering. The open set is what makes the ledger something an institution can rely on and an individual can join.

Fairness here means that no node, including nodes inside consensus, can decide alone when a transaction is accepted or where it sits in the order. Those decisions are votes inside the algorithm. Three properties follow.

Fair timestamps

Each transaction receives a consensus timestamp equal to the median of the times nodes report when they first receive it. The median is a collective value, so one node cannot set it. If more than two-thirds of participating nodes are honest and their clocks are reasonably synchronized, the timestamp is accurate and Byzantine fault tolerant. That matters wherever a deadline or a contractual time has to be proved.

Fair transaction order

Order is taken from those timestamps. Because the timestamps are fair, the order is fair. In a market, order changes outcomes. A blockchain miner can prioritize, reorder, or drop transactions inside a block. On Onyx, order is the network’s agreement. The advantage left to a participant is ordinary network latency, not a privileged seat in consensus.

Fair access

Submission is equitable. No intermediary and no privileged node can sit on the path and refuse a transaction. If a malicious node tries to delay or suppress dissemination, the randomized peer-to-peer gossip finds other routes. The transaction still spreads. That keeps the network live under localized interference and keeps access open.

Onyx is built for regulated and large-scale use: controlled mutability, opt-in identity, governance, privacy, and real-time audit through consensus nodes. Governments will keep setting rules for people and companies that use public ledgers. A core objective of the network is to make compliance with those rules technically possible, including GDPR and anti-money-laundering standards, and to stay adaptable as the rules change.

Self-custody

Any transaction that changes an account must be signed by that account’s private key. Users who hold their own keys keep exclusive control. Onyx does not take custody of funds, and neither does a developer or enterprise merely by building on the network. Transfers of XCN are peer-to-peer. Developers may offer self-custody, or they may offer custody, in which case they carry the regulatory duties that come with holding user assets.

Controlled mutability

Most ledgers treat recorded data as permanent. Onyx can allow modification or deletion under a policy chosen when the data is published. The publisher names the keys that may later change or remove it. Applications can implement a right to erasure, and users can decide how long their data remains visible, without abandoning decentralized verification of everything else.

Identity and privacy

Accounts are pseudonymous by default. The architecture can bind verified attributes from a certificate authority to an account when the user asks for that. A counterparty can require proof of a legal name, an age, or a jurisdiction before accepting a transaction. Disclosure is per transaction. Users who never opt in stay pseudonymous, and they may be unable to use services that require verification.

In practice, a user attaches a hash of a certificate issued by a recognized provider. The transaction that attaches it can require both the user’s key and the provider’s key, and it can name who may later check the certificate. While the binding stands, a transfer into or out of the account can be tied to a known person. Either the user or the provider can revoke the binding with a signed transaction.

A bank example: a customer wants to move funds from Onyx to a U.S. bank. They present the certificate and the account address. The bank checks that the account holds the matching hash and that the issuer is one it trusts. Only then does it accept the funds. The bank may still have to report the certificate and the transfer to an authority, immediately for some amounts or on a schedule for others.

Anti-money laundering

Developers and enterprises with AML duties can combine on-network identity certificates with the transaction data available from consensus nodes. Those nodes are read-only observers. Over time, anyone may run one. They can collect and analyze public transaction data so suspicious patterns can be investigated. The aim is to meet those obligations without giving up the privacy and security properties of the ledger. Consensus nodes, like the rest of the network, do not receive unencrypted personal data as part of ordinary operation.

Every node holds a full, synchronized copy of the current state — for example, every account balance. At the end of a consensus round, each node applies the transactions from that round and from every round before it, hashes the resulting state, signs the hash, and shares the signature. Nodes collect those signatures into a joint attestation of the shared state.

Signed state proofs

When a client asks for part of the state, a node can return a compact proof: the aggregated signatures and the cryptographic material needed to check them. The state is a Merkle tree, so a proof can be small. A verifier receives the fragment of state, the sibling hashes up to the root, the signatures on the root, and the address book needed to check the public keys. From that, they can confirm the fragment matches the state the network agreed on.

Ledger identity

The proof includes an address book: the public keys of participating nodes and the stake attached to each. It also includes the history of address books. Each version is signed by nodes from the previous one, and a version is valid only if it carries signatures from more than two-thirds of the stake recorded in that previous book. The chain runs back to the genesis address book, signed by the original nodes. The hash of that genesis book is the ledger’s unique identifier. Clients use it to confirm they are looking at this network and not another.

Forks

A minority can copy the current state and start a new ledger. They cannot reproduce an address-book history that the majority will sign. The fork needs a new genesis address book and therefore a new identifier. It is a different network, and state proofs from it will not verify as Onyx.

When a client submits a transaction, the node returns proof that it entered the consensus state, including a signed chain of state hashes back to genesis. Sender and recipient can both check a transfer. If stake ever split evenly, neither side could extend the original address-book history. The result would be two new ledgers, not a fork that inherits the original currency, fees, or users. That cost is the economic reason not to split. The same proofs let shards exchange messages that each carry evidence of their source shard’s consensus.

Onyx is consensus infrastructure for systems that need a timestamp, a deterministic order, and an independent way to check both. It can sit beside existing systems and give them an audit trail. The privacy design is the same throughout: consensus anchors ciphertext, while personal data stays in systems the enterprise controls. Deleting keys satisfies a right to erasure without erasing the proof that something happened. Nodes never see the unencrypted personal data.

A full set of developer resources is published with the network so independent developers and enterprise teams can integrate against a known interface. Documentation lives on a versioned portal that can be updated as the protocol changes, with code samples kept aligned to those versions. The release of that material tracks testnet evaluation and production readiness.

• API specifications for Onyx Layer 1 and Onyx Mesh, including message formats, transaction types, and endpoints.
• SDK libraries and language bindings for common environments.
• Interface definitions for clients, indexers, and relay services.
• Reference implementations and contract templates for issuance, transfer, and access control.
• Integration guides and architecture patterns for application-layer services.