KEPT / v1.0 · ML-DSA-65 · FIPS 204 · mainnetconnecting · seal key … · log …
KEPT
05 / API & rules

Read the rules. Use the API.

Everything the site shows comes from these endpoints. Every check the verifier runs can be run anywhere with the receipt, the public key and a Solana RPC.

ARules

What a covenant binds.

The watcher reads every transaction that touches the creator wallet. Facts are sealed as they land; outcomes follow from these rules and are sealed too.

  1. R1
    Buyback share

    Every time creator fees leave the creator's pump.fun vaults (bonding-curve vault or PumpSwap creator vault), that claim times the buyback share is owed. Owed amounts add up across claims.

  2. R2
    Deadline

    By each claim's deadline (24, 48 or 72 hours after it), the SOL the creator wallet has spent buying the coin since launch must cover everything owed so far.

  3. R3
    Burn

    With a buyback share above zero, every token the creator wallet buys after launch counts as buyback and must be burned by the same deadline (0.1% rounding forgiven). Missing R2 or R3 seals a buyback_missed breach.

  4. R4
    Sell lock

    Inside the lock, any drop in the creator wallet's balance of the coin that isn't a burn is a breach: sold_in_lock when SOL came back, moved_in_lock otherwise. After the lock, sales are recorded but allowed.

  5. R5
    Fee routing

    If a pump.fun fee-sharing config appears for the mint, creator fees no longer reach the watched vaults: fees_rerouted breach.

  6. R6
    Verdict

    broken once any breach is sealed. pending while the lock runs or a buyback is open. kept otherwise. Use a fresh creator wallet for a buyback covenant: pump.fun pays one fee vault per wallet, so every claim from it counts.

KEPT records and proves; it doesn't hold funds or stop transactions. The rules are a pure function of the sealed receipts and the clock (src/lib/covenant.ts), so anyone with the chain gets the same verdict.

BReceipts

The receipt format.

Canonical JSON (keys sorted, no whitespace, integers only), hashed with SHA-256 and signed with ML-DSA-65 under the FIPS 204 context kept/receipt/v1. Each receipt names the digest of the one before it.

{  "type": "kept.receipt", "version": 1,  "network": "solana:mainnet",  "mint": "…pump", "symbol": "RIVET",  "seq": 4, "prev": "<digest of R3>",  // chain  "kind": "dev_sell",  // what happened  "at": 1793140000,  // block time  "tx": { "signature": "…", "slot": 457401960 },  "data": { "tokens": 410000000000, "lamports": 3100000000,            "pctOfDevBuyBps": 4100, "inLock": true },  "verdict": "broken",  // after this receipt  "issuedAt": "2026-…Z",  "digest": { "alg": "SHA-256", "value": "…" },  "seal": { "alg": "ML-DSA-65", "keyId": "…",            "context": "kept/receipt/v1", "signature": "<3309 B>" }}
  1. K1
    launch

    Covenant, its digest and memo, metadata URI + SHA-256 of the metadata JSON and image, dev buy.

  2. K2
    fee_claim · buyback · burn

    Claimed lamports with owed and deadline; SOL spent and tokens bought; tokens burned.

  3. K3
    dev_sell · dev_transfer

    Tokens out of the creator wallet, share of the dev buy, inside or outside the lock.

  4. K4
    obligation_met · lock_ended · breach

    Outcomes of the rules, with the receipt they refer to.

CAPI

Public, read-only, JSON.

No key needed. Amounts are raw integers: lamports for SOL, base units (6 decimals) for tokens.

GET/api/coinsEvery coin with covenant, verdict and ledger state. ?verdict=pending|kept|broken
GET/api/coins/:mintOne coin and its whole receipt chain
GET/api/receipts/:digestA receipt, with its inclusion proof against the first anchored head that holds it
GET/api/feedNewest receipts across all coins. ?limit= (max 100)
GET/api/sealThe ML-DSA-65 public key, contexts and the anchor wallet
GET/api/logLog size, latest signed tree head, recent heads and anchors
GET/api/log/proofInclusion proof. ?digest= [&size=]
GET/api/log/consistencyRFC 9162 consistency proof. ?first=&second=
GET/api/log/leavesRaw leaves in order, to rebuild the tree. ?start=&limit= (max 1000)
GET/api/anchorServer-side anchor memo check. ?signature=&size=&root=
GET/api/statusNetwork, slot, seal key, counts, last tick
// verify a receipt anywhere (Node or browser)import { ml_dsa65 } from "@noble/post-quantum/ml-dsa.js";const { publicKey } = await (await fetch(SITE + "/api/seal")).json();const { digest, seal, ...body } = receipt;const msg = utf8(canonicalize(body));       // sorted keys, no spacessha256hex(msg) === digest.value;            // digestml_dsa65.verify(b64(seal.signature), msg, b64(publicKey),  { context: utf8("kept/receipt/v1") });     // seal
  1. V1
    Leaf hash

    SHA-256(0x00 ‖ 32-byte receipt digest). Nodes are SHA-256(0x01 ‖ left ‖ right).

  2. V2
    Tree head

    kept.tree-head with treeSize, rootHash, timestamp; sealed under kept/tree-head/v1.

  3. V3
    Anchor memo

    kept:head:v1:<treeSize>:<rootHash> from the anchor wallet in /api/seal.

  4. V4
    Covenant memo

    kept:covenant:v1:<SHA-256 of the canonical covenant>, signed by the creator in the create transaction.