> For the complete documentation index, see [llms.txt](https://argon-4.gitbook.io/argon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://argon-4.gitbook.io/argon-docs/suresign/review-plan.md). # The ReviewPlan The ReviewPlan is the canonical meaning of a transaction. How SureSign builds it, hashes it, binds your approval to it, and checks the signed bytes against it. Every transaction SureSign will sign is first expressed as a **ReviewPlan**: a canonical, complete description of what the transaction does. The interface renders the plan; the user approves the plan; the kernel signs the bytes the plan describes and then proves that the signed bytes still mean what the plan said. The plan is the contract between the user and the kernel, and the review hash is its signature line. ## The pipeline ``` Intent ──► Snapshot ──► construct ──► ReviewPlan (+ review_hash) │ user reads, approves │ Authorization(review_hash) ──► revalidate ──► sign │ post-sign decode ≡ plan? ──► release ``` 1. **Intent.** The host expresses what the user asked for as a typed intent: a transfer, an asset operation, a covenant step, a PSKT, a message, an Igra action. Intents carry addresses, amounts, and choices. They never carry transaction bytes, fees, or change addresses. 2. **Snapshot.** The host supplies the candidate Notes it collected from the node, with the network and current DAA score. The kernel treats each Note as a claim to be verified: it re-derives the script from the wallet's own keys and refuses any Note it cannot prove is its own. 3. **Construct.** The kernel selects inputs, derives a change address of its own, applies the protocol pack if one is involved, computes mass and fee against the pinned consensus parameters, and builds the unsigned transaction. 4. **ReviewPlan.** The kernel decodes the transaction it just built into a plan, checks the plan against its invariants, and computes the review hash. 5. **Approval.** The user reads the plan to its end and approves. The host returns an authorization carrying the review hash, the origin, the wallet, the account, the network, and a request id. Authorization is single-use. 6. **Revalidate and sign.** Before signing, the kernel checks the inputs against a fresh snapshot: a Note that has been spent, or a chain that has moved materially, invalidates the approval. Then it derives the private keys for exactly the inputs it owns, signs, and verifies the signatures. 7. **Post-sign equivalence.** The kernel decodes the signed transaction and compares it with the approved plan. Any difference is a refusal. Only then are the bytes released to the host for broadcast. ## What a plan contains | Field | Meaning | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `network`, `account`, `origin` | Where and for whom this plan is valid, and who asked (the wallet itself or a site origin). | | `inputs` | Every Note spent, by outpoint. `wallet_owned_inputs` marks which the kernel proved are its own. | | `outputs`, `recipients` | Every destination and amount, including fees paid as outputs (an Enclave fee, a protocol fee). | | `change`, `wallet_owned_change` | The change outputs, and which of them the kernel itself derived. A host or dApp cannot add to this list. | | `kas_effect` | Spent, received, change, and fee, in sompi. *Leaves this wallet* on the review is spent minus change. | | `fee_sompi`, `masses` | The miner fee and the compute, storage, and transient masses the kernel calculated. | | `payload`, `subnetwork`, `tx_version` | The transaction's payload bytes (an inscription, an Igra call), subnetwork, and version. | | `sighashes` | The signing mode for each input. Only modes the kernel honors appear here. | | `protocol_id`, `protocol_version`, `protocol_maturity` | Which protocol pack interpreted the transaction, at which pinned version, and whether its facts are consensus, convention, experimental, or indexer-dependent. | | `asset_effects`, `covenant_effects`, `covenant_ids` | What the transaction does to tokens, names, or covenants, in kernel-authored sentences, and the covenant identities it touches. | | `warnings`, `unknowns` | Findings the user must see, and anything the kernel could not decode. A non-empty `unknowns` is a blocked plan. | | `risk` | The plan's class: native KAS, a protocol, a covenant family, a Desk handshake. | | `review_hash` | The hash of everything above and of the exact unsigned transaction bytes. | Amounts are integers in sompi throughout. The interface formats them; it never recomputes them. Every figure shown on a review is a figure from the plan. ## The review hash The review hash is a keyed BLAKE2b-256 over a canonical encoding of the plan's fields followed by the exact unsigned transaction bytes. The key is a domain string specific to review hashes, so a review hash can never be mistaken for, or collide with, a consensus transaction id, which uses the same construction with a different key. Because the bytes are part of the hash, the hash binds meaning *and* form. Changing an amount, a recipient, a fee, a payload byte, a warning, or a single input changes the hash, and an approval carrying the old hash no longer applies. There is no way to approve "roughly this". At signing time the kernel requires the approved hash to equal the hash of the plan it holds, refuses a consumed authorization, refuses an expired one, revalidates the inputs, and only then signs. ## Seals and findings The interface shows one of three seals, each derived from the plan: | Seal | Derived from | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Ready** | Nothing in `unknowns`, and no finding that needs reading first. | | **Caution** | Nothing in `unknowns`; one or more findings, such as several recipients in one transaction, a privacy note about joined clusters, or an irreversible effect. | | **Blocked** | Anything in `unknowns`. Nothing can be approved; the authorize path is not offered. | Warnings are kernel-authored sentences. Some are informational facts the interface folds into the ledger it already shows (a note about how the fee output is classed, for instance) rather than raising as findings; the canonical plan, and therefore the hash, always carries all of them, and Technical details shows the plan whole. ## Packages: one approval, several transactions Some actions on Kaspa take more than one consensus transaction: a KRC-20 transfer is a commit then a reveal; an Igra action may need an unwrap, a wrap or an approval before the call, and a bridge from Kaspa before any of them. SureSign plans these as an **action package**: an ordered list of slots with a headline, bounds, and a **package hash** that commits to the intent, the slot graph, the custody addresses, the recipient, and the maximum KAS that may leave. The user approves the package hash once. As the chain makes each slot legal, the kernel constructs the slot's transaction, proves it lies within the package's bounds, signs it, and checks it against that slot's own ReviewPlan before release. If a slot would exceed the bounds or the chain has moved, the package pauses and waits; it never guesses. Interrupted packages persist in an encrypted journal and resume after unlock; the host may advance an authorized package but cannot invent one. This is the only case in which the kernel signs without a fresh approval, and it is bounded on every axis by the approval the user already gave. ## Decode is the same code The same decoder that produces the plan from a transaction the kernel built also runs on the signed bytes for the equivalence check, on transactions a dApp submits as a PSKT, and on any raw transaction pasted into the Decode tool. There is one transaction engine and one way to read a transaction; what you see in Decode is what the kernel would sign.