Protocol documentation aligned to the running implementation.

The native token is TLKD. One TLKD has 1,000,000,000 axi. Public balances, fees, staking positions, faucet limits, and explorer amounts use this precision.

The programmable unit is the Axiom Cell. A cell carries bytecode, storage, ownership, optional immutability, balance, manifest metadata, and token configuration when the cell is a token cell.

Native protocol intents cover transfers, batch transfers, staking, compute escrow, cells, token cells, NFTs, names, MCP activity, oracle commit/reveal, governance, and treasury actions.

The CLI resolves RPC from explicit flags, network selection, configuration, and environment. It resolves signing keys from direct keyfile arguments, local config, configured defaults, and the default TruthLinked key path.

The faucet command is intentionally short. axiom faucet signs a devnet faucet request from the resolved keyfile and requests the default 15,000 TLKD amount. --amount changes the requested amount. --from ./axiom/config reads the keyfile from a local config file.

The public faucet endpoint is https://faucet.truthlinked.org. TLKD_FAUCET_URL can point the CLI at another faucet service for private or local networks.

Account pages show the account id, chain history, assets, token holdings, NFT holdings, compute escrow, and staking state surfaced from chain records.

.tl names bind human-readable protocol names to accounts and agents. When a name is resolved, explorer surfaces prefer the name and keep the account id available through navigation and copy actions.

Key rotation is a native account operation. The account id remains the stable protocol surface while signing material can be rotated through a signed transaction path.

Transfer and batch-transfer intents pay native TLKD gas. The fee includes the fixed transfer gas component and the transaction byte fee.

Cell execution, staking, token, NFT, MCP, oracle, governance, and administrative paths consume compute units. CU-metered fees settle from compute escrow into TLKD-denominated protocol revenue.

Explorer transaction pages show the merged paid fee as TLKD and expose native gas, CU, and raw transaction data where available. Rejected or failed attempts do not report a paid fee.

A cell manifest declares reads, writes, commutative keys, dynamic storage key specs, oracle schema bindings, manifest hash, and manifest version. Deployment and upgrade paths verify this metadata against the cell bytecode and runtime limits.

Cells can be deployed, called, upgraded, transferred, made immutable, closed, and governed through explicit transaction intents. Immutability is an explicit state, not a default assumption.

Token cells are Axiom Cells with token metadata and token balance behavior. Explorer labels them as token cells and shows token names, symbols, holders, and related transactions when the chain data is present.

A call chain carries a list of cell calls and one global gas limit. Each call contains a cell id, calldata hex, and value. The chain limit is 64 calls and total calldata is bounded by the protocol calldata limit.

The explorer write-cell surface includes a call-chain builder so developers can assemble atomic multi-call payloads without hand-writing the transaction JSON.

MCP tool calls compile into call-chain execution where policy, tool logic, and action-log behavior can be enforced as one coordinated on-chain flow.

The global search bar accepts transaction hashes, account ids, public keys, NFT ids, cell ids, block heights, and .tl names. Ambiguous 64-character ids are resolved through server-side chain lookup.

Transaction detail pages show status, block, timestamp, signer, intent-specific actors, amount, fee paid, compute details, and raw transaction data. Rejected entries remain visible with their rejection reason.

Block pages show finalized block height, validator, transaction count, paid fees, age, and status. Vote transaction rows are removed from public block tables where they obscure user-facing activity.

The MCP layer contains registries for tools, resources, prompts, agents, policies, and action logs. These are protocol entities with storage keys, counters, ownership, permission flags, and activity records.

Tools are Axiom-backed capability surfaces. Resources carry URI scheme, MIME type, content hash, update time, and read counters. Prompts carry names, template hashes, argument counts, use counters, and approval timestamps.

Agents bind identity, policy, registry, and activity. Agent pages present registered agents and MCP activity as structured rows: entity type, name or id, agent, registry or policy, block, and transaction.

Cells can declare oracle schema bindings and queue oracle requests through Axiom execution. Validators submit commit and reveal transactions, consensus tallies the result, and finalized oracle data becomes available through canonical oracle state and settlement paths.

URL access is governed through proposal, voting, and slashing surfaces. Approved URL patterns define what external data paths can enter the oracle process.

Accord records pending requests, commits, reveals, finalized results, URL proposals, schema proposals, and visibility state inside the chain state transition system.

Validators propagate valid transactions across the peer set before finality. Batches are committed through signed commitments, executed against deterministic state, and finalized with block headers that carry state root, batch hash, validator identity, and total paid fees.

The validator execution path prioritizes exact applied-set accounting. A committed block records success, rejection, and error status so explorer reads, block fees, and transaction lookup stay aligned.

The protocol is leader-MEV resistant through streamed intake, batch commitments, deterministic ordering, peer verification, and state-root agreement.

The storage stack records block headers, raw batches, transaction locations, account histories, cell state, state snapshots, and transaction result status. Reads reconstruct details from committed chain data and preserve failure status.

Snapshots and replay paths support recovery. The block repairer can compare stored batch transaction counts against chain data surfaces and repair transaction records when needed.

The explorer consumes RPC and chain-data routes backed by this persistence layer. User-facing pages speak in terms of confirmed, rejected, errored, pending, and finalized chain data.