Assets on Argonmine: ARG, wARG, uARG

Status (2026-10-26): the asset layer of section 1 is implemented in consensus as version-2 transactions (SPEC §3.5). uARG issuance and redemption through the inbound bridge work end to end on the defaults recommended below (USDC backing, Ethereum first): the desktop and command-line wallets hold, send and redeem uARG, the explorer shows asset balances and supply, and the browser app lists what an address holds. wARG, further chains and on-chain swaps follow. The rest of this document is the design as decided.

The request

1. ARG: the native coin, only ever created by mining. Unchanged.
2. wARG: a wrapped token on the Argonmine chain.
3. uARG: a stable-value token on the Argonmine chain.
4. ARG never leaves the chain. Users bring value in: from Ethereum (ETH, USDC), BNB Chain (BNB), Base (ETH, USDC), Robinhood Chain (ETH) and Bitcoin (BTC), receiving uARG; and take it back out by redeeming uARG.
5. Later, when ARG has liquidity, users swap between ARG, wARG and uARG on the chain.

This reverses the current bridge, which exports ARG to EVM chains as an ERC-20 ("WrappedCoin"). That direction is to be retired.

What the chain can do today

Argonmine's consensus has exactly two output types: pay-to-public-key and an 80-byte data output. There are no tokens, no scripts and no contracts. That was deliberate: the smallest possible rule set is the easiest to get right and to audit. So "a token on our network, on chain" is not a feature to add to an app; it is a change to the consensus rules that every node enforces.

Design

1. Asset layer in consensus (required for any on-chain token)

Add an asset identifier to outputs and conservation rules per asset.

• TxOut gains Asset (32 bytes). Asset == 0 is ARG. Every other asset is identified by the hash of its issuance definition.
• Value is conserved per asset in every transaction: for each asset, inputs equal outputs. Fees are paid in ARG only, so miners are paid in the coin they mine and tokens cannot be used to spam the chain for free.
• A new transaction kind, issuance, creates or destroys units of a non-ARG asset. It is valid only if signed by that asset's issuer key set (an n-of-m threshold of guardian keys, exactly like the bridge custody today). Issuance of ARG is impossible by rule: ARG comes from the coinbase only.
• A burn is an issuance with a negative amount, carrying a memo with the destination on the external chain (the existing bridge memo format).
• Dust, fee and size rules apply unchanged. Coinbase outputs are ARG only.

Scope of the change: consensus/ (encoding, validation, sighash commits to asset ids, UTXO set keyed by asset), docs/SPEC.md, the wallet (per-asset balances and sends), the explorer (per-asset indexing and the address API), both apps (asset list, per-asset send once sending exists), tests for every new rule and every Bitcoin-pitfall analogue (value overflow per asset, asset substitution, issuance replay). The mainnet genesis can stay as it is; rules change before launch, not after.

Estimated effort: two to three weeks of focused work plus review. Genesis is not launched, so this is still a pre-launch rule, not a hard fork.

2. uARG: the stable token

• One uARG is redeemable for one US dollar of stablecoin held in custody.
• Backing: USDC (and optionally USDT) deposited to guardian-controlled vault contracts on Ethereum and Base. The vault is the same federated model as today's bridge: deposits are observed by the guardians, who then co-sign an issuance of uARG on Argonmine to the depositor's address.
• Redemption: the user burns uARG with an EVM destination in the memo; the guardians release the same amount of stablecoin from the vault.
• Volatile deposits (ETH, BNB, BTC) cannot be credited as uARG one to one. Two honest options: (a) swap them to USDC on the source chain at deposit time, so uARG is always backed by dollars, or (b) credit them as wARG units representing that asset. Minting a "stable" token against a volatile reserve would make uARG insolvent on the first market drop. Recommendation: (a) for Ethereum and Base, where USDC liquidity exists; BNB and BTC later.
• Proof of reserves: the vault addresses are public; the explorer shows total uARG issued next to the vault balances so anyone can check backing.

3. wARG: wrapped ARG

Decided 2026-10-26: wARG is wrapped ARG, one to one, the way WETH wraps ETH. ARG is the native coin and cannot sit in an asset-layer output; wARG can, so it is what a swap rule or a pool pairs with uARG. Wrapping locks ARG and issues wARG; unwrapping burns wARG and releases the ARG. The locking rule has to be enforced by consensus (an issuer that is a rule, not a key), which is why wARG comes after the bridge and before swaps.

ARG has no price until a market sets one. The decision is to let that happen on its own, once a good part of the mining has been done and demand has formed; nothing in the bridge or the tokens assumes a price for ARG. Until then wARG has nothing to be swapped against, so it is not built yet.

Volatile deposits (ETH, BNB, BTC) are not accepted by the bridge: a dollar token has to be backed by a dollar asset. The bridge takes USDC and USDT, both counted at one dollar, on several EVM chains (section 4); users who hold ETH swap it to a stablecoin on the source chain first.

4. Chains

Decided 2026-10-26: one multi-token vault per EVM chain, holding USDC and USDT; the guardian daemon watches every chain and the user names the chain and token for a payout in the burn memo. First Ethereum, Base and BNB Chain, then Arbitrum and Polygon; testnets before mainnets.

5. Swaps between ARG, wARG and uARG

An on-chain swap needs either a market maker contract (the chain has none) or a consensus-level swap rule (an output that can be spent by anyone who pays the quoted price into a paired output). The second is possible in the asset layer design, but it is a new consensus primitive with its own attack surface and should come after the asset layer and the inbound bridge are stable and audited. Until then, swaps can run as guardian-quoted trades (off-chain order, on-chain settlement) with the price shown openly.

6. What this means for security

• Guardians hold real dollars and real ETH. The federated model's trust assumptions move from "can mint IOUs" to "custody of user funds". The guardian set, threshold, key storage (hardware), monitoring and incident process must be designed before any mainnet deposits.
• The consensus asset layer must be reviewed with the same rigour as the base rules; it is the largest consensus change since the specification.
• A stablecoin issuer is a regulated activity in most jurisdictions. That is a legal question for the operator, not an engineering one, but it affects which chains and which tokens are sensible to start with.

Decisions needed before code

1. Approve the consensus asset layer (section 1). Without it there are no on-chain tokens; everything else depends on it.
2. uARG backing: USDC only (recommended), or USDC and USDT.
3. Volatile deposits: auto-swap to USDC at deposit (recommended), or credit as wrapped assets.
4. What wARG wraps.
5. Launch chains: Ethereum and Base first (recommended); BNB and Robinhood second; Bitcoin last.
6. Guardian set size, threshold, and who runs them.
7. Fees: deposit, redemption and swap fees, and who receives them. Decided 2026-10-26: the bridge keeps 1 percent of every deposit and 1 percent of every redemption, enforced by the vault contract; the fees accumulate in the vault above what backs uARG and only the vault owner can withdraw that surplus. Swap fees are decided with the swap rule.

Suggested order of work

1. Asset layer in consensus with spec and tests (two to three weeks).
2. Wallet, explorer and app support for multiple assets.
3. Vault contract and guardian daemon for inbound USDC on Ethereum and Base; uARG issuance and redemption end to end on testnets.
4. Public reserve dashboard in the explorer.
5. Wrapped volatile assets, then BNB and Robinhood, then Bitcoin.
6. Swaps.