wSOST & Gold Reserve V2

State machine

Every conversion moves through these states. The names in the first column are the design names; the prototype uses the names in the second.

The Atomic Bridge versions of these flows are in Diagram 2 (entry), Diagram 3 (exit) and Diagram 6 (failures). The Gold Access Key amounts below are the same in both models.

Example 1 · Ana converts 1,000 SOST

Example 2 · small and very large operations

Example 3 · Ben returns wSOST he bought on an exchange

Example 4 · when something goes wrong

Example 5 · how Gold Reserve V2 would grow

An illustrative month with 300 completed conversions:

The reserve grows only with real use of the bridge. The gold stays in the reserve under its own rules: it is not paid out to anyone, it backs neither SOST nor wSOST, and it gives no holder a redemption right. Growth of the reserve does not guarantee any price of SOST.

Example 6 · the two reserves are never the same thing

Most cross-chain bridges belong to one of five families. They differ in who decides that a deposit is real, where the money for the other side comes from, and who keeps the fee.

Comparison table

No model is universally better: each trades trust, capital, speed and cost differently. Light-client and rollup bridges minimize trust but need one chain to verify the other; liquidity networks are fast but need capital; issuer bridges work only for the issuer’s own token. The SOST Atomic Bridge avoids capital, pools and outside operators at the price of an engine-authorized entry release and an unsolved native custody problem.

What SOST does differently — and what it does not claim

Sources: Across documentation (fees); Stargate documentation (protocol fees); Wormhole, Circle CCTP and Optimism documentation; public post-mortems of the Ronin, Harmony Horizon and Wormhole incidents. Other bridges change over time; descriptions are for orientation only.

wSOST is not another coin. It is a token on Ethereum that represents native SOST one-for-one. The SOST it represents stays on the SOST blockchain, locked in a dedicated Bridge Vault, until the wSOST is turned back into SOST.

Example — John wraps 500 SOST

Example — John unwraps 200 wSOST

How a deposit would work (design)

The deposit carries a capsule (a data field active on SOST since block 7,350) with the id of your bridge request. That id is a public hash of the Ethereum recipient, the amount, the chain and the bridge contract, so your SOST signature binds the deposit to exactly that request. No consensus change, no new transaction type.

Why wSOST would exist

Integrating a brand-new Layer-1 is real work for wallets and exchanges; Ethereum and ERC-20 tokens are already integrated almost everywhere. wSOST would make SOST reachable from:

• Ethereum wallets;
• DEX liquidity pools and therefore public price discovery;
• exchanges where ERC-20 support reduces Layer-1 integration work;
• future DeFi compatibility.

The integration barrier

One practical barrier to wider SOST market access is the technical burden a centralized exchange faces when it integrates a new, independent Layer-1 blockchain. Listing native SOST would require the exchange to:

• run and maintain a SOST full node;
• integrate SOST deposits and withdrawals;
• implement a SOST-specific confirmation and reorganisation policy;
• monitor wallet and node infrastructure around the clock;
• review SOST RPC and transaction semantics;
• build custody and operational tooling for a new chain;
• carry the security and maintenance work specific to SOST.

Ethereum and ERC-20 infrastructure, on the other hand, is already in place at virtually every major centralized exchange: deposits, withdrawals, custody and monitoring for ERC-20 tokens are standard operations there. For such a venue, integrating an ERC-20 representation is operationally much simpler than integrating a new chain.

What would be listed

The initial exchange-access target is wSOST: the representation offered to CEX and DEX venues where integrating the native SOST chain is impractical or unnecessarily complex. wSOST does not replace SOST. wSOST is designed to make SOST easier to integrate without replacing the native SOST network.

Example — John reaches an Ethereum-compatible exchange

Three roles, three layers

Native SOST remains the canonical protocol asset. wSOST is the planned Ethereum-compatible market-access representation. Gold Reserve V2 is the planned external gold-reserve layer.

From the Genesis Gold Vault to Gold Reserve V2

The original SOST design introduced a Gold Vault concept from Genesis: part of the early block distribution accumulated in a constitutional reserve, with the long-term idea of connecting SOST with an external gold reserve. That historical architecture later changed. From block #25,000:

• the Gold Vault receives 0% of new emission;
• the PoPC Pool receives 0% of new emission;
• the current block distribution is 50% miner / 50% DTD;
• the historical Gold Vault + PoPC balances are frozen and committed to the DTD Jackpot.

How wSOST feeds Gold Reserve V2

wSOST and Gold Reserve V2 live on the same Ethereum infrastructure as tokenized gold such as XAUT. In the C701 design the reserve grows from one source only: the Gold Access Key each bridge user contributes in XAUT, paid straight from the user's wallet to the reserve inside the mint transaction.

That gives the Genesis reserve philosophy a practical modern infrastructure — SOST L1 + the wSOST access layer + an external tokenized-gold reserve — while every accounting layer stays separate. DEVELOPMENT · NOT DEPLOYED

Nothing below can be done today. It describes the C701 conventional lock/mint prototype (automated verification) — no longer the target architecture — prototyped and tested on a local development chain only. Design in development · not active · not ready for production.

1 · SOST → wSOST

A transaction hash typed by a user is only used to search or recover; it is never treated as proof. The engine always re-reads the SOST chain.

Who pays what

All costs are shown before you confirm. Nothing about the bridge is free, and it is never described as free.

Do I need MetaMask?

You need an Ethereum wallet that can sign the mint transaction and hold XAUT and a little ETH for gas: MetaMask, Rabby, a hardware wallet or any EVM wallet. The wSOST recipient can be another address, but only one you control or one that explicitly supports wSOST.

