SOST Wallet

Welcome to SOST Wallet

Client-side wallet — your private keys never leave this device.

Get Started

Create a new wallet or import an existing one to begin.

Security Notice: This wallet runs entirely in your browser. Private keys are encrypted with AES-256-GCM before storage. The wallet auto-locks after 5 minutes of inactivity. Always back up your seed phrase.

Dashboard

Not loaded

Balance

0.00000000SOST

0 UTXOs

Recent Transactions

No transaction history

Decrypt Sealed Capsule

Paste a TXID below to attempt decryption with the keys in this wallet. Only sealed capsules (types 0x02 / 0x04 / 0x06) addressed to one of your addresses will open. Plaintext is rendered in memory only and is wiped when you lock or end the session.

▸ Show UTXOs (advanced)

Send SOST

Construct and broadcast a transaction

Recipient Address

Amount (SOST)

Single tx, all recipients atomic. Capsule disabled when >1 recipient.

Fee Mode

Estimating fee...

Message Type (Capsule Protocol)

Mark as Protocol Registry entry

Builds a sost-protocol capsule using Open Note. Entries signed by whitelisted SOST Protocol addresses appear under “Official Protocol Registry”; entries from other wallets appear under “Community Capsules”. The wallet imposes no whitelist — anyone with SOST can publish. View the Registry →

Recommended for APP rewards distributions: use Structured Data. Suggested category: APP rewards distribution — verified settlement. Public, auditable, accounting-grade metadata on-chain.

1. None — No capsule attached No payload

Use when the transaction does not need any note, document reference, receipt, or certification.

Visibility: no extra data is attached.

2. Open Note — Public short note Public

Adds a short public message to the transaction. Everyone can read it on-chain. Use for simple labels such as APP rewards payout, Invoice payment, or Donation.

Input: plain text, max 80 characters.

Visibility: public clear text.

Do not include private information.

3. Sealed Note — Private encrypted note Private / encrypted

Adds an encrypted message readable only by the recipient. Uses ECIES over secp256k1 with AES-256-GCM. Use for private payment notes, internal references, or confidential descriptions.

Input: message text and the recipient address.

Visibility: the chain stores encrypted bytes, not readable text.

Recipient: must be able to decrypt with their wallet key.

Only the recipient with the matching private key can decrypt it.

4. Document Reference — Public document reference Public

Links the transaction to an external document by storing its hash and an optional URL or IPFS link. Use for invoices, PDFs, agreements, delivery notes, reports, or public proofs.

Input: document hash + optional URL or IPFS CID.

Visibility: the reference is public.

Do not link private documents unless they are meant to be public.

5. Sealed Document Reference — Private document reference Private / encrypted

Stores an encrypted document reference. Only the recipient can read the URL/IPFS link or document metadata. Use for private invoices, confidential files, private delivery notes, or internal documents.

Input: document hash + private reference/link.

Visibility: encrypted on-chain reference.

Recipient: must be able to decrypt with their wallet key.

The document itself must still be stored securely outside the chain.

6. Structured Data — Public receipt / invoice Public

Adds structured public fields to the transaction, such as invoice ID, order ID, period, service, amount note, or payout category. Use for accounting, APP rewards, public receipts, business payments, and reward distributions.

Example: type=APP rewards distribution; period=2026-05; ref=batch-001

Visibility: public structured data.

Do not include personal or confidential details.

7. Sealed Structured Data — Private receipt / invoice Private / encrypted

Adds structured invoice/receipt fields encrypted for the recipient only. Use when the transaction needs accounting metadata but the details should remain private.

Input: invoice fields, order reference, period, service, or private payout details.

Visibility: encrypted structured data.

Recipient: must be able to decrypt with their wallet key.

Keep your own backup if this data is needed for accounting.

8. Certification — Public proof / cert Public

Attaches a public certification-style capsule to the transaction. Use for gold certificates, warranty proofs, authenticity proofs, custody proofs, audit references, or formal attestations.

Input: certificate ID, issuer, proof hash, optional public reference.

Visibility: public proof data.

This records a proof/reference. It does not automatically verify the real-world truth of the document unless the issuer and hash can be checked.

