NEP-200: Imprints Standard

Core

April 16, 2026

Testnet

Imprints represent the Netrun Foundation's answer to a fundamental question: how do we bring the inscription paradigm to account-based blockchains? This document defines the Imprints standard—a system fundamentally different from Bitcoin inscriptions, designed from first principles for Solana's architecture.

Imprints are developed and maintained by the Netrun Foundation.

Why Inscriptions Cannot Work on Solana

Bitcoin inscriptions rely on two properties unique to UTXO chains: witness data fields and satoshi ordinal tracking. When you inscribe data on Bitcoin, you attach it to a specific satoshi, and the Ordinals protocol tracks that satoshi as it moves through transactions. The data travels with the sat.

Solana has neither of these. There are no discrete units to track—balances are just numbers in accounts. There is no witness field—all transaction data is executed, not stored passively.

Imprints don't attempt to port inscriptions. They solve the same problem—permanent, owned, onchain data—using Solana-native primitives: PDAs, state compression, and program composability.

Core Architecture

Each Imprint is a Program Derived Address (PDA) with explicit ownership semantics. Unlike inscriptions where ownership is implicit through satoshi tracking, Imprints store an owner field directly in account data.

PDA = derive(["imprint", creator_pubkey, nonce], program_id)

where nonce increments per creator, ensuring unique addresses

Content is stored directly in account data with a SHA-256 hash for integrity. Transfers are atomic single-instruction operations—no UTXO selection, no fee estimation complexity.

State Tokens: Native Program Instructions

BRC-20 encodes operations as JSON strings inscribed onto satoshis. Indexers parse these strings to reconstruct balances. This is a workaround for Bitcoin's lack of smart contracts.

State Tokens take a fundamentally different approach: operations are native program instructions that modify on-chain state directly. No JSON. No indexers. Balances exist as real account data.

Instruction Format

Each instruction is a binary-encoded call to the Imprints program. The discriminator byte identifies the operation:

// Instruction discriminators
0x00 → InitializeToken
0x01 → MintTokens
0x02 → TransferTokens
0x03 → BurnTokens
0x04 → FreezeAccount
0x05 → CloseToken

InitializeToken (0x00)

Creates a new token with fixed parameters. Unlike BRC-20's deploy inscription, this creates actual on-chain accounts.

// Instruction data layout (41 bytes)
[0x00]                    // discriminator (1 byte)
[symbol: 8 bytes]         // token symbol, null-padded
[decimals: 1 byte]        // decimal places (0-9)
[max_supply: 8 bytes]     // u64, little-endian
[mint_limit: 8 bytes]     // u64, max per mint tx
[mint_price: 8 bytes]     // u64, lamports per token
[authority: 32 bytes]     // mint authority pubkey

Accounts required:

[0] Token registry PDA (writable, derived)

[1] Creator wallet (signer, pays rent)

[2] System program

MintTokens (0x01)

Mints tokens to a recipient. Fails if amount exceeds mint_limit or remaining supply.

// Instruction data layout (9 bytes)
[0x01]                    // discriminator
[amount: 8 bytes]         // u64, tokens to mint

Accounts required:

[0] Token registry PDA (writable)

[1] Recipient balance PDA (writable, init if needed)

[2] Minter wallet (signer, pays mint_price * amount)

[3] Treasury account (receives payment)

[4] System program

TransferTokens (0x02)

// Instruction data layout (9 bytes)
[0x02]                    // discriminator
[amount: 8 bytes]         // u64, tokens to transfer

Accounts required:

[0] Token registry PDA (readonly)

[1] Sender balance PDA (writable)

[2] Recipient balance PDA (writable, init if needed)

[3] Sender wallet (signer)

[4] System program

On-Chain State

Token state is stored in two account types:

TokenRegistry (97 bytes)
symbol: [u8; 8]       // Token symbol
decimals: u8          // Decimal places
max_supply: u64       // Maximum tokens
circulating: u64      // Currently minted
mint_limit: u64       // Max per transaction
mint_price: u64       // Cost in lamports
authority: Pubkey     // Mint authority
treasury: Pubkey      // Payment recipient
frozen: bool          // Global freeze flag
bump: u8              // PDA bump seed
BalanceAccount (41 bytes)
owner: Pubkey         // Wallet address
amount: u64           // Token balance
bump: u8              // PDA bump seed

Supply Economics

The mint_price creates a treasury that accumulates as tokens are minted. Total treasury value at full mint:

T = P_mint × S_max

where P_mint = mint price, S_max = max supply

Example: NETRUN Token

Circulating Supply8,400,000 / 21,000,000

Mint Price0.001 SOL

Treasury Balance8,400 SOL

Remaining Supply12,600,000 tokens

State Tokens vs BRC-20

Aspect	BRC-20	State Tokens
Operation format	JSON strings	Binary instructions
State storage	Reconstructed by indexers	On-chain accounts
Balance query	Parse full tx history	Single RPC call
Validation	Off-chain (indexer rules)	On-chain (program logic)
Composability	None	Full CPI support
Mint price	Free (gas only)	Creator-defined

Netrun Integration

Imprints and State Tokens integrate with the broader Netrun ecosystem:

•Cross-chain bridges can lock Imprints on Solana and mint representations on other chains, with content integrity verified via stored hashes.
•Ethos credibility (NEP-100) gates high-value operations: State Token deployment requires CS > 600, and curve parameter modifications require CS > 800.
•Governance weight incorporates both Imprint holdings and State Token reserve contributions.

The Imprints program is deployed at ImprtNetrunF0undati0n... with SDK support for TypeScript, Rust, and CLI tooling.

Imprints and State Tokens are not ports of Bitcoin primitives. They achieve similar goals through architecture native to account-based chains, with capabilities—on-chain state, program composability—that UTXO systems cannot replicate.