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. A small number of chains take the opposite bet instead: build the specific primitives you need directly into the chain's own core state-transition logic, and trade generality for speed and predictability. Hyperliquid did this for an order book and margin engine. Stellar did it earlier and differently — its base protocol has shipped a native decentralized exchange (offers, order books, path payments) and native multi-asset issuance since long before smart-contract layers like Soroban existed, with no contract deployment step required to trade or issue an asset. Both are evidence that "native, not bytecode" is a viable production architecture, not only a testnet curiosity.

TeleCanor Chain follows that same lineage, 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. Of the networks examined for this design, Hyperliquid, Stellar, and TeleCanor Chain are the ones whose core trading and token primitives are coded directly into Layer-1 state-transition logic, rather than deployed as smart contracts on top of a general-purpose VM.

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.

3a. Leader-Rotation Upgrade (Live, Staged Rollout)

§3.3 describes a real cost of this chain's design: two nodes racing to finalize different actions at the same height, with the loser silently dropped rather than retried. A stake-weighted leader-rotation gate has been built to remove that race, reusing the Staking contract described in §6 as the source of truth for who may propose — and is now running on the primary AUUM mesh, not only in an isolated test environment.

3a.1 Mechanism

Time is divided into fixed 1-second slots. Every node independently computes the same leader for a given slot by hashing the slot number with Keccak-256 and walking the active validator list (read directly from the Staking contract's own EVM storage — no extra RPC round trip, no gossip needed to agree), weighted by each validator's stake. A node that opts in via --validator-address only finalizes a submission if it is the computed leader for the current slot; otherwise it rejects with an explicit not the leader for slot N; current leader is <address> error rather than racing to finalize anyway. A node that does not opt in is completely unaffected — this is an additive gate at the single choke point (submit()) that both native actions and eth_sendRawTransaction already share, and try_append accepts a gossiped block from an un-upgraded peer unchanged whenever it carries no proposer field.

3a.2 Isolated Verification

Before touching the primary mesh, this was built and tested in a fully isolated three-node chain — separate genesis, separate ports, zero contact with the primary AUUM mesh. Across repeated rounds of concurrent submission to two staked validators (500 and 1000 AUUM respectively), exactly one validator accepted per slot every time, the non-leader correctly named the true leader in its rejection, and all three nodes stayed converged on one identical chain throughout. Two real bugs were found and fixed during this work, both case-sensitivity mismatches against the EVM's lowercase-only account-key convention (a checksummed contract address and a checksummed CLI-supplied validator address each silently failed to match, independently, before being caught).

3a.3 Live Deployment

The rollout to the primary mesh happened in three deliberate stages, each verified before moving to the next: deploy a dedicated Staking contract on the live chain (distinct from the isolated test deployment); rebuild and redeploy the updated binary across the primary mesh with the gate still fully disabled everywhere, to prove the new code changes nothing on its own; then, only after confirming every node stayed healthy and in sync, enable --validator-address on exactly one node and watch it under real traffic before going further.

That canary node correctly identified itself as the current slot's leader, proposed a real submitted action as a properly-attributed block, and every other node on the mesh — none of which are gated yet — accepted and adopted that block without incident. Extending --validator-address opt-in to the rest of the mesh is the next stage; see Roadmap. The mesh itself has also grown since this section was first written, now spanning multiple independent cloud providers rather than a single host pair, for the fault-tolerance reasons discussed alongside the Staking contract in §6.

Separately, the Staking contract's minimum stake was lowered from the 500 AUUM used during isolated testing to 50 AUUM on the live deployment, and staking is fully permissionless — the contract has no allowlist or owner-gating on who may stake, so any address that stakes 50+ AUUM is automatically added to the active validator set and becomes eligible for leader slots, weighted by stake. Running a node as a validator is self-service: the standard install path at wallet.auum.net/run-a-node (a one-line installer for Linux/macOS, and native double-click installers for macOS and Windows, all auto-detecting OS and CPU architecture) now asks for a staked address and wires --validator-address in automatically if one is given.

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.

4a. Token Distribution & Economics

AUUM's total supply is fixed at 1,000,000,000 tokens, allocated across seven buckets separating institutional capital from public and ecosystem liquidity.

4a.1 Allocation

4a.2 Vesting & Lockup Schedules

Vesting is dual-speed by design: institutional allocations vest slowly enough to align long-term incentives, while public-sale allocations unlock quickly enough to give retail buyers real liquidity against their principal risk.

• Institutional Seed & Private Sale. 6-month cliff, then 18-month linear monthly vesting (24 months total). The cliff prevents selling into the critical post-launch price-discovery window; the full horizon matches standard Web3 fundraising terms.
• Public Sale / IDO Launchpad. 10% unlocked at Token Generation Event (TGE), 2-month cliff, then 12-month linear vesting. The TGE unlock gives retail buyers immediate liquidity; the remainder is spread out to discourage aggressive early sell-offs.
• Telecanor Corporate Treasury. 12-month cliff, then 36-month linear vesting.
• Core Team & Developers. 12-month cliff, then 24-month linear vesting. A one-year total lockup before any team tokens move signals the founding team cannot exit the project immediately post-raise.
• Liquidity & Market Making. 100% unlocked at TGE, locked into exchange pools via smart contract.
• Ecosystem & Validator Incentives. No cliff; emitted dynamically over 48 months, driven by network block production and staking demand rather than a fixed calendar schedule.

4a.3 Buyback-and-Burn

A share of TeleCanor's corporate B2B revenue is committed to buying AUUM on the open market and sending it to a verifiable burn address, tying token scarcity directly to corporate performance rather than to token emissions alone:

Telecanor Corporate B2B Revenue
        |
        v
Allocate 15-20% of Net Profits
        |
        v
Market-Purchase AUUM from Exchanges
        |
        v
Send to Verifiable Burn Address (0x000...)
        |
        v
Reduces Circulating Supply --> Scarcity / Upward Price Pressure

• Downside mitigation. Token prices move with broader market sentiment regardless of fundamentals; a consistent, programmatic buyback creates a standing buy-pressure floor that works against that volatility during broader crypto downturns.
• Value accrual over emission. Rather than funding growth by printing more tokens, circulating supply is actively reduced over time — as network utility grows, fewer tokens remain to divide it among.
• Transparency. Every buyback-and-burn event is intended to be programmatic, executed on-chain via smart contract, and independently auditable through a public treasury dashboard rather than taken on trust.

5. AMM & Perps

5.1 Native AMM & Perps (legacy demo primitives)

These predate AUUM on this chain and remain unauthenticated demo primitives — a deliberate scope boundary, not an oversight. 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. Perps here is one position per trader; entry price was originally a demo mark price set directly by a PerpSetMarkPrice action, not a real oracle — §5a's native CLOB now provides genuine two-sided price discovery instead, once a given market has traded at least once.

5.2 EVM-Based AMM & Perps (Solidity, testnet live)

A second, independent implementation of the same two primitives, this time as Solidity contracts deployed on AUUM's own EVM (revm) rather than native chain actions — and consequently properly authenticated, since every EVM transaction on this chain requires a valid secp256k1 signature checked before execution, unlike §5.1's free-text account model. SimpleAMM.sol is a real on-chain constant-product pool, verified via actual on-chain swaps rather than a simulation. SimplePerps.sol reads its mark price live from the AMM's own reserves (getReserves()) rather than any admin-set or oracle price — there is no code path for anyone to set the mark price directly.

5a. Native CLOB (Central Limit Order Book)

§5.1 already flagged the gap directly: Perps here has “no order book — entry price is a demo mark price set directly by a PerpSetMarkPrice action, not a real oracle.” A native central limit order book closes that gap with genuine two-sided price discovery, built the same way every other primitive on this chain is — as first-class Action variants (ClobPlaceOrder, ClobCancelOrder) handled directly inside WorldState::apply(), not a Solidity contract. This is also the more faithful Hyperliquid parallel from §2: Hyperliquid’s actual core product is a perpetuals order book, not a spot DEX, and matching there runs in the chain’s own state machine too, not a smart contract.

5a.1 Mechanism

Orders are real, signed instructions — trader must equal pubkey over a valid ed25519 signature, the same authentication bar as AUUM’s own actions, plus a strictly-incrementing per-trader nonce (a check the AUUM signing scheme itself doesn’t need, since replaying a transfer just moves the same funds again; replaying a captured order signature could otherwise re-lock margin). Placing an order reserves its declared margin out of the trader’s spendable AUUM balance immediately — a new lock/reserve mechanism, since nothing on this chain needed one before a resting order could exist. Matching runs synchronously, inline, inside the same state transition that places the order: a crossing order fills immediately against the best resting price on the opposite side, at the resting (maker) order’s price, walking price levels in strict price-then-order-id sequence until it stops crossing or is fully filled; any unfilled remainder rests in the book. Filled quantity feeds directly into the trader’s Perps position from §5.1/§5.2’s model — opening or adding to a same-side position (weighted-average entry price), or reducing/closing an opposite-side one. mark_price updates to the last trade’s price once a market has traded at least once; PerpSetMarkPrice remains the cold-start fallback until then.

5a.2 Honest v1 Scope

A single fill never flips a trader’s position from long to short (or back) in one step — a fill against an existing opposite-side position is capped at that position’s remaining size, so the worst case is a full close, never a flip past zero. A resting order larger than the position it’s about to close simply keeps the leftover resting rather than silently reopening the opposite side in the same match (though a second, separate crossing fill within the same call can legitimately close-then-reopen, passing through flat in between — economically the same as a real flip, just decomposed into two priced steps, never skipped). A reducing fill’s own posted margin is refunded unused rather than spent, since a reduce doesn’t need fresh collateral — what actually settles is the closed portion of the pre-existing position’s own margin plus realized PnL, floored at zero. A real system would force-liquidate a position before it could go this far underwater; this demo doesn’t yet pre-empt a CLOB reduce fill that way, so that floor is a backstop, not a liquidation event. The order book itself isn’t in the Merkle tree yet — §9 already documents this gap for the AMM pool and Perps positions; the CLOB’s resting orders and reserved-margin state follow that same precedent.

5a.3 Verification & Rollout

Built and verified first on a fully isolated three-node chain — separate genesis, separate ports, zero contact with the primary mesh — matching the same discipline already used for the leader-rotation and auto-tick rollouts. Confirmed there: signature and nonce-replay rejection; the spendable-balance lock actually blocking a double-spend via a plain transfer against a locked order; strict price-time tie-break (three same-price resting orders from three different traders filled in exact submission order, not wall-clock time or any incidental iteration order); cancel correctly refunding reserved margin without ever touching spendable balance; the no-flip cap described above; and, most importantly for a change that touches every node’s own replayed state, byte-identical state across all three nodes after a full restart-and-reload from each node’s own persisted chain history, and again after one node was wiped entirely and rebuilt purely from peer gossip.

6. Staking

Staking.sol is a stake-weighted reward contract, deployed live on AUUM's EVM, and also the source of truth the leader-rotation upgrade in §3a reads to determine the active validator set and their weights — the same stake secures both rewards and, on the node that has opted in, block-proposal rights. The consensus-facing deployment sets a 50 AUUM minimum stake and is fully permissionless: stake() is a plain payable function with no owner-gating, so any address clearing the minimum is added to the active validator set by the contract itself, immediately, with no approval step.

Rewards accrue via a MasterChef-style reward-per-share accumulator, avoiding an O(n) iteration over every validator on each accrual. Epochs (1 hour each) now advance automatically off real elapsed time: this chain's EVM wires a genuine wall-clock value into block.timestamp on every call — an earlier version of this contract needed an owner-triggered tick() as a manual substitute, because block.timestamp was a hardcoded constant that never advanced on this EVM; that gap is now closed at the chain level. stake(), unstake(), and claimRewards() each check on entry whether one or more epoch boundaries have been crossed since the last check and, if so, catch up every missed epoch's reward distribution in a single pass — no owner, no external keeper, no cron job required. tick() still exists as a permissionless convenience function that anyone may call to nudge a boundary forward early, but nothing depends on anyone actually calling it.

7. CEX & Custodial Wallet

A centralized exchange service sitting above the chain, not a smart contract — real custody, identity checks, and off-chain order matching, live today as a hosted API and as a downloadable self-hosted package.

Every registered user gets a real, individually-generated on-chain AUUM address (private key encrypted at rest with AES-256-GCM, never handled in plaintext outside a signing operation) plus an off-chain ledger balance for instant trading — mirroring how real exchanges separate on-chain settlement from off-chain matching rather than settling every order on-chain. Order matching is price-time priority with atomic database transactions and price-improvement refunds for takers. The same custodial wallets also trade the EVM-based AMM & Perps from §5.2 natively — a user's custodial balance can swap or open a leveraged position directly, with no separate wallet or manual on-chain step required.

8. Performance

Early measurement identified two real bottlenecks, neither of them cryptographic: every submitted action paid for a full replay of chain history from genesis to derive current state before it could even be checked, and each action was finalized as its own block with no batching, so fixed per-block overhead (a gossip broadcast, a Merkle rebuild, a disk write) was paid once per action rather than shared across many.

Both are now addressed. Chain state is kept in memory as a single running WorldState, updated incrementally as each block finalizes rather than re-derived by replay on every request — replay is now reserved for startup (when no valid snapshot exists) and for genuine chain reorganizations. Concurrently-submitted actions are now collected into short-lived batches and finalized together as one block under a single lock acquisition, rather than the previous one lock acquisition (and, before the caching fix above, one full replay) per individual action. Signature verification for a batch is additionally checked in parallel across available CPU cores rather than one action at a time, since ed25519 verification touches no shared state and is safe to parallelize with no effect on the result. Work to parallelize the batch's actual state mutations themselves, not just their signature checks, where two actions provably touch disjoint accounts, is in progress; see Roadmap.

9. Security Model & Honest Limitations

• Only AUUM and the EVM side are signed. §5.1's native Transfer/AMM/Perps actions use free-text account names with no cryptographic authentication — a deliberate scope decision, not a gap that was missed. Everything on the EVM (§5.2's contracts, Staking, and every CEX on-chain settlement) requires a real secp256k1 signature, checked by revm before execution.
• 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 on nodes that haven't opted into leader-rotation. Under the rare simultaneous-finalization race described in §3.3, one of the two competing actions does not survive. §3a's gate closes this race on the node that has opted in; every node that hasn't yet opted in remains subject to §3.3's behavior until the staged rollout extends further.
• 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.
• Leader-rotation is opt-in and not yet BFT. §3a's gate has no slashing, no formal finality proof, and no protection against a validator that is malicious rather than merely non-leader — it closes one specific race, not the full space of consensus attacks.

10. Roadmap

Listed without dates, because none have been committed to:

• Leader-rotation rollout to the rest of the primary mesh — §3a is live on one node with a real, permissionlessly-staked validator set behind it; extending --validator-address opt-in to every other node, and growing the external (non-operator) validator set beyond the current single staker, is in progress.
• CLOB canary & wider availability — §5a's order book is live and inert across the primary mesh; a small team-controlled canary pass at real cross-datacenter latency, then publishing the order/cancel/orderbook UI, is the next step.
• Parallel batch execution — §8 already parallelizes signature verification within a batch; extending that to the state mutations themselves, for the subset of actions provably touching disjoint accounts, is in progress.
• Slashing & formal finality — closing the gap between §3a's leader-rotation gate and a full BFT consensus.
• Multi-Sig — threshold-authorized AUUM spending across multiple keys.
• DeFi Lending — collateralized borrowing/lending, processed natively like everything above.

11. Disclaimer