Protocol Registry

1. Compose the claim. A structured JSON object describing what is being recorded (a protocol term, a document hash, a release statement, etc.). The schema is open — the example below uses keys like registry_type, name, acronym, project, statement, evidence_links.
2. Wrap it in a capsule. The JSON is encoded into a SOST capsule using CapsuleType::TEMPLATE_FIELDS_OPEN (0x05) — an existing, audited capsule type in include/sost/capsule.h. No new capsule type needed for the first iteration. A future protocol-level PROTOCOL_CLAIM_V1 template id is documented below as a proposed extension.
3. Attach to a transaction. The capsule is attached to a normal SOST transaction. The transaction can have minimal value (dust output to self) and pays a normal network fee.
4. Sign with the publishing address. The transaction is signed by the address claiming the publication. For protocol-level claims, the SOST constitutional genesis address (or a controlled SOST Protocol address) is the most authoritative signer.
5. Broadcast and confirm. Once the transaction is included in a block, the record is permanent. Block height + block timestamp = the public proof of when the content existed.
6. Verify by anyone. Anyone can later query the transaction, extract the capsule, verify the signature against the publishing pubkey, and confirm the block height + content hash.

1. Take the txid from the registry record.
2. Query the transaction via sost-explorer.html or any SOST node RPC.
3. Verify the transaction signature against the signer pubkey. For SOST-constitutional records, the signer is the genesis-controlled address documented in the whitepaper.
4. Decode the capsule payload. Confirm capsule_type == 0x05 (or the template id documented for the record) and that the SHA-256 of the decoded payload matches the published capsule hash.
5. Confirm the block_height and block_timestamp from the block header. These are the immutable evidentiary anchors.
6. Compare the decoded JSON to any public mirror you have (whitepaper, GitHub commit, archive.org snapshot). Multiple independent records strengthen the evidentiary chain.

Proposed addition to enum class TemplateId : uint8_t in include/sost/capsule.h:

PROTOCOL_CLAIM_V1   = 0x0B,   // public timestamp / provenance record
                              // for protocol terms, document hashes,
                              // release statements; payload schema
                              // defined in this page.

Until that template id is added at consensus level, the same record is published using the existing TEMPLATE_FIELDS_OPEN (0x05) capsule type with the schema fields above. Existing capsule-aware tooling already decodes 0x05, so no new tooling is required to read these records today.

Pick in 5 seconds

Compute the SHA-256 of your manifesto file

Whatever content you want to anchor on-chain (a JSON manifesto, a PDF, a release note) needs a stable SHA-256 hash. This hash is what goes inside the capsule.

For the worked example below we use the canonical SOST Protocol PoPC manifesto already committed in the repo at website/api/sost-protocol-popc-manifesto-v1.json (publicly reachable at api/sost-protocol-popc-manifesto-v1.json).

sha256sum website/api/sost-protocol-popc-manifesto-v1.json

Full 64-hex SHA-256 of the manifesto at the time this guide was generated:

First 16 hex chars (used as the on-chain prefix, fits comfortably under the 80-byte open-note cap):

The capsule body string (max 80 bytes, three space-separated fields = namespace + record name + first 16 hex):

sost-protocol popc-manifesto 3bed02e2f5c589e4

Now pick Method A (Wallet UI — easiest) or Method B (sost-cli) below. Either produces the exact same on-chain record.

Method A — Wallet (recommended)

The wallet page lets you compose a capsule transaction without touching a terminal. The same Open Note capsule mode that sost-cli uses is exposed as a dropdown in the wallet's Compose form.

Prefer full control? The manual steps below (A.2) build the exact same capsule by hand — pick the Open Note dropdown and type the sost-protocol … line yourself.

1. Open the SOST Wallet. Go to sost-wallet.html and unlock (or import) the identity you want to sign with. For protocol-level claims this should be your SOST Protocol operator address; for personal records it can be any wallet you control.
   What you should see: the wallet sidebar shows your active address and balance. If you see a lock icon, click it and enter your password.
2. Open the Compose / Send form. Click Send in the wallet sidebar. The recipient can be your own address — a capsule does not need a real economic transfer, just the smallest valid output.
   What you should see: form fields for Recipient, Amount, Fee and a Message Type (Capsule Protocol) dropdown.
