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
👁 WATCH ONLY — Send disabled
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)
No UTXOs found
Send SOST
Construct and broadcast a transaction
Single tx, all recipients atomic. Capsule disabled when >1 recipient.
Estimating fee...
0 / 80
SEALED CAPSULE — Prepared for V13 @ block 12,000
Sealed Capsule is single-recipient only and needs the recipient's
public key (not their address). The address contains
hash160(pubkey); the pubkey itself must be supplied
separately. Paste it below as 66 hex characters
(02… or 03…).
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-001Visibility: 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.
Your Seed Phrase
⚠ READ BEFORE REVEALING THE SEED PHRASE
- The 12 words are the only way to recover your funds if you lose this device.
- Write them on physical paper, in order. Verify each word twice.
- NEVER take a photo. NEVER paste them in chat / email. NEVER store them in cloud notes.
- Anyone who reads these 12 words can move every SOST you own.
Write these words down and store them safely. This is the only way to recover your wallet. Never share your seed phrase with anyone.
Address
Import Wallet
Import from seed phrase, private key, or encrypted backup
From BIP39 Seed Phrase
From Private Key (Hex)
From Encrypted Backup
Watch-Only Mode
Monitor an address without importing the private key. You will not be able to send transactions.
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.
Address Book
Manage trusted addresses for safer sending
Add Address
Saved Addresses
PSBT Offline Signing
Create, sign, and broadcast partially-signed transactions
Create Unsigned PSBT
Sign PSBT
Broadcast Signed PSBT
Multisig
Create and manage M-of-N multisig addresses (sost3)
Create Multisig Address
Multisig Address (sost3)
RedeemScript
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
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.
Scan this QR code with Google Authenticator, Authy, or any TOTP app
Or enter this secret key manually
2FA is Active ENABLED
A TOTP code is required for every send transaction.
Settings
Wallet configuration
RPC Endpoint
Auto-Lock
Treasury Safety Policy
Set limits to protect against accidental or unauthorized sends.
Security Guide
Step-by-step guide to securing your wallet and funds