Versioned guide

Lite ABI and layout

Linkable section with data contracts and reproducible examples.

  • Examples identify the expected cluster and IDs.
Mainnet · Finalized

Program ID and evidence match the Lite manifest; the upgrade authority is revoked.

Guide contract

Opcodes, instruction lengths, offsets, and economics declared by the manifest.

Use the Lite manifest as the source for the Program ID, slot, hash, authority, and account parameters. The program is finalized: the manifest records the revoked authority and immutable program.

Frozen ABI v1

InstructionOpcodeData bytes
register025
transfer133
setResolver233
setPrice39
buy49
release51
Record bytes
96
Compiled rent bounds
155904010000000 lamports
Registration protocol fee
0
Sale protocol fee
0 bps
Settlement
native SOL only

Program errors

CodeMeaning
1invalid name
2bad PDA
3bad record state
4signer is not owner
5wrong System Program
6rent outside compiled bounds
7not listed
8seller changed
9buyer equals seller
10lamport overflow
11fixed price changed

Keep program, RPC, wallet, simulation, blockhash, pending, failed, and finalized states separate. Technical disclosures should contain only a safe code, cluster, and request ID.

Explorer verification

Open the immutable Lite program

Explorer is a convenience view. Independently fetch a signature and the name PDA at finalized commitment, require a successful transaction containing the expected Program ID, then repeat every account check.

Lite and Full cannot silently diverge

Full V1 is not deployed or canonical. A future migration must transfer the current Lite record into deterministic Full custody and create the Full record atomically with the current Lite owner’s signature. Every new Full registration must also atomically claim and custody the Lite PDA. Until deployed code proves that invariant, no Core asset or Full name represents a Lite name.

Read security and deployment evidence