✓ Capsule modes wired in this wallet: Open Note (≤80 B), Structured Data (≤128 B fields under one of 10 templates, default payment_receipt_v1) and Certification (≤64 B note) broadcast with the payload signed into the sighash. Sealed Note and Sealed Structured Data are wired from V13 (block 12,000) with single-recipient ECIES (secp256k1 ECDH + HKDF-SHA256 + AES-256-GCM) verified byte-for-byte against the C++ envelope. Document Reference and Sealed Document Reference still bridge to sost-cli — the file picker UI is on the roadmap. Capsule attach requires chain height ≥ V12 (block 7,350); sealed modes also require chain height ≥ V13 (block 12,000) and a recipient compressed pubkey whose hash160 matches the recipient address.

1. Fee-pass converging loop

The wallet does NOT pre-estimate the fee from a guess at the input count. After you click Send it builds a tx with a seed fee, reads the signed raw size, recomputes fee = txSize × feePerByte, and rebuilds. Up to 4 passes plus a final exact-fee rebuild so the confirm dialog shows the exact bytes that go on the wire. Refuses to broadcast if it cannot converge (you would otherwise be rejected with consensus rule S8).

2. In-flight UTXO tracking

Once a tx is built and the user confirms, the wallet reserves the selected UTXOs in a per-address Map persisted in localStorage with a 5-min TTL. A second Send fired seconds later cannot re-pick those inputs and double-spend. If the broadcast fails, the reservation releases immediately so retry works. refreshBalance reconciles: any reservation whose UTXO the node no longer reports (mined or rejected) is dropped automatically.

3. Auto-split when capsule payment is too large

When a single-recipient send with a capsule converges to a signed tx larger than the 16 KB policy cap (typical case: hundreds of small UTXOs), the wallet offers to break the amount into N smaller transactions to the same recipient, each carrying the same capsule, broadcast sequentially. Default chunk 150 SOST. The proposal lists the exact amounts; the chunk-sum invariant is enforced (no overpay, no underpay) and a self-test runs at script load to catch regressions.

4. Sealed Capsule decrypt panel

The dashboard has a Decrypt Sealed Capsule card. Paste a txid; the wallet calls gettransaction, walks every output's payload_hex, filters those with sealed type (0x02 / 0x04 / 0x06), and tries to open each envelope with the wallet's active privkey. Gold callout for opened plaintext; grey chip for “not for this wallet”. Plaintext lives in DOM only — lockWallet wipes it; nothing is written to localStorage / sessionStorage / console.

5. Multi-recipient sends

Add more than one recipient row → the wallet routes to sendmany: a single transaction with N payment outputs and one change output, atomic broadcast, capped at 100 KB consensus. Multi-recipient + capsule is intentionally rejected: the V13 contract is one capsule per single-recipient tx (auto-split handles “same recipient, multiple tx with the same capsule”). For different capsules to different recipients, send them as separate single-recipient txs.

6. RPC mode awareness

