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.

Register via the SOST Wallet (easy path)

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.

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

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.

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.