Skip to content

NFT Standard

Jump to bottom
Vipertech (Affolter Matias) edited this page Mar 15, 2026 · 1 revision

The upcoming protocol specification for non-fungible tokens on the Pixa blockchain.

Introduction

Pixa's NFT system is being developed as a Graphene plugin — a modular extension to the core blockchain that adds new object types, new operations, and new validation rules specifically for non-fungible tokens. Unlike Ethereum-based NFTs (which use smart contracts like ERC-721), Pixa's NFTs are native protocol objects with enforced rules at the consensus level.

This guide describes the expected specification. As the NFT plugin is still in development, some details may change before launch.

This document reflects the design intent as described in Pixa's technical documentation. Final implementation may differ.

What is a native NFT?

On Ethereum, NFTs are smart contract deployments — each collection is a separate contract, and the EVM executes token logic at runtime. This provides flexibility but introduces gas costs, reentrancy risks, and reliance on contract correctness.

On Pixa, NFTs are first-class protocol objects. The blockchain itself understands what an NFT is, how it transfers, and how royalties are enforced. There is no contract to audit, no bytecode to execute, and no gas to pay.

Property Ethereum NFT (ERC-721) Pixa NFT (native plugin)
Definition Smart contract Protocol object type
Execution EVM runtime Consensus-level validation
Gas/fees Variable (often high) Free (RC only)
Royalty enforcement Optional, bypassable Protocol-enforced, mandatory
Storage Off-chain (IPFS link in metadata) On-chain (Base64 in linked post)
Flexibility Unlimited (custom logic) Fixed feature set (standard operations)

What are the NFT object fields?

Each NFT on Pixa is expected to be stored as a protocol object with the following fields:

Field Type Description
token_id Unique integer Protocol-assigned unique identifier
creator Account name Original minter (immutable after creation)
owner Account name Current holder (updates on transfer/sale)
linked_permlink String Reference to the on-chain post containing the artwork
metadata JSON Title, description, attributes, and custom data
royalty_bps Integer (basis points) Creator royalty percentage (e.g., 500 = 5%)
created_at Timestamp Block time when the NFT was minted
sale_price Asset (optional) Current listing price, if on sale
sale_currency Token type PXA or PXS

Immutable fields

Once minted, certain fields cannot be changed:

Field Mutable?
token_id No
creator No
linked_permlink No
royalty_bps No
created_at No
owner Yes (transfers/sales)
metadata Potentially updatable by creator
sale_price Yes (listing/delisting)

The immutability of creator, linked_permlink, and royalty_bps ensures that provenance and economic terms are permanent — they cannot be altered after the fact by anyone.

What operations does the NFT plugin add?

Minting

Operation Authority Key parameters
nft_mint Active creator, linked_permlink, metadata, royalty_bps

Creates a new NFT linked to an existing on-chain post. The post must be authored by the minter. The royalty percentage is set at this point and cannot be changed.

Transferring

Operation Authority Key parameters
nft_transfer Active from, to, token_id, memo

Transfers ownership from one account to another. No fee is applied on direct transfers (only marketplace sales trigger fees).

Listing for sale

Operation Authority Key parameters
nft_sell Active seller, token_id, price, currency

Lists the NFT on the marketplace at a specified price in PXA or PXS.

Purchasing

Operation Authority Key parameters
nft_buy Active buyer, token_id

Executes the purchase at the listed price. The protocol handles the full settlement atomically.

Canceling a listing

Operation Authority Key parameters
nft_cancel_sale Active seller, token_id

Removes the NFT from the marketplace without transferring it.

How does the fee and royalty settlement work?

When an nft_buy operation executes, the protocol performs the following settlement in a single atomic transaction:

Primary sale (first sale by the creator)

buyer_pays = listed_price + (listed_price × 10%)
 
Distribution:
  → creator receives:   listed_price
  → burned:             listed_price × 10%

Secondary sale (any subsequent sale)

buyer_pays = listed_price + (listed_price × 2.5%)
 
Distribution:
  → seller receives:    listed_price - royalty_amount
  → creator receives:   listed_price × royalty_bps / 10000
  → burned:             listed_price × 2.5%

Example — Secondary sale

Parameter Value
Listed price 2,000 PXA
Creator royalty 5% (500 bps)
Marketplace fee 2.5%
Flow Amount
Buyer pays 2,000 + 50 = 2,050 PXA
Creator receives (royalty) 2,000 × 5% = 100 PXA
Seller receives 2,000 − 100 = 1,900 PXA
Burned (marketplace fee) 2,000 × 2.5% = 50 PXA

Atomicity

All five steps (debit buyer, credit seller, credit creator, burn fee, transfer NFT ownership) execute as a single atomic operation. If any step fails, the entire transaction reverts. There is no partial settlement.

How is the NFT linked to on-chain art?

The linked_permlink field permanently connects the NFT to a specific comment operation (post) on the blockchain. This post contains the Base64-encoded pixel art in its body.

Validation rules (expected)

Rule Purpose
Post must exist on-chain Prevents minting against nonexistent content
Post author must match minter Prevents minting someone else's artwork
One NFT per post (expected) Ensures 1:1 relationship between art and token

What this guarantees

The art and the token are inseparable at the protocol level. The NFT points to a specific on-chain post, and that post's content (the pixel art) is immutable. The result:

  • The art cannot be swapped (linked_permlink is immutable)
  • The art cannot be deleted (on-chain data is permanent)
  • The art cannot be degraded (lossless encoding is preserved forever)

How does metadata work?

The metadata field stores descriptive information about the NFT as a JSON object. Expected structure:

{
  "name": "Sunset Warrior",
  "description": "A 64x64 pixel warrior at sunset",
  "attributes": [
    { "trait_type": "Palette", "value": "Warm" },
    { "trait_type": "Canvas", "value": "64x64" },
    { "trait_type": "Style", "value": "Retro RPG" }
  ],
  "image_format": "png",
  "dimensions": [64, 64]
}

Metadata provides the descriptive layer for marketplaces, galleries, and collection browsers. The format is inspired by the OpenSea metadata standard for interoperability, adapted for Pixa's on-chain context.

How will indexing work?

The NFT plugin will maintain its own indexes within the Graphene shared memory database:

Index Purpose
By token ID Look up any NFT by its unique identifier
By owner List all NFTs owned by a specific account
By creator List all NFTs created by a specific artist
By sale status List all NFTs currently on the marketplace
By price Sort marketplace listings by price

These indexes are maintained automatically as NFT operations are applied to blocks. API nodes expose them through query endpoints.

Summary

Component Specification
Implementation Graphene plugin (native protocol objects)
Uniqueness One token per minted piece
On-chain art link linked_permlink to a comment post (immutable)
Creator royalty Set at mint time (basis points, immutable)
Primary sale fee 10% burned
Secondary sale fee 2.5% burned
Settlement Atomic (all-or-nothing in a single operation)
Transfer cost Free (RC only)
Metadata JSON (name, description, attributes, format, dimensions)
Key operations nft_mint, nft_transfer, nft_sell, nft_buy, nft_cancel_sale

Pixa's NFT standard is designed for one purpose: making pixel art ownership verifiable, tradable, and permanent — with royalties guaranteed by consensus, not by contract. The native plugin approach sacrifices the flexibility of smart contracts for the certainty of protocol-level enforcement. On Pixa, the rules are not code that someone deployed. They are the law of the chain.

Clone this wiki locally