The RPC bar at the top tags the active endpoint: LOCAL NODE (http://127.0.0.1:18232), READ ONLY (/rpc/public) or AUTH REQUIRED (/rpc). A read-only endpoint cannot accept a broadcast, so the wallet refuses to sign + send before any key material is exercised. Click the ? next to CONNECT for the full clarification of what each endpoint does.

7. Re-entrancy guard

A double-click on Send (or pressing Enter twice quickly) used to spawn two parallel async builds; the in-flight set caught them but the user got a confusing race. The wallet now sets window._sendInProgress = true as the very first thing in sendTransaction and clears it in an outer finally. A second click while a send is mid-flight shows “A transaction is already being broadcast. Wait for it to finish.” instead of starting a parallel attempt.

Reference docs: sost-transactions.html — Sending Capsule Transactions · Wallet & backup security.

Coin Selection: Uses smallest-first UTXO selection. Change is returned to your address. Transaction is signed client-side and broadcast via RPC.

Receive SOST

Share your address to receive funds

Your Address

No wallet loaded

Generate New Wallet

Create a new SOST wallet with a BIP39 seed phrase

Set Password

Your wallet will be encrypted with AES-256-GCM. Minimum 8 characters.

Password

Confirm Password

Import Wallet

Import from seed phrase, private key, or encrypted backup

From BIP39 Seed Phrase

Seed Phrase (12 or 24 words)

Password

Backup Wallet

Export an encrypted wallet backup

Download Encrypted Backup

Your wallet is encrypted with AES-256-GCM. The backup file can be imported using the Import tab.

Reference: Wallet & backup security — what's encrypted, what's not, when to upload to cloud, and how to restore.

Reveal Seed Phrase

Enter your password to reveal the seed phrase.

Password

Address Book

Manage trusted addresses for safer sending

Add Address

Address

Label

Trust Level

Visibility

Private labels stay in this browser's storage. Public labels are official, shipped with the wallet, and shown to all users (and survive a fresh/incognito session).

Saved Addresses

PSBT Offline Signing

Create, sign, and broadcast partially-signed transactions

Create Unsigned PSBT

Recipient Address

Amount (SOST)

Sign PSBT

Broadcast Signed PSBT

Multisig

Create and manage M-of-N multisig addresses (sost3)

Create Multisig Address

Required Signatures (M)

Total Signers (N)

Public Keys (one per line, 66 hex chars each)

Co-Sign Multisig PSBT

Proof of Personal Custody

Bond your SOST to prove custody of real gold (XAUT/PAXG)

How It Works

1. You hold XAUT or PAXG in your Ethereum wallet

2. You lock a SOST bond (12-30% of gold value) on the SOST chain

3. Random audits verify your gold balance via Ethereum RPC

4. If you maintain custody: bond returned + reward (up to 20%, dynamic tiers)

5. If you sell your gold: bond is slashed automatically

Your gold NEVER leaves your wallet. Only the SOST bond is at risk.

Register for PoPC

Your Ethereum Address (holding XAUT/PAXG)

Declared XAUT (oz)

Declared PAXG (oz)

Commitment Period

Enter gold amounts above to see bond calculation.

Reward Table

Duration	Reward % (of bond)	Annualized
1 month	1%	12%
3 months	4%	16%
6 months	9%	18%
9 months	14%	18.7%
12 months	20%	20%

Rates are Tier 1 maximums (first 25 contracts). Dynamic participation tiers reduce rates as contracts grow. Hard cap: 1,000 SOST/contract. Anti-whale tiers above 10 oz. Protocol fee: 3% (Model A) / 8% (Model B). Bond returned on completion.

Important: PoPC is a voluntary commitment protocol, NOT a yield product. Bond slashing is automatic if custody fails. Reward rates may be adjusted. This is not financial advice.

Two-Factor Authentication

TOTP-based 2FA for transaction signing

Setup TOTP

Add an extra layer of security. A 6-digit code will be required for every send transaction.

GeaSpirit Access — Sign Message

Prove control of your address (and your SOST holding) without ever sending your private key.

⚠ Only sign messages you understand. Signing proves you control this address. Your private key never leaves this browser; nothing is sent to any server.

Message (paste the exact text GeaSpirit gives you)

Output = address + compressed pubkey + DER signature over SHA-256(message). Paste it into GeaSpirit → "Unlock with SOST". Nothing here is stored or transmitted.

SOST Gateway

One door for SOST: prove holdings, pay, guarantee, and bridge liquidity. Design skeleton — inert and hidden in production.

⚠ Skeleton only. Nothing here moves funds, signs, or contacts the network. Every module is behind a feature flag that defaults to OFF. See docs/SOST_GATEWAY_WALLET_ARCHITECTURE.md.

Hold Access — prove you hold SOST

Sign a challenge; the API reads your on-chain balance and unlocks access. No funds move, no key is sent, and the token expires so access cannot outlive your holding.

Reuses the existing GeaSpirit Access → Sign Message flow. Proof JSON:

Pay with SOST — simple send, verifiable

v1 verification: destination + amount + confirmations. (txindex is a later improvement.) The form below only builds a dummy intent and validates it — it never signs or broadcasts.

Destination (sost1…) Amount (SOST) Reference (optional)

Escrow / Guarantee — conditional lock

Lock SOST with release / refund / dispute rules (native P2SH — no new consensus). v1 produces a spec only; no redeem-script is built here.

multisig_2of3_cltv — 2-of-3 {payer, beneficiary, arbiter} + CLTV refund. Marketplace / data-room / B2B.
hashlock_timelock — preimage-before-expiry / refund-after. Event-tied & the SWAP leg.

States: . Every escrow always has a refund branch (no funds can get stuck).

Need SOST? Swap — cross-chain HTLC (advanced)

Liquidity bridge, not the checkout. v1 is a link to the Atomic Swap console; deep in-wallet integration waits for V15 / a mature SOST leg.

Pairs:

Open Atomic Swap console →

PoPC Bond Dashboard — native SOST bond · create · monitor · claim

Create PoPC Bond

Bond amount (SOST) Duration Your SOST address Ethereum EOA (future custody proof)

Base reward
—

Total at unlock
—

Unlock block
—

⚠ Only the native SOST bond is collateral and can be slashed. Gold is not collateral. Gold Boost is disabled on mainnet.

My bonds

Connect the node RPC to list your bonds (create · status · claim).

PoPC base activates at block 20,000. Gold Boost: future only. Gold Vault governance: future only.

Settings

Wallet configuration

RPC Endpoint

Node URL

RPC Username

RPC Password

Auto-Lock

Lock after inactivity (minutes)

Treasury Safety Policy

Set limits to protect against accidental or unauthorized sends.

Daily Send Limit (SOST, 0 = no limit)

Per-Transaction Limit (SOST, 0 = no limit)

Vault Mode — only send to trusted addresses

Require address book for large TXs (>100 SOST)

⚠ Export Private Key (Advanced)

For wallet migration or setting up local sBPoW mining with this address. Anyone with your private key can spend all your SOST. Prefer encrypted seed backups for normal use. Keys are decrypted only in this browser and never sent anywhere.

Security Guide

Step-by-step guide to securing your wallet and funds

SECURITY SCORE

0/10

http://127.0.0.1:18232 LOCAL NODE	Only use this if YOU run sost-node on this computer. The full URL is exactly `http://127.0.0.1:18232` — `18232` is the RPC port and there is nothing else to add after it. Read + broadcast both work; uses the `--rpc-user`/`--rpc-pass` from your own `sost-node.conf`. Do not use this if you are only browsing the website — on someone else's computer it points at their node, not yours.
/rpc/public WEBSITE · PUBLIC	Recommended — nothing to configure. The sostcore.com public node. Read AND broadcast (send) both work with no credentials and no SSH tunnel. Only signed transactions are accepted; admin RPC methods (stop, etc.) are blocked server-side. This is what most users should use.
/rpc WEBSITE · PUBLIC	Same public node as `/rpc/public` — read + broadcast, no credentials needed.

Key Storage	AES-256-GCM encrypted in browser localStorage
Key Derivation	PBKDF2 with 100,000 iterations
Auto-Lock	5 minutes of inactivity (configurable)
Memory Clearing	Private keys cleared from JS memory on lock
Network	Keys never transmitted — only signed transactions are sent
2FA	Optional TOTP (Google Authenticator compatible)
Watch-Only	Monitor addresses without importing private keys
Backup	Encrypted JSON download — AES-256-GCM

Architecture	Single self-contained HTML file
Crypto Libraries	noble-secp256k1, noble-hashes (audited, zero-dependency)
QR Generation	qrcode.js (client-side canvas rendering)
Address Format	sost1 + HASH160(compressed_pubkey)
Transaction Format	P2PKH (Pay-to-Public-Key-Hash)
RPC Endpoint	/rpc (relative, same domain)
Coin Selection	Smallest-first UTXO strategy
Signing	ECDSA secp256k1 with low-S normalization
SLIP-0044 coin_type	1869902947 (registered) · current derivation: BIP-39 mnemonic, seed = key (no BIP-32). Full BIP-44 HD path m/44'/1869902947'/0'/0/0 reserved for a future wallet version.

Dashboard

Send SOST

Receive SOST

Generate Wallet

Import Wallet

Backup

2FA (TOTP)

Settings

Wallet Locked

Welcome to SOST Wallet

Get Started

Dashboard

Recent Transactions

Decrypt Sealed Capsule

Send SOST

Receive SOST

Generate New Wallet

Set Password

Your Seed Phrase

Import Wallet

From BIP39 Seed Phrase

From Private Key (Hex)

From Encrypted Backup

Watch-Only Mode

Backup Wallet

Download Encrypted Backup

Reveal Seed Phrase

Address Book

Add Address

Saved Addresses

PSBT Offline Signing

Create Unsigned PSBT

Sign PSBT

Broadcast Signed PSBT

Multisig

Create Multisig Address

Co-Sign Multisig PSBT

Proof of Personal Custody

How It Works

Register for PoPC

Reward Table

Two-Factor Authentication

Setup TOTP

2FA is Active ENABLED

GeaSpirit Access — Sign Message

SOST Gateway

Hold Access — prove you hold SOST

Pay with SOST — simple send, verifiable

Escrow / Guarantee — conditional lock

Need SOST? Swap — cross-chain HTLC (advanced)

PoPC Bond Dashboard — native SOST bond · create · monitor · claim

Settings

RPC Endpoint

Auto-Lock

Treasury Safety Policy

⚠ Export Private Key (Advanced)

Security Guide

SECURITY SCORE