POPC_DEX_ENABLED=false) and not part of V15. PoPC is a non-tradeable native SOST bond — see PoPC Bond Staking. This surface is being converted into non-custodial swap & OTC coordination (signed offers, encrypted deal channels).Non-custodial peer-to-peer swaps for tokenized gold (XAUT, PAXG) and SOST, settled with on-chain HTLC / smart-contract escrow. OTC coordination runs on signed offers (ED25519) and encrypted deal channels (X25519) — SOST never custodies funds. PoPC is a separate, non-tradeable native SOST bond — see PoPC Bond Staking.
SOST lets two parties agree a swap with signed private messages and settle it non-custodially through on-chain HTLC / smart-contract escrow — SOST never holds your funds.
1. A maker publishes a signed swap offer — for example, tokenized gold (XAUT or PAXG) for SOST, or SOST for an EVM asset. The offer carries a price, an amount, a unique nonce and an expiry, and is signed with the maker’s ED25519 key.
2. Counterparties discover the offer over OTC coordination. There is no order book that custodies anything — the offer is just a signed message describing the swap each side will execute.
3. A taker accepts the offer with their own signed message. Both signatures derive a unique deal, and the two sides open an encrypted deal channel.
4. Each side locks its asset in escrow — an on-chain HTLC / smart-contract escrow on the EVM side and a SOST escrow lock on the SOST side. No party can take the other’s funds without revealing the matching secret.
5. Coordination happens 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, both legs locked, no double-spend, no expired offers. The atomic swap either completes for both sides or refunds both sides — never one-sided.
Angel holds 0.5 oz of XAUT and wants SOST. Pedro holds SOST and wants gold exposure. They agree a non-custodial atomic swap at ~9.7 SOST.
Step 1: Angel creates a signed offer: “I swap 0.5 oz XAUT 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 encrypted deal channel. He verifies the signature is valid and accepts: “I swap 9.7 SOST for 0.5 oz XAUT.” Also signed.
Step 3: The system derives a unique deal_id from both signatures and creates the deal.
Step 4: Each side locks its leg in escrow — Angel locks XAUT in the on-chain HTLC / smart-contract escrow, Pedro locks SOST in the SOST escrow. The settlement engine verifies both legs, signatures and timing.
Step 5: The atomic swap settles. Pedro receives the XAUT, Angel receives 9.7 SOST. A settlement notice is emitted and the full history is recorded in the audit log. If either leg fails, both sides are refunded.
Note: This is a swap of assets each party already holds — not the trading of PoPC staking contracts or reward rights. PoPC is a separate, non-tradeable native SOST bond; see PoPC Bond Staking.
▶ Makers
▶ Takers
The DEX exists so two parties can swap assets they already hold — non-custodially, atomically, without a central counterparty.
POPC_DEX_ENABLED=false) and not part of V15. Retained for reference only.Historical rule (Model B)
The right to the principal belonged to the principal_owner. The right to the reward belonged to the reward_owner. The escrow paid to the currentBeneficiary, which always reflected the principal_owner.
In the historical Model B design, every position had 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 |
Non-custodial peer-to-peer swaps for tokenized gold and SOST — signed offers, encrypted deal channels, on-chain HTLC / smart-contract escrow
Core configuration for the SOST Atomic Swap DEX engine. All swaps settle non-custodially through peer-to-peer on-chain HTLC / smart-contract escrow with no central counterparty — SOST never custodies funds.
| Parameter | Value | Description |
|---|---|---|
| Swap Pairs | SOST/XAUT, SOST/PAXG | Tokenized gold pairs only |
| Settlement Mode | Non-custodial HTLC Escrow | Both parties lock their own leg before atomic 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 swap messages are ED25519-signed and relayed via encrypted deal channels (SOST E2E protocol). Each message type drives the deal state machine forward. Offers describe a swap each side executes from its own custody — not the trading of PoPC positions or reward rights.
| 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)
POPC_DEX_ENABLED=false), so this is a reference model only — superseded by the single native SOST bond (PoPC Bond Staking). For atomic swaps, price is simply the rate the two parties sign into their offer.For reference, the historical model combined spot gold backing with time-discounted future rewards from PoPC contracts.
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
The DEX ships with a browser-side Copilot stack that helps the user compose swap offers, understand deals and avoid common mistakes. The copilot is advisory only — it never signs transactions, never moves funds and never updates ownership state. Sensitive actions still require the user's session unlock and (when configured) a passkey re-authentication.
| Module | File | Role |
|---|---|---|
| Intent Parser | js/dex-intent-parser.js | Parses natural language (EN + ES) into structured swap intents (pair, side, amount, price, expiry). |
| Form Assistant | js/dex-ai-assistant.js | Fills the Swap Composer / OTC form from a parsed intent and renders an explicit "what the assistant understood" review layer before any submission. |
| Deal Explainer | js/dex-ai-explainer.js | Explains what a swap does in plain language — which leg locks on SOST, which leg locks on the EVM side, and what each party receives at atomic settlement. |
| Risk Guardian | js/dex-ai-validator.js | Validates intents and detects problems before the user confirms. Warnings are classified INFO, WARNING or BLOCKING. BLOCKING warnings prevent the form from being submitted. |
| Compare Helper | js/dex-ai-compare.js | Compares swap alternatives: different rates, expiries and counterparties. |
| Lifecycle Guide | js/dex-ai-lifecycle.js | Explains deal lifecycle state and available actions (offer, accept, lock, atomic settle, refund). |
| Swap Engine | js/dex-trade-engine.js | Builds offers from form data, signs with ED25519, encrypts with ChaCha20-Poly1305 via channel keys, submits to the blind relay. |
| Session Manager | js/dex-session.js | Manages unlock / lock / timeout. Bridges the keystore with the DEX UI and relay. |
| Onboarding Glue | js/dex-onboarding.js | Connects all Phase A+B+C modules to the DEX page UI — public/private mode, wallet panel, AI assistant box, inbox, error/empty states. |
| Severity | Effect | Examples |
|---|---|---|
INFO | Shown but does not block submission. | Offer expires soon; counterparty has not locked its leg yet. |
WARNING | Shown prominently; user must acknowledge. | Rate deviates significantly from reference; short HTLC timeout relative to confirmation time. |
BLOCKING | Submission is disabled until the user fixes the issue. | Signature invalid; expired offer; reused nonce; insufficient balance to lock the leg; trying to publish a guarantee-style claim. |
Browser keystore: IndexedDB + Argon2id passphrase encryption Signing: ED25519, generated and stored locally Encryption: X25519 key agreement + ChaCha20-Poly1305 AEAD Strong auth: WebAuthn passkey for sensitive actions Auto-lock: 5 min idle timeout Re-auth gate: sign offer, accept deal, export identity
| Guarantee | Scope |
|---|---|
| The AI Copilot never signs a transaction on its own. | All signatures originate from a user-initiated unlock + (optional) passkey re-auth. |
| The Copilot never moves funds. | Each party locks its own leg in the on-chain HTLC / smart-contract escrow and on the SOST chain via standard OUT_ESCROW_LOCK transactions. SOST never custodies funds. |
| The Copilot never settles on your behalf. | Atomic settlement is driven by the matching HTLC secret and valid signed messages, not by the browser copilot. |
| Private keys never leave the device. | Keys live in IndexedDB encrypted with Argon2id. WebAuthn returns yes/no signals only. |
| The relay never sees plaintext deals. | Trade messages are end-to-end encrypted before reaching the relay; the relay performs blind transport. |
| BLOCKING warnings cannot be bypassed silently. | The Risk Guardian disables the submit path when a BLOCKING flag is raised; the user must address the cause. |
- It does not trade autonomously. - It does not create or fund liquidity pools. - It does not guarantee price, liquidity, or settlement timing. - It does not call paid third-party AI models. - It does not call external network services from the trade flow. - It does not bypass the Risk Guardian on BLOCKING flags. - It does not relax public-claim wording (no "trustless" promotion while alpha is operator-assisted).
This module set is the operational AI layer of the DEX. The off-chain SOST AI Engine is a separate internal research system; it does not run inside the DEX page and does not have access to keys, beneficiaries or signed messages.
Historical Model A / Model B design — superseded by the single native SOST bond (PoPC Bond Staking)
Historical reference. Two custody models once served different risk profiles — Model A rewarded self-custody with higher yields; Model B offered simplicity through immutable escrow. Both are superseded by the single native SOST bond (PoPC Bond Staking) and are shown here for reference only.
| 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 rewards 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...