| Internet-Draft | Digital Money Threat Models | October 2026 |
| Das | Expires 4 May 2027 | [Page] |
Problem: unauthorized movements of digital money often succeed with valid credentials. A compromised service presents its genuine workload identity; a signing module signs a digest it was handed; an account is delegated to changed code; a coordinator feeds threshold signers inconsistent inputs; parallel wallets each see the same balance; a stale region honors a revoked authorization; a retry after a crash sends a second transfer; an AI agent turns injected text into a valid payment-tool call; or a bridge releases on provisional finality. Identity checks, TLS, hardware key protection, threshold signing, allowlists, fraud scoring, audit logs and ledger consensus each answer a different question. None of them, by itself, verifies at the moment of release that the exact effect is authorized, current and unused.¶
Solution: this document gives fourteen security threat models (TM-01 to TM-14), each with attacker capability, plausible pathway, why existing protections may fail, a constructive protected procedure, a YES/NO/UNKNOWN workflow, coverage limits and a negative-effect test. It analyzes thirteen classes of existing controls and specifies a common protected sequence: independent authority bound in a protected domain, reconstruction of the effect from the final native bytes, protected freshness, budget and replay state, a non-bearer handle consumed atomically at the exclusive signer, dispatcher or account guard, and typed outcomes that keep UNKNOWN distinct from success or failure. The control is complementary to ledger consensus, not a replacement for it.¶
Scope: 29 diagrams, 56 test vectors, 90 enforcement points, worked mathematical examples, and runnable Python, Go and Node.js reference models with a latency harness. The document is informational and defines no wire format. The scenarios are hypothetical threat models, not findings about any real incident or organization.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A companion document [I-D.das-digital-money-safety-module] describes how digital-money systems can bind authority to the exact financial effect released at the last controllable boundary. This document asks the adversarial question: in which concrete ways can money move without authority even though every credential, signature and API call is valid, and what must a protected boundary do in each case?¶
The recurring pattern is a gap between who is allowed to act and what effect is actually released. A genuine service credential may carry a changed recipient. A non-exportable key may sign whatever digest reaches it. A valid delegation may point at code that later changes. Valid parallel requests may together exceed a limit. A valid authorization may be honored by a region that has not seen its revocation. A valid approval may be reused after a crash. An AI agent may produce a well-formed payment-tool call from instructions planted in a document or web page. None of these requires breaking cryptography.¶
Each existing control supplies a real assurance: user or session authenticity, transport integrity, protocol validity, key secrecy, quorum participation, list membership, static limits, request filtering, risk scoring, after-the-fact evidence, code review, human approval or cached revocation. Section 8 sets out, for thirteen control classes, the conditional failure mode under these threat models and the execution-finality requirement that would close it (Figure 32). Where a conventional control already implements the same exact-effect, current-state and non-bypassability predicates, it remains in place.¶
Ledger consensus establishes validity, ordering and shared history. It does not, in general, know whether the economic effect matched an independently protected mandate (Figure 3).¶
The protected sequence (Steps S-01 to S-12, Figure 36) places an execution-facing decision before the exclusive signer, broadcaster, protected account function or other Finality Sink. PED-1 holds independently authenticated authority in a Protected Transaction Authority Record (PTAR). PED-2 builds an Execution-Facing Effect Descriptor (EFED) from the final native representation. Protected sink-local state supplies freshness, budget and single use, and a Finality Decision Record (FDR) records a typed local outcome that is never treated as proof of remote settlement. Every effect-capable path must cross such a gate, or the stated coverage is narrowed.¶
Fourteen threat models with constructive procedures, decision workflows, limitations and pseudocode.¶
A conditional analysis of thirteen existing control classes.¶
Records (PTAR, EFED, FDR), the S-01 to S-12 sequence, decision branches SEC-B-01 to SEC-B-06, invariants with worked examples, a path-completeness method and alternative placements.¶
A negative-effect laboratory protocol with 56 test vectors, runnable reference models and a latency decomposition.¶
Implementation variations restated as 90 enforcement points (Section 10).¶
This document is informational. It defines no wire format, makes no statement that any named system is vulnerable, and attributes no illustrated sequence to any real incident. Protection is claimed only for paths actually mediated by the described gate. An independently usable key, an already released unrestricted signature or delegation, a simultaneously compromised policy authority and signer, and non-cooperating external rails remain outside the guarantees, as set out in the limitations sections. The reference code is educational and is not production custody, settlement or hardware security software.¶
This document does not use BCP 14 key words. Lowercase "shall", "must" and "should" describe the intended behavior of the described arrangement. Bracketed labels such as [S01] identify the public sources listed in Section 6. Long lines in code listings are folded using the double-backslash strategy of [RFC8792].¶
This document applies the protected transaction authority and execution-finality architecture, and the companion digital money safety module [I-D.das-digital-money-safety-module], to security threat models. Terms defined in that architecture, including Candidate Act (CA), Non-Effective State (NES), Protected Enforcement Domain (PED-1 and PED-2), Execution Handle (EH), Finality Sink (FS), policy generation, and protected state, retain their described meanings unless a local refinement is expressly indicated.¶
The textual workflows, conditional decisions, structural arrangements, state-transition tables, record fields, formulas, pseudocode, executable reference code and test descriptions are provided to assist an implementer to understand and implement representative technical profiles. They are non-limiting with respect to programming language, processor family, database engine, cryptographic primitive, ledger, virtual-machine arrangement, administrative topology, form of proof, deployment location and number of components. A stated technical requirement is not dispensed with merely because its implementation technology is interchangeable.¶
Examples of an unauthorized transfer, delegated execution, internal-service compromise or signing-service misuse are hypothetical threat models, not allegations that any particular person or organization used, suffered or enabled the illustrated sequence. No specific cause, attacker identity, exfiltration method, private-key status, monetary impact or completed forensic finding is asserted. A recent publicly reported high-value digital-asset security incident with an ongoing technical investigation provides context for evaluating these general attack classes, but does not establish any illustrative causal chain.¶
Protected authorization before signature release, authorization before network dispatch, and enforcement inside a programmable account are distinct effectuation boundaries. An off-chain gateway that does not control an independent signer or on-chain delegated code cannot claim to prevent effects through those routes. Reconciliation evidence is not a substitute for actual denial at the boundary. All experimental reference programs included here are educational models and not validated production custody, legal settlement or hardware security systems.¶
Further reference implementations are furnished in Python, Go and JavaScript to illustrate the same authorization-to-effectuation control through different programming languages, with deliberate differences in persistence and scheduling. Code listings, local measurements, test harnesses and textual workflows are non-limiting implementation examples for implementers and do not confine the architecture to any programming language or guarantee a security, latency, cryptographic or settlement property outside the explicitly modeled conditions.¶
The following material supplements the disclosed financial execution-finality and protected transaction authority architectures by identifying plausible failure pathways at which authentication, cryptographic signatures, delegated program execution or gateway approval may diverge from the exact financial action originally authorized. This document addresses both conventional transfers and executable-account delegations, as well as multiple independent wallets, administrative domains and transaction networks.¶
Forensic uncertainty is expressly preserved. The examples assume that an attacker may control one or more lower-trust computational components, possess valid operational credentials, influence a transaction builder, trigger a signing service, or cause a previously approved executable implementation to change. The cases do not require a private key to be exported. A separate threat class does consider direct access to an unmediated signer, which is a coverage limit unless that route is technically removed or independently enforced.¶
The technical solution described for each case is the protected comparison of independently maintained authorized intent against reconstructed sink-facing operation state, followed by bounded, non-bearer, sink-bound authority consumption and controlled consequence release. Distinct authority is required both for installing delegated executable code and for consequential operations performed by that code; where a signature itself creates an effective independent capability, verification precedes the release of the signature.¶
This document concerns execution-time control of cryptographic signing, executable account delegation, transaction dispatch, digital-asset movements, distributed treasury operations, autonomous agent tool calls and cross-network financial obligations. In representative deployments, the consequential boundary occurs when a usable signature is exposed, a protected broadcaster dispatches signed bytes, an on-chain account permits execution of code, or a ledger or settlement controller commits an externally effective transfer.¶
Authentication of an employee, use of encrypted transport, possession of a non-exportable signing key, satisfaction of a smart-contract signature check or recording of a policy approval may each be technically correct without proving that the exact pending value transfer, delegate code, withdrawal destination or aggregated spend remains authorized. The challenge is protecting the equivalence between previously granted effect-specific authority and the actual operation as reconstructed at the last boundary under current policy and protected use state.¶
Recent publicly discussed digital-asset security events have raised questions about how apparently valid transaction authorizations, internal operational access, programmable account delegation and transfers across multiple networks interact. In an evolving investigation, a reported result does not alone establish whether a key was exported, a signing service was improperly invoked, a host was compromised, a delegate target was substituted, or a separate path was abused. These possibilities are alternative security hypotheses; no particular sequence is attributed to any real incident.¶
This document uses synthetic scenarios to isolate boundary failure classes. It does not state that any one control actually failed in a particular organization, that a specific product uses a described implementation, or that a specific threat model fully explains any event. This neutrality does not affect the independent technical reproducibility of the described algorithms and tests.¶
Source provenance. The generic threat classes below draw on formally published protocol specifications, standards guidance and enumerated software weaknesses [S01]-[S13]. Cited publications describe technical conditions used to construct hypothetical failure scenarios; they do not identify, confirm or reconstruct the cause, chronology or responsibility for any particular recently reported digital-asset security event. Each threat model is labeled as documented protocol behavior, a recognized weakness class, or a hypothetical architectural extrapolation.¶
Protected components include an independently administered authority binder (PED-1), an execution-facing reconstructing checker (PED-2), a restricted signer or guarded account execution module, a Finality Sink, and a durable protected state record. The attacker may control untrusted request builders, one or more agent instances, a service container, intermediary APIs, displayed approval summaries, scheduling and retry logic, an ordinary transaction relay, or a network-adjacent component. The threat model may allow possession of otherwise valid API credentials without treating such possession as effect-specific approval.¶
For a given deployment, root trust assumes the protected policy source, protected state, enforcement mechanism and signing key use boundary have not all been subverted simultaneously. Where the attacker controls the protected trust root, possesses an unrestricted independently usable key, or holds a previously released on-chain capability that bypasses the proposed account guard, the given off-chain profile cannot guarantee prevention. Those cases call for stronger enforcement placements or expressly narrower protection statements.¶
An observed signature proves the signing primitive accepted a preimage, not independently that the preimage was semantically permitted. An observed broadcast proves attempted dispatch, not confirmation. A transaction-receipt or log entry from a local service does not prove an external transfer permanently settled. A ledger confirmation remains subject to the applicable consensus and reorganization assumptions.¶
ATTACKER MAY CONTROL PROTECTED (not all subverted
(untrusted side) at the same time)
+---------------------------+ +-------------------------+
| request builders, agents, | | PED-1 authority binder |
| service containers, | CA | (independent admin) |
| intermediary APIs, |-------->+-------------------------+
| displayed approval | (non- | PED-2 reconstructing |
| summaries, schedulers, | effect- | checker (final bytes) |
| retries, relays | ive) +-------------------------+
+---------------------------+ | protected state record |
| (use ids, budget, epoch)|
+-------------------------+
| restricted signer / |
| guarded account module |
| = Finality Sink |
+-------------------------+
|
v effect
OUTSIDE GUARANTEE: compromised trust root, unrestricted independent
key, previously released on-chain capability bypassing the guard
observation proves does NOT prove
-------------------- -------------------- ----------------------
valid signature primitive accepted preimage was
a preimage semantically allowed
broadcast observed dispatch attempted confirmation
local receipt / log local service record external transfer
permanently settled
ledger confirmation protocol acceptance permitted beneficiary
(consensus rules) or mandate compliance;
still subject to reorg
A distributed ledger establishes protocol-defined validity, transaction ordering, state-transition execution and, subject to its consensus model and confirmation assumptions, shared transaction history. These are essential properties. A conventional validator may nevertheless lack an independently authenticated record of whether a real account owner, custodian, principal, regulated entity or delegated agent actually approved the precise economic effect. A valid signing credential or executable-account authorization may satisfy ledger rules despite a substituted beneficiary, malicious delegated implementation, altered fee, exceeded enterprise quota, or unauthorized purpose, unless a correctly implemented on-chain or off-chain policy mechanism separately verifies those constraints.¶
AI-assisted cybersecurity threats include prompt-injected agent instructions, apparently legitimate tool requests produced from untrusted content, adversarial transformation of payment parameters after approval, and automated fan-out across signing services or multiple networks. In each case the decisive issue can be a mismatch between effective operation semantics and independently protected authority. This document does not assert that an autonomous agent or a particular company participated in any actual investigated incident.¶
An ordinary ledger signature and transaction receipt are not necessarily evidence of a pre-execution business authorization. Likewise a successful on-chain transaction or ledger confirmation may prove protocol acceptance without proving permissible beneficiary identity or compliance with an external spending mandate. Conversely, a properly designed on-chain smart account with per-call policy, bounded authority and replay protection may enforce relevant semantics directly, and must not be categorically described as inadequate.¶
Accordingly, the proposed technical addition is an execution-facing protected decision before an exclusive signer, broadcaster, protected account function or other actual Finality Sink may initiate the consequence. PED-1 independently holds the permitted act, PED-2 reconstructs the effect from the actual final representation, and protected sink-local state ensures one-use/bounded use, policy freshness and denial correctness. A signed transaction that fails that predicate is refused at the controlled effectuation boundary, even if conventional network or ledger verification would otherwise accept its signature.¶
The proposed control is complementary to, and not a substitute for, consensus, ledger finality, transaction inclusion, external settlement, fraud investigations or successful recovery. No off-chain protection is effective against an uncontrolled independent signing key or an unrestricted already-effective delegated account. Deployment must mediate each relevant signing or execution path, or expressly narrow the covered effect class.¶
Conditional gap G1: a signature is valid but the final payee or asset differs from the independently approved mandate; protected response: compare exact native fields immediately before controlled signature release.¶
Conditional gap G2: a cryptographically authorized executable delegate points to changed code or a mutable upgrade generation; protected response: bind delegated code identity, relevant executable implementation and upgrade epoch, and where possible verify each downstream call.¶
Conditional gap G3: an AI agent receives an instruction from an untrusted document or website and invokes a real payment tool; protected response: preserve source authority lineage and refuse to promote model output into independent financial approval.¶
Conditional gap G4: simultaneous valid requests exceed account-level spending limits; protected response: serialize protected budget consumption or use a demonstrably safe distributed escrow allocation.¶
Conditional gap G5: a failed or timed-out transaction is retried under an apparently valid authorization; protected response: record consumption before release and preserve UNKNOWN external outcome until independently reconciled.¶
Conditional gap G6: a validly signed operation is routed through a backup key, unmediated relay, or earlier delegated contract; protected response: enumerate and close real alternate paths, use on-chain policy where required, or narrow the security assertion.¶
independently authenticated authority (PED-1)
|
final native bytes -> PED-2 reconstructs effect
|
protected gate at exclusive signer / dispatcher /
account function: exact match, fresh policy, one use
| (gaps G1-G6 closed here, before effect)
v
signature / dispatch --> ledger: validity, ordering, execution,
consensus finality (unchanged, still
required; complementary, not replaced)
G1 payee/asset differs G2 delegate code changed
G3 agent instruction G4 concurrent overspend
G5 retry after timeout G6 backup key / relay / old delegate
The following references are identified solely as technical sources used to formulate the illustrative threat models TM-01 through TM-14. They are not identified as sources of the separately described protected execution-finality solutions, do not attribute authorship of those solutions to any reference author, and do not establish that any hypothetical scenario occurred in a particular incident.¶
The enumerated TM-01 through TM-14 are defensive threat-modeling exercises, not fourteen observed attack routes. Their source references establish background protocol semantics, generalized adversarial behaviors, or broadly recognized software weaknesses. They do not establish that any described exploit occurred, that any named or unnamed organization has the specified configuration, or that a proposed mechanism is novel or patented.¶
Provenance classes. (A) Documented protocol behavior: functionality or security considerations expressly present in a public primary specification. (B) Established weakness class: a documented category of errors without evidence that a particular product is affected. (C) Constructed engineering hypothesis: a conditional example formed by combining known components and defined attacker capabilities. A threat model may draw on A or B while its specific attack path remains C.¶
Source-use limitations. RFCs, EIPs, MITRE entries, OWASP guidance, and NIST recommendations describe different technical subjects and do not validate a financial incident reconstruction. A strong cryptographic signature, secure transport, threshold cryptography or blockchain consensus is not categorically insecure; each can enforce important security properties, and correctly deployed application- or contract-level policy may prevent the described conditional effects.¶
Verified technical references; identifiers used in TM-01 through TM-14¶
[S01] RFC 3552. Rescorla and Korver, Guidelines for Writing RFC Text on Security Considerations, BCP 72, July 2003. URL: https://www.rfc-editor.org/rfc/rfc3552.html. Relevance and limit: Methodological guidance: state adversary capabilities, assumptions, threats, countermeasures and residual security considerations; not evidence of a financial incident.¶
[S02] MITRE ATT&CK T1078. Valid Accounts, MITRE ATT&CK Enterprise technique. URL: https://attack.mitre.org/techniques/T1078/. Relevance and limit: Documents abuse of legitimate credentials, including service and cloud accounts; it does not identify a particular digital-asset compromise.¶
[S03] MITRE CWE-863. Incorrect Authorization, Common Weakness Enumeration. URL: https://cwe.mitre.org/data/definitions/863.html. Relevance and limit: Defines flawed permission checking despite some authentication or authorization processing; specific financial applications are hypothetical.¶
[S04] NIST SP 800-57 Part 1 Revision 5. Barker, Recommendation for Key Management: Part 1 - General, May 2020. URL: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final. Relevance and limit: Key-lifecycle, cryptographic protection and key-use context; the distinction between key custody and approval of each economic effect is the author's technical inference.¶
[S05] Ethereum EIP-7702. Buterin et al., Set Code for EOAs, Ethereum Improvement Proposals. URL: https://eips.ethereum.org/EIPS/eip-7702. Relevance and limit: Primary specification for account delegation, authorization tuples, delegate-code execution, nonces, replay cautions and balance-affecting delegated calls.¶
[S06] MITRE CWE-367. Time-of-check Time-of-use (TOCTOU) Race Condition, Common Weakness Enumeration. URL: https://cwe.mitre.org/data/definitions/367.html. Relevance and limit: A checked state can change before it is used; application to financial transaction serialization is a reasoned extension.¶
[S07] MITRE CWE-362. Concurrent Execution Using Shared Resource with Improper Synchronization, Common Weakness Enumeration. URL: https://cwe.mitre.org/data/definitions/362.html. Relevance and limit: Concurrency and atomicity failure class; cross-wallet overspending is a synthetic financial example, not an observed incident.¶
[S08] RFC 9591. Connolly et al., The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures, Informational, June 2024. URL: https://www.rfc-editor.org/rfc/rfc9591.html. Relevance and limit: Primary technical description of threshold-signing coordinator, participant checks and nonce handling. The hypothetical business-authority mismatch is not an assertion that FROST is insecure.¶
[S09] MITRE CWE-294. Authentication Bypass by Capture-replay, Common Weakness Enumeration. URL: https://cwe.mitre.org/data/definitions/294.html. Relevance and limit: Established replay weakness pattern; its extension to business authorization identifiers and EIP-7702 nonce variants is hypothetical.¶
[S10] Ethereum ERC-1967. Palladino et al., Proxy Storage Slots, Ethereum ERC-1967. URL: https://eips.ethereum.org/EIPS/eip-1967. Relevance and limit: Primary documentation for proxy implementation, beacon and admin storage slots and upgrade observability; not evidence of compromised code in any real system.¶
[S11] OWASP LLM01:2025. OWASP GenAI Security Project, LLM01:2025 Prompt Injection. URL: https://genai.owasp.org/llmrisk/llm01-prompt-injection/. Relevance and limit: Describes malicious influence over model behavior through untrusted inputs; the financial tool-call scenario is a defensive extrapolation.¶
[S12] Ethereum.org proof-of-stake security. Ethereum proof-of-stake attack and defense, Ethereum developer documentation. URL: https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/. Relevance and limit: Explains consensus reorganization, finality delay and related risks; does not prove a particular cross-chain or bridge incident.¶
[S13] MITRE CWE-841. Improper Enforcement of Behavioral Workflow, Common Weakness Enumeration. URL: https://cwe.mitre.org/data/definitions/841.html. Relevance and limit: Addresses missing or out-of-sequence steps; used as general background for revocation, effect initiation and recovery modeling.¶
Threat-to-source classification index¶
TM-01: [S02], [S03]. Classification: Documented generic technique; hypothesized financial context. Established credential-abuse and authorization weakness classes; applying them to a finance signing container is an illustrative hypothesis.¶
TM-02: [S04], [S03]. Classification: Architectural inference from established key-management and authorization principles. Key protection and incorrect-authorization literature provide background. A non-exportable key used for an unapproved transaction is a constructed separation-of-authority example, not a documented conclusion about an incident.¶
TM-03: [S05]. Classification: Documented protocol semantics; malicious scenario hypothetical. EIP-7702 defines executable account delegation and its protocol-level validity. A malicious delegate accepted by a separate business workflow is a possible conditional failure, not an allegation about an identified custodian.¶
TM-04: [S06], [S03]. Classification: Established weakness class; payment-specific extension hypothetical. TOCTOU is a documented weakness class. A mutable payment builder, altered recipient or post-approval serialization is an application-specific threat construction.¶
TM-05: [S07]. Classification: Established race-condition principle; multi-wallet case hypothetical. A shared quota checked without atomic synchronization can be raced; separate wallets and networks are an illustrative distributed accounting environment.¶
TM-06: [S08], [S04]. Classification: Documented threshold-signature roles; application-policy failure hypothetical. RFC 9591 explains threshold signing and coordinator roles, with participant input validation. The scenario assumes a deficient application-level policy wrapper; it does not claim a vulnerability in FROST itself.¶
TM-07: [S05], [S09]. Classification: Protocol-derived and replay-derived hypothesis. EIP-7702 specifies authorization tuples and nonce handling, while CWE-294 documents generic replay risk. Coordinated nonce fan-out or unauthorized use of multiple signed variants remains an engineered threat hypothesis.¶
TM-08: [S03], [S01]. Classification: Author-defined consequence-path completeness hypothesis. An alternate signer is considered under a defined threat model when different effective paths do not enforce the same authorization. No listed public source reports that a particular organization had such a route.¶
TM-09: [S05]. Classification: Protocol-derived behavior; persistence scenario hypothetical. EIP-7702 states that delegated accounts may experience balance decreases from calls other than the account-originating transaction. An unbounded delegate acting on later deposited value is a logical security scenario, not an independently documented incident.¶
TM-10: [S03], [S13]. Classification: Author-defined distributed-state hypothesis. Authorization and workflow correctness provide the technical basis for a freshness and failover test. The stale-region/revocation-epoch example is a distributed-systems construction; these sources do not document that exact exploit.¶
TM-11: [S13], [S07]. Classification: Author-defined failure/recovery hypothesis. Out-of-order workflow and concurrency classes provide the technical basis for crash/retry safety. Duplicate external transfers following unknown acknowledgment are synthetic fault-injection scenarios, not traced to a real financial event.¶
TM-12: [S10], [S05]. Classification: Documented programmable-account mechanisms; combined scenario hypothetical. ERC-1967 defines mutable proxy implementation paths, while EIP-7702 defines account delegation. Combining a delegating account with upgrade-sensitive executable authority is a conditional design threat, not a proven exploit at a named service.¶
TM-13: [S11], [S03]. Classification: Established LLM threat class; financial effect scenario hypothetical. OWASP documents prompt injection as a model-behavior risk; an untrusted tool result changing a payment instruction is a hypothetical downstream effect that depends on actual tool privileges.¶
TM-14: [S12], [S13]. Classification: Established finality concepts; cross-domain consequence hypothesis. Ethereum documents consensus finality and reorganization behavior. A bridge or settlement adapter trusting an insufficiently finalized event is a cross-domain reasoning scenario; no particular bridge vulnerability is claimed.¶
TM-01 through TM-14 are hypothesis-driven classes selected to cover the attack possibilities described in the technical problem. They are not a forensic reconstruction of any real event. The current-control limitations below are conditional. Each threat includes a constructive control placement, failure behavior and falsifiable negative-effect acceptance criterion.¶
Protected asset and consequence. restricted signing service, private custody operations and trusted account authority.¶
Attacker capability and trust assumptions. attacker controls a request-building container, service credential or workstation but not the protected signer, protected authority registry or all privileged key-use paths.¶
Authorized operation. a legitimate authenticated service builds an approved transfer and requests a protected signature.¶
Plausible unauthorized pathway. malicious intermediary submits a syntactically valid but unauthorized recipient, amount or account with its normal service credential.¶
Why existing protections may fail. OAuth, mTLS or workload-identity checks can accept the service as genuine, while an API-policy check that trusts caller-generated transaction descriptions may not independently validate the native payload.¶
Source basis and evidentiary status. [S02], [S03]. Documented generic technique; hypothesized financial context. Established credential-abuse and authorization weakness classes; applying them to a finance signing container is an illustrative hypothesis. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
compromised container (valid OAuth/mTLS credential)
| builds request with changed recipient / amount / account
v
API policy that trusts caller description --> may accept
|
PED-1 approved account, payee, amount, network, use id
|
PED-2 reads actual pending native bytes from restricted signer
| (not the compromised service's response)
v
sink: exact fields, fresh revocation, budget, sink binding,
atomic consume --> signature only if all match
emergency / backup / raw-digest signer: disabled or gated
Constructive protected execution-finality procedure¶
PED-1 stores approved account, payee, amount, network and finite use identity from an independent authenticated principal.¶
PED-2 reads the actual pending native bytes from the restricted signer, not the compromised service response.¶
The sink checks exact fields, fresh revocation, budget and sink binding, and atomically consumes authority before signing.¶
Any emergency, backup or raw-digest signer exposed to the host must be disabled or brought under equivalent control.¶
Implementation alternatives and design-around-resistant technical placements. an HSM verify-and-sign function, attested signing enclave, isolated kernel gate or constrained key service may provide the effective boundary.¶
Failure / recovery behavior. A suspected compromised service is quarantined; already released signatures are reconciled without reissuing unknown transactions.¶
Negative-effect experiment and acceptance criterion. Use valid compromised-service credentials to submit a changed recipient while instrumenting all signing interfaces; expect DENY and zero usable signature outputs.¶
Technical coverage limitation. If the host has a separately usable private key or can reprogram protected signing policy, this boundary does not prevent the alternate path.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-01 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-01 / Native operation test: the adversarial branch considered here is that a compromised service credential or host changes a native withdrawal beneficiary, account, network, or amount. The execution-time verifier must evaluate whether the signing service reads protected approval independently and checks exact native transfer data rather than a caller summary. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-01 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-01 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; independent unrestricted raw-key or emergency signer operation is outside the protected boundary.¶
TM-01 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-01 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (verified_principal(a) and e.account == a.account): DENY_NO_E\ \FFECT if not (e.recipient in a.allowed_recipients and e.amount_minor <= a.\ \max_minor): DENY_NO_EFFECT if not (e.signing_preimage_digest == sink.reconstructed_digest): DEN\ \Y_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-01).¶
Protected asset and consequence. non-exportable key control and permission to issue a particular signature.¶
Attacker capability and trust assumptions. attacker cannot extract the secret key but can request a signing operation through a high-privilege internal interface.¶
Authorized operation. signer authorizes exact amount, recipient, fee, chain and operation type.¶
Plausible unauthorized pathway. signer receives a correctly formatted digest for a different effect or an unrestricted raw-digest request.¶
Why existing protections may fail. Key non-exportability alone proves that the key remains protected at rest, not that every use of it satisfied operational approval.¶
Source basis and evidentiary status. [S04], [S03]. Architectural inference from established key-management and authorization principles. Key protection and incorrect-authorization literature provide background. A non-exportable key used for an unapproved transaction is a constructed separation-of-authority example, not a documented conclusion about an incident. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
internal high-privilege caller (cannot extract key)
| correctly formatted digest for a different effect,
| or unrestricted raw-digest request
v
+---------------- restricted signing boundary ---------------+
| decode native transaction -> derive digest inside boundary |
| cross-check decoding vs authenticated authority |
| bind to signer instance + request-use nonce |
| record protected consumption, then sign |
+------------------------------------------------------------+
no general-purpose digest-signing route is exposed
out of scope: already exported key, pre-existing signature
Constructive protected execution-finality procedure¶
Derive signing digest within restricted boundary from independently read native transaction.¶
Cross-check final decoding against authenticated authority before allowing cryptographic key use.¶
Bind signature capability to exact signer instance and request-use nonce; do not expose a general-purpose digest signing route.¶
Record protected consumption before a signature becomes externally usable.¶
Implementation alternatives and design-around-resistant technical placements. signatures may use HSM, TEE, secure element, threshold module or fixed function cryptographic coprocessor.¶
Failure / recovery behavior. When signature output status is ambiguous, retain the use record and reconcile rather than issuing a new signature.¶
Negative-effect experiment and acceptance criterion. Request a valid signature on an unauthorized digest via all documented signer methods; assert none are produced.¶
Technical coverage limitation. An already exported key or independently valid pre-existing signature remains outside a guard that cannot revoke it.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-02 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-02 / Native operation test: the adversarial branch considered here is that a cryptographically valid signing request carries a financial consequence outside the stored mandate. The execution-time verifier must evaluate whether the restricted signer compares independently protected intent with the actual transaction and available protected use/budget. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-02 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-02 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; availability of an independent sign-anything path cannot be defeated by the guarded API.¶
TM-02 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-02 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (e.signing_preimage_digest == strict_digest_from_native_bytes\ \(e.native)): DENY_NO_EFFECT if not (signer.only_exposes_effect_aware_signing): DENY_NO_EFFECT if not (e.account == a.account and e.recipient == a.recipient): DENY\ \_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-02).¶
Protected asset and consequence. permission to install code and permission for its subsequent financial actions.¶
Attacker capability and trust assumptions. a proposer can obtain or replay a valid account authorization but cannot change protected authority records or an enforced on-chain validation module.¶
Authorized operation. user or custodian approves a defined delegate identity, code digest, privilege scope and expiry.¶
Plausible unauthorized pathway. account is delegated to an executable implementation with different code, upgrades, methods or spend authority.¶
Why existing protections may fail. A protocol-level delegation signature may establish account authority over a code target without separately expressing internal custody constraints; code review cannot by itself bound every future delegated call.¶
Source basis and evidentiary status. [S05]. Documented protocol semantics; malicious scenario hypothetical. EIP-7702 defines executable account delegation and its protocol-level validity. A malicious delegate accepted by a separate business workflow is a possible conditional failure, not an allegation about an identified custodian. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
valid account authorization (obtained or replayed)
|
v
CA-1: install delegate CA-2..n: each delegated effect
verify code digest, upgrade reconstruct and check separately
generation, proxy, methods, at on-chain or exclusive
account and chain identity off-chain sink
| |
+--- changed code, privilege escalation, unknown nested
call, expired delegation --> DENY
limit: off-chain signer cannot stop already-installed
unrestricted code without an on-chain enforcement rule
Constructive protected execution-finality procedure¶
Represent delegate installation as its own Candidate Act, separately from a transfer.¶
Validate target code digest, upgrade generation, proxy implementation, authorized method set and account/chain identity before effective authorization release.¶
Require each subsequent delegated financial effect to be separately reconstructed and checked, with an enforceable on-chain or exclusive off-chain sink.¶
Deny changed code, privilege escalation, unrecognized nested call and expired delegation.¶
Implementation alternatives and design-around-resistant technical placements. guarded account modules, restricted off-chain signer, on-chain spend validator, fixed-code implementation, immutable policy-controlled proxy.¶
Failure / recovery behavior. On delegation revocation or code upgrade, invalidate policy generation and all future-use handles; reconcile already committed effects.¶
Negative-effect experiment and acceptance criterion. Install an unauthorized executable implementation with otherwise valid cryptographic syntax, and separately test an allowed installation followed by forbidden nested transfer.¶
Technical coverage limitation. An off-chain signer cannot stop transactions by already installed unrestricted code unless an actual on-chain enforcement rule exists.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-03 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-03 / Native operation test: the adversarial branch considered here is that a signed executable-account delegation targets a different code digest, method scope, upgrade generation, or financial privilege. The execution-time verifier must evaluate whether the delegation installation and every later delegated effect are separately checked at an effective account/signing boundary. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-03 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-03 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; previously unrestricted on-chain delegated execution cannot be stopped by an off-chain gateway alone.¶
TM-03 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-03 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (e.delegation_target == a.delegation_target): DENY_NO_EFFECT if not (e.code_digest == a.code_digest and e.upgrade_epoch == a.upgr\ \ade_epoch): DENY_NO_EFFECT if not (e.delegated_methods <= a.permitted_methods): DENY_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-03).¶
Protected asset and consequence. integrity of final native transfer semantics.¶
Attacker capability and trust assumptions. attacker controls routing, conversion or serialization between an approval UI and a signer.¶
Authorized operation. approved representation and final signed data describe the same economic operation.¶
Plausible unauthorized pathway. fee selection, contract calldata, account alias resolution, amount precision or recipient changes after approval.¶
Why existing protections may fail. Human approval screenshots and high-level summaries do not prove final serialized effect; integrity of transport only preserves altered data.¶
Source basis and evidentiary status. [S06], [S03]. Established weakness class; payment-specific extension hypothetical. TOCTOU is a documented weakness class. A mutable payment builder, altered recipient or post-approval serialization is an application-specific threat construction. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
approval UI ---> router / converter / serializer ---> signer
(shows A) attacker changes fee, calldata, (gets A')
alias, precision or recipient
|
PED-1: normalized typed limits |
v
PED-2: strict decode of FINAL bytes -> recipient, token,
amount, network, fee, selector
unknown extension / ambiguous decimals / unsupported
semantics / non-equivalent transform -> DENY
no mutable transformation between verification and effect
Constructive protected execution-finality procedure¶
Record normalized, typed authorization limits in PED-1.¶
Strictly decode final native bytes at PED-2 and derive actual recipient, token, amount, network, fee and invoked selector.¶
Reject unknown critical extensions, ambiguous decimals, unsupported contract semantics or non-equivalent transformations.¶
Allow no further mutable transformation between verification and restricted effectuation.¶
Implementation alternatives and design-around-resistant technical placements. native transaction parser within HSM wrapper, network protocol sink adapter, guarded contract dispatch function.¶
Failure / recovery behavior. Changed intent requires new protected authority; malformed or ambiguous native data must not default to approval.¶
Negative-effect experiment and acceptance criterion. Modify nested call data and asset decimal scale while keeping displayed payee label fixed; assert no signature or dispatch.¶
Technical coverage limitation. Without a trusted decoder for particular arbitrary programmable code effects, the implementation must restrict that code or decline the operation.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-04 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-04 / Native operation test: the adversarial branch considered here is that the transaction builder changes native payee, amount, chain, or method after approval but before irreversible release. The execution-time verifier must evaluate whether the sink independently parses the last native bytes, rechecks protected equality and current authorization, and closes the check-to-use interval. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-04 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-04 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; a subsequent unguarded mutation after the last effective check makes that path unprotected.¶
TM-04 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-04 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (e.native_recipient == a.recipient): DENY_NO_EFFECT if not (e.asset == a.asset and e.network == a.network): DENY_NO_EFFE\ \CT if not (no_unverified_mutable_transform_between(e, sink)): DENY_NO_E\ \FFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-04).¶
Protected asset and consequence. aggregate authorized treasury budget and independently held custody resources.¶
Attacker capability and trust assumptions. attacker schedules parallel withdrawals through independent wallets and chain-specific signers.¶
Authorized operation. global limit applies to all participating protected custody operations.¶
Plausible unauthorized pathway. each signer observes the same apparent available amount and approves separately, yielding aggregate overuse.¶
Why existing protections may fail. Per-request ceilings and eventually consistent caches may individually succeed even when their sum violates the intended protected total.¶
Source basis and evidentiary status. [S07]. Established race-condition principle; multi-wallet case hypothetical. A shared quota checked without atomic synchronization can be raced; separate wallets and networks are an illustrative distributed accounting environment. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
wallet A / chain 1 --+ option 1: serialized
wallet B / chain 2 --+--> common durable quota record
wallet C / chain 3 --+ budget scope option 2: disjoint escrow
+ auth gen slices E1 + E2 + E3 <= B
|
consume local share BEFORE the effect; fence stale signers
uncertain outcome -> reservation kept until evidence
without control: each signer sees same balance -> overuse
Constructive protected execution-finality procedure¶
Bind every protected operation to common budget scope and authorization generation.¶
Use a serialized durable quota record or disjoint escrow slices distributed to each chain-domain signer.¶
Consume local share before the corresponding effect and fence stale signers from reused shares.¶
Maintain uncertainty reservations until remote effect evidence supports release.¶
Implementation alternatives and design-around-resistant technical placements. central protected SQL transaction, consensus-backed quota service, HSM counters, disjoint pre-reserved escrow between regions.¶
Failure / recovery behavior. Partitioned regions stop spending upon escrow exhaustion; no automatic reset on unacknowledged transfer.¶
Negative-effect experiment and acceptance criterion. Race two candidate withdrawals each valid independently but invalid in aggregate; assert maximum effective total remains inside protected quota.¶
Technical coverage limitation. If one signer outside the declared budget domain can freely spend the same asset, aggregate constraint is not enforced globally.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-05 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-05 / Native operation test: the adversarial branch considered here is that parallel wallets or networks reserve or debit more than the same protected aggregate authorization. The execution-time verifier must evaluate whether the aggregate committed-plus-reserved accounting is serialized, or independently bounded escrow prevents double reservation. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-05 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-05 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; partitioned control without disjoint escrow or reconciliation does not establish a shared global spending cap.¶
TM-05 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-05 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (e.amount_minor <= protected_escrow_for(e.wallet, e.network))\ \: DENY_NO_EFFECT if not (total_committed_and_reserved(a.budget_scope) + e.amount_mino\ \r <= a.budget_minor): DENY_NO_EFFECT if not (all_participants_are_fenced_to_current_generation): DENY_NO_\ \EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-05).¶
Protected asset and consequence. threshold signing authority, nonce generation and signer participant policies.¶
Attacker capability and trust assumptions. attacker controls coordinator or one participant but not the threshold of independently enforcing participants.¶
Authorized operation. t-of-n participants authorize same exact operation digest and policy generation.¶
Plausible unauthorized pathway. coordinator submits inconsistent preimages, reuses abandoned sessions or downgrades roster/approval evidence.¶
Why existing protections may fail. Threshold cryptography divides key material but participants which only authenticate a coordinator might still sign a collectively unauthorized exact effect.¶
Source basis and evidentiary status. [S08], [S04]. Documented threshold-signature roles; application-policy failure hypothetical. RFC 9591 explains threshold signing and coordinator roles, with participant input validation. The scenario assumes a deficient application-level policy wrapper; it does not claim a vulnerability in FROST itself. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
coordinator (possibly compromised)
| inconsistent preimages, reused sessions,
| downgraded roster or approval evidence
+--------+--------+-----------------+
v v v
participant 1 participant 2 participant t
decode/verify decode/verify decode/verify
same final same final same final
digest + policy digest + policy digest + policy
| share bound to session id, roster, nonce gen, sink,
| amount; commit prevents nonce/share reuse
+--------+--------+-----------------+
v
final signature only from a protected completed quorum
Constructive protected execution-finality procedure¶
Each protected participant independently decodes or verifies the same final-operation digest and policy generation.¶
Share release binds session ID, participant roster, nonce generation, sink identity and permitted amount.¶
Signer commit prevents nonce/share reuse; abandoned sessions and stale participant generations are fenced.¶
Only protected completed quorum can release the final signature.¶
Implementation alternatives and design-around-resistant technical placements. distributed MPC protocol, HSM-backed quorum service, dual custody approval with independent verifier.¶
Failure / recovery behavior. Coordinator restart requires a new fenced signing session and preserved used-nonce state.¶
Negative-effect experiment and acceptance criterion. Supply two distinct preimage digests to participant set within same session; expect no valid threshold signature.¶
Technical coverage limitation. If threshold participants share compromised authority data or an attacker controls enough participants, stated protection can fail.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-06 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-06 / Native operation test: the adversarial branch considered here is that a threshold signing coordinator substitutes session data, a signer role, transaction digest, or authorized participant set. The execution-time verifier must evaluate whether every relevant threshold participant independently verifies exact authorized native effect, protected quorum and session generation. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-06 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-06 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; a threshold implementation whose raw shares can be used elsewhere bypasses coordinator-only checks.¶
TM-06 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-06 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (all_participants_use_identical_effect_digest): DENY_NO_EFFECT if not (current_participant_roster == a.authorized_roster): DENY_NO_\ \EFFECT if not (signing_session_nonce_not_previously_used): DENY_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-06).¶
Protected asset and consequence. single- or bounded-use delegation and native authorization nonce.¶
Attacker capability and trust assumptions. attacker can replay or submit multiple nonce variants and valid-looking authorization statements.¶
Authorized operation. exact authorized transaction may be used only within explicitly permitted count, nonce and window.¶
Plausible unauthorized pathway. multiple signed variants or saved artifacts are exercised against changing account nonces to obtain persistent authority.¶
Why existing protections may fail. A chain-level nonce prevents some duplicate transactions but may not establish single-use of the separate business authorization or prevent pre-authorized nonce fan-out.¶
Source basis and evidentiary status. [S05], [S09]. Protocol-derived and replay-derived hypothesis. EIP-7702 specifies authorization tuples and nonce handling, while CWE-294 documents generic replay risk. Coordinated nonce fan-out or unauthorized use of multiple signed variants remains an engineered threat hypothesis. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
signed variants v1, v2, v3 ... (nonce n, n+1, n+2 ...)
|
v
protected authorization-use id (independent of chain nonce)
| each nonce / delegation code bound to its own policy
| and use budget, or an explicit finite set
v
signing / account sink: consume business-use state
(even if the nonce itself is valid)
expiry, revocation, account-generation change -> unused
authorizations invalidated
Constructive protected execution-finality procedure¶
Allocate unique protected authorization-use ID independent of chain nonce.¶
Bind each proposed nonce and delegation code to its own policy and use budget or explicitly bound finite set.¶
Consume business-use state at the signing/account sink regardless of nonce validity.¶
Invalidate unused authorizations on expiry, revocation or change of account generation.¶
Implementation alternatives and design-around-resistant technical placements. sink-local used-identifier store, programmable account usage counter, signed one-use state proof checked on-chain.¶
Failure / recovery behavior. A malformed external nonce does not silently burn arbitrary unrelated account nonce space; only an authentically allocated local use ID may be consumed.¶
Negative-effect experiment and acceptance criterion. Present two different native nonces under one exact-use authorization and attempt parallel replay; expect at most one permitted release.¶
Technical coverage limitation. Unrestricted already valid signed authorizations released before the protected system was deployed cannot be retroactively constrained off-chain.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-07 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-07 / Native operation test: the adversarial branch considered here is that valid delegations, nonces, or previously accepted use records are replayed or fanned out through another domain. The execution-time verifier must evaluate whether use identity, nonce scope, chain/account binding, and monotonic protected consumption are checked at the actual effect boundary. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-07 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-07 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; a second unguarded ledger route is not fenced by consumption in the first domain.¶
TM-07 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-07 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (e.use_id == a.use_id and e.native_nonce in a.allowed_nonces)\ \: DENY_NO_EFFECT if not (a.use_id not in sink.protected_used_identifiers): DENY_NO_EF\ \FECT if not (number_of_released_nonce_variants(a.use_id) == 0): DENY_NO_E\ \FFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-07).¶
Protected asset and consequence. completeness of transaction finality enforcement.¶
Attacker capability and trust assumptions. attacker discovers a legacy API, recovery key, failover process, emergency procedure or direct contract execution route.¶
Authorized operation. every effect-producing call requires equivalent protected finality predicates.¶
Plausible unauthorized pathway. a normally denied act is signed or sent through an alternate privileged path.¶
Why existing protections may fail. An API gateway or primary signing wrapper may be non-bypassable for its own route but not for unrelated signing or account-execution paths.¶
Source basis and evidentiary status. [S03], [S01]. Author-defined consequence-path completeness hypothesis. An alternate signer is considered under a defined threat model when different effective paths do not enforce the same authorization. No listed public source reports that a particular organization had such a route. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
principal --> privilege --> key --> release interface --> effect normal API -------> [gate] ----+ legacy API -------> [gate] ----+ recovery key -----> [gate] ----+---> asset-moving sink region failover --> [gate] ----+ direct contract --> [gate] ----+ every reachable path from a compromised or requesting domain must cross a gate; otherwise disable it, or narrow the stated coverage; negative-effect test per path
Constructive protected execution-finality procedure¶
Construct a directed graph of principal, privilege, signing key, release interface and effect paths.¶
Identify all reachable paths from compromised/requesting domains to the effective asset-moving sink.¶
Disable or gate raw signing, backup key, recovery, contract dispatch and region fallback.¶
Run negative-effect tests against each path; narrow coverage if exclusivity cannot be established.¶
Implementation alternatives and design-around-resistant technical placements. key rotation to restricted keys, smart-contract-only spending path, security-module access policy, operating-system kernel control.¶
Failure / recovery behavior. If a bypass is discovered, suspend claimed exclusivity and fence affected signing credentials pending remediation.¶
Negative-effect experiment and acceptance criterion. Attempt a denied withdrawal through primary API, maintenance signer, backup region and direct contract method; assert no equivalent effect.¶
Technical coverage limitation. A genuinely independent key or account path remains a counterexample unless technically controlled.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-08 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-08 / Native operation test: the adversarial branch considered here is that an operator sends the same spend through a backup signer, emergency key, administrative API, or maintenance route. The execution-time verifier must evaluate whether the deployment inventories all effective paths and forces every in-scope route through equivalent protected enforcement. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-08 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-08 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; an uncovered independent route is an explicitly unprotected path, not an implicit success.¶
TM-08 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-08 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (all_reachable_effect_paths_are_enforced_or_disabled): DENY_N\ \O_EFFECT if not (restricted_key_route_is_exclusive): DENY_NO_EFFECT if not (backup_and_admin_signer_generation_is_current): DENY_NO_EFFE\ \CT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-08).¶
Protected asset and consequence. control of future deposits and delegated recurring spending authority.¶
Attacker capability and trust assumptions. attacker can benefit from a prior code delegation after the initial balance changes.¶
Authorized operation. one bounded authorization applies only to specified transfer and duration.¶
Plausible unauthorized pathway. delegated code remains active and transfers later deposits even without new user action.¶
Why existing protections may fail. Checking only initial delegate installation or original balance does not restrict later on-chain calls against newly credited balance.¶
Source basis and evidentiary status. [S05]. Protocol-derived behavior; persistence scenario hypothetical. EIP-7702 states that delegated accounts may experience balance decreases from calls other than the account-originating transaction. An unbounded delegate acting on later deposited value is a logical security scenario, not an independently documented incident. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
t0: delegate installed (one Candidate Act)
t1: deposit arrives (balance-change event, not authority)
t2: delegated code proposes transfer
|
v
account execution boundary: call-time reconstruction,
per-call and cumulative limits, code-generation continuity,
revocation, expiry --> bounded spend or DENY
unrestricted downstream code -> limit or remove delegation;
off-chain observation alone is insufficient
Constructive protected execution-finality procedure¶
Separate delegate installation, each subsequent spending act and balance-change events.¶
Require call-time reconstruction and bounded spend against protected delegation policy.¶
Maintain cumulative limits, code-generation continuity, revocation and expiry at actual account execution boundary.¶
Where automatic downstream code is unrestricted, limit or remove delegation rather than relying on off-chain observations.¶
Implementation alternatives and design-around-resistant technical placements. on-chain policy module with per-call use counter, capability-limited delegation implementation, immutable account spending gate.¶
Failure / recovery behavior. Pending funds are not automatically considered authorized to spend; release requires current on-chain or exclusive signer policy.¶
Negative-effect experiment and acceptance criterion. Install initially approved delegate then credit additional funds and attempt fresh unauthorized transfer; assert blocked at guarded account.¶
Technical coverage limitation. If delegated code has already obtained unrestricted on-chain authority, an off-chain control alone is insufficient.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-09 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-09 / Native operation test: the adversarial branch considered here is that persistently delegated code spends funds deposited after an earlier off-chain authorization has expired. The execution-time verifier must evaluate whether each new delegated effective act is checked against current on-chain or otherwise exclusive execution enforcement. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-09 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-09 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; if installed code has unconditional authority, an off-chain policy update cannot stop later effects.¶
TM-09 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-09 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (e.delegation_epoch == a.delegation_epoch): DENY_NO_EFFECT if not (e.method in a.permitted_methods): DENY_NO_EFFECT if not (e.amount_minor + prior_delegate_spend <= a.delegate_cumulati\ \ve_limit): DENY_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-09).¶
Protected asset and consequence. freshness of protected approvals and signer-state versions.¶
Attacker capability and trust assumptions. attacker can force delayed state propagation, old snapshots or region failover.¶
Authorized operation. current denial policy must govern subsequent signing or transfer.¶
Plausible unauthorized pathway. stale region accepts an authorization after it has been revoked elsewhere.¶
Why existing protections may fail. Cached policy decisions and ordinary signed tokens may remain cryptographically valid after local revocation or rollback.¶
Source basis and evidentiary status. [S03], [S13]. Author-defined distributed-state hypothesis. Authorization and workflow correctness provide the technical basis for a freshness and failover test. The stale-region/revocation-epoch example is a distributed-systems construction; these sources do not document that exact exploit. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
authoritative epoch (illustrative): policy gen G7, revocation V12
| |
region 1 (current: G7, V12) region 2 (stale: G6, V11)
| |
sink verifies freshness sink: stale -> fenced from key
-> may release use; restored snapshot fenced
cannot establish current state -> fail closed or PENDING
offline lease: only pre-agreed risk limits
Constructive protected execution-finality procedure¶
Bind authority to monotonically increasing revocation and policy generations.¶
At protected sink verify freshness against authoritative epoch or bounded delegated lease.¶
Fence stale replicas, region leaders and restored snapshots from key use.¶
Fail closed or remain pending when current state cannot be established.¶
Implementation alternatives and design-around-resistant technical placements. monotonic hardware counter, quorum policy state, lease-expiring HSM key capability, signed leader epoch.¶
Failure / recovery behavior. Recovery from old snapshot must reconcile with higher protected generation and may not simply revive earlier authorizations.¶
Negative-effect experiment and acceptance criterion. Revoke permission, restore old signer snapshot, partition network and attempt release; assert no effect on stale generation.¶
Technical coverage limitation. Offline leases permit only pre-agreed risk limits; unconditional global freshness during network partition is not assumed.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-10 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-10 / Native operation test: the adversarial branch considered here is that regional failover, replicated policy cache, or rollback allows a formerly approved request after revocation. The execution-time verifier must evaluate whether sink-local policy generation, revocation freshness, monotonic epoch and failover fencing are checked before release. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-10 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-10 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; inability to authenticate fresh policy state requires fail-closed treatment, not optimistic continuation.¶
TM-10 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-10 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (sink.protected_epoch >= a.required_epoch): DENY_NO_EFFECT if not (a.revocation_epoch == sink.current_revocation_epoch): DENY_N\ \O_EFFECT if not (no_stale_replica_can_exercise_key_use): DENY_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-10).¶
Protected asset and consequence. one-use authority across retries and uncertain downstream outcomes.¶
Attacker capability and trust assumptions. attacker manipulates timeout, acknowledgment and retry scheduler without modifying protected journal.¶
Authorized operation. one approved act causes at most one effective initiation within controlled boundary.¶
Plausible unauthorized pathway. signer releases an effective command, crashes, then scheduler retries with new request ID after no acknowledgment.¶
Why existing protections may fail. Conventional idempotency at caller level can fail if downstream endpoint does not honor the same key or local state is not durable.¶
Source basis and evidentiary status. [S13], [S07]. Author-defined failure/recovery hypothesis. Out-of-order workflow and concurrency classes provide the technical basis for crash/retry safety. Duplicate external transfers following unknown acknowledgment are synthetic fault-injection scenarios, not traced to a real financial event. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
prepare/use record (exact op + external idempotency id)
|
commit protected consumption --> release effect
| |
| crash / no acknowledgment
v v
OUTCOME_UNKNOWN <--------------------+
|
query authenticated downstream evidence on ORIGINAL id
|
confirmed -> record absent (proven) -> resolve
never: new request id created from the original approval
Constructive protected execution-finality procedure¶
Write durable prepare/use record tied to exact operation and external idempotency identity.¶
Commit protected consumption before or in coordination with effect release.¶
Mark status OUTCOME_UNKNOWN on crash between effect and external observation.¶
Query authenticated downstream evidence; never create a second effective request from original approval alone.¶
Implementation alternatives and design-around-resistant technical placements. transactional outbox plus protected signer, durable HSM operation counter, reconciliation ledger keyed by native transaction.¶
Failure / recovery behavior. Restore ability to act only after supported evidence or new independently authorized operation.¶
Negative-effect experiment and acceptance criterion. Terminate signer immediately after release but before response and restart; ensure effective emission count remains one.¶
Technical coverage limitation. Exactly-once settlement across an external noncooperating rail is not guaranteed by local state alone.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-11 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-11 / Native operation test: the adversarial branch considered here is that a signer crashes after release but before acknowledgment, and retry software submits another effective transfer. The execution-time verifier must evaluate whether a durable operation identity and consumed/unknown state are preserved across restart and downstream status is queried. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-11 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-11 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; local atomicity alone does not prove exactly-once settlement at an independent payment rail.¶
TM-11 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-11 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (a.use_id not in protected_consumed_set): DENY_NO_EFFECT if not (no_outcome_unknown_conflict(a.exact_effect_id)): DENY_NO_EFF\ \ECT if not (native_retry_id_is_bound_to_same_durable_effect_record): DEN\ \Y_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-11).¶
Protected asset and consequence. program behavior actually executed after delegation.¶
Attacker capability and trust assumptions. attacker controls contract implementation upgrade or dependency resolution without control of the protected code-policy root.¶
Authorized operation. authorized code has measured identity and bounded callable functions.¶
Plausible unauthorized pathway. a proxy points to new code or invokes nested delegatecall that expands approved authority.¶
Why existing protections may fail. Valid signature on a proxy address or originally reviewed bytecode may not constrain later implementation or dynamically selected code paths.¶
Source basis and evidentiary status. [S10], [S05]. Documented programmable-account mechanisms; combined scenario hypothetical. ERC-1967 defines mutable proxy implementation paths, while EIP-7702 defines account delegation. Combining a delegating account with upgrade-sensitive executable authority is a conditional design threat, not a proven exploit at a named service. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
approved: implementation digest K0, proxy resolution P0,
upgrade epoch U0, method / nested-call policy
|
execution-relevant boundary reads actual code state
|
K == K0 and U == U0 and selector allowed and
nested calls within policy ?
| yes | no / unknown code change
v v
bounded execution DENY or require new authority
undecidable behavior -> deny or controlled execution mode
Constructive protected execution-finality procedure¶
Bind approved executable implementation digest, proxy resolution and upgrade epoch.¶
Read actual implementation storage or code state at execution-relevant boundary.¶
Apply strict method-selector and nested call policy or restrict to validated execution path.¶
Reject or require new authority after unknown code change.¶
Implementation alternatives and design-around-resistant technical placements. immutable code, runtime code hash checks in account validator, authenticated upgrade registry, guarded execution interpreter.¶
Failure / recovery behavior. On uncertain dependency identity or reorganization, keep act non-effective until valid state proof.¶
Negative-effect experiment and acceptance criterion. Approve proxy then modify implementation and invoke new transfer method; assert denial.¶
Technical coverage limitation. Arbitrary smart-contract behavior may be undecidable from a static parser; deny unknown behavior or employ controlled execution with enforceable effect limits.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-12 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-12 / Native operation test: the adversarial branch considered here is that proxy upgrade, mutable delegate implementation, or nested call changes the effective code or target after permission was collected. The execution-time verifier must evaluate whether effective code digest, implementation generation, nested call authority, and downstream financial effects are revalidated. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-12 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-12 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; a proxy controlled through unguarded on-chain administrator keys remains outside an off-chain-only guarantee.¶
TM-12 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-12 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (e.resolved_implementation_digest == a.approved_code_digest):\ \ DENY_NO_EFFECT if not (e.upgrade_epoch == a.approved_upgrade_epoch): DENY_NO_EFFECT if not (e.nested_call_effects <= a.allowed_effect_envelope): DENY_NO\ \_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-12).¶
Protected asset and consequence. separation of agent computation from payment authority.¶
Attacker capability and trust assumptions. attacker controls retrieved text, supplier messages, browser content or tool results but not independent payment authority.¶
Authorized operation. agent plans within approved economic mandate and only permitted tool effects execute.¶
Plausible unauthorized pathway. malicious content changes amount, wallet address, purpose or approving principal in generated tool call.¶
Why existing protections may fail. Prompt-scanning, agent authentication and tool-API credentials may not prove the actual tool effect matches independently granted financial authority.¶
Source basis and evidentiary status. [S11], [S03]. Established LLM threat class; financial effect scenario hypothetical. OWASP documents prompt injection as a model-behavior risk; an untrusted tool result changing a payment instruction is a hypothetical downstream effect that depends on actual tool privileges. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
untrusted: retrieved text, supplier message, browser page,
tool result
| (may change amount, wallet, purpose, approver)
v
agent / planner output = untrusted Candidate Act (NES)
|
PED-1: authority only from separately verified principal
and policy source
|
PED-2: reconstruct actual native API call and tool action
|
gate at real sink: payment, wallet approval, credential-
assisted egress --> release or DENY
outside scope: unmediated credentials, human payments
Constructive protected execution-finality procedure¶
Treat planner output and retrieved instructions as untrusted Candidate Acts.¶
PED-1 accepts protected authority only from separately verified principal/policy source.¶
PED-2 reconstructs actual native API call and downstream tool action.¶
Gate payments, wallet approvals and credential-assisted egress at real effectuation sink.¶
Implementation alternatives and design-around-resistant technical placements. isolated tool gateway, HSM-backed payment proxy, guarded browser/payment API, on-chain account validator.¶
Failure / recovery behavior. Untrusted instruction lineage cannot be upgraded into fresh authorization by a model summary or replayed approval.¶
Negative-effect experiment and acceptance criterion. Inject vendor page instruction to change wallet destination while valid agent token persists; expect zero unauthorized payment release.¶
Technical coverage limitation. The gate cannot constrain unrelated unmediated credentials, external human payment actions or independent agent tool paths.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-13 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-13 / Native operation test: the adversarial branch considered here is that prompt injection or tool-output laundering causes an authenticated AI agent to submit an unauthorized financial tool call. The execution-time verifier must evaluate whether authority comes from independently authenticated protected records and the last actual native call is verified at the tool or signing sink. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-13 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-13 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; a logging-only approval, or an agent with uncontrolled secret access, does not enforce the proposed prevention.¶
TM-13 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-13 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (authority_origin_is_independent_of_agent_text(a)): DENY_NO_E\ \FFECT if not (e.merchant == a.authorized_merchant): DENY_NO_EFFECT if not (e.amount_minor <= a.maximum_price_minor and e.payment_tool =\ \= a.allowed_payment_tool): DENY_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-13).¶
Protected asset and consequence. underlying economic obligation across swaps, bridges and settlement legs.¶
Attacker capability and trust assumptions. attacker changes bridge route, receives provisional proof, or exploits uncertain source-chain confirmation.¶
Authorized operation. approved source debit and destination credit remain within bounds and independently evidenced.¶
Plausible unauthorized pathway. one leg is announced successful but not final, or slippage changes amount or destination, while next leg releases.¶
Why existing protections may fail. A local allowed receipt or source event log is not necessarily irreversible settlement; naive swaps may authorize downstream credits before trustworthy source finality.¶
Source basis and evidentiary status. [S12], [S13]. Established finality concepts; cross-domain consequence hypothesis. Ethereum documents consensus finality and reorganization behavior. A bridge or settlement adapter trusting an insufficiently finalized event is a cross-domain reasoning scenario; no particular bridge vulnerability is claimed. These sources support only the stated generic behavior or weakness class and do not establish this attack path at a specific financial institution.¶
leg 1 (source) leg 2 (conversion) leg 3 (destination)
typed obligation typed obligation typed obligation
| | |
reconstruct assets, fees, slippage, bridge identity, recipient,
consensus-finality evidence for each leg
| | |
consume bounded authority separately at each controlled sink
|
upstream finality contested / provisional?
yes -> no dependent unconditional release, or explicit
risk-bounded escrow
no -> release next leg
Constructive protected execution-finality procedure¶
Represent every effective leg as a typed financial obligation transition.¶
Reconstruct source and destination assets, fees, slippage, bridge identity, recipient and relevant consensus-finality evidence.¶
Consume bounded authority separately at each controlled effect sink.¶
If upstream finality remains contested, prohibit dependent unconditional release or use an explicit risk-bounded escrow alternative.¶
Implementation alternatives and design-around-resistant technical placements. coordinated bank-style settlement, on-chain HTLC/escrow, finality proof verifier, protected bridge signer.¶
Failure / recovery behavior. Keep independently reconciled source and destination states, handle reorgs and partial release without inventing global atomicity.¶
Negative-effect experiment and acceptance criterion. Inject stale source proof, altered destination and bridge reorganization in controlled ledger model; assert no unauthorized dependent payout.¶
Technical coverage limitation. Independent ledgers or validators without cooperation cannot guarantee atomic finality by an off-chain assertion.¶
Textual Decision and State-Transition Workflow (YES / NO / UNKNOWN)¶
TM-14 / Candidate held: obtain independent protected approval and record the bounded act in Non-Effective State; do not give the untrusted planner, host or caller unrestricted authority. If the originating authority or supported sink is missing, the decision is NO: DENY_NO_EFFECT.¶
TM-14 / Native operation test: the adversarial branch considered here is that cross-chain transfer, exchange conversion, or provisional receipt is mislabeled as final economic settlement. The execution-time verifier must evaluate whether each independently consequential source and destination leg has authenticated finality evidence and a controlled local release. YES: continue only to the remaining protected predicates. NO, ambiguous parser output, changed effective identity or absent independent evidence: DENY_NO_EFFECT.¶
TM-14 / Protected state test: is policy generation current; is revocation/freshness satisfied; is nonce or use identity unconsumed; and is cumulative reserved-plus-committed exposure within its bound? YES: perform protected reservation or single-use consumption as prescribed by the source profile. NO or stale protected state: DENY_NO_EFFECT.¶
TM-14 / Consequence boundary test: does the enforcement component actually control the signing, contract, dispatch or account effect that is about to become effective? YES: permit only the verified operation with its bound scope. NO: withhold any controlled release and report the limitation; one ledger receipt cannot guarantee external bank settlement or unwind an independently irreversible leg.¶
TM-14 / Outcome branch: if authenticated evidence confirms an authorized controlled effect, record its exact use and effect-specific status. If a crash, timeout, remote-leg uncertainty or provisional confirmation occurs, keep the same use fenced as OUTCOME_UNKNOWN/PENDING/PROVISIONAL where applicable, query authentic evidence, and do not generate a new effective act merely on retry.¶
TM-14 / Negative-effect test: submit the model-specific unauthorized mutation and monitor the actual final sink, not only the outer API return. Acceptance requires no unauthorized effective release through governed paths; a positive-control authorized operation may succeed under all predicates.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== authority := PED1.read_independently_authenticated_authority(candida\ \te) actual := PED2.parse_native_sink_operation(sink.pending_bytes) if authority is absent or actual is undecodable: DENY_NO_EFFECT if not (e.route in a.permitted_routes): DENY_NO_EFFECT if not (e.destination == a.destination and e.net_value >= a.minimum_\ \net_value): DENY_NO_EFFECT if not (dependent_release_requires_accepted_source_finality_proof): \ \DENY_NO_EFFECT if not sink.protected_state.current(authority): DENY_NO_EFFECT if not sink.protected_state.available_exact_use_and_budget(authority\ \, actual): DENY_NO_EFFECT sink.atomic_consume_authority_and_release_bounded_effect(authority, \ \actual) return EFFECT_RELEASED_WITH_EXTERNAL_OUTCOME_UNKNOWN
Related enforcement points: see Section 10 (families citing TM-14).¶
class added execution-finality requirement
---------------------------- ------------------------------------
01 identity / MFA exact-effect mandate + sink check
02 TLS / authenticated API reconstruct sink-facing operation
03 signatures / ledger typed semantics before signature
04 HSM / TEE keys effect-aware verify-and-sign; route
exclusivity
05 threshold / MPC identical digest + current policy
per share release
06 wallet allowlist code digest, upgrade epoch, per-call
07 static ceilings serialization or disjoint escrow
08 API gateway / WAF close all effect-capable paths
09 fraud / anomaly score non-effective hold, enforced denial
10 log / audit / reconcile receipt paired with release gate
11 delegation audit bind implementation, each action
12 manual / timelock / 4-eyes PED-2 on final bytes at the gate
13 revocation cache/failover sink epoch fencing, fail closed
The following are conditional gaps, not assertions that the named class of security technology is inherently ineffective or that any particular implementation has such a defect. A correctly implemented signing HSM, smart contract or multi-party approval system may itself incorporate execution-time semantic enforcement; in that case the corresponding gap is absent.¶
A security solution designed for identity, encrypted transport, signature validity, account administration or forensic monitoring addresses a different technical property from reconstructing exact effect and controlling the final effective boundary. Gap analysis is performed per trust assumption and effect class.¶
Conventional assurance supplied: User/session authenticity.¶
Conditional failure mode: Valid operator credentials may coexist with an unauthorized final transaction; absence of transaction-specific authorization.¶
Execution-finality technical requirement: Combine independently authenticated exact-effect mandate with sink verification.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Channel integrity and server identity.¶
Conditional failure mode: The trusted channel transports a changed operation faithfully; trusted API callers can request impermissible effects.¶
Execution-finality technical requirement: Reconstruct actual sink-facing operation and compare with approved effect.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Key possession and signed-preimage integrity.¶
Conditional failure mode: Valid signing does not imply that code delegation or payee is business-authorized.¶
Execution-finality technical requirement: Verify typed operation semantics before restricted signature release.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Prevent direct key extraction.¶
Conditional failure mode: Privileged service may legitimately ask protected key to sign unintended digest.¶
Execution-finality technical requirement: Expose only effect-aware verify-and-sign, enforce key-route exclusivity.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Distribute signing control.¶
Conditional failure mode: Participants may rely on shared coordinator or check different preimages or stale policies.¶
Execution-finality technical requirement: Each effective share release validates identical digest and current policy.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Fixed destinations or contracts.¶
Conditional failure mode: Mutable delegation implementation or nested calls may reach other recipients.¶
Execution-finality technical requirement: Check code digest, upgrade epoch and downstream per-call effects.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Bound a single operation.¶
Conditional failure mode: Concurrent signers may each see the same unused quota and collectively exceed it.¶
Execution-finality technical requirement: Protected serialization or disjoint escrow accounting.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Filter exposed requests.¶
Conditional failure mode: Alternate direct signer or privileged administrative route may bypass ingress gateway.¶
Execution-finality technical requirement: Enumerate and close all effect-capable paths or narrow deployment coverage.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Detect unusual patterns.¶
Conditional failure mode: Monitoring may occur after an irreversible signature or transfer.¶
Execution-finality technical requirement: Non-effective hold state and enforced denial before effect.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Record subsequent evidence.¶
Conditional failure mode: Receipt is not proof of authority; confirmation after effect cannot prevent first release.¶
Execution-finality technical requirement: Protected decision receipt paired with actual release gate, external outcome distinct.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Review initial code.¶
Conditional failure mode: Code may later be upgraded or executed under broader privileges than approved.¶
Execution-finality technical requirement: Bind implementation identity and enforce each downstream action.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Introduce process checkpoints.¶
Conditional failure mode: Approved summary may diverge from final bytes; emergency bypass might skip normal checks.¶
Execution-finality technical requirement: PED-2 reconstructs final bytes at actual effective gate and enforces fallback.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
Conventional assurance supplied: Improve availability and policy propagation.¶
Conditional failure mode: Stale region may continue accepting expired permissions during partition.¶
Execution-finality technical requirement: Sink epoch fencing and fail-closed unknown state.¶
Protection is maintained where the conventional control independently implements the same exact-effect, current-state and non-bypassability predicates; this document does not require discarding that control.¶
A Protected Transaction Authority Record (PTAR) is an illustrative typed record that contains an independently authenticated principal and tenant, account or wallet binding, operation kind, permitted recipient, asset and amount constraints, chain or network domain, authorized delegate identity and upgrade generation where applicable, policy and revocation epochs, allowed nonce or use identity, expiry, maximum cumulative spend, sink identity and cryptographically protected provenance. PTAR is a local illustrative name for a structured form of the previously described protected authority; an implementation may use an opaque reference or another authenticated format.¶
An Execution-Facing Effect Descriptor (EFED) is reconstructed from the actual signing preimage, native call bytes, decoded executable delegation or ledger-facing command. EFED includes all effect-critical fields and critical extensions under a versioned parser. It is not merely a model-generated explanation or an upstream UI summary.¶
A Finality Decision Record (FDR) records a protected decision identifier, PTAR reference, EFED digest, sink identity, state version, consumed use identifier and status such as DENY, RESERVED, EFFECT_RELEASED, OUTCOME_UNKNOWN or RECONCILED. A positive local FDR states what was permitted at that sink and is not by itself evidence that a remote transaction reached financial settlement.¶
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
{
"ptar": {
"authorization_id": "A-100", "tenant": "T-1", "principal": "P-1",
"source_account": "W-1", "sink_id": "S-1", "operation": "transfe\
\r",
"network": "chain-1", "asset": "asset-1", "recipient": "payee-1",
"amount_max_minor": 700, "budget_minor": 1000, "nonce": "n-1",
"policy_epoch": 8, "revocation_epoch": 3, "expiry": "expiry-1",
"delegation": {"code_digest": "approved-digest", "upgrade_epoch"\
\: 0,
"permitted_methods": ["bounded_transfer"]}
},
"efed": {
"source_account": "W-1", "sink_id": "S-1", "operation": "transfe\
\r",
"network": "chain-1", "asset": "asset-1", "recipient": "payee-1",
"amount_minor": 600, "nonce": "n-1", "native_bytes_digest": "nat\
\ive-digest"
},
"fdr": {"authorization_id": "A-100", "decision": "EFFECT_RELEASED",
"protected_use_state": "CONSUMED", "external_outcome": "UN\
\KNOWN"}
}
PTAR (protected, PED-1) EFED (reconstructed, PED-2)
+---------------------------+ +------------------------------+
| principal, tenant | | effect-critical fields from |
| account / wallet | | signing preimage, native |
| operation kind | | call bytes, decoded |
| recipient, asset, amount | | delegation or ledger command |
| chain / network domain | | + critical extensions |
| delegate id, upgrade gen | | (versioned parser; not a |
| policy, revocation epochs | | model or UI summary) |
| nonce / use id, expiry, | +------------------------------+
| cumulative maximum | |
+---------------------------+ |
+---------> compare <-----------+
|
v
FDR: decision id, PTAR ref, EFED digest, sink id, state
version, consumed use id, status: DENY | RESERVED |
EFFECT_RELEASED | OUTCOME_UNKNOWN | RECONCILED
(local decision; not proof of remote settlement)
The following steps form a representative implementation of the existing underlying execution-finality architecture specialized for the threat conditions disclosed here. The steps are functional dependencies rather than a mandatory physical order; independent reconstruction and protected consumption must occur before the relevant controlled effectuation boundary. A supported on-chain variant may use a contract-state transition instead of an off-chain signing wrapper.¶
Step S-01: Enumerate effect-capable signing, dispatch, account-delegation, privileged API and recovery paths for the deployment; identify which path or paths the apparatus exclusively mediates.¶
Step S-02: In PED-1 receive an independently authenticated authority, determine authorized principal and protected intent, encode allowable exact effects or explicit bounded variations, and bind sink, account, domain, policy, nonce, budget and time restrictions.¶
Step S-03: Preserve each proposed transfer or delegation as a Candidate Act in a Non-Effective State (unsigned buffer, guarded signing queue, restricted command queue or pending account operation).¶
Step S-04: At the selected effectuation boundary, PED-2 obtain the final native serialized representation, independently derive semantic effect attributes, and identify executable code hash, delegate upgrade generation and nested calls when applicable.¶
Step S-05: Reject unrecognized critical fields, ambiguous numeric scales, unverifiable code identity, changed recipient, changed network, altered calldata, unknown request lineage or inconsistent derived economic effect.¶
Step S-06: Verify authenticated protected authority, current policy and revocation epoch, expiry, sink identity, device or signer generation, delegation limits and exact/ bounded effect equality.¶
Step S-07: Acquire a protected serialization point or disjoint escrow reservation so overlapping wallets, workers and chains cannot collectively exceed the same authorized budget, where their common budget is within the deployment trust scope.¶
Step S-08: Derive or validate an operation-specific, non-bearer EH bound to the candidate, effect, authorized entity, sink, generation, nonce and protected use state; its copied bytes alone are insufficient.¶
Step S-09: In a durable single-use state transition, consume or reserve EH authority before or in coordination with releasing the sole effective signature, transaction dispatch or guarded account operation.¶
Step S-10: For delegated account designs, repeat operation-specific verification when delegated code later proposes consequential effects, using an actual on-chain guard or an off-chain enforcement path that really remains exclusive.¶
Step S-11: Emit a typed local FDR and separately track downstream acceptance, inclusion, confirmation and settlement; maintain OUTCOME_UNKNOWN after a crash or missing acknowledgment.¶
Step S-12: Enumerate key export, raw-signature APIs, backup signers, administrative recovery, regional failover and direct contract-call routes; fail a negative-effect test or narrow deployment claims if they can produce equivalent effects without mediation.¶
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
function PROTECTED_VERIFY_AND_EFFECTUATE(candidate_ref, sink):
a := PED1.load_authenticated_authority(candidate_ref)
if a is absent: return DENY_UNAUTHORIZED
final_native := sink.obtain_actual_pending_native_operation()
e := strict_decode_and_reconstruct(final_native, sink.execution_\
\context)
if e is ambiguous or has_unknown_critical_fields: return DENY_PA\
\RSE
if not exact_or_bounded_effect_match(a, e): return DENY_EFFECT_M\
\ISMATCH
if not current_epoch_and_revocation(a, sink): return DENY_STALE
if not approved_delegation_code_and_calls(a, e): return DENY_DEL\
\EGATION
with sink.protected_serialized_transaction() as state:
if state.is_consumed(a.use_id): return DENY_REPLAY
if state.budget_remaining(a.scope) < e.maximum_bounded_debit:
return DENY_BUDGET
handle := derive_sink_bound_nonbearer_authority(a, e, sink, \
\state.version)
state.reserve_and_consume(handle, e.maximum_bounded_debit)
state.commit_durable()
# The restricted key or account gate never exposes a raw byp\
\ass interface.
outcome_id := sink.release_only_validated_effect(e, handle)
return FDR(status=EFFECT_RELEASED,
outcome=OUTCOME_UNKNOWN, id=outcome_id,
authority_use=handle.id)
# A local positive FDR is not a ledger-settlement receipt.
S-01 enumerate effect-capable paths; mark mediated ones
S-02 PED-1: authenticated authority, exact or bounded effects,
sink, account, domain, policy, nonce, budget, time
S-03 Candidate Act held in Non-Effective State
S-04 PED-2: final native bytes -> semantic attributes, code
hash, upgrade generation, nested calls
S-05 reject unknown / ambiguous / changed fields
S-06 verify authority, epochs, expiry, sink, signer gen,
delegation limits, effect equality
S-07 serialization point or disjoint escrow reservation
S-08 operation-specific non-bearer EH
S-09 durable single-use consume with release
S-10 delegated designs: re-verify each later effect
S-11 typed FDR; downstream evidence tracked separately;
OUTCOME_UNKNOWN after crash
S-12 test alternate routes; fail test or narrow coverage
The following YES/NO/UNKNOWN conditions specify the effective decision branches of the common protected authority-to-consequence procedure. They are supplemental to, not substitutes for, the complete S-01 through S-12 sequence, threat-specific procedures, security invariants and executable pseudocode. Each release is enforced only at an actual controlled signer, protected dispatch interface, account guard or equivalent consequential boundary.¶
SEC-B-01 -- Is this a governed consequence path with an exclusive enforcement point? YES: identify the sink and close all in-scope alternate key, contract, delegation, administration and recovery paths. NO: report the path as outside the prevention scope; ordinary API authentication or logging does not make an unguarded path protected.¶
SEC-B-02 -- Has independent authority been authenticated and preserved in protected PED-1 state? YES: load the narrow principal, operation, constraints, purpose, epoch and finite use identity, holding the candidate Non-Effective. NO: DENY without signature, contract admission or dispatch.¶
SEC-B-03 -- Is the actual native sink operation unambiguously reconstructed and identical or within an explicitly permitted variation? YES: compare authoritative signer bytes, delegated implementation, recipients, units, chain, fee and code identities as applicable. NO or UNKNOWN fields: DENY or retain non-effective state pending trustworthy input; do not trust a caller or model-produced summary.¶
SEC-B-04 -- Are current revocation, budget, nonce, execution epoch, protected state and concurrency predicates satisfied? YES: reserve and atomically consume the bounded authority in sink-local or properly fenced protected state. NO, stale state or replay: DENY without releasing an effective capability.¶
SEC-B-05 -- Is protected release technically enforceable at this exact boundary? YES: issue at most the operation-specific bounded effect and audit actual use. NO: withhold release and acknowledge that another unrestricted signing or already-installed delegated-code path may still act outside scope.¶
SEC-B-06 -- Is the remote or cross-chain outcome unknown, partial, provisional or potentially already effective? YES: record UNKNOWN/PARTIAL/PROVISIONAL and reconcile original native identifiers; do not infer nonexecution from missing acknowledgment or automatically replay. NO: record only the authenticated outcome evidenced by the actual controlled sink and relevant external ledger/settlement source.¶
B-01 governed path with exclusive enforcement point?
NO --> outside prevention scope (reported)
B-02 independent authority in protected PED-1 state?
NO --> DENY (no signature, admission or dispatch)
B-03 native operation reconstructed, identical or within
permitted variation? NO/UNKNOWN --> DENY or hold NES
B-04 revocation, budget, nonce, epoch, concurrency OK?
NO/stale/replay --> DENY; YES --> reserve + consume
B-05 release enforceable at this exact boundary?
NO --> withhold; acknowledge out-of-scope paths
YES --> release at most the bounded effect
B-06 remote outcome unknown / partial / provisional?
YES --> record UNKNOWN/PARTIAL/PROVISIONAL; reconcile
original identifiers; no automatic replay
NO --> record authenticated outcome
Let A denote a protected authorization, E the strictly reconstructed actual effect, S the protected sink state, G a current policy/revocation generation, H a locally consumable use identifier, and R the release event. An implementation enforces R => Authentic(A) AND Match(A,E) AND Fresh(A,G) AND Bound(A,S) AND Unconsumed(H,S) AND SufficientCapacity(S,E). If any mandatory term cannot be established, it must not release R.¶
For non-negative minor-unit amounts, if B is a shared authorized limit, C the sum of committed debits and P the sum of outstanding reservations within a serializable protected scope, the safety constraint is C+P <= B. Under a finite disjoint-escrow budget, each participating signer is assigned escrow E_i such that sum(E_i) <= B. Reallocation requires an independently protected transfer of escrow; using cached uncoordinated global balances does not meet this constraint.¶
Example A: B=1,000, C=0, Agent-1 requests 800 while Agent-2 requests 700. A serialization-controlled sink permits at most one such reservation, and the other must be denied. If the first request was emitted but its remote outcome is unknown, that reservation is not automatically restored.¶
Example B: an authorized delegation binds code digest K0, upgrade generation U0, per-transfer limit 100 and cumulative limit 300. A proposal to install code digest K1 is denied even when accompanied by a cryptographically valid account authorization; a later downstream operation exceeding cumulative limit or targeting an unauthorized recipient is also denied at its independently effective boundary.¶
Example C: a legitimate withdrawal is approved for account W1, network N1 and recipient R1. A relayer prepares final bytes targeting R2. A cryptographically valid session credential and matching display string cannot supply missing recipient equality; the restricted signer refuses an effective signature.¶
Global exactly-once external settlement cannot be concluded solely from local atomic use consumption. If the sink controls only signature generation and an attacker independently holds another valid signature, exclusive control is not established. If source-chain finality can be reorganized, any dependent bridge payout must use appropriate source-consensus proof and waiting policies or remain indeterminate.¶
=============== NOTE: '\\' line wrapping per RFC 8792 =============== Invariant I1 (no unauthorized release): RELEASE -> AUTHENTIC and MAT\ \CH and FRESH Invariant I2 (one-use): for each (sink, authority-use-id), RELEASE_C\ \OUNT <= 1 Invariant I3 (budget): COMMITTED + RESERVED <= AUTHORIZED_BUDGET Invariant I4 (delegation): DELEGATE_INSTALL and DELEGATE_USE are sep\ \arate acts Invariant I5 (unknown outcome): UNKNOWN does not imply NOT_SENT Invariant I6 (no bypass): all effect-capable paths in declared scope\ \ require gate Invariant I7 (foreign finality): LOCAL_ALLOW does not imply REMOTE_S\ \ETTLED Invariant I8 (fail closed): UNKNOWN_CRITICAL or STALE_POLICY -> no R\ \ELEASE
Example A: B = 1,000, C = 0, P = 0 (constraint C + P <= B)
Agent-1 requests 800 --+
+--> serialization-controlled sink
Agent-2 requests 700 --+
first: 0 + 800 = 800 <= 1000 -> reserve
second: 0 + 800 + 700 = 1,500 > 1000 -> DENY
first outcome unknown -> reservation NOT auto-restored
Example C: approved W1 / N1 / R1; relayer prepares bytes -> R2
valid session credential + matching display string
recipient(R2) != R1 -> restricted signer refuses signature
The correspondence table is expressed in prose to keep the technical requirements explicit for each threat model. PED-1 supports independent authorization, PED-2 ensures actual-effect reconstruction, protected sink state supplies current policy and single-use accounting, and a control over the actual effectuation boundary provides enforceability. These elements may be combined with commercially available authentication, cryptographic and access-control mechanisms rather than replacing them.¶
Cases TM-01, TM-02, TM-04 and TM-13 principally require exclusive guarded signature or dispatch operations; TM-03, TM-09 and TM-12 additionally require enforceable delegated-program controls; TM-05, TM-07, TM-10 and TM-11 require durable, current and concurrency-safe use accounting; TM-06 requires identical participant-level verification and session fencing; TM-08 requires complete consequence-path mediation; TM-14 requires leg-specific authority and independent outcome finality evidence.¶
Consequence-path completeness can be tested by constructing a directed graph of actors and protected/unprotected operations. For each attack-origin node in the graph, the verifier enumerates paths reaching an effective asset movement. Every reachable effective path within the claimed deployment scope must include a protected enforcement gate; otherwise the implementation has a demonstrable alternate-path failure and its coverage statement must be narrowed.¶
attack-origin nodes protected gate effect
+----------------+
| agent / tool |------------>[ G ]------------+
+----------------+ |
| service host |------------>[ G ]------------+--> asset
+----------------+ | movement
| admin recovery |------------>[ G ]------------+
+----------------+ |
| stale region |--------------------------X---+
+----------------+ ungated path = demonstrable
alternate-path failure: gate it,
remove it, or narrow the scope
Equivalent operations may be placed at a non-exportable key HSM, an isolated threshold-signature participant, a TEE-protected signer, a guarded account abstraction module, a programmable account policy hook, a network switch that is the sole authorized outbound transaction path, an isolated API credential daemon, or a protected settlement processing node. The depicted labels, process counts and communication mechanisms are not mandatory.¶
Authority may be encoded as an opaque database reference, authenticated policy record, signed one-time permit checked against local replay state, hardware authorization slot, disjoint escrow ledger, or an on-chain policy state commitment. What must be demonstrated for a particular claimed combination is protected origin and interpretation of authority, execution-time exact effect reconstruction, current enforceable state and bounded/consumed release.¶
Where a direct bearer token or unrestricted signature can independently produce an effective act, merely calling another token non-bearer does not supply technical non-bearer protection. A claimed non-bearer property requires context verification and protected state that copied authorization material cannot bypass.¶
Denial burning is applied to the protected local authorization use identity only when it is authentically allocated. Untrusted malformed inputs must not be allowed to exhaust arbitrary legitimate chain nonce space or permanently block another account.¶
The alternative placement must preserve refusal of unauthorized effects under the declared threat assumptions; code written in another language or control housed in another trust domain is an implementation variation, while an unrestricted bypass path is a failure condition rather than a valid equivalent.¶
same invariant: protected authority origin, exact
reconstruction, current state, one use, exclusivity
|
+-----------+-----------+---+-------+------------+---------+
v v v v v v
non- threshold TEE account sole credential
exportable participant signer abstraction outbound daemon /
key HSM / policy network settlement
hook switch node
an unrestricted bypass path is a failure, not an equivalent
The following statements explain scope honestly rather than asserting unconditional prevention. If a third party obtains an effective private key or a previously created unrestricted signature outside the guarded key-use boundary, an off-chain gate cannot undo that authority. If an account has already delegated code with independent on-chain spending rights, an off-chain signer cannot stop later code execution unless the account itself or a necessary execution path enforces the bounds.¶
If a trusted policy authority and protected signer are simultaneously compromised, the separation assumption may fail. If replay state is lost or rolled back and no monotonic trusted anchor exists, a previously consumed authorization may be reusable. If a remote settlement rail ignores idempotency and confirms after an unknown acknowledgment, local at-most-once initiation does not prove exactly-once external settlement.¶
If an arbitrary smart contract, transaction format or foreign network effect cannot be faithfully decoded into bounded effect-critical semantics, the implementation must reject, reduce permitted actions or use a more strongly controlled execution mode. A guessed semantic interpretation does not satisfy independent reconstruction.¶
If an independent backup region can sign without checking current policy, the protection does not cover that route. If distributed escrow is not coordinated, a global budget invariant cannot be claimed. The precise controlled boundary and negative-effect test coverage must be declared rather than assumed.¶
legitimate baseline (approved native operation)
|
+--> one adversarial modification
+--> concurrent variant (where applicable)
+--> crash / unknown variant (where applicable)
|
v
instrument actual signer, guarded account execution and
outbound dispatch interfaces
|
accept a denied case only if decision = DENY and effective
emissions = 0 on every instrumented route
SEC-TV-001 .. SEC-TV-056: 4 vectors x 14 threat models
(baseline, single-field/code change, replay/concurrency/
epoch drift, alternate path/crash/unsupported effect)
Test harnesses are designed to capture the actual effective signer invocation, guarded account execution or outbound transaction-dispatch interface, rather than infer safety from an ALLOW/DENY function alone. For a denied candidate, acceptance requires a protected decision DENY and zero effective emissions along each instrumented route within the test scope.¶
Each candidate test includes a legitimate baseline followed by a single adversarial modification, a concurrent or crash variant when applicable, expected protected state and actual release count. Test evidence must distinguish unit model behavior from hardware, chain, signing or settlement behavior. Unless independently run, tests are specifications rather than measured outcomes.¶
Input setup. Use the TM-01 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-01 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-01 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-01 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-02 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-02 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-02 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-02 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-03 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-03 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-03 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-03 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-04 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-04 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-04 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-04 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-05 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-05 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-05 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-05 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-06 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-06 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-06 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-06 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-07 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-07 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-07 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-07 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-08 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-08 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-08 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-08 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-09 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-09 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-09 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-09 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-10 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-10 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-10 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-10 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-11 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-11 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-11 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-11 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-12 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-12 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-12 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-12 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-13 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-13 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-13 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-13 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-14 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: baseline authorized operation.¶
Expected result. ALLOW once. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-14 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: adversarial single-field or code change.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-14 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: replay, concurrency or epoch drift.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Input setup. Use the TM-14 scenario with independently authenticated test authorization, a sink-specific canonical candidate and a test-only effect capturer. Run the indicated mutation category: alternative path, crash or unsupported-effect denial.¶
Expected result. DENY with zero unauthorized effective release. Record policy epoch, protected used-set, native operation digest, sink identity, reconstructed effect and each actual emission. Confirm whether all declared alternate paths were instrumented.¶
For concurrency, launch overlapping clients and compare durable budget/used state. For crash, interrupt between durable use and acknowledgment and verify no fresh release under the same authority. A mock ALLOW or DENY without captured effects does not pass an actual boundary test.¶
Effect (account, recipient, asset, network, sink, nonce,
kind, amount_minor, code digest, upgrade epoch)
|
v
Guard (SQLite transactional state)
set_budget(account, ceiling)
authorize(effect, maximum, uses)
revoke_all() -> epoch advance
verify_and_effect(effect) --> exact match, epoch,
| unused, budget, then
| consume + journal emission
v
emission journal (simulated signing events)
GuardTests: 24 tests (wrong recipient, account, asset, chain,
sink, nonce, kind, limits, revoked epoch, duplicate use,
concurrency, code digest, upgrade epoch, crash-unknown, ...)
The following Python 3 standard-library reference implementation demonstrates sink-local durable authorization and budget consumption, exact-effect checks, a code-digest/upgrade-generation delegation condition, simple epoch freshness, replay denial and a simulated protected signing event journal. SQLite is used to make transactional state transitions visible to an implementer. Its simulation deliberately does not implement real cryptographic signatures, secure key custody, smart-contract execution, consensus or external settlement.¶
This new code is self-contained and accompanies rather than replaces the executable Python, Go and JavaScript models in the companion digital money safety module. The choice of Python and SQLite here is non-limiting. Equivalent logic may be implemented in secure firmware, HSM APIs, isolated processes, guarded smart contracts, threshold-signature participants or other programming languages when the same enforceable invariant is maintained.¶
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
#!/usr/bin/env python3
"""Illustrative, local-only execution-finality decision model.
No real cryptography, ledger, custody, HSM, or external payment oper\
\ations.
"""
import sqlite3
import tempfile
import os
import unittest
from dataclasses import dataclass
from pathlib import Path
class Denied(Exception):
"""A candidate did not meet an exact-effect or state predicate."\
\""
@dataclass(frozen=True)
class Effect:
aid: str
account: str
recipient: str
asset: str
network: str
amount_minor: int
sink: str
nonce: str
kind: str = "transfer"
code_digest: str = ""
upgrade_epoch: int = 0
class Guard:
"""A SQLite transaction stands in for a serializable protected s\
\tate boundary."""
def __init__(self, dbfile):
self.dbfile = str(dbfile)
self.conn = sqlite3.connect(self.dbfile, timeout=10, isolati\
\on_level=None)
self.conn.execute("PRAGMA busy_timeout=10000")
self.conn.execute("PRAGMA journal_mode=WAL")
self.conn.executescript('''
CREATE TABLE IF NOT EXISTS policy (epoch INTEGER NOT NUL\
\L);
CREATE TABLE IF NOT EXISTS auth (
aid TEXT PRIMARY KEY, account TEXT NOT NULL, recipien\
\t TEXT NOT NULL,
asset TEXT NOT NULL, network TEXT NOT NULL, sink TEXT\
\ NOT NULL,
nonce TEXT NOT NULL, kind TEXT NOT NULL,
code_digest TEXT NOT NULL, upgrade_epoch INTEGER NOT \
\NULL,
max_minor INTEGER NOT NULL, epoch INTEGER NOT NULL,
use_limit INTEGER NOT NULL);
CREATE TABLE IF NOT EXISTS budget (
account TEXT PRIMARY KEY, ceiling INTEGER NOT NULL,
consumed INTEGER NOT NULL DEFAULT 0);
CREATE TABLE IF NOT EXISTS usage (
aid TEXT PRIMARY KEY, status TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS emission (
seq INTEGER PRIMARY KEY AUTOINCREMENT, aid TEXT NOT N\
\ULL,
recipient TEXT NOT NULL, amount_minor INTEGER NOT NUL\
\L);
''')
if self.conn.execute('SELECT COUNT(*) FROM policy').fetchone\
\()[0] == 0:
self.conn.execute('INSERT INTO policy(epoch) VALUES(1)')
def close(self):
self.conn.close()
def set_budget(self, account, ceiling):
assert isinstance(ceiling, int) and ceiling >= 0
self.conn.execute('INSERT OR REPLACE INTO budget(account,cei\
\ling,consumed) VALUES(?,?,0)',
(account, ceiling))
def authorize(self, e, maximum, uses=1):
assert isinstance(maximum, int) and maximum >= 0
assert uses == 1 # this minimal model implements exactly-on\
\e use only
if not isinstance(e, Effect):
raise TypeError('Effect required')
ep = self.conn.execute('SELECT epoch FROM policy').fetchone(\
\)[0]
self.conn.execute('''INSERT INTO auth
(aid,account,recipient,asset,network,sink,nonce,kind,code_di\
\gest,
upgrade_epoch,max_minor,epoch,use_limit)
VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?)''',
(e.aid,e.account,e.recipient,e.asset,e.network,e.sink,e.nonc\
\e,
e.kind,e.code_digest,e.upgrade_epoch,maximum,ep,uses))
def revoke_all(self):
self.conn.execute('UPDATE policy SET epoch=epoch+1')
def verify_and_effect(self, e, fail_after_commit=False):
# There is no real signer here. The emission row models a la\
\st-hop effect.
if not isinstance(e, Effect):
raise Denied('TYPE')
if type(e.amount_minor) is not int or e.amount_minor <= 0:
raise Denied('AMOUNT')
c=self.conn
c.execute('BEGIN IMMEDIATE')
try:
row=c.execute('''SELECT account,recipient,asset,network,\
\sink,nonce,kind,
code_digest,upgrade_epoch,max_minor,ep\
\och,use_limit
FROM auth WHERE aid=?''',(e.aid,)).fet\
\chone()
if row is None:
raise Denied('NO_AUTH')
a=dict(zip(['account','recipient','asset','network','sin\
\k','nonce','kind',
'code_digest','upgrade_epoch','max_minor','e\
\poch','use_limit'],row))
current=c.execute('SELECT epoch FROM policy').fetchone()\
\[0]
if current != a['epoch']:
raise Denied('STALE_POLICY')
for key in ('account','recipient','asset','network','sin\
\k','nonce','kind',
'code_digest','upgrade_epoch'):
if getattr(e,key) != a[key]:
raise Denied('MISMATCH_'+key.upper())
if e.amount_minor > a['max_minor']:
raise Denied('PER_ACT_LIMIT')
if c.execute('SELECT 1 FROM usage WHERE aid=?',(e.aid,))\
\.fetchone():
raise Denied('REPLAY')
b=c.execute('SELECT ceiling,consumed FROM budget WHERE a\
\ccount=?',
(e.account,)).fetchone()
if b is None or e.amount_minor > b[0]-b[1]:
raise Denied('BUDGET')
c.execute('UPDATE budget SET consumed=consumed+? WHERE a\
\ccount=?',
(e.amount_minor,e.account))
c.execute('INSERT INTO usage(aid,status) VALUES(?,?)',
(e.aid,'OUTCOME_UNKNOWN'))
c.execute('INSERT INTO emission(aid,recipient,amount_min\
\or) VALUES(?,?,?)',
(e.aid,e.recipient,e.amount_minor))
c.execute('COMMIT')
except BaseException:
c.execute('ROLLBACK')
raise
if fail_after_commit:
raise ConnectionError('simulated loss of acknowledgment \
\after local effect')
return {'decision':'EFFECT_RELEASED', 'external_outcome':'UN\
\KNOWN'}
def emission_count(self):
return self.conn.execute('SELECT COUNT(*) FROM emission').fe\
\tchone()[0]
def consumed(self, account):
return self.conn.execute('SELECT consumed FROM budget WHERE \
\account=?',
(account,)).fetchone()[0]
class GuardTests(unittest.TestCase):
def setUp(self):
self.temp=tempfile.TemporaryDirectory()
self.path=Path(self.temp.name)/'guard.db'
self.g=Guard(self.path)
self.g.set_budget('W1',1000)
self.good=Effect('a1','W1','R1','TOKEN','CHAIN1',600,'S1','N\
\1')
self.g.authorize(self.good,700)
def tearDown(self):
self.g.close()
self.temp.cleanup()
def change(self,**k):
d=self.good.__dict__.copy();d.update(k)
return Effect(**d)
def denied(self,e):
count=self.g.emission_count()
with self.assertRaises(Denied): self.g.verify_and_effect(e)
self.assertEqual(count,self.g.emission_count())
def test_01_valid_exact_effect(self):
self.assertEqual('EFFECT_RELEASED',self.g.verify_and_effect(\
\self.good)['decision'])
self.assertEqual(1,self.g.emission_count())
def test_02_wrong_recipient(self):self.denied(self.change(recipi\
\ent='R2'))
def test_03_wrong_source_account(self):self.denied(self.change(a\
\ccount='W2'))
def test_04_wrong_asset(self):self.denied(self.change(asset='OTH\
\ER'))
def test_05_wrong_chain(self):self.denied(self.change(network='C\
\HAIN2'))
def test_06_wrong_sink(self):self.denied(self.change(sink='BACKU\
\P'))
def test_07_wrong_nonce(self):self.denied(self.change(nonce='N2'\
\))
def test_08_wrong_kind(self):self.denied(self.change(kind='deleg\
\ate'))
def test_09_over_per_act_limit(self):self.denied(self.change(amo\
\unt_minor=701))
def test_10_zero_amount(self):self.denied(self.change(amount_min\
\or=0))
def test_11_negative_amount(self):self.denied(self.change(amount\
\_minor=-1))
def test_12_boolean_is_not_integer(self):self.denied(self.change\
\(amount_minor=True))
def test_13_missing_authority(self):self.denied(self.change(aid=\
\'absent'))
def test_14_revoked_epoch(self):
self.g.revoke_all();self.denied(self.good)
def test_15_duplicate_use(self):
self.g.verify_and_effect(self.good);self.denied(self.good)
def test_16_budget_concurrent_intent(self):
e=Effect('a2','W1','R1','TOKEN','CHAIN1',700,'S1','N2')
self.g.authorize(e,700)
self.g.verify_and_effect(self.good)
self.denied(e)
self.assertEqual(600,self.g.consumed('W1'))
def test_17_code_digest_binding(self):
e=Effect('d1','W1','CODE','TOKEN','CHAIN1',1,'S1','Nd',kind=\
\'delegate',code_digest='hashA',upgrade_epoch=1)
self.g.authorize(e,1)
self.denied(Effect('d1','W1','CODE','TOKEN','CHAIN1',1,'S1',\
\'Nd',kind='delegate',code_digest='hashB',upgrade_epoch=1))
def test_18_upgrade_epoch_binding(self):
e=Effect('d1','W1','CODE','TOKEN','CHAIN1',1,'S1','Nd',kind=\
\'delegate',code_digest='hashA',upgrade_epoch=1)
self.g.authorize(e,1)
self.denied(Effect('d1','W1','CODE','TOKEN','CHAIN1',1,'S1',\
\'Nd',kind='delegate',code_digest='hashA',upgrade_epoch=2))
def test_19_nonce_fanout_blocked(self):
self.g.verify_and_effect(self.good)
self.denied(self.change(nonce='N2'))
def test_20_crash_unknown_does_not_retry(self):
with self.assertRaises(ConnectionError):self.g.verify_and_ef\
\fect(self.good,fail_after_commit=True)
self.denied(self.good)
self.assertEqual(1,self.g.emission_count())
def test_21_stale_region_instance(self):
old=Guard(self.path)
try:
self.g.revoke_all()
count=old.emission_count()
with self.assertRaises(Denied):old.verify_and_effect(sel\
\f.good)
self.assertEqual(count,old.emission_count())
finally:old.close()
def test_22_no_alternative_sink_authorization(self):
self.denied(self.change(sink='S2'))
def test_23_rejected_effect_does_not_consume_budget(self):
self.denied(self.change(recipient='Evil'))
self.assertEqual(0,self.g.consumed('W1'))
def test_24_new_authorization_after_consumption(self):
self.g.verify_and_effect(self.good)
e=Effect('a2','W1','R1','TOKEN','CHAIN1',400,'S1','N2')
self.g.authorize(e,400)
self.assertEqual('EFFECT_RELEASED',self.g.verify_and_effect(\
\e)['decision'])
self.assertEqual(1000,self.g.consumed('W1'))
if __name__ == '__main__':
unittest.main(verbosity=2)
Suggested reproduction: save the Python listing to ptef_security_reference.py and execute python3 ptef_security_reference.py. The program runs self-contained tests and prints their pass/fail results; no secrets or external financial system connections are required. A production implementation must independently validate its enforcement path, protected hardware or on-chain account authority as applicable.¶
One implementation begins with a restricted key that cannot sign an arbitrary external digest. Establish an authenticated authorization database in an administrative boundary independent from a lower-trust transaction builder; use sink-side decoding code that reconstructs every critical field from native bytes. Create a protected durable store for used operation IDs, budget reservations, policy epochs and incomplete external effects. Finally, require the restricted signing method to perform a single atomic decision against state immediately before exposing any effective signature.¶
For programmable accounts, code installation is validated against an authenticated code digest, proxy implementation and upgrade policy; every later execution is subject to a current method/recipient/amount limit at an on-chain or equivalent enforced boundary. If the deployed chain lacks such a necessary account guard, the system does not claim prevention of independent on-chain execution.¶
For multiple networks, define actual scopes of synchronized budget: central serialization where connectivity and availability permit; otherwise disjoint preallocated protected budgets and expiry/fencing. For remote confirmations, maintain separate native receipts and record contested confirmations or chain reorganizations as pending/unknown instead of claiming guaranteed global atomicity.¶
An implementer can construct reproducible negative-effect tests by building legitimate approved native transactions, replacing one effect-critical field, exercising concurrency, restoring stale state and invoking alternate signer interfaces. The security assertion must count actual effective operations at the guarded boundary.¶
1 restricted key that cannot sign an arbitrary digest 2 authenticated authorization DB, separate admin boundary from the lower-trust transaction builder 3 sink-side decoder reconstructs every critical field 4 protected durable store: used ids, reservations, policy epochs, incomplete operations 5 programmable accounts: code digest, proxy, upgrade policy; per-execution limits at an enforced boundary 6 multiple networks: central serialization or disjoint pre-allocated budgets with expiry and fencing 7 remote confirmations kept separate; contested -> pending 8 negative-effect tests count actual effective operations
These sections supplement, rather than replace, the previously disclosed two-instance protected authority model and the financial profiles E-45 through E-63 of the companion digital money safety module. Direct technical correspondence includes E-01 (restricted signer), E-02 (independent threshold participants), E-03 (PED-1/PED-2 separation), E-04 (sink-bound bounded use), E-05/E-06 (native effect and canonicalization), E-07 (delegated code identity), E-21 (payment and settlement outcome separation), and E-54 (multi-wallet custody). The newer threat catalog identifies additional adverse operating conditions and explicit acceptance tests for those combinations.¶
For a financial Candidate Act A, let B(A) represent independently authenticated authority binding; E(A) represent the execution-facing effect reconstructed by the protected verifier; S represent protected sink identity; P and R represent current policy and revocation generations; Q represent remaining protected use or spending capacity; and U represent the protected prior-use set. The protected gate may release effect authority only when B(A) is authentic, E(A) is within B(A), S is bound, P/R are current, the candidate remains fresh, the amount or use is within Q, and A is not already in U. The comparison may be exact or within an expressly authorized typed range. Unknown effect-critical attributes cause denial rather than implicit omission.¶
The effect-checking stage is arranged at an actual point where an irreversible or transferable capability would first become usable, such as a restricted signing invocation, last cryptographic-share release, sink-enforced smart-account entry point or guarded outbound dispatch. Authorization success is a typed local result, not proof of chain inclusion or economic settlement. Where a signing key remains independently usable, the local gate is insufficient to prevent bypass and cannot be characterized as globally non-bypassable.¶
In an illustrative signature-compatible threat condition, a model-generated transfer may be cryptographically well formed while containing a payee never authorized by the principal. The protected verifier independently parses final transaction bytes and rejects the payee before the only effective signer creates a usable signature. In a delegated-code variant the verifier also binds the effective code target and upgrade generation, and a contract guard checks later value-moving calls when a valid preexisting delegation could otherwise operate without a new signature.¶
This is a technical distinction in effect authorization and enforcement placement, not a claim that ledger consensus or smart-contract validation lacks security. A correctly programmed ledger-resident policy component may implement some or all relevant protections and represents one of the implementation alternatives.¶
S1: enumerate effect-capable paths and define the final gate-controlled operation before any transferable signature, downstream command, delegated executable release or key share becomes available.¶
S2: keep the proposed act in a Non-Effective State and obtain authority from an independently authenticated protected input, not from an agent narrative, web document or untrusted API parameter.¶
S3: bind the authorized fields and policy generation at PED-1, including exact recipient, amount, asset, chain, sink, account, delegation code and nonce or explicitly permitted typed ranges.¶
S4: reconstruct actual executable native fields from the final message, instruction or code state at PED-2; refuse ambiguous decoding and unknown critical semantics.¶
S5: obtain sufficiently fresh revocation, expiry, budget, replay and usage state under an identified protected consistency mechanism.¶
S6: validate equality or declared bounded variation, and condition authority release on a protected terminal gate at the actual effectuation boundary.¶
S7: consume the bounded permission with a durable or atomic coordination strategy before or at effect release; journal possible outcomes including UNKNOWN.¶
S8: independently reconcile signature creation, chain acceptance, consensus finality and economic settlement; never infer an external result from local authorization.¶
S1 enumerate paths; define gate-controlled operation
S2 Candidate Act non-effective; independent authority
S3 PED-1 binds recipient, amount, asset, chain, sink,
account, delegation, policy generation
S4 PED-2 reconstructs final native fields
S5 fresh revocation, expiry, budget, replay state
S6 equality or bounded variation; gate at actual boundary
S7 durable / atomic consume; journal possible outcomes
S8 reconcile signature, acceptance, finality, settlement
---------------------------------------------------------
ledger: validity, ordering, consensus (independent layer)
The following concrete source-code listings are illustrative technical implementation aids for implementers. They show independent authorized-effect objects, exact effect-field reconstruction at the modeled gate, current policy-epoch comparison, nonce and delegate-code binding, bounded local budget consumption, rejection of replay, and instrumented local emission counters. They are not blockchain nodes, signing implementations, secure enclaves, quantum-safe cryptographic modules or payment settlement engines. The relevant protected authorization and exclusive effect-capable hardware or software interfaces must be implemented separately in a production profile.¶
The Python 3 example uses a SQLite transaction with an instrumented emission table to model a serialized protected decision journal. A database file under a normal operating-system user account is not itself equivalent to hardware-isolated PED-1 or PED-2, and the example does not make release of a real external signature atomic with a database commit. The Go and JavaScript examples use in-memory state to make the semantics inspectable across languages; they are not durable, distributed or cross-process secure. The Go mutex serializes goroutines sharing one Gate; the JavaScript example serializes synchronous calls only within one process event loop.¶
For each accepted candidate the modeled code records a local emission exactly once. For denied candidates the instrumented emission count remains unchanged. The user of these listings must replace the model emission with a genuinely exclusive effectuation interface and separately establish isolation, trusted time, durable rollback resistance, distributed fencing, malicious administrator limitations, anti-bypass coverage, and cryptographic correctness as applicable.¶
The original Python program and its local tests are retained earlier in Section SEC-012. The next two complete listings are additional, independently runnable Go and JavaScript variants. A further Python benchmark listing imports the original Python program as a separate file; all four listings are included in the XML and reproduced as extractable files in the accompanying conversion package.¶
A further stand-alone Python demonstrator models the precise semantic difference between protocol-compatible credential integrity and independent effect authorization. It uses a publicly disclosed HMAC test secret as an intentionally simplified signature substitute, not a real blockchain signature. Its mock protocol verifier checks descriptor well-formedness, test network domain and tag integrity; it deliberately does not make a claim about the complete rules enforced by actual validators, smart contracts or consensus. A changed beneficiary or changed delegated-code identity can satisfy this limited test verifier when signed by the same illustrative key but must be rejected by the independently provided mandate. It illustrates the missing authorization predicate and not real-world exploit reproducibility or cryptographic assurance.¶
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
package main
// Non-limiting local reference model. No wallet, HSM, signature, ne\
\twork or blockchain access.
import (
"fmt"
"sort"
"sync"
"time"
)
type Effect struct {
ID, Account, Payee, Asset, Chain, Sink, Nonce, Kind, CodeHash stri\
\ng
CodeEpoch int
Minor int64
}
type Authority struct { Expected Effect; Maximum int64; Epoch int; U\
\sed bool }
type Gate struct {
mu sync.Mutex
epoch int
ceilings, spent map[string]int64
authorities map[string]*Authority
emitted []string // only an instrumented local side-effect; not bl\
\ockchain settlement
}
func NewGate() *Gate {return &Gate{epoch:1, ceilings:map[string]int6\
\4{}, spent:map[string]int64{}, authorities:map[string]*Authority{}}}
func (g *Gate) Budget(account string, ceiling int64) {
g.mu.Lock(); defer g.mu.Unlock()
if ceiling < 0 {panic("negative ceiling")}
g.ceilings[account]=ceiling
}
func (g *Gate) Authorize(a Effect, max int64) error {
g.mu.Lock(); defer g.mu.Unlock()
if a.ID=="" || a.Account=="" || a.Sink=="" || a.Nonce=="" || max<0\
\ {return fmt.Errorf("bad authority")}
if _,exists:=g.authorities[a.ID]; exists {return fmt.Errorf("dupli\
\cate authority")}
g.authorities[a.ID]=&Authority{Expected:a,Maximum:max,Epoch:g.epoc\
\h}
return nil
}
func (g *Gate) Revoke() {g.mu.Lock(); defer g.mu.Unlock(); g.epoch++}
func (g *Gate) Release(actual Effect) error {
g.mu.Lock(); defer g.mu.Unlock()
a,ok:=g.authorities[actual.ID]
if !ok || a.Used || a.Epoch!=g.epoch {return fmt.Errorf("missing, \
\used, or revoked")}
// Strongly typed exact-effect comparison includes delegate and si\
\gning context.
if actual != a.Expected || actual.Minor<=0 || actual.Minor>a.Maxim\
\um {return fmt.Errorf("effect mismatch")}
limit,known:=g.ceilings[actual.Account]
if !known || g.spent[actual.Account]>limit-actual.Minor {return fm\
\t.Errorf("budget exceeded")}
// Local atomic simulation: use + budget + emission occur while pr\
\otected state is locked.
// Actual deployments require durable protected journaling and exc\
\lusive physical/cryptographic release.
a.Used=true
g.spent[actual.Account]+=actual.Minor
g.emitted=append(g.emitted,actual.ID)
return nil
}
func check(ok bool, why string) {if !ok {panic("FAILED: "+why)}}
func sample(id string, minor int64) Effect {return Effect{ID:id, Acc\
\ount:"W", Payee:"approved", Asset:"COIN", Chain:"chain-1", Sink:"si\
\gner-1", Nonce:"nonce-"+id, Kind:"transfer", Minor:minor}}
func test() int {
checks:=0
g:=NewGate();g.Budget("W",1000)
a:=sample("one",600);check(g.Authorize(a,700)==nil,"authorize");ch\
\ecks++
bad:=a;bad.Payee="unapproved"
check(g.Release(bad)!=nil && len(g.emitted)==0,"substituted recipi\
\ent blocked");checks++
bad=a;bad.Sink="backup"
check(g.Release(bad)!=nil && len(g.emitted)==0,"alternate sink blo\
\cked");checks++
check(g.Release(a)==nil && len(g.emitted)==1,"allowed once");check\
\s++
check(g.Release(a)!=nil && len(g.emitted)==1,"replay blocked");che\
\cks++
b:=sample("two",500);check(g.Authorize(b,500)==nil,"second auth");\
\checks++
check(g.Release(b)!=nil && g.spent["W"]==600,"cumulative budget bl\
\ocked");checks++
d:=sample("del",1);d.Kind="delegate";d.CodeHash="approved-code";d.\
\CodeEpoch=3
check(g.Authorize(d,1)==nil,"delegate authority");checks++
bad=d;bad.CodeHash="altered-code"
check(g.Release(bad)!=nil,"delegate code altered");checks++
bad=d;bad.CodeEpoch=4
check(g.Release(bad)!=nil,"upgrade epoch altered");checks++
g.Revoke();check(g.Release(d)!=nil,"revocation");checks++
// One of two simultaneous effect requests can consume the limited\
\ budget.
c:=NewGate();c.Budget("W",1000)
x:=sample("race-a",650); y:=sample("race-b",650)
check(c.Authorize(x,650)==nil && c.Authorize(y,650)==nil,"race set\
\up");checks++
var wg sync.WaitGroup; wg.Add(2)
var successes int; var cm sync.Mutex
for _,e:=range []Effect{x,y}{ e:=e;go func(){defer wg.Done();if c.\
\Release(e)==nil {cm.Lock();successes++;cm.Unlock()}}() }
wg.Wait();check(successes==1 && len(c.emitted)==1 && c.spent["W"]=\
\=650,"concurrency safety");checks++
return checks
}
func percentile(samples []int64, p int) int64 {sort.Slice(samples,fu\
\nc(i,j int) bool{return samples[i]<samples[j]});idx:=((len(samples)\
\-1)*p)/100;return samples[idx]}
func benchmark() {
g:=NewGate();g.Budget("W",1_000_000)
const n=5000
samples:=make([]int64,0,n)
for i:=0;i<n;i++ {
e:=sample(fmt.Sprintf("bench-%d",i),1)
if err:=g.Authorize(e,1);err!=nil {panic(err)}
start:=time.Now()
if err:=g.Release(e);err!=nil {panic(err)}
samples=append(samples,time.Since(start).Nanoseconds())
}
fmt.Printf("GO protected-state simulation: operations=%d p50_ns=%d\
\ p95_ns=%d (not signing or settlement)\n",n,percentile(samples,50),\
\percentile(samples,95))
}
func main(){fmt.Printf("GO local_checks_passed=%d\n",test()); benchm\
\ark()}
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
'use strict';
// Non-limiting Node.js local reference model. No HSM, transaction s\
\igning or ledger operations.
const assert = require('node:assert/strict');
function sample(id, minor=600) {
return {id, account:'W', payee:'approved', asset:'COIN', chain:'ch\
\ain-1',
sink:'signer-1', nonce:`nonce-${id}`, kind:'transfer', codeHash:\
\'',codeEpoch:0,minor};
}
const fields = ['id','account','payee','asset','chain','sink','nonce\
\','kind','codeHash','codeEpoch','minor'];
function validInt(n){return Number.isSafeInteger(n)&&n>=0;}
class Gate {
constructor(){this.epoch=1;this.ceiling=new Map();this.spent=new M\
\ap();this.authority=new Map();this.emissions=[];}
budget(account,minor) {if(!validInt(minor)) throw Error('invalid b\
\udget');this.ceiling.set(account,minor);}
authorize(expected,maximum) {
if(!validInt(maximum)||!expected.id||!expected.account||!expecte\
\d.nonce||this.authority.has(expected.id))
throw Error('bad authority');
this.authority.set(expected.id,{expected:Object.freeze({...expec\
\ted}),maximum,epoch:this.epoch,used:false});
}
revoke(){this.epoch++;}
release(actual) {
const a=this.authority.get(actual.id);
if(!a||a.used||a.epoch!==this.epoch) return false;
if(Object.keys(actual).length!==fields.length||fields.some(k=>ac\
\tual[k]!==a.expected[k])) return false;
if(!validInt(actual.minor)||actual.minor===0||actual.minor>a.max\
\imum) return false;
const allowed=this.ceiling.get(actual.account), used=this.spent.\
\get(actual.account)||0;
if(!validInt(allowed)||used>allowed-actual.minor) return false;
// Single synchronous critical section within one Node process/e\
\vent loop ONLY.
// Not durable or safe across processes/workers; use protected s\
\erializable state at a real sink.
a.used=true;this.spent.set(actual.account,used+actual.minor);thi\
\s.emissions.push(actual.id);
return true;
}
}
function test() {
let n=0;const ok=(b,msg)=>{assert.ok(b,msg);n++;};
const g=new Gate();g.budget('W',1000);const e=sample('one');g.auth\
\orize(e,700);
ok(!g.release({...e,payee:'hostile'})&&g.emissions.length===0,'pay\
\ee tamper');
ok(!g.release({...e,sink:'backup'}),'sink bypass');
ok(!g.release({...e,minor:701}),'amount tamper');
ok(!g.release({...e,nonce:'duplicate'}),'nonce mismatch');
ok(!g.release({...e,unknownField:'critical'}),'unknown field');
ok(g.release(e),'allowed exact effect');
ok(!g.release(e)&&g.emissions.length===1,'replay');
const e2=sample('second',500);g.authorize(e2,500);
ok(!g.release(e2)&&g.spent.get('W')===600,'budget bound');
const del={...sample('del',1),kind:'delegate',codeHash:'approved-c\
\ode',codeEpoch:1};g.authorize(del,1);
ok(!g.release({...del,codeHash:'swapped-code'}),'delegated code ch\
\ange');
ok(!g.release({...del,codeEpoch:2}),'delegated epoch change');
g.revoke();ok(!g.release(del),'stale policy epoch');
const second=new Gate();second.budget('W',1000);
const a=sample('race-a',650),b=sample('race-b',650);second.authori\
\ze(a,650);second.authorize(b,650);
const success=[second.release(a),second.release(b)].filter(Boolean\
\).length;
ok(success===1&&second.emissions.length===1&&second.spent.get('W')\
\===650,'serialized budget');
return n;
}
function benchmark() {
const g=new Gate();g.budget('W',1000000);
const samples=[];const iterations=5000;
for(let i=0;i<iterations;i++) {
const e=sample(`bench-${i}`,1);g.authorize(e,1);
const start=process.hrtime.bigint();assert.equal(g.release(e),tr\
\ue);
samples.push(Number(process.hrtime.bigint()-start));
}
samples.sort((a,b)=>a-b);const pct=p=>samples[Math.floor((samples.\
\length-1)*p/100)];
console.log(`JS protected-state simulation: operations=${iteration\
\s} p50_ns=${pct(50)} p95_ns=${pct(95)} (not signing or settlement)`\
\);
}
console.log('JS local_checks_passed='+test());benchmark();
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
#!/usr/bin/env python3
"""Reproducible local benchmark of the already disclosed SQLite mode\
\l.
Measures the guard's local transaction, not real cryptographic signi\
\ng,
network transit, chain inclusion, confirmation, or attack-prevention\
\ assurance.
"""
import importlib.util
import pathlib
import statistics
import tempfile
import time
HERE=pathlib.Path(__file__).resolve().parent
module_path=HERE/'PTEF_Security_Reference_Model.py'
spec=importlib.util.spec_from_file_location('ptef_local',str(module_\
\path))
mod=importlib.util.module_from_spec(spec)
import sys
sys.modules[spec.name]=mod
spec.loader.exec_module(mod)
with tempfile.TemporaryDirectory() as td:
g=mod.Guard(pathlib.Path(td)/'guard.db')
try:
n=500
g.set_budget('W1',n+100)
timings=[]
for i in range(n):
e=mod.Effect('bench-'+str(i),'W1','R1','TOKEN','CHAIN1',\
\1,'S1','N'+str(i))
g.authorize(e,1)
begin=time.perf_counter_ns()
result=g.verify_and_effect(e)
timings.append(time.perf_counter_ns()-begin)
assert result['decision']=='EFFECT_RELEASED'
assert g.emission_count()==n
s=sorted(timings)
print('PYTHON SQLite local model: operations={} p50_us={:.2f\
\} p95_us={:.2f} (excluding authorize)'.format(
n,s[int((n-1)*0.50)]/1000,s[int((n-1)*0.95)]/1000))
finally:
g.close()
Execution example for Python 3: save the full SEC-RUN-01 programlisting as PTEF_Security_Reference_Model.py; run python3 PTEF_Security_Reference_Model.py; run python3 PTEF_Security_Python_Latency_Example.py for measurement.¶
Execution example for Go: run go run PTEF_Security_Go_Protected_Gate.go using a standard Go installation; the program executes its assertions and prints percentile timings for 5,000 additional accepted local effects.¶
Execution example for JavaScript: run node PTEF_Security_JavaScript_Protected_Gate.js with Node.js; the program executes assertions and prints percentile timings for 5,000 additional accepted local effects.¶
Negative-effect acceptance: changed payee, amount, sink, nonce, code digest, code epoch, stale policy and replay do not increase the modeled emission count. Budget conflict does not authorize both effects. This is a local correctness property and does not establish the behavior of an unmodeled external signer.¶
Additional illustrative contrast: run python3 PTEF_Security_Python_Ledger_Contrast_Demo.py; inspect positive signed test cases, rejected beneficiary substitutions, rejected delegated-code substitution and the signature-tamper negative control. The HMAC secret and mock ledger semantics are solely instructional.¶
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
#!/usr/bin/env python3
"""Educational contrast between valid credential signatures and mand\
\ate authority.
This is NOT a blockchain implementation: HMAC substitutes for signat\
\ure verification;
no real consensus, chain nonce state, private keys, signing device o\
\r wallet is involved.
All demonstration secrets below are publicly readable test material.
"""
import hashlib
import hmac
import json
TEST_SECRET = b'public-example-only-never-use-to-secure-value'
REQUIRED = {'account','payee','asset','network','nonce','kind','amou\
\nt_minor','code_digest','code_epoch'}
def canonical(act):
if type(act) is not dict or set(act) != REQUIRED:
raise ValueError('invalid native descriptor')
if type(act['amount_minor']) is not int or act['amount_minor'] <\
\= 0:
raise ValueError('invalid amount')
if type(act['code_epoch']) is not int or act['code_epoch'] < 0:
raise ValueError('invalid code epoch')
return json.dumps(act, sort_keys=True, separators=(',',':')).enc\
\ode()
def test_sign(act):
return hmac.new(TEST_SECRET, canonical(act), hashlib.sha256).dig\
\est()
def mock_protocol_valid(act, tag):
# Illustrates only signature integrity, domain identity and well\
\-formed amount.
# Real ledger consensus can enforce additional conditions (nonce\
\, balance, fees, code).
try:
return (act['network']=='test-chain' and
hmac.compare_digest(test_sign(act), tag))
except (KeyError, TypeError, ValueError):
return False
class MandateGate:
def __init__(self, approved):
self.approved = dict(approved) # stands for independently p\
\rotected PED-1
self.used = False
self.emitted = 0
def verify_and_release(self, actual, tag):
if self.used or not mock_protocol_valid(actual, tag): return\
\ False
if any(actual.get(k) != expected for k,expected in self.appr\
\oved.items()):return False
# Local one-shot simulation only; real effect requires prote\
\cted exclusive signer.
self.used=True; self.emitted+=1
return True
def transfer(payee):
return dict(account='wallet-1',payee=payee,asset='TOKEN',network\
\='test-chain',
nonce='auth-1',kind='transfer',amount_minor=600,code\
\_digest='',code_epoch=0)
def run_tests():
checks=0
good=transfer('approved');gate=MandateGate(good)
assert mock_protocol_valid(good,test_sign(good));checks+=1
assert gate.verify_and_release(good,test_sign(good));checks+=1
assert not gate.verify_and_release(good,test_sign(good)) and gat\
\e.emitted==1;checks+=1
wrong=transfer('unapproved');v=MandateGate(good)
assert mock_protocol_valid(wrong,test_sign(wrong));checks+=1
assert not v.verify_and_release(wrong,test_sign(wrong)) and v.em\
\itted==0;checks+=1
# Test signed delegation: the protocol format is valid while exe\
\cutable code differs.
delegation=transfer('delegate');delegation.update(kind='delegate\
\',amount_minor=1,code_digest='code-approved',code_epoch=1)
hostile={**delegation,'code_digest':'code-changed'}
d=MandateGate(delegation)
assert mock_protocol_valid(hostile,test_sign(hostile));checks+=1
assert not d.verify_and_release(hostile,test_sign(hostile)) and \
\d.emitted==0;checks+=1
tampered={**good,'amount_minor':700}
assert not mock_protocol_valid(tampered,test_sign(good));checks+\
\=1
print('PYTHON illustrative signature/mandate contrast: local_che\
\cks_passed={}'.format(checks))
print('A valid mock credential signature is not, by itself, proo\
\f of exact approved effect.')
if __name__=='__main__':run_tests()
Three dissimilar time quantities must be separated. T_gate is elapsed time from presentation of the final effect descriptor to the protected local authorization decision; T_sign_and_dispatch is elapsed time to create and send the real effective command or signature; T_ledger_finality is the chain-specific time required for inclusion and the selected degree of consensus finality. A combined path can satisfy T_total = T_gate + T_sign_and_dispatch + T_network_inclusion + T_ledger_finality + T_external_reconciliation, with optional overlap according to the actual protocol. No local-only benchmark measures T_ledger_finality or proves post-settlement assurance.¶
The additional Python protocol/mandate contrast program executes eight local assertions. It does not measure latency and is excluded from the timing observations. Across all included local self-tests the originally retained Python model has 24 checks, the Go model 13 checks, the JavaScript model 12 checks, and the additional illustrative Python contrast 8 checks; the separate benchmark programs report samples but are not counted as security proofs.¶
Illustrative local measurements from the authoring runtime on 31 October 2026, not guarantees or universal engineering performance: Python 3 with SQLite WAL on a temporary local file, 500 separate accepted one-unit operations, measured only around verify_and_effect after each new authority was inserted, approximately 250.49 microseconds p50 and 678.92 microseconds p95. Go in-memory example, 5,000 accepted operations, approximately 80 nanoseconds p50 and 110 nanoseconds p95. Node.js in-memory example, 5,000 accepted operations, approximately 861 nanoseconds p50 and 1,973 nanoseconds p95. These observations were taken on different storage models, include no external cryptographic signing, and cannot be used as a like-for-like comparison or as proof of achieved production latency.¶
An engineering target for an adapted single-host or near-signer installation may be a protected decision p95 within approximately 1 to 10 milliseconds under a specified, measured workload, with alternative budgets for protected-key hardware, remote quorum protocols and durable synchronization. This range is a proposed design objective only; it is not established by the reference programs and must be validated for every deployment. The target is not guaranteed to be lower than the cost of every on-chain policy check. A permissioned chain, local execution environment or optimized smart-account function may have different characteristics.¶
The primary benefit compared with relying solely on later ledger validation is the earlier denial of an independently unauthorized act before an effective signature, privileged dispatch or irreversible settlement operation can be initiated, where the relevant path is actually controlled. An early refusal may also avoid unnecessary network submissions or transaction fees, but it cannot replace consensus, create faster blockchain finality, or prevent an already-effective malicious delegated contract from using an uncontrolled path. Throughput, cost, false-denial rate and latency must be measured under the selected threat and fault model.¶
A representative performance benchmark records p50, p95, p99, maximum, number of approved and denied candidates, durable fsync policy, processor and memory, process count, storage type, synchronization policy, cryptographic hardware, end-to-end signer latency, callback or acknowledgement behavior, network topology and finality depth. Each load test should include changed delegation code, altered recipient, two simultaneous budget-consuming workers, stale policy, process crash after journal commit, and an attempted backup-signer bypass. The measured gate must be observed at the real effective interface, not only through a successful local decision response.¶
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
for each workload profile W:
configure measured protection scope, key exclusivity, fsync poli\
\cy, signer placement
record valid and adversarial Candidate Acts under independently \
\stored authority
for each act:
t0 := monotonic_clock()
r := final_effect_gate.verify_and_maybe_release(act)
t1 := monotonic_clock()
collect (t1-t0, r.decision, real_signer_emission_count, actu\
\al_external_effect)
assert each DENY has zero unauthorized effect from every control\
\led effective path
assert bounded use is never exceeded under concurrent workers
report p50, p95, p99 and maximum; state excluded hardware / ledg\
\er delays
if unknown or unmediated bypass path exists: report that the sco\
\pe is unproven
// Never infer network confirmation, economic settlement or chain fi\
\nality from t1-t0.
|-T_gate-|-T_sign_and_dispatch-|-T_network_inclusion-|
|-T_ledger_finality-|-T_external_reconciliation-|
T_total = T_gate + T_sign_and_dispatch + T_network_inclusion
+ T_ledger_finality + T_external_reconciliation
(with optional overlap per protocol)
local benchmarks measure T_gate only; they do not measure
T_ledger_finality or settlement assurance
This section restates the protected arrangements for the threat models as enforcement points (EP-S-01 to EP-S-90). Each family opens with a base enforcement point that names the components and the release condition, followed by implementation variations that refine it. Variations are optional and non-limiting; an implementation may adopt any technically compatible subset. The threat-model identifiers in each family heading indicate which threat models the family primarily addresses. Lowercase "shall", "must" and "should" in this section describe the behavior of the described arrangement and are not BCP 14 requirements.¶
A protected transaction-effect control system that includes an independently controlled authorization store, an execution-facing operation adapter, a non-effective candidate-operation buffer, a protected use-state journal, and an effectuation interface configured to prevent release of an effective financial instruction in the absence of a protected decision. The authorization store records a principal, source account, permitted financial effect, sink identity, policy generation and bounded use. The adapter obtains a native operation from the buffer at the effectuation interface and independently reconstructs at least a recipient, value, asset or network identity, operation type and effect-bearing extension from the native operation rather than from a caller-provided approval summary. A verifier compares the reconstructed operation with the independently recorded permission and current protected use state. The effectuation interface refuses release on a mismatch and, on a match, coordinates consumption of a non-reusable authorization use with release of only the verified operation, such that possession of an otherwise valid service credential does not independently confer authority to change the financial effect.¶
The operation adapter obtains the operation after the last permitted transaction-building or serialization transformation, and rejects a changed recipient identifier, asset scale, fee, network domain, nested call parameter or unrecognized critical extension that was not permitted by the authorization store.¶
The non-effective candidate-operation buffer comprises an unsigned transaction buffer, a restricted signing queue, a pending programmable-account operation, or a guarded payment-instruction queue, each lacking an independent ability to create the protected financial effect.¶
The authorization store and the execution-facing operation adapter are protected from a compromised transaction-building process by different access-control authorities, independently authenticated channels or distinct hardware protection domains, and the transaction-building process cannot alter both the protected permission and the reconstructed effect.¶
The verifier computes an operation-context digest over typed fields and a versioned interpretation schema and declines execution where ambiguous integer scale, unrecognized optional-call semantics or inconsistent canonical encoding prevents reliable identification of the actual effect.¶
The effectuation interface is implemented by an effect-aware hardware security module signing function, an attested signing enclave, a protected settlement commit adapter, or a guarded programmable-account entry point, the selected interface controlling the first release capable of producing the specified effect.¶
A denial record identifies the rejected native-effect digest and policy generation, and an independently instrumented signing or dispatch interface establishes that no usable signature, executable authorization or protected transaction transmission was emitted for a denied candidate.¶
A cryptographic financial-operation authorization apparatus that includes a protected cryptographic key-use component having a restricted signing function, a protected transaction-authority record, a native signing-input decoder, and a durable authorization-use register. The cryptographic key-use component withholds any externally usable signature from a requester until the decoder reconstructs effect-critical financial parameters from the actual bytes to be signed, the reconstructed parameters are compared with the authority record independently of a requester-supplied digest description, and a current account, recipient, asset, amount, network, operation-kind and policy-generation condition is verified. The restricted signing function computes or verifies its signing preimage inside a protection boundary and binds an authorized operation identifier to protected use-state consumption in coordination with release of a signature. An unrestricted signing interface capable of using the same protected signing authority to create a covered financial effect is disabled or subjected to the same operation-specific check.¶
A private key is non-exportable, and its non-exportability is combined with an effect-aware signing interface that refuses arbitrary digest signing without independently validated native transaction semantics.¶
A signing response interrupted after cryptographic computation but before confirmation is assigned an unresolved signature-status record that prevents production of a fresh signature under the same bounded authorization until protected release records are reconciled.¶
The native signing-input decoder verifies a domain separator, chain identity, contract-call target, asset identifier, native-value field and encoded call data, and rejects a signed delegation authorization whose executable implementation identity differs from a protected permitted identity.¶
A remote signing client receives only an operation-specific result and cannot access a raw-signing, key-export, debug-signing, maintenance-signing or recovery-signing method capable of creating the same covered operation without protected validation.¶
The restricted signing function is realized in a hardware security module, trusted execution environment, cryptographic coprocessor or isolated signing service, and the protected use-state register is maintained within or authenticated to the selected protection boundary.¶
The protected signing decision records an authorization identifier, a digest of the final native representation, a signer generation, a single-use identifier and whether usable signature bytes were released, without representing that record as proof of downstream ledger acceptance or settlement.¶
A delegated-account execution authorization system that includes a protected delegation-authority record, a delegation-installation verifier, an execution-time delegate-call verifier and an account-effectuation interface. The protected delegation-authority record binds an account, approved implementation identity, permitted callable behavior, upgrade-state generation, validity interval, permitted spend effects and use limitations. The delegation-installation verifier reconstructs an actual authorization to install or designate executable account code and withholds an effective authorization when the actual code target, account domain or permitted behavior diverges from the record notwithstanding cryptographic validity of the authorization. The execution-time delegate-call verifier independently checks each covered operation initiated under an installed delegation against current protected policy and actual executable identity. The account-effectuation interface denies a transfer or other consequential account operation that does not satisfy the relevant installation and per-use checks and protected use-state consumption.¶
The delegation-installation verifier checks a code digest, implementation address, proxy implementation slot, upgrade authority or authorized code-generation identifier before a usable delegation signature is released.¶
The execution-time delegate-call verifier resolves an implementation reached by a proxy, delegate-call, nested call or upgradeable dispatcher, and refuses a covered financial effect when a mutable implementation does not match the currently permitted code generation.¶
An approved delegation installation does not independently authorize later spending, and each subsequent effect is subject to a separate recipient, value, asset, remaining-use and revocation comparison at a protected account or signing boundary.¶
A code upgrade invalidates a previously issued execution authorization whose code-identity or permitted-method binding cannot be proven valid for the upgraded executable implementation.¶
An on-chain account validation module enforces a per-operation effect limitation when off-chain signing control cannot prevent an already installed delegation from executing directly.¶
An unrecognized nested call, dynamically selected implementation or critical code-identity dependency prevents effective operation unless an independently enforced bounded-effect mechanism establishes that the operation remains within the permitted financial effects.¶
The account-effectuation interface authenticates a revocation or expiration generation and prevents the installed delegation from treating a newly received account balance as fresh authority to transfer that balance.¶
A persistent delegated-financial-authority containment apparatus that includes a programmable-account effect gate, a protected per-delegation allowance register, a source-account balance-event observer and a per-call effect reconstruction interface. A delegated implementation is permitted to remain installed independently of a particular account balance. The effect reconstruction interface derives, for each proposed delegated financial operation, an actual beneficiary, asset, transfer value and delegate identity from an operation about to become effective. The effect gate determines whether the reconstructed operation falls within a still-current delegation scope and an unconsumed allowance, without treating later incoming funds or a prior installation approval as an enlargement of that scope. The allowance register is advanced under protected serialization in coordination with each approved release, thereby preventing persistent executable delegation from obtaining additional spending authority solely because account value subsequently increases.¶
The programmable-account effect gate is a contract validation module having exclusive control over covered outgoing transfers, and the module rejects a delegate call lacking a current transfer-specific approval even if the account contains newly credited funds.¶
A previously permitted implementation receives a non-transferable, bounded execution authorization naming a recipient class, asset, maximum cumulative amount, expiry and account-effectuation interface, and copied authorization data cannot enable another delegate or account sink.¶
A new inbound deposit updates an observed account balance but leaves the protected per-delegation allowance unchanged until a separately authenticated authority increases the allowance.¶
A delegation termination event increments a protected generation such that queued calls, delayed relays or restarted delegate processes presenting an earlier generation are refused by the account-effectuation interface.¶
A withdrawal initiated before a balance change but released after the change is validated against the actual effect and protected remaining allowance at its effectuation boundary instead of being approved solely from a cached pre-deposit snapshot.¶
The per-call effect reconstruction interface includes a guarded executable-code adapter, an on-chain policy hook or an exclusive account-transaction signer, and a deployment using only an off-chain adapter does not assert prevention of transactions independently executable by unrestricted on-chain code.¶
A distributed threshold-financial-signing system that includes at least a threshold number of independently controlled signing participants, an authenticated session-identity record, a participant-side financial-effect verifier and a protected signing-nonce lifecycle register. Each signing participant independently derives a canonical commitment to the same native financial operation and compares the operation with a locally authenticated authority record and current policy generation before releasing a signature share. The session-identity record binds participant roster, threshold configuration, account, operation digest and session generation. The nonce lifecycle register prevents use of an abandoned, replayed or already consumed signing nonce after participant restart or coordinator replacement. An effective threshold signature cannot be assembled within the declared protection scope unless the required participants have approved the same authorized operation and session state, notwithstanding a compromised signing coordinator.¶
Each participant rejects a signing request when the operation digest or account, asset, recipient, maximum value or policy generation differs from a value independently authenticated to the participant.¶
A coordinator restart fences an earlier session generation and requires a new participant-agreed session identity before additional signature shares can be issued.¶
A signing-nonce commitment is permanently associated with one session and one financial-effect digest, and a conflicting preimage under that commitment causes the participant to abort without emitting a usable share.¶
A change in participant roster, quorum threshold or key-aggregation configuration is permitted only under an independently authorized signer-policy generation and cannot be selected solely by the coordinator proposing the financial operation.¶
An unavailable policy authority or a network partition preserves refusal of fresh shares rather than permitting the coordinator to substitute stale quorum approval, except within a pre-authorized bounded offline signing allocation enforced by the participants.¶
Signer participants comprise hardware security modules, independent cryptographic services or separately administered protected enclaves, and their authorization state is checked against an authenticated common operation identity without requiring storage of every participant key share in one physical enclosure.¶
A multi-account financial-effect budget enforcement system that includes a protected shared exposure record, a plurality of execution-facing wallet or account adapters operating across distinct financial networks, a reservation controller and a respective controlled effectuation interface for each participating account. Each adapter independently reconstructs an actual outgoing effect, including source account, recipient, asset, amount and network identity. The reservation controller associates the effects with a common independently authorized financial-exposure budget and obtains either a serialized reservation or a disjoint preallocated escrow entitlement before a participating interface may release the corresponding effect. Pending, released and outcome-unknown effects remain charged to the common budget until supported evidence permits an adjustment. Simultaneous individually permissible requests cannot collectively release more exposure than the protected budget permits within the participating controlled interfaces.¶
The participating interfaces include at least two protected wallet signers associated with different chains, and a common exposure value is computed using a protected versioned valuation rule where the assets or value units differ.¶
The reservation controller serializes concurrent authorization consumption through a transactional database lock, a protected counter, a consensus-backed authority service or non-overlapping pre-reserved budget partitions.¶
A network partition fences any signer without a current protected reservation or valid unexpired escrow entitlement, and no two isolated signers may independently issue the same escrow allocation.¶
A pending withdrawal continues to encumber a budget even when a remote acknowledgment is absent, and a timeout does not itself restore the associated spending capacity.¶
The reservation controller maintains a network- and account-specific exposure state together with a tenant-level or treasury-level aggregate state, and both states are atomically checked for each proposed effect.¶
A newly discovered independent signing path that can spend a participating account without checking the shared exposure record causes suspension of the system's declared aggregate-enforcement coverage until that path is controlled or excluded from the covered account set.¶
A protected account-authorization replay control apparatus that includes an operation-specific authorization registry, a native account-nonce adapter, a protected use-state register and an effective signing or account-execution interface. The registry binds an independently approved financial effect to a permitted account, network, native nonce condition, validity period and bounded authorization-use identity. The nonce adapter distinguishes a native network transaction nonce from the independently protected authorization-use identity and verifies both against the actual transaction about to be signed or executed. The use-state register durably consumes a validly allocated authorization-use identity at a protected serialization point. Presentation of alternative signatures, copied permit bytes, substituted network nonces or repeated authorization messages cannot create a second covered financial effect under the same independently granted permission.¶
An authorization for executable-code delegation is bound to an account and target code-identity generation and is invalidated when a different candidate changes the target implementation while reusing the original authorization-use identity.¶
A plurality of candidate messages differing only in their account-network nonces cannot each obtain separate protected spending permission unless separately allocated bounded-use identities and budget capacity are available.¶
A copied authorization representation presented at a different effectuation sink, tenant, account or network domain is refused notwithstanding verification of its cryptographic authenticator.¶
Malformed or unauthenticated requests are rejected without burning arbitrary native network nonce values belonging to another legitimate account operation, and only an authenticated locally allocated use identity may be irreversibly consumed on a denied attempt.¶
An authorization accepted before a network reorganization or nonce-state change is reevaluated against the current native account state before a later effective release, without resetting the protected use-state register to permit duplicate issuance.¶
The protected use-state register is a rollback-resistant hardware counter, durable keyed ledger, sink-local transactional journal or account-contract storage, and copied authorization data is ineffective without confirmation of current register state at the operative interface.¶
A consequence-path mediation system for restricting unauthorized financial effects that includes a machine-readable reachability representation of effect-capable components, a plurality of enforcement interfaces, an authority inventory and a path-completeness evaluator. The reachability representation identifies at least transaction-building processes, signing interfaces, key-recovery routes, account-delegation methods, backup-region dispatch paths and final financial-effect destinations. The evaluator determines, for each path originating from an untrusted proposer and reaching a covered effect-capable destination, whether the path crosses an enforcement interface that independently verifies current financial authority and native operation semantics and controls release of the effect. The system either enforces the required verification at every such path or marks a discovered unmediated path as outside its protected coverage and prevents the affected path from being represented as protected by a positive decision recorded at a different interface.¶
The authority inventory associates each signing key, key share, wallet identity, maintenance credential, recovery identity and privileged account method with the financial effects the item can independently produce.¶
A backup hardware signer or disaster-recovery region cannot release a covered effect until its interface authenticates a current authority generation and checks use state shared with, or disjointly fenced from, a primary region.¶
A direct contract method that permits transfers independently of an off-chain signing gateway is classified as an unmediated path unless a contract-level validator enforces corresponding operation-specific restrictions.¶
A newly enabled raw-digest signing, debug, export, emergency or key-restoration method triggers reevaluation of the reachability representation before the method is permitted to produce a covered effect.¶
The evaluator computes a cut set of protected enforcement interfaces intersecting all enumerated paths to each covered financial effect and requires a deployment-time test showing denial at an effect-capable destination when each protected interface refuses an unauthorized native operation.¶
An operating-system security hook, credential daemon, key-use hardware boundary or programmable-account validation function forms an enforcement interface only where its authority actually prevents an alternate effect-capable operation from bypassing the same check.¶
A negative-effect validation injects a disallowed transaction through both normal and alternate routes and checks the actual count of externally usable signatures, accepted privileged commands or admitted ledger transactions, rather than relying only on a gateway denial response.¶
A protected financial-authority continuity apparatus that includes an authenticated policy-generation source, a revocation-state authority, a durable monotonic state anchor, a plurality of effectuation gateways and a generation-fencing controller. Each gateway obtains or validates an applicable policy generation and revocation generation before releasing an operation-specific financial effect. The generation-fencing controller prevents a gateway restored from an earlier snapshot, transferred to a backup region or isolated by a network partition from treating a previously valid authorization artifact as current merely because its digital signature still verifies. Release of a covered operation requires protected effect comparison and a consumption transition consistent with an authenticated non-rollback state anchor, with a gateway unable to establish the requisite current generation retaining the candidate operation in a non-effective state.¶
A recovered gateway compares a sealed local generation against a higher independently authenticated generation and refuses any use identity issued for a superseded generation until protected state is reconciled.¶
A bounded offline lease specifies an expiry, total value allowance, sink identity and policy generation, and the gateway may spend only the remaining precommitted lease entitlement while disconnected from the revocation-state authority.¶
A protected hardware monotonic counter, authenticated quorum epoch or non-rollback key-state service forms the durable monotonic state anchor and prevents revival of a consumed authorization after restoration of a virtual-machine snapshot.¶
A failover operation fences the prior gateway's signing or dispatch authority before the replacement gateway can consume authority for the same financial operation or shared spending budget.¶
A revoked delegation, signer-key policy or recipient permission causes a generation transition that invalidates pending execution handles not already irreversibly effectuated, including handles generated before the revocation became visible to a request builder.¶
The gateways may be geographically distributed or located in hardware-enforced partitions on one host, and the claimed continuity is limited to the authenticated generation and revocation conditions actually enforceable under a partition or connectivity failure.¶
A crash-safe financial-effect initiation system that includes a non-effective transaction queue, an exclusive effect-release interface, a protected prepare-and-consume journal and a downstream outcome reconciler. The protected journal records an independently authenticated operation identity and exact native financial-effect digest before an effect-release attempt. The release interface coordinates a durable use-state transition with release of an effective signature, payment command or account operation and records whether release may have occurred. Interruption after possible release but before acknowledgment causes an outcome-unknown state which is not treated as failed settlement. A retry scheduler cannot generate another independent effective instruction under the same financial authorization solely by replacing a transport request identifier, until supported downstream evidence or a newly authorized distinct financial act resolves the condition.¶
A durable preparation record identifies a sink identity, source account, recipient, amount, operation digest, native transaction identifier and idempotency identity and is committed before an effective command is allowed to escape.¶
Failure after protected consumption but before confirmation of signature release retains the consumed use identity and invokes a non-effectuating signature-status query rather than authorizing a new key-use operation.¶
Failure after a payment instruction is transmitted but before a downstream receipt causes the outcome reconciler to query a trusted endpoint, transaction ledger or settlement reference without issuing a second payment command.¶
A downstream receipt is classified as initiation acknowledgment, network admission, provisional inclusion, confirmed ledger effect or settlement evidence, and a local authorization record cannot be promoted to a stronger class without separately authenticated evidence.¶
A compensation, reversal or refund arising after a partial financial effect is represented as a newly authorized corrective candidate with its own non-reusable protected use identity rather than as automatic restoration of the original authorization.¶
A transactional outbox, protected hardware command counter or constrained signer queue coordinates the journal with effect release, and non-cooperating external rails are represented with explicit outcome uncertainty instead of an unsupported guarantee of globally exactly-once settlement.¶
A recovery process compares protected journal records with observed sink-side effective output counts and fails a negative-effect test if a single consumed authorization caused two independently effective financial commands.¶
A protected autonomous-agent financial effectuation system that includes an autonomous computational agent, an instruction-provenance classifier, an independently authenticated financial authority source, an execution-facing tool-call adapter and a protected payment or signing sink. The agent is permitted to process untrusted retrieved content, messages, browser output or third-party tool results to propose a financial Candidate Act but is prevented from independently converting those materials into increased financial authority. The tool-call adapter obtains the actual operation that a payment, signing or wallet tool would execute and reconstructs a beneficiary, amount, asset, purpose and destination. The sink compares the reconstructed operation with a protected authority record and current use state, taking account of whether proposed changes originated from untrusted instruction material. The sink refuses an otherwise authenticated tool invocation when its financial consequence exceeds the independently authorized effect, notwithstanding possession of a valid agent credential.¶
The instruction-provenance classifier labels supplier pages, retrieved documents, emails, payment challenges or tool outputs as informational inputs that cannot themselves alter the financial authority record.¶
An agent-generated approval explanation, chain-of-thought summary, simulated confirmation or user-interface message is insufficient as authorization unless linked to independently authenticated authority acquired through a protected channel.¶
A payment tool's credential is isolated within a host-controlled credential service or protected gateway, and the computational agent receives only a constrained interface that cannot export unrestricted signing keys or invoke an unmediated payment route.¶
An autonomous agent delegates work to another agent or tool worker under a parent spending envelope and a child-specific bounded budget, and payment release consumes both the child authorization and shared parent budget without duplicating spending capacity.¶
A machine-readable payment challenge is validated against an independently resolved service or merchant identity, requested resource identifier, maximum price, supported asset and receiving endpoint before the sink releases any payment-specific signature or authorization.¶
A legitimate signed payment request that reaches the sink with a modified recipient, larger amount or altered settlement network is denied even when the agent session, transport channel and payment tool authentication remain valid.¶
Protected payment-initiation evidence is maintained separately from authenticated proof of service delivery or settlement and an agent cannot interpret a local positive authorization receipt as permission to duplicate payment after an ambiguous downstream result.¶
A multi-domain value-transfer finality system that includes a protected economic-obligation record, a source-domain event verifier, a destination-domain release controller, a conversion-effect adapter and a plurality of independently maintained leg-state journals. An authorized obligation specifies a source asset and amount, permitted conversion parameters, intended destination asset and beneficiary, applicable source and destination domains and required effect conditions. The source-domain event verifier independently verifies native source-event identity, confirmation or finality state and applicable reorganization or revocation conditions rather than accepting an unverified relay statement as conclusive. The conversion-effect adapter reconstructs actual destination value, asset mapping, fees, route and recipient from executable native operations. The destination-domain release controller compares the reconstructed destination effect with the protected obligation and source evidence and conditionally consumes a destination-specific protected authorization before a credit, mint, unlock or payment becomes effective. Each leg remains independently classified as pending, effective, reversed or outcome-unknown without representing a local allowance as globally atomic settlement.¶
A change of bridge route, relayer, settlement provider, network or asset-conversion path after initial approval triggers revalidation of the actual converted effect against a protected maximum debit, minimum receivable amount and permitted beneficiary.¶
The source-domain event verifier rejects a replayed source event, invalid state proof, insufficient confirmation, source-chain reorganization or event identifier that has already been consumed for a covered destination release.¶
The destination-domain release controller is positioned at a controlled minting contract, bridge signing quorum, settlement-account commit interface or protected token-unlock function that cannot be independently bypassed for a covered destination credit.¶
A bridge implementation upgrade, validator-roster change, rollup proof-generation change or destination token-mapping revision causes revalidation of the corresponding authorized code or verification generation before destination effectuation.¶
An operation involving two independently administered settlement domains maintains separate per-leg authorization consumption identifiers and refuses dependent release when a required source leg is outcome-unknown rather than independently evidenced as sufficiently final under an expressly selected settlement policy.¶
A conversion-effect descriptor records source and destination units, fee assessment, rounding rule, rate reference, intermediate asset identity and ultimate beneficiary, and the destination release is withheld when a critical conversion transformation cannot be deterministically reconstructed.¶
A partial-release event causes the corresponding leg-state journal to preserve already effective obligations and to require a separately authorized compensation or reconciliation action rather than unconditionally retrying all legs of the transfer.¶
An uncooperative external ledger, bridge or relay that can independently issue an equivalent credit outside the destination-domain release controller is expressly excluded from the declared enforcement scope unless an additional independently validating effect gate mediates that external credit path.¶
This entire document is a security analysis. The main considerations are: protection exists only on mediated paths, so path enumeration and per-path negative tests are required; reconstruction must use strict, versioned parsing of the final native bytes, and undecodable or ambiguous semantics must be denied or confined; consumption must be durable, serialized with release and protected against rollback; stale replicas and restored snapshots must be fenced; unknown outcomes must be reconciled on the original identifier and never replayed; and denial burning must apply only to authentically allocated use identities so that malformed input cannot exhaust legitimate nonce space. Compromise of the protected trust root, an independently usable key, or an already effective unrestricted delegation defeats an off-chain gate.¶
Authority records, effect descriptors and decision records contain account, counterparty and amount data and should be minimized, access-controlled and retained only as needed. Test vectors and reference models use synthetic data only.¶
This document has no IANA actions.¶
The author welcomes critical technical review. The analysis may contain errors or gaps, and corrections are invited.¶