> 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/fail-closed.md). # Fail closed Why SureSign refuses what it cannot fully understand instead of guessing, and what that policy looks like in practice. A signing kernel has two ways to handle something it does not recognize. It can find the nearest thing it does recognize and proceed, or it can stop. SureSign stops. This is a deliberate trade. A wallet that guesses supports more things on day one and, sooner or later, signs something its user did not mean. A wallet that stops supports fewer things and never signs a meaning it could not show. Between more features with ambiguous signing semantics and fewer features with provably understood semantics, SureSign chooses the latter, every time. ## What "unknown" means A plan is blocked when any part of the transaction carries meaning the kernel cannot decode with a pinned rule. Concretely: | Situation | What SureSign does | | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | An output script it cannot classify | Lists it under *unknowns*. Blocked. | | A payload it has no protocol pack for | Treats it as opaque. Blocked for signing; visible in Decode. | | A covenant script that matches no template in the catalog | Recognizes the opcodes if it can, refuses to spend. *Recognition is not authorization.* | | A known template at an unknown version or compiler pin | Refuses. No fallback to a "similar" version. | | A sighash type other than the ones it honors | Refuses. Never substitutes `SIG_HASH_ALL` for what was asked. | | An Igra contract or function outside the pinned set | Refuses the call. Reads to that contract may still be answered. | | A provider fee address, vault, or route that differs from the pin | Refuses, even if the provider's own API returned it. | | A network without pinned consensus parameters | Refuses to plan on it. | | A KRC-20 or KRC-721 operation the pack does not define | Refuses. Marketplace listing and sale operations are in this class. | | A message-signing grammar that does not parse | Refuses a Sign-In-With-Ethereum request whose domain does not equal the origin, whose address is not this wallet's, or whose chain is not Igra. | The interface shows all of these as **Blocked** with the kernel's reason. There is no override. ## Where the pins live Everything SureSign is willing to understand ships inside the repository: consensus types from a specific rusty-kaspa commit, protocol packs at specific versions, covenant templates as compiled dumps from a specific compiler tag, Igra contract addresses and function selectors, provider fee addresses, message grammars. A change to any of them is a code change, reviewed and released like any other. Remote sources are allowed to add *data*: a token's logo, a collection's name, a covenant's directory entry, a bridge's current quote. They are never allowed to add *behaviour*. There is no remote protocol registry, no downloadable decoder, no script that participates in signing. A registry can tell Enclave that a token exists; only a release can teach SureSign what a transaction involving it means. ## Feature gates Behaviour that is understood but not yet proven on the live network stays behind a gate. A template can be in the catalog for inspection while its spend path is disabled; a protocol can be decoded for display while its construction is refused. Gates are lifted by a release, with tests, after the upstream behaviour has been verified against the reference implementation and, where it matters, exercised on testnet-10 and mainnet. ## Consensus, convention, indexed, experimental Every protocol pack declares the authority of its facts, and the plan carries that declaration: | Maturity | Meaning | Examples | | -------------------- | ------------------------------------------------- | ------------------------------------------------- | | **Consensus** | Defined or enforced by Kaspa itself | KAS payments, P2PK and P2SH scripts, covenant ids | | **Convention** | An interoperability agreement on top of consensus | KCC standards, multisig conventions | | **Indexed protocol** | Meaning depends on an external indexer | KRC-20, KRC-721, KNS | | **Experimental** | Evolving or feature-gated | Templates under evaluation | The interface never collapses these. A KAS payment that Kaspa confirmed and a token balance that an indexer recognized are different kinds of fact and are labelled differently on the plan, in Activity, and on Holdings. ## What this costs you Occasionally a legitimate dApp will present something SureSign refuses: a contract it has not pinned, a PSKT with an unusual signing mode, an inscription operation outside the pack. The refusal is not a bug. It means the request would have required the kernel to sign a meaning it could not show you. The remedy is a release that adds the pin, with review and tests, not a switch in Settings.