3. Pick the capsule mode. In the Message Type dropdown choose Open Note — Public text (max 80 chars). A text box appears under the dropdown.
   What you should see: a multi-line text input with a small live counter in its bottom-right corner (0 / 80).
4. Paste the capsule text. Copy the line from Step 1 above (sost-protocol popc-manifesto 3bed02e2f5c589e4 for the worked example) into the capsule text box.
   What you should see: the live counter updates to 49 / 80. If you see a red error, your line is over 80 bytes — shorten the namespace or the record name.
5. Review and sign. The wallet shows recipient, amount, fee and the capsule body. Confirm everything is correct, then click Sign & Broadcast. The wallet signs locally with your key — the key never leaves your browser.
   What you should see: a confirmation banner with a txid (a 64-hex hash). Save it.
6. Capture txid + block height. Open the SOST Explorer, paste the txid in the search box, and wait for the transaction to be included in a block. Note the confirming block height.
   What you should see: a transaction page showing the capsule body in plain text, the block height and the block timestamp.
7. Add the entry to the Registered capsules list below. Same as Method B — the publisher (you or an indexer) appends a new row binding txid · block_height · capsule_text · manifesto sha-256.

Register via sost-cli (for operators, scripts, CI/CD)

Use this method when you are publishing capsules from a script, a CI/CD pipeline or a headless operator machine. It uses the same Open Note capsule mode as Method A and produces the exact same on-chain record. The flow is the one already used for the Trinity Kalgoorlie Phase 1 proof bundle.

1. SSH (or open a shell) on the operator machine. Verify the node is up: sost-cli getblockcount should return the current chain tip.
2. Send the on-chain transaction with the attached capsule. Replace <SOURCE_WALLET>, <DEST_ADDRESS> and <AMOUNT> with operator values; the destination can be a dust output to the source itself, and the amount can be the protocol minimum:

   sost-cli --rpc-host 127.0.0.1 --rpc-port 28443 \
     --rpc-user <USER> --rpc-password <PASS> \
     --from <SOURCE_WALLET> \
     --to <DEST_ADDRESS> \
     --amount <AMOUNT> \
     --capsule-mode open-note \
     --capsule-text 'sost-protocol popc-manifesto 3bed02e2f5c589e4' \
     --send

   The exact flags follow src/sost-cli.cpp (see --capsule-mode open-note documented at line 686 of that file).
3. Capture txid and block height. The CLI returns the txid on success. Wait for confirmation, then look up the txid in sost-explorer.html and capture the confirming block height.
4. Add the entry to the registered-capsules list below. Same row binding as Method A.

Independent verification

Whichever method you used, the verification path is identical and reproducible by any third party without trusting this page:

1. Take the manifesto JSON file (or whatever content was anchored).
2. Run sha256sum on it locally.
3. Compare the first 16 hex of that SHA-256 against the on-chain capsule text in the txid's output payload (via sost-explorer.html or any SOST node RPC).
4. Verify the transaction signature against the publishing pubkey using standard SOST node tooling.

Match means the capsule, the file, and the signing key all line up — the timestamp + author + content tuple is cryptographically proven. No trust in this page required.

Worked example used in both methods above: registering the canonical SOST Protocol PoPC manifesto so the term "Proof of Personal Custody" is timestamped on-chain by the SOST Protocol operator before anyone else attempts to claim it. The fields below were computed in Step 1 and used identically by both methods.

Frequently asked questions

SOST Protocol — Beacon Phase II-A Operator Key (anchored on-chain)

First OFFICIAL Protocol Registry entry. This anchors the canonical Beacon Phase II-A operator-key fingerprint on the SOST chain itself. The on-chain capsule carries the first 16 hex (ceb19dd6b5fd676f) of the manifesto's SHA-256; the manifesto publishes the full key fingerprint bbb560e3…. Anyone can verify independently: (1) download the manifesto JSON and confirm its SHA-256 starts with ceb19dd6b5fd676f; (2) recompute the key fingerprint from BEACON_PUBKEY_HEX in src/beacon.cpp and confirm it equals bbb560e3…. Advisory only — the Beacon key never affects consensus, mining, or block validity.  → Beacon verification guide

SOST Protocol — GeaSpirit REE v0.4 Sealed Prospective Campaign (anchored on-chain)

