Skip to main content
is_approved_or_owner returns u128 (1 or 0), not a bool. Xmarket settles on require(approved == 1), which a bool return can never satisfy, so an implementation that returns bool will compile, verify, and then be silently untradeable. Every Xpectrum contract on mainnet returns u128.The reference implementation is XNS1.aml v4.0.0, formally verified and published. Copy that, not an older revision.
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.