Decentralized exchange for tokenized gold (XAUT, PAXG) with bilateral escrow settlement, ED25519 message signing, and Proof of Personal Custody contract specifications. On-chain gold backing meets trustless peer-to-peer trading.
SOST lets you hold positions backed by tokenized gold, trade them with signed private messages, and settle automatically.
1. You deposit tokenized gold (XAUT or PAXG) into an immutable escrow contract on Ethereum. No admin key on deposits — the immutable settlementOperator can update beneficiary for position transfers, but cannot withdraw funds. Only the current beneficiary can withdraw after the lock period.
2. The system registers a native SOST position with its own ID, owner, reward schedule, and expiry date. That position is now a tradeable asset inside the SOST ecosystem.
3. You can sell the entire position to someone else for SOST. You get immediate liquidity without waiting for the lock to expire.
4. Or you can sell just the reward right — keep the gold-backed principal, monetize only the future yield.
5. Trades happen through signed and end-to-end encrypted messages (ED25519 signatures + X25519 key agreement + ChaCha20-Poly1305 AEAD). Every message — offer, accept, cancel, settlement notice — has a hash, a signature, a nonce, and an expiry. No forgery. No replay. No middleman.
6. The settlement engine verifies everything automatically: valid signatures, correct owner, no double-spend, no expired offers. Then it executes the transfer and records the complete audit trail.
Angel has a Model B position: 0.5 oz of XAUT locked for 28 days, with a future reward of 2,000 SOST units. The position is valued at ~9.7 SOST.
Angel needs liquidity now. Pedro is willing to wait.
Step 1: Angel creates a signed offer: “I sell position 8afed8fc for 9.7 SOST.” The offer is signed with Angel’s ED25519 key, includes a unique nonce and expires in 1 hour.
Step 2: Pedro receives the offer through the private relay channel. He verifies the signature is valid, checks the position exists, and accepts: “I buy position 8afed8fc for 9.7 SOST.” Also signed.
Step 3: The system derives a unique deal_id from both signatures and creates the deal.
Step 4: The settlement engine verifies: Angel is the real owner, the position is active, signatures are valid, no replay. Everything checks out.
Step 5: Ownership transfers. Pedro is now the owner of position 8afed8fc. Angel receives 9.7 SOST. A settlement notice is emitted and the full history is recorded in the audit log.
Alternative: Angel could instead sell only the reward right — keeping the gold-backed principal and selling the future 2,000 SOST reward to Pedro at a discount. The system creates a “child position” for Pedro (reward only) while Angel keeps the parent (principal only).
▶ Sellers
▶ Buyers
The market exists because the same position doesn’t have the same value for everyone: some prefer money today, others prefer future value.
Constitutional Rule
The right to the principal belongs to the principal_owner. The right to the reward belongs to the reward_owner. The escrow pays to the currentBeneficiary, which must always reflect the principal_owner.
Every Model B position has two separate rights:
1. Right to the Principal
The right to recover the gold locked in the escrow at maturity. Belongs to principal_owner.
2. Right to the Reward
The right to receive the SOST reward at maturity. Belongs to reward_owner. Can be sold separately.
| COMPONENT | STATUS | FUNCTION |
|---|---|---|
| Settlement Engine | Operational | Verifies signatures, executes transfers, updates ownership |
| E2E Relay | Operational | Encrypted coordination, blind transport, offline delivery |
| Position Registry | Operational | Tracks principal_owner, reward_owner, lifecycle |
| Maturity Tracker | Operational | Monitors unlock times, detects maturity |
| SOSTEscrow v1 | Deployed (Sepolia) | Immutable lock, pays original depositor only |
| SOSTEscrow v2 | Implemented | Adds currentBeneficiary — pays whoever owns the principal |
| Auto-Withdraw Daemon | Implemented | Calls withdraw() automatically at maturity |
| Reward Engine | Implemented | Automatically credits reward SOST to reward_owner |
Decentralized peer-to-peer exchange for tokenized gold assets
Core configuration for the SOST DEX bilateral exchange engine. All trades settle through peer-to-peer escrow with no central counterparty.
| Parameter | Value | Description |
|---|---|---|
| Trading Pairs | SOST/XAUT, SOST/PAXG | Tokenized gold pairs only |
| Settlement Mode | Bilateral Escrow | Both parties lock funds before settlement |
| Message Signing | ED25519 | All trade messages cryptographically signed |
| ETH Confirmations | 6 | Required confirmations for ETH-side locks |
| Deal Expiry | 3,600 s | Unmatched offers expire after 1 hour |
| Daemon Tick | 5 s | Trade engine polling interval |
| ETH Watcher | 15 s | Ethereum chain polling interval |
| Token | Decimals | Backing | Standard |
|---|---|---|---|
| XAUT (Tether Gold) | 6 | 1 token = 1 troy oz = 31,103 mg | ERC-20 |
| PAXG (Paxos Gold) | 18 | 1 token = 1 troy oz = 31,103 mg | ERC-20 |
All messages are ED25519-signed and relayed via the SOST E2E encrypted protocol. Each message type drives the deal state machine forward.
| Message Type | Direction | Payload | Effect |
|---|---|---|---|
trade_offer | Maker → Network | pair, side (buy/sell), amount, price, expiry | Creates deal in CREATED state |
trade_accept | Taker → Maker | offer_id, taker_pubkey, taker_eth_address | Transitions to NEGOTIATED |
trade_cancel | Either → Either | deal_id, reason | Transitions to EXPIRED (if pre-lock) |
settlement_notice | Either → Either | deal_id, eth_txid, sost_txid, proofs | Transitions to SETTLED |
Every deal progresses through a deterministic state machine. The happy path flows left-to-right; alternative flows handle failures and disputes.
| State | Description | Timeout |
|---|---|---|
| CREATED | Offer broadcast, awaiting taker | 3,600 s |
| NEGOTIATED | Taker accepted, exchanging lock addresses | 600 s |
| AWAITING_ETH_LOCK | Waiting for gold token lock on Ethereum (6 confirmations) | 1,800 s |
| AWAITING_SOST_LOCK | ETH confirmed, waiting for SOST escrow lock | 1,200 s |
| BOTH_LOCKED | Both sides locked, ready to settle | 3,600 s |
| SETTLING | Settlement transactions broadcast | 1,800 s |
| SETTLED | Both sides confirmed, deal complete | — |
| EXPIRED | Deal timed out at any pre-lock stage | — |
| REFUND_PENDING | One side locked, other failed; initiating refund | 7,200 s |
| REFUNDED | Locked funds returned to original party | — |
| DISPUTED | Settlement proof mismatch, requires resolution | — |
Step-by-step bilateral escrow settlement between maker and taker. All steps are cryptographically verified via ED25519 signatures.
Step 1: OFFER Maker broadcasts trade_offer (pair, amount, price, expiry) Signed with maker's ED25519 key Deal enters CREATED state Step 2: ACCEPT Taker sends trade_accept (offer_id, taker_pubkey, taker_eth_address) Signed with taker's ED25519 key Deal enters NEGOTIATED state Step 3: ETH LOCK Gold-side party locks XAUT/PAXG in Ethereum escrow contract ETH Watcher polls every 15s for confirmation After 6 ETH confirmations: deal enters AWAITING_SOST_LOCK Step 4: SOST LOCK SOST-side party creates SOST escrow transaction (OUT_ESCROW_LOCK) Transaction confirmed on SOST chain Deal enters BOTH_LOCKED state Step 5: SETTLEMENT Both parties release escrow to counterparty addresses ETH escrow releases gold tokens to buyer SOST escrow releases SOST to seller Deal enters SETTLING state Step 6: NOTICE Both parties broadcast settlement_notice with tx proofs ETH Watcher confirms gold token transfer (6 confirmations) SOST node confirms SOST transfer Deal enters SETTLED state (final)
Position valuation combines spot gold backing with time-discounted future rewards from PoPC contracts. This provides a fair-value reference for DEX trades.
position_value = gold_backing + time_discounted_rewards - illiquidity_discount gold_backing = oz_held * spot_gold_price reward_component = annual_rate * remaining_term * gold_backing illiquidity = 3% * gold_backing Model A: 12%/yr reward rate (self-custody, higher risk/reward) Model B: 5%/yr reward rate (escrow, lower risk/reward) Illiquidity discount: 3% (compensates for lock-up period)
gold_backing = 1 oz * $2,400 = $2,400 reward_component = 12% * 0.5yr * $2,400 = $144 illiquidity = 3% * $2,400 = -$72 position_value = $2,400 + $144 - $72 = $2,472
Proof of Personal Custody — on-chain gold backing with verifiable reserves
Two custody models serve different risk profiles. Model A rewards self-custody with higher yields; Model B offers simplicity through immutable escrow.
| Attribute | Model A (Self-Custody) | Model B (Escrow) |
|---|---|---|
| Gold Location | User's own ETH wallet (EOA) | Immutable EVM escrow contract |
| Bond Required | Yes (20-30% of gold value in SOST) | No bond required |
| Reward Payout | Periodic from PoPC Pool | Immediate from PoPC Pool |
| Protocol Fee | 3% | 8% |
| Audits | Random, entropy-based | None (escrow is self-proving) |
| Slash Risk | Yes — 50% PoPC Pool + 50% Gold Vault | None |
| Reward Floor | ≥ 1% (min 10 SOST) | ≥ 0.5% (min 5 SOST) |
| Hard Cap | 1,000 SOST per contract · 1,000 max active contracts | |
| Durations | 1 / 3 / 6 / 9 / 12 months | 1 / 3 / 6 / 9 / 12 months |
| Blacklist | Blacklisted after 3 slashes | |
Annualized reward rates scale with lock duration. Longer commitments earn higher yields. All rates are percentages of gold value, paid in SOST from the PoPC Pool.
| Duration | Model A Rate | Model B Rate |
|---|---|---|
| 1 month | 1% | 0.4% |
| 3 months | 4% | 1.5% |
| 6 months | 9% | 3.5% |
| 9 months | 14% | 5.5% |
| 12 months | 20% | 8% |
Model A requires a SOST bond proportional to gold value. The bond percentage decreases as the SOST/gold ratio increases, incentivizing larger positions while managing protocol risk.
| Ratio (bps) | Bond % | Description |
|---|---|---|
| < 100 bps | 25% | Low ratio — maximum bond requirement |
| 100 – 500 bps | 20% | Standard ratio |
| 500 – 1,000 bps | 15% | Elevated ratio |
| 1,000 – 5,000 bps | 12% | High ratio |
| ≥ 5,000 bps | 10% | Maximum ratio — minimum bond |
The ratio is calculated as (sost_value_usd / gold_value_usd) * 10000 in basis points. Higher SOST-to-gold ratios indicate greater protocol coverage, allowing reduced bond requirements.
To prevent concentration risk and ensure broad participation, the protocol applies acceptance limits based on gold position size.
| Gold Amount (oz) | Acceptance Rate | Effect |
|---|---|---|
| 0 – 10 oz | 100% | Always accepted |
| 10 – 50 oz | 75% | Reduced acceptance |
| 50 – 200 oz | 50% | Half acceptance rate |
| > 200 oz | REJECTED | Position too large — must split |
Rewards adjust dynamically based on total protocol participation to maintain sustainable yield from the PoPC Pool.
PUR = active_contracts / max_contracts
= active_contracts / 1000
dynamic_factor = participation_tier_multiplier(PUR)
effective_rate = base_rate * dynamic_factor
| Active Contracts | PUR Range | Dynamic Factor | Effect |
|---|---|---|---|
| 0 – 25 | 0 – 2.5% | 100% | Full rewards (bootstrap phase) |
| 26 – 50 | 2.6 – 5% | 75% | Slight reduction |
| 51 – 100 | 5.1 – 10% | 50% | Moderate reduction |
| 101 – 200 | 10.1 – 20% | 30% | Significant reduction |
| 201 – 500 | 20.1 – 50% | 15% | Heavy reduction |
| 501 – 1,000 | 50.1 – 100% | 8% | Minimum factor (high utilization) |
Example: With 150 active contracts (PUR = 15%), a Model A 12-month base rate of 20% becomes: 20% * 30% = 6% effective annualized rate.
Model A custodians build reputation through successful audits. Higher reputation reduces audit frequency, rewarding honest behavior.
| Stars | Status | Audit Probability | Requirements |
|---|---|---|---|
| 0 | New | 30% | Initial state for all custodians |
| 1 | Established | 20% | 1 successful audit cycle |
| 3 | Trusted | 10% | 3 consecutive successful audits |
| 5 | Exemplary | 5% | 5 consecutive successful audits |
Audit entropy: SHA256(block_id || commit || checkpoints_root) Audit grace: 288 blocks (48 hours) Slash penalty: 50% to PoPC Pool + 50% to Gold Vault Blacklist: After 3 slashes (permanent ban from Model A)
Audit challenges are derived from ConvergenceX entropy (block_id, commit, checkpoints_root), making them unpredictable and tamper-proof. Custodians have a 288-block (48-hour) grace period to respond to an audit challenge before being slashed.
Constitutional governance rules for the Gold Vault. These rules are immutable and enforced at consensus level.
| Rule | Name | Description |
|---|---|---|
| GV1 | Accumulation Only | Gold Vault funds may only be used to purchase physical gold or tokenized gold (XAUT, PAXG). No other expenditures permitted. |
| GV2 | Transparent Accounting | Every Gold Vault transaction must include an on-chain memo referencing the gold acquisition (weight, purity, custodian, or token contract address). |
| GV3 | Multi-Signature Requirement | Gold Vault disbursements require multi-signature authorization. No single key can move Gold Vault funds. |
| GV4 | Quarterly Proof of Reserves | The protocol must publish a quarterly proof-of-reserves report linking on-chain Gold Vault balances to verifiable gold holdings (physical receipts or Ethereum token balances). |
Hardcoded protocol addresses receiving 25% each of every block reward. These are immutable and enforced by consensus rules CB4 (output order) and CB6 (PKH validation).
| Role | Address | Allocation |
|---|---|---|
| PoPC Pool | sost1d876c5b8580ca8d2818ab0fed393df9cb1c3a30f | 25% of every block reward |
| Gold Vault | sost11a9c6fe1de076fc31c8e74ee084f8e5025d2bb4d | 25% of every block reward |
The remaining 50% goes to the miner who solves the block. The PoPC Pool funds all custody rewards (Model A and Model B). The Gold Vault accumulates funds exclusively for gold acquisition under GV1–GV4 governance rules.
q = (subsidy + fees) / 4 miner = (subsidy + fees) - 2*q // 50% + rounding remainder gold_vault = q // 25% → sost11a9c6fe1de... popc_pool = q // 25% → sost1d876c5b85...