AUUM: A Natively-Processed Signed Token on TeleCanor Chain

Testnet documentation. Describes what is running today, not a roadmap dressed up as a launch.

1. Abstract

AUUM is a fungible token running on TeleCanor Chain, a minimal Rust Layer-1 built to test one specific idea: that an AMM, a perpetuals engine, and a fungible token can be processed as first-class state transitions inside a blockchain's own state machine, rather than compiled to bytecode and run inside a virtual machine. This document describes the system as it actually runs today — a gossip-propagated testnet mesh with no proof-of-work and real ed25519 signature verification on every AUUM action.

2. Design Philosophy: Native, Not Bytecode

Ethereum-style chains give you a general-purpose VM and let you deploy arbitrary logic as smart contracts. That flexibility comes at a cost: every operation pays for interpretation overhead, and correctness depends on the contract author, not the chain itself. Hyperliquid's actual innovation is the opposite bet — build the specific primitives you need (an order book, a margin engine) directly into the chain's core logic, and get speed and simplicity in exchange for generality.

TeleCanor Chain follows that same bet, at a much smaller scale. There is no VM. Action::Erc20Transfer, Action::AmmSwap, and Action::PerpOpen are Rust enum variants handled directly by WorldState::apply() — the same function, the same code path, whether the action came from a wallet click or a curl command.

3. Chain Architecture

3.1 Blocks and Finality

Each valid action is finalized into its own block immediately on receipt — there is no mempool, no batching, and no proof-of-work. A block's hash covers its index, timestamp, previous hash, and a digest of its contained actions; validity is simply hash == recompute(block).

Proof-of-work exists in chains like Bitcoin to make it costly for an anonymous, adversarial party to flood the network with fraudulent blocks — a Sybil-resistance mechanism. TeleCanor Chain's validator set is small and operator-known, not open and adversarial, so PoW would only add latency without buying any real security property here.

3.2 Gossip & Sync

Nodes connect over raw TCP, exchanging newline-delimited JSON messages (NewBlock, RequestChain, ChainResponse). On connecting to any peer — inbound or outbound — a node immediately requests that peer's chain, so a freshly-joined node catches up right away rather than waiting for the next new action to reveal it's behind.

3.3 Fork Resolution

The chain-selection rule prefers the longer chain. Without PoW, two nodes can occasionally finalize different actions at the same height simultaneously — a real but rare race given the small validator set. On a length tie, every node deterministically prefers the candidate with the lexicographically lower block hash, so the whole network converges on the same winner. The losing action is not retried; this is an inherent cost of having multiple independent block producers with no single sequencer, not something the tiebreak can eliminate, only make consistent across the network.

4. The AUUM Token

AUUM implements the same interface ERC20 defines — transfer, approve/transferFrom, mint/burn, balanceOf/totalSupply — as native chain actions rather than contract calls. It is the one part of this chain with real cryptographic authentication: an AUUM account is its ed25519 public key (hex-encoded), and every AUUM action must carry a valid signature over a canonical message, checked by every node before the action can touch state.

4.1 Actions

The authorizing field must literally equal the provided public key — there is no separate registry mapping human-readable names to keys. The account is the key.

4.2 Mint Authority & the Faucet

Only one public key — the AUUM treasury — may successfully mint. This is enforced as an ordinary state-machine rule (checked alongside the signature), the same category of rule as everything else on this chain. A testnet faucet (/aum/faucet) mints 50 AUUM to a requested address, self-signed by whichever node's treasury key is configured, rate-limited to one claim per address per hour per node.

4.3 Client-Side Signing

The reference wallet (wallet.auum.net) signs entirely in the browser using a standard ed25519 implementation — a private key entered or generated there never leaves the page. Signatures are RFC 8032-standard and interoperate with any conformant ed25519 library; the reference implementation has been cross-checked against three independent libraries (Rust's ed25519-dalek, JavaScript's tweetnacl, and Python's cryptography) to confirm signatures produced by one verify correctly against the others.

5. AMM & Perps

These predate AUUM on this chain and remain unauthenticated demo primitives — a deliberate scope boundary, not an oversight.

5.1 AMM

A constant-product pool (x·y=k), the same formula Uniswap v2 uses, with a 0.3% fee retained for liquidity providers. LP shares mint proportionally to the smaller fair share on lopsided deposits, preventing a mispriced deposit from minting excess shares.

5.2 Perps

One position per trader, no order book — entry price is the current demo mark price (set directly by a PerpSetMarkPrice action, not a real oracle), PnL scales linearly with size relative to entry, and liquidation is permitted once margin plus PnL goes non-positive.

6. Performance

374 signed AUUM transfers/second, measured directly: 500 independently pre-signed, cryptographically distinct transfers fired at 20-way concurrency against a live node, wall-clock timed. This number is essentially identical to the same benchmark run against unsigned actions, meaning ed25519 verification is not the bottleneck — the single-threaded RPC accept loop is. Raising this further is a known, addressable engineering problem (concurrent request handling), not a cryptographic one.

7. Security Model & Honest Limitations

• Only AUUM is signed. Transfer, AMM, and Perps actions use free-text account names with no cryptographic authentication — a deliberate scope decision, not a gap that was missed.
• No disk persistence yet. Chain state is held in memory and derived by replaying every action from genesis; a node restart resets it. This is a planned addition, not yet built.
• Treasury key custody is currently manual. The mint authority is a single keypair; there is no multi-party control over it today (see Roadmap).
• Fork-loser actions are not recoverable. Under the rare simultaneous-finalization race described in §3.3, one of the two competing actions does not survive.
• No Sybil resistance is needed or provided against an open, adversarial network, because the validator set is not open — this is an explicit design tradeoff for a small operator-controlled mesh, not a limitation to be fixed later.

8. Roadmap

Listed without dates, because none have been committed to:

• Multi-Sig — threshold-authorized AUUM spending across multiple keys.
• DeFi Lending — collateralized borrowing/lending, processed natively like everything above.
• Disk persistence — chain state surviving node restarts.
• Concurrent RPC handling — removing the single-threaded accept loop as the throughput ceiling.

9. Disclaimer