At the core of the release is a shift from per-token chain blocks to a DAG-structured transaction graph.
Instead of representing RBT transfers, fungible tokens, NFTs and smart-contract interactions through different transaction structures, v1.0.0 introduces a single canonical transaction representation across the network. Every participant in a transaction works from the same transaction record, which is deterministically hashed and cryptographically signed.
From token blocks to a transaction graph
Rubix has always been designed around independently evolving token histories rather than a single globally ordered blockchain. v1.0.0 takes this architecture further.
Every transaction now becomes a node in the broader Rubix DAG, while each token maintains an ordered reference to the transactions in which it participated. A token's history can therefore be represented as a sequence of:
Transaction→Role→Transaction→Role
rather than as an independent sequence of serialized blocks. This separates the transaction itself from the history of each token participating in it, making multi-token and multi-asset interactions substantially cleaner.
Explicit token state through roles
Every token participating in a transaction now carries an explicit role:
- Mint
- Transfer
- Execute
- Deploy
- Burn
- Commit
- Uncommit
- Pledge
- Unpledge
These roles describe precisely how a token participated in a transaction. Previously, parts of this state had to be inferred from transaction context. Explicit roles make token-chain traversal, validation and state determination more deterministic.
This becomes particularly important as Rubix expands beyond simple value transfers into programmable assets, NFTs and multi-asset transactions.
One canonical transaction
A Rubix transaction now brings together:
- Initiator and owner identities
- Network and timestamp information
- Participating tokens
- Previous transaction references
- Committed tokens
- Quorum pledge information
- Transaction data and metadata
The completed transaction structure is deterministically hashed to produce the Transaction ID. Initiators and quorum nodes sign this transaction ID, meaning all parties participating in consensus are cryptographically agreeing on the same canonical transaction state.
Stronger transaction verification
The consensus verification pipeline has also been redesigned around multiple deterministic checks. Before a transaction is accepted, Rubix verifies its transaction hash and signatures, current token ownership, previous transaction references, token state, token-ID validity and genesis provenance.
On mainnet, genesis-level tokens can additionally be traced back to their original authorised minting identities and token ranges. Token data received during transactions is also added and pinned through IPFS, keeping asset state linked to content-addressed data.
Native multi-asset transactions
The unified transaction architecture is particularly important for Rubix's multi-asset model. RBT, fungible tokens, NFTs and smart-contract interactions can now participate in the same underlying transaction structure.
This removes the need for fundamentally different transaction models for different classes of assets and provides a common foundation for applications involving combinations of value, ownership, data and programmable digital assets.
The transaction remains singular, while each participating token independently records its relationship to that transaction in its own history.
Consensus with less coordination
The consensus flow has also been restructured. Initial validation happens before network communication begins. Quorum nodes receive the value they are expected to pledge and return the corresponding pledge-token information. Once quorum information is incorporated, the canonical transaction is hashed, signed and submitted for consensus.
Background token-chain synchronisation can then occur independently rather than blocking completion of the transaction. This reduces unnecessary coordination while preserving transaction-level consensus.
NFTs become first-class participants
NFT transactions now follow the same quorum-authorised and consensus-verified transfer model used by other assets.
v1.0.0 also introduces explicit parent-child relationships between NFTs, lineage traversal, child-NFT minting, multi-file NFT deployment and the ability to execute an NFT without transferring its ownership. These capabilities allow more complex digital objects to exist while maintaining verifiable provenance throughout their lifecycle.
A more efficient state model
Rubix v1.0.0 also changes how transaction history is persisted. The previous CBOR block representation and LevelDB transaction storage have been replaced with a PostgreSQL-backed model centred around three logical structures:
Transactions
Hold the canonical transaction and signatures.
Tokenchain
Records each token's ordered sequence of transaction IDs and roles.
Requests
Track transactions while they move through their lifecycle.
Token history can therefore be resolved through indexed transaction references rather than repeatedly traversing serialized token blocks.
The Rubix graph becomes more explicit
The significance of v1.0.0 is not simply a change in storage or transaction format. It makes the underlying Rubix model more explicit:
- Tokens maintain independent histories.
- Transactions connect those histories.
- Transactions form a DAG.
- Consensus occurs at the transaction level.
Instead of every participant competing to append transactions to one globally ordered ledger, Rubix allows independent asset histories to evolve in parallel while maintaining cryptographically verifiable relationships between them.
v1.0.0 establishes a cleaner foundation for that architecture, and for building scalable applications around digital assets, identity and programmable interactions.