Skip to main content
XNS-1 is our NFT standard for Octra: the interface and behavior every Xpectrum NFT implements, and the contract a third party implements to issue NFTs that the rest of the ecosystem (wallets, indexers, the marketplace) understands. It is defined natively for Octra’s AML environment.

​
What XNS-1 defines

An XNS-1 contract is a single collection of non-fungible tokens with one canonical owner per token.
  • Tokens and ids. Tokens are identified by a u128 id. Ids are sequential from 0 as tokens are minted, so a collection of supply N holds ids 0..N-1.
  • Single ownership. Each token has exactly one owner address at a time. balance_of(addr) counts how many a wallet holds; tokens_of / get_tokens_page enumerate them.
  • Transfers and delegation. An owner moves a token with transfer. They can delegate a single token with approve, or delegate their whole balance with set_operator (an operator can move any of the owner’s tokens). transfer_from is the delegated move used by approved parties.
  • Metadata. token_uri(token_id) returns where a token’s metadata lives. On Xpectrum that resolves into the collection’s Circle and follows the Metadata Standard.
  • Provenance. The standard includes the one-way set_provenance_hash / get_provenance_hash interface used for verifiable, tamper-evident collections. See Provenance.
  • Circle resources. A native per-token extension for attaching on-chain resources to a token (covered below).
  • Royalties. Royalty is a first-class on-chain field per token, set at mint and capped at 10%.

​
Ownership and transfers

​
Reading token state

All token-id view functions bounds-check the id and revert if the token does not exist. Some reads return pipe-delimited strings:

​
Events

Indexers can follow ownership entirely from Transferred (mints included), without rescanning state.

​
Circle resources

A native XNS-1 extension: each token can have on-chain resources attached, each a URI plus an access string. The contract owner manages them with add_circle_resource, set_circle_resource, and clear_circle_resource; the token holder does not control them. token_circle_uri returns an empty string for inactive resources rather than reverting, so a caller can walk every id up to token_circle_count without per-slot error handling. The version field in get_token_circle_info is 1 in this revision.

​
Royalties

Royalty is on-chain, not metadata. Each token carries a royalty in basis points set at mint, readable via royalty_of, with the recipient from creator_of. XNS-1 caps royalty at 10% (1000 bps). How royalties are paid out on a sale is the marketplace’s job; see Xmarket.

​
Marketplace compatibility

Implementing XNS-1 makes a contract tradeable on Xmarket automatically. The marketplace only relies on a small subset of the interface: owner_of, is_approved_or_owner, transfer_from, creator_of, and royalty_of. The full integration guide, including the exact settlement flow and gotchas, is in Integrate with Xmarket.

​
Implementations

Every Xcollection and XpectrumGenesis deployment implements XNS-1 and is formally verified. Any contract implementing the interface is compatible with the marketplace and tooling.