2 · wSOST → SOST

If an exchange lists wSOST

An exchange that supports the wSOST ERC-20 does not have to integrate the SOST chain first, and anyone who holds wSOST — including wSOST bought on an exchange — can use the return path. Only send wSOST to an exchange that explicitly supports wSOST deposits; tokens sent to an address that does not credit them can be lost.

So, once the bridge is liquid and freely usable, the wSOST market price is expected to become a market reference for native SOST. Prices are not guaranteed identical: bridge risk, fees, liquidity, access restrictions and finality delays can create temporary premiums or discounts. A large, persistent gap would mean wrapping is not freely available or the bridge is impaired.

The Genesis Gold Vault is the conceptual ancestor of Gold Reserve V2 — a rule-bound reserve with one purpose and public accounting — but it is not the same reserve. It accumulated SOST; Gold Reserve V2 would hold tokenized gold. Historical Gold Vault ≠ Gold Reserve V2.

A new, external reserve on Ethereum. It receives tokenized gold — not newly emitted SOST — and it never mints wSOST. In the C701 design it is funded by the Gold Access Key of completed bridge operations (plus voluntary contributions); its balance and every deposit are verifiable on Ethereum, and it provides no liquidity.

What the reserve means — and what it does not

A proposed use for the XAUT collected by the Gold Access Key: periodically buy wSOST back from the market and take the same amount of native SOST out of circulation forever. Ordinary users of the SOST Atomic Bridge are not affected: entering and leaving keep working exactly as described above (wSOST from and back to the inventory, no mint, no burn).

How it would work — option A (chosen): permanent immobilization, no burn

Option A keeps the founding rule of the SOST Atomic Bridge: wSOST is issued once and its total supply never changes. The retired wSOST still exist on Ethereum, but they sit in a contract with no way out, and they are counted separately from the ordinary inventory. (Option B — really burning them and reducing totalSupply() — was considered and not chosen.)

Example — one year retires 10,000 SOST

The order is fixed: first the wSOST are final in the retired inventory, then the native SOST move. If the second step is delayed, what remains is a public, pending obligation to immobilize — never wSOST circulating without backing.

The SOST Dead Vault

The Dead Vault immobilizes SOST, it does not burn it: the emission schedule and the 4,669,201 hard cap are untouched. An address “with no known key” would not give the same guarantee, which is why it needs a consensus rule.

What it needs — and what it does not promise

Earlier versions of this page described the treasury Gold → wSOST desk and a federated observer architecture. They were never operational and are not the target architecture; C701 replaced them with automated verification, and on 26 Oct 2026 the target became the SOST Atomic Bridge. They are listed here so the history stays readable.

Controls built into the design

Native custody today

SOST native multisig is not active (library code; planned for V17). The Bridge Vault could therefore only be a single cold key with offline signing, and releases would not be automatic. Deployment is blocked until custody can guarantee a safe, tested recovery.

Open blockers — all must be closed before any activation

Stronger proofs later — without a federation

• SOST header relay with Merkle inclusion proofs on Ethereum (SPV-style), likely optimistic with a challenge window, since verifying ConvergenceX itself on-chain is impractical;
• succinct (zero-knowledge) proofs of SOST chain validity — long-term research;
• delay and veto window for large mints;
• threshold signing inside the operator and native SOST multisig for the vault.

The SOST Atomic Swap is a separate peer-to-peer service. It does not offer SOST ↔ wSOST, charges no Gold Access Key and does not use Gold Reserve V2. The SOST Atomic Bridge would use the same native HTLC primitive, but against the bridge’s own wSOST inventory and native reserve; the two services stay separate.

The basic invariant is wSOST.totalSupply ≤ confirmed native SOST backing. That inequality is necessary but not sufficient: a deposit minted twice and a release paid twice can cancel out in the balance. So the indexer reconciles every deposit id, mint, burn and release separately. The SOST side is derived from the SOST chain; the Ethereum side from Ethereum; the browser is never the source of truth.

A failure is shown, never hidden. Transfers of existing wSOST continue while minting is paused.

Critical rescue example

Final migration — every key at the same time

The proposal is frozen before anyone votes

Miners do not vote on "should we move the gold?" — they vote on one exact instruction. If any material field changes, the old vote is invalid and a new proposal and a new vote are required.

Who can vote

The vote is a normal SOST transaction from the eligible identity to itself, carrying the choice in a capsule (28 of the verified 80 bytes). Because it spends from that identity, chain validation itself proves control of the private key — no new message-signing tool is needed. The website never asks for a private key, seed phrase, wallet file or password, and it does not run a central poll: the votes are on the SOST blockchain, and anyone can recount them.

Status panel — example

Advisory first, binding later

No proposal is open, so this checks your mining identity against the current Jackpot V2 participation framework — the base of the planned voter census — using the chain-derived participation index. Binding age is still under research.

If a future wallet integration exists, it would build the vote transaction locally. This page never collects keys.

wSOST, Gold Reserve V2 and governance are part of this research horizon. Unlike the 80/15/5 scenario, they need no SOST consensus change: they would run on Ethereum and on existing SOST capsules, behind their own engineering, audit and legal gates.

One Proof of Work, two control dials. ConvergenceX defines the work of every attempt. bitsQ sets how rare a winning commit must be (every block; 288-block average; ±15 s dead band; steps 0.5% / 1% / 2% / ≈3.03%). The Equalizer sets how demanding each attempt is (43 profiles E7…B0…H35 from the schedule lag) and never changes bitsQ. Full rules: Technology · comparison with examples: SOST vs Bitcoin vs Ethereum.