What this is. GeaSpirit's private regional REE prior (a frozen model that ranks ground by geological favourability for carbonatite/alkaline rare-earth systems, using open data + craton context) selected 50 highest-ranked novel target areas and 50 controls, froze the model and sealed the set behind a Merkle tree. The exact coordinates, scores and evidence stay private and encrypted; only the file SHA-256 (9da4548f…) and the Merkle root (7f29c111…) are public. This capsule timestamps that sealed campaign on the SOST chain.

What it proves. Precedence + integrity: the campaign existed, unchanged, no later than block #13,483, signed by the operator address. The 50 targets cannot be edited after the fact without breaking these hashes — so any future hit cannot be cherry-picked retroactively.

What it does NOT prove. It is not evidence of mineralisation, grade, depth, tonnage, resources or reserves. The score_type is a relative regional rank, not a probability of a deposit. The campaign is unresolved; targets will be adjudicated later only by independent evidence (government/lab assays, drilling, primary publications) under the published resolution protocol. Verify independently: (1) fetch the commitment file and confirm its SHA-256 starts with 9da4548fdbfe8b57 (the on-chain capsule prefix); (2) confirm the JSON's merkle_root equals 7f29c111…; (3) look up the txid in the explorer and confirm the Open Note capsule + signing address.

SOST Protocol — Proof of Personal Custody (PoPC) protocol term (anchored on-chain)

What this is. A signed, block-anchored timestamp recording that SOST Protocol publicly uses "Proof of Personal Custody" (PoPC) as a protocol term, binding it to the canonical PoPC manifesto (api/sost-protocol-popc-manifesto-v1.json). The on-chain capsule carries the first 16 hex (3bed02e2f5c589e4) of the manifesto's SHA-256.

What it proves. Precedence + integrity: the PoPC term and that exact manifesto existed, unchanged, no later than block #15,439, published by the operator address.

What it does NOT prove. It is not a patent, trademark or copyright, and it does not certify the truth of any claim in the manifesto. Verify independently: (1) fetch the manifesto JSON and confirm its SHA-256 starts with 3bed02e2f5c589e4 (the on-chain capsule prefix); (2) look up the txid in the explorer and confirm the Open Note capsule + signing address.

Trinity Kalgoorlie Phase 1 — proof bundle

This capsule is a public cryptographic timestamp proving that Trinity existed and produced its first verifiable proof bundle on SOST at block #8085. It is not a mineral reserve claim, not a geological conclusion, and not an announcement of active Useful Compute rewards. The bundle binds four SHA-256 anchors (scorecard + dossier + Useful Compute plan + campaign manifest) into one document with a Merkle root; the on-chain capsule carries the first 16 hex of the bundle SHA-256, and the full 64-hex hash lives in the published JSON for independent verification by any third party.

SOST Protocol — PoPC (Proof of Personal Custody) manifesto v1

This row will be promoted to full ON-CHAIN status once the SOST Protocol operator publishes the capsule on mainnet following the registration guide above. The manifesto SHA-256 above is the canonical hash of the committed JSON file; if the JSON is ever changed, the hash changes and a new manifesto version must be issued (v2, v3, etc.) and re-anchored on chain.

Verified entries signed by SOST Protocol constitutional addresses (genesis / developer whitelist). The whitelist is a frontend classifier only — it never hides or deletes anything on-chain. Future iterations may expand the whitelist or open additional submission paths.

Community-submitted entries. Not official SOST Protocol records. Anyone with SOST can publish via the wallet. SOST Protocol does not endorse the truth of off-chain content beyond what each manifest itself says.

A public registry that anyone can append to without cost is exposed to spam — thousands of trivial records flooding the chain. SOST already requires a normal network transaction fee for every transaction (paid in SOST), which is the primary anti-spam mechanism on the base layer.

For a future iteration, a small application-level fee (also paid in SOST) could be required for registry records, in addition to the normal network fee. This would be enforced at the indexer / surface layer (not at consensus), so a misconfigured indexer cannot censor records. No such fee is active, and no current iteration of this page enforces or collects any payment.

The registry is read-only documentation in this iteration. Records are published manually by the operator via a normal SOST transaction with an attached capsule. Third parties are not invited to submit registry records yet — that pathway is reserved for a future design after the anti-spam, identity-attribution and dispute-handling models are settled.