Internet Engineering Task Force S. K. Das Internet-Draft Independent Researcher Intended status: Experimental 31 October 2026 Expires: 4 May 2027 Protected Transaction Authority and Execution-Finality Boundaries for Delegated Digital Operations draft-das-protected-transaction-execution-finality-00 Abstract Recent publicly reported incidents involving unauthorized use of legitimately signed account-delegation and asset-transfer operations have exposed a gap between cryptographic validity and permission to perform an exact consequential act. This document proposes an experimental, transport-independent execution-finality protocol for delegated digital operations. A Candidate Act is placed in a non- effective state; protected collection-time and execution-time enforcement domains bind approved intent, independently reconstruct the pending effect, and require an unforgeable, sink-specific, single-use authorization before signing, dispatching, transmitting, exporting, or actuating. The protocol specifies state continuity, revocation, nonce burn, quota settlement, delegated-code controls, multi-domain interoperability, failure behavior, receipts, conformance tests, and migration profiles. It includes ASCII sequence diagrams and flowcharts, complete executable Python, Go, and JavaScript reference listings, a reproducible test-vector generator and runner, and recorded cross-language test results in informative appendices. This is a proposal for discussion, not an adopted IETF standard; the reference code is not production cryptographic custody software. Status of This Memo 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." Das Expires 4 May 2027 [Page 1] Internet-Draft Protected Transaction Execution Finality October 2026 This Internet-Draft will expire on 4 May 2027. Copyright Notice 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. Table of Contents 1. Introduction and Recent Security Motivation . . . . . . . . . 5 2. Status, Scope and Interpretation . . . . . . . . . . . . . . 6 3. Architecture, Roles and Trust Topology . . . . . . . . . . . 7 4. Threat Model and Security Assumptions . . . . . . . . . . . . 8 5. Protocol Objects and Canonical Semantics . . . . . . . . . . 9 6. Wire Exchange and Message Ordering . . . . . . . . . . . . . 10 7. Protected State, Replay and Atomicity . . . . . . . . . . . . 11 8. Delegated-Code Authority and EIP-7702 Profile . . . . . . . . 12 9. Execution-Time Reconstruction and Equality . . . . . . . . . 13 10. Decision Codes, Failure Classes and Receipts . . . . . . . . 14 11. Transport, Serialization and Cryptographic Profiles . . . . . 15 12. Interoperability and Deployment Profiles . . . . . . . . . . 15 13. Formal Safety Invariants and Progress Properties . . . . . . 16 14. Security and Privacy Considerations . . . . . . . . . . . . . 17 15. IANA, IETF IPR and Implementation Maturity . . . . . . . . . 18 16. M-01. Canonical Account and Tenant Binding . . . . . . . . . 18 17. M-02. Destination and Payee Substitution . . . . . . . . . . 21 18. M-03. Delegation Code Hash Rotation . . . . . . . . . . . . 24 19. M-04. Chain Identifier and Consensus Domain . . . . . . . . 27 20. M-05. Signer-Service Impersonation . . . . . . . . . . . . . 30 21. M-06. Pre-Signature Delegation Screening . . . . . . . . . . 33 22. M-07. Account Nonce Versus Local One-Shot Capability . . . . 36 23. M-08. Receipt-Before-Authority Release . . . . . . . . . . . 39 24. M-09. Receipt Versus Final Settlement . . . . . . . . . . . 42 25. M-10. Policy Revocation Under In-Flight Load . . . . . . . . 45 26. M-11. Concurrent Quota Reservation . . . . . . . . . . . . . 48 27. M-12. Multi-Currency and Decimal Normalization . . . . . . . 51 28. M-13. Fee and Gas-Budget Bounding . . . . . . . . . . . . . 54 29. M-14. Cross-Service Credential Substitution . . . . . . . . 57 30. M-15. Non-Bearer Execution Handle . . . . . . . . . . . . . 60 Das Expires 4 May 2027 [Page 2] Internet-Draft Protected Transaction Execution Finality October 2026 31. M-16. Untrusted Planner and Tool Injection . . . . . . . . . 63 32. M-17. Code-Execution Sandbox Egress . . . . . . . . . . . . 66 33. M-18. Cloud Resource Mutation . . . . . . . . . . . . . . . 69 34. M-19. Device Actuation and Reset Epoch . . . . . . . . . . . 72 35. M-20. Radio Transmission Finality . . . . . . . . . . . . . 75 36. M-21. Payment Initiation and Clearing . . . . . . . . . . . 78 37. M-22. Multi-Channel Communications Quota . . . . . . . . . . 81 38. M-23. Data Export and Privacy Boundary . . . . . . . . . . . 84 39. M-24. Cryptographic Key-Usage Separation . . . . . . . . . . 87 40. M-25. Hardware Security Module Integration . . . . . . . . . 90 41. M-26. Cross-Region Policy Continuity . . . . . . . . . . . . 93 42. M-27. Offline Signing and Air-Gapped Approval . . . . . . . 96 43. M-28. Distributed Ledger Non-Inclusion . . . . . . . . . . . 99 44. M-29. External State-Root Drift . . . . . . . . . . . . . . 102 45. M-30. Fallback Path and Emergency Operator . . . . . . . . . 105 46. M-31. Service-Mesh and Sidecar Bypass . . . . . . . . . . . 108 47. M-32. Versioned Policy Rollback Protection . . . . . . . . . 111 48. M-33. Unknown Critical Extension . . . . . . . . . . . . . . 114 49. M-34. Canonical Unicode and Binary Addresses . . . . . . . . 117 50. M-35. Delegation Persistence Across Failures . . . . . . . . 120 51. M-36. Signer Threshold and Dual Control . . . . . . . . . . 123 52. M-37. Remote Attestation and Runtime Measurement . . . . . . 126 53. M-38. Source Authority and Instruction Lineage . . . . . . . 129 54. M-39. Protected Audit Chain and Redaction . . . . . . . . . 132 55. M-40. Crash-Safe Idempotent Commit . . . . . . . . . . . . . 135 56. M-41. Multi-Sink Atomicity and Partial Failure . . . . . . . 138 57. M-42. Bounded Clock Uncertainty . . . . . . . . . . . . . . 141 58. M-43. Revocation Cache and Partition Semantics . . . . . . . 144 59. M-44. Request Cancellation and Nonce Burn . . . . . . . . . 147 60. M-45. Quorum Witness Availability . . . . . . . . . . . . . 150 61. M-46. Semantic Transaction Simulation . . . . . . . . . . . 153 62. M-47. Account Abstraction and User Operation . . . . . . . . 156 63. M-48. Delegation Scope and Call-Graph Closure . . . . . . . 159 64. M-49. Constrained Upgrades and Rollback . . . . . . . . . . 162 65. M-50. External Withdrawal Destination Registry . . . . . . . 165 66. M-51. Protocol Downgrade and Legacy Credentials . . . . . . 168 67. M-52. Overload and Resource Exhaustion . . . . . . . . . . . 171 68. M-53. Formal Mediation-Path Enumeration . . . . . . . . . . 174 69. M-54. Multi-Party Administrative Governance . . . . . . . . 177 70. M-55. Sensitive Metadata Minimization . . . . . . . . . . . 180 71. M-56. On-Device Firmware and Silicon Continuity . . . . . . 183 72. M-57. Non-Repudiable Audit Without False Finality . . . . . 186 73. M-58. Independent Verification of Prior Approval . . . . . . 189 74. M-59. Post-Authorization Route Mutation . . . . . . . . . . 192 75. Algorithm: Two-Instance Intent-to-Effect Protocol . . . . . . 195 76. Algorithm: Denial, Crash Recovery and Anti-Replay . . . . . . 196 77. Algorithm: Policy Epoch and Quota Settlement . . . . . . . . 197 78. Conformance Levels and Test Methodology . . . . . . . . . . . 198 Das Expires 4 May 2027 [Page 3] Internet-Draft Protected Transaction Execution Finality October 2026 79. Test-Vector Catalog 001-008 . . . . . . . . . . . . . . . . . 199 80. Test-Vector Catalog 009-016 . . . . . . . . . . . . . . . . . 201 81. Test-Vector Catalog 017-024 . . . . . . . . . . . . . . . . . 203 82. Test-Vector Catalog 025-032 . . . . . . . . . . . . . . . . . 205 83. Test-Vector Catalog 033-040 . . . . . . . . . . . . . . . . . 207 84. Test-Vector Catalog 041-048 . . . . . . . . . . . . . . . . . 209 85. Test-Vector Catalog 049-056 . . . . . . . . . . . . . . . . . 211 86. Test-Vector Catalog 057-064 . . . . . . . . . . . . . . . . . 213 87. Test-Vector Catalog 065-072 . . . . . . . . . . . . . . . . . 215 88. Test-Vector Catalog 073-080 . . . . . . . . . . . . . . . . . 217 89. Test-Vector Catalog 081-088 . . . . . . . . . . . . . . . . . 220 90. Test-Vector Catalog 089-096 . . . . . . . . . . . . . . . . . 222 91. Test-Vector Catalog 097-104 . . . . . . . . . . . . . . . . . 224 92. Test-Vector Catalog 105-112 . . . . . . . . . . . . . . . . . 226 93. Test-Vector Catalog 113-120 . . . . . . . . . . . . . . . . . 228 94. Test-Vector Catalog 121-128 . . . . . . . . . . . . . . . . . 230 95. Test-Vector Catalog 129-136 . . . . . . . . . . . . . . . . . 232 96. Test-Vector Catalog 137-144 . . . . . . . . . . . . . . . . . 234 97. Test-Vector Catalog 145-148 . . . . . . . . . . . . . . . . . 236 98. Reference Implementations: Python, Go and JavaScript . . . . 237 99. Reference Implementation Limitations and Required Production Changes . . . . . . . . . . . . . . . . . . . . . . . . . 239 100. Interoperability Test Playbook and Operator Checklist . . . 239 101. References . . . . . . . . . . . . . . . . . . . . . . . . . 240 Appendix A. Runnable Reference Model, Scope and How to Reproduce (Informative) . . . . . . . . . . . . . . . . . . . . . . 241 Appendix B. Captured Laboratory Test Results and Coverage (Informative) . . . . . . . . . . . . . . . . . . . . . . 242 Appendix C. Python 3 Executable Reference Engine (Informative) . . . . . . . . . . . . . . . . . . . . . . 243 Appendix D. Go Executable Reference Engine (Informative) . . . . 246 Appendix E. Go Module Metadata (Informative) . . . . . . . . . . 248 Appendix F. JavaScript Executable Reference Engine (Informative) . . . . . . . . . . . . . . . . . . . . . . 248 Appendix G. Deterministic Test-Vector Generator (Informative) . 250 Appendix H. Cross-Language Test Runner (Informative) . . . . . . 253 Appendix I. Extract Embedded Executable Listings from This RFCXML (Informative) . . . . . . . . . . . . . . . . . . . . . . 254 Appendix J. Reference Source Fingerprints and Reproducibility Boundaries (Informative) . . . . . . . . . . . . . . . . 254 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 255 Das Expires 4 May 2027 [Page 4] Internet-Draft Protected Transaction Execution Finality October 2026 1. Introduction and Recent Security Motivation Modern digital operations traverse several independently secured components: a planner, a workflow host, an identity provider, an approval service, a signing daemon, a transaction builder, a relay, a remote protocol endpoint and an effectuation sink. Authentication proves a principal or credential relationship; transport security protects a channel; neither necessarily proves that the final effect exactly matches an authorized intent at the moment the effect becomes possible. Recent publicly reported incidents involving signed delegations and unauthorized digital-asset movements illustrate the practical distinction. A signature may satisfy a platform-level verification rule while being inconsistent with an operator-approved destination, delegation target, execution path, revocation state, or usage limit. The document deliberately does not identify any organization, incident amount, or affected customer. The proposed protocol is called Protected Transaction Execution Finality (PTEF). PTEF is an experimental application-layer coordination and enforcement model, not a replacement for a ledger signature format, cryptographic verification, OAuth, TLS, or existing transaction semantics. PTEF mediates the last trustworthy point before a consequential effect, with a sink-local final decision. All names, field values, and examples herein are provisional and subject to IETF review. A deployment claims conformance only for the specific effectuation paths it can actually mediate. An off-chain guard cannot stop a party that directly possesses an unrestrained signing key, and an API gateway cannot stop an independent physical control path. Implementers MUST enumerate and close every relevant alternate path or narrow their stated coverage accordingly. * The protected boundary MUST reject a validly signed but policy- inconsistent act. * A positive approval MUST be scoped to the exact act, sink, environment and policy version. * A successful decision MUST consume a bounded authorization atomically with effect initiation. * No deployment may claim on-chain finality or post-commit settlement solely because an off-chain precommit authorization was issued. Das Expires 4 May 2027 [Page 5] Internet-Draft Protected Transaction Execution Finality October 2026 Identity / token / secure channel Action-specific authority +------------------------------+ +-----------------------+ | Authenticates a relationship | -------> | Reconstruct exact act | | Protects message in transit | | Check policy + state | +------------------------------+ | Verify exclusive path | +-----------+-----------+ | v +--------------------+ | Effectuation sink | | Atomic consumption | +--------------------+ Figure 1: Problem separation 2. Status, Scope and Interpretation This memo is a proposed Internet-Draft using RFCXML version 3 and is explicitly experimental. It defines interoperability requirements for application-layer decision exchanges between protected authorities and effectuation sinks; it does not assign an IANA code point, change an existing blockchain consensus rule, or mandate a hardware vendor. A proof-of-concept directory accompanies the memo, and security evaluations are restricted to that directory and its laboratory vectors. The uppercase terms MUST, MUST NOT, SHOULD, SHOULD NOT, MAY and RECOMMENDED are interpreted as described by BCP 14 [RFC2119] [RFC8174] only when capitalized. Non-normative deployment examples illustrate possible profiles and are not blanket claims about cryptocurrency platforms or other systems. The protocol separates four questions: who or what may request; what exact action was permitted; whether the authorization remains applicable at the local sink; and whether the sink can effectuate atomically under that permission. An upstream allow decision is neither the final enforcement decision nor evidence that the consequence actually occurred. Profiles cover asset movement, code delegation, payment initiation, credential-assisted API actions, service-provider communications, radio actuation, cloud mutation, data export, and autonomous agent execution. A profile MUST state its irreversible or externally visible boundary. A purely advisory monitor that cannot refuse the act is outside the conformance definition. Das Expires 4 May 2027 [Page 6] Internet-Draft Protected Transaction Execution Finality October 2026 Related specifications used by the profiles in this document include CBOR [RFC8949], COSE [RFC9052], the RATS architecture [RFC9334], OAuth 2.0 Rich Authorization Requests [RFC9396], OAuth 2.0 DPoP [RFC9449] and the EIP-7702 account-delegation model [EIP7702]. IETF intellectual-property rules are described in [RFC8179], and the document format follows [RFC7991]. * Normative messages are conceptual until their concrete serialization and registry are standardized. * No Internet-Draft is an RFC or IETF consensus document merely because it uses RFCXML. * All illustrative cryptographic tags in the reference repository use public demo secrets and MUST NOT be deployed. 3. Architecture, Roles and Trust Topology The Candidate Act (CA) is the exact proposed external effect, represented without releasing the authority needed to perform it. A Non-Effective State (NES) is a holding region, queue, unsigned transaction object or protected device command buffer in which a candidate cannot create the effect by itself. The Protected Enforcement Domain (PED) is an isolation and policy environment with authority not transferable to the untrusted computation or planning plane. PED-1 binds collection-time intent, provenance, policy context, approved effect attributes and a nonce. PED-2 reconstructs the execution-time act from the actual bytes, destinations, resource identifiers, device state and code delegation target that are about to be used. The Finality Sink (FS) or protected signing boundary is the sole permitted transition from NES to effect initiation. A Protected Authority Component may create a narrowly scoped Execution Handle (EH) only after PED-2 is satisfied. The handle is non-bearer: possession of bytes alone MUST NOT be sufficient to exercise it from a different sink, principal, context or runtime. The FS checks the handle against its own protected state and a digest of the pending operation. Its use is atomic with the initiating effect, and denial invalidates the attempted authority. A verifier witness, policy authority and settlement receipt service MAY be separate processes or co-resident protected modules. The authority/gate separation is logical and MUST resist compromise of the ordinary agent process; a deployment MUST state which compromise domains it assumes independent. Das Expires 4 May 2027 [Page 7] Internet-Draft Protected Transaction Execution Finality October 2026 +------------------- UNTRUSTED COMPUTATION -------------------+ | Agent / UI / controller -> candidate action -> NES queue | +-------------------------+----------------------------------+ | proposed exact act v +------------------ PROTECTED AUTHORITY ---------------------+ | PED-1: bind approved intent PED-2: reconstruct at use | | policy, provenance, epoch bytes, state, sink identity | +---------------+---------------------------+---------------+ | non-bearer Execution Handle v +--------------------- FINALITY SINK -------------------------+ | verify EH + current state | atomic consume | sign / emit | +---------------------------------------------+--------------+ | effect v External consequence Figure 2: Architecture and protected islands 4. Threat Model and Security Assumptions The adversary may control a planning model, tool output, job runner, workflow container, proxy, credential-bearing process, API client, transaction constructor, telemetry source, or network route. The adversary may induce approval confusion, exploit stale state, misdirect a transfer, substitute a delegate address, reorder signing requests, race a revocation, repeat a nonce, or split a single authorized effect into many unauthorized consequences. The baseline assumes the protected FS has a trustworthy key or exclusive actuation privilege, correct monotonic state, authenticated source of policy epochs, and bounded clock uncertainty. The application transport may be adversarial; TLS, mTLS, COSE and authenticated transport are complementary but insufficient without action binding. The proposal cannot protect against deliberate malicious authorization by a legitimate policy owner, implementation errors inside the FS trusted computing base, a compromised hardware root, a direct use of exported signing keys, a physically independent alternate transmitter, or a blockchain rule that allows a signature outside the chosen gate. Such exclusions MUST be explicit in a deployment security statement. Das Expires 4 May 2027 [Page 8] Internet-Draft Protected Transaction Execution Finality October 2026 The adversary may run simultaneous requests on multiple workers and across zones. State management MUST provide a linearizable consume operation for each authorization resource, or else enforce a provable partitioning invariant under which two concurrent requests cannot both spend the same authority or quota. * No producer-provided authorization claim is trusted without independent verification. * No UNKNOWN lineage value may be silently upgraded to VERIFIED. * A timeout, absence of witness, or partial commit is a denial or indeterminate non-effective state, never implicit approval. 5. Protocol Objects and Canonical Semantics A PTEF request describes a CandidateAct, IntentBinding, CurrentObservation, PolicyReference, ProtectedWitness and SinkTarget. CandidateAct identifies operation kind, resource, counterparty, value, source account, delegated code hash, deployment domain, nonce and candidate identifier. IntentBinding refers to authorized constraints; it is not itself a bearer credential. An execution handle binds at least the protocol version, issuer identity, authorized candidate digest, subject and tenant, sink identifier, operation type, effect destination, acceptable code or payload digest, policy epoch, revocation epoch, local state generation, validity interval, unique usage identifier and a maximum usage count. Omitted optional fields MUST have a canonical and profile-defined interpretation; unknown security-critical extensions MUST cause rejection. ProtectedWitness covers the authority attestation over the exact handle and a precommit boundary observation. A receipt is only a record of what the FS decided and, separately, what the external system acknowledged. These two records MUST NOT be conflated. Where the effect is asynchronous, the final outcome is UNKNOWN until independently observed. Interoperable deployments SHOULD employ deterministic CBOR (RFC 8949) and COSE structures (RFC 9052) with explicit critical headers, algorithm constraints, domain separation and protected key storage. The repository uses a separate, byte-length-prefixed educational encoding only to demonstrate cross-language binding without introducing dependencies. Das Expires 4 May 2027 [Page 9] Internet-Draft Protected Transaction Execution Finality October 2026 PTEF-Request = { version: 1, candidate: { id, kind, domain, tenant, target, amount, nonce }, delegate: { chain_id, contract, code_hash, state_root }, intent: { authorized_digest, purpose, policy_epoch }, freshness: { not_before, not_after, revocation_epoch }, protected: { sink_id, sink_generation, witness, usage_limit }, extensions: { critical_extension_names, profile_data } } PTEF-Decision = { candidate_id, sink_id, decision, reason_code, consumed_nonce, committed_effect_digest, decision_epoch, precommit_receipt, external_outcome: UNKNOWN | ACK | FAIL } Figure 3: Illustrative conceptual PTEF envelope 6. Wire Exchange and Message Ordering The protocol exchanges PTEF-PREPARE, PTEF-CHALLENGE, PTEF-WITNESS, PTEF-COMMIT, PTEF-DENY and PTEF-STATUS messages. PREPARE carries a candidate without transferable effect authority. CHALLENGE binds a verifier nonce and local sink generation. WITNESS contains a cryptographically authenticated response from the protected authority. COMMIT transfers a short-lived, sink-specific handle directly to the protected sink over a mutually authenticated channel, not through an arbitrary planner. A valid response is not sufficient to commit until the FS verifies the current operation against its own reconstruction. The boundary SHALL be positioned such that no signature or device command capable of bypassing the FS has already escaped. Applications MAY pipeline non-sensitive computation but MUST NOT release an effective delegation authorization until verification and protected consumption complete. The PREPARE and WITNESS messages MAY be retransmitted with the same request identifier; duplicates do not extend validity and do not add quota. A COMMIT request MUST be idempotently associated with one consumed authorization identity. A cached ALLOW response MUST NOT grant a second external effect. An external ledger confirmation, downstream acceptance or device acknowledgment is a distinct status event. Implementation MUST record failure to observe an outcome rather than treating a positive precommit decision as proof of settlement. Das Expires 4 May 2027 [Page 10] Internet-Draft Protected Transaction Execution Finality October 2026 Requester PED-1 PED-2 / witness Finality Sink | PREPARE | | | |------------>| bind | | | |-------------->| reconstruct | | | |<---CHALLENGE-------| | | |----WITNESS-------->| | | | | verify | | | | consume | | | | initiate |<---------------- PTEF-STATUS / receipt ----------| | External confirmation later | Figure 4: Protocol sequence diagram 7. Protected State, Replay and Atomicity The FS maintains a monotonic protected state composed of sink generation, policy generation, revocation epoch, consumed nonce set or equivalent replay accumulator, authorization-use counters, resource quota, delegation generation and a transactional journal. Persisting only a signature cache does not satisfy this state requirement. For each commit, the FS MUST read an authoritative local snapshot, compare the candidate and authorized digest, validate every epoch, verify non-bearer binding and confirm remaining use and quota. The FS then atomically consumes the authorization and initiates the effect under an implementation-defined isolation transaction. For non-transactional downstream systems, the implementation MUST explain the uncertainty between local consumption and remote confirmation. A denial burns any already allocated one-shot capability; it does not necessarily burn an unrelated account or chain nonce. The architecture distinguishes a local execution nonce from an external consensus nonce. Implementations MUST NOT assume that consuming an off-chain nonce invalidates a previously signed on-chain authorization. Where the sink cannot atomically coordinate the protected state update with effect initiation, it SHALL use a durable prepare/commit journal, idempotency key, and compensating recovery that cannot grant duplicate authority. An UNKNOWN outcome is a controlled state, not a reason to retry with fresh capability. Das Expires 4 May 2027 [Page 11] Internet-Draft Protected Transaction Execution Finality October 2026 +------------------+ | Receive COMMIT | +---------+--------+ | v +------------------+ No | Trusted lineage? |----------> DENY + burn +---------+--------+ |Yes v +------------------+ No | Exact act equal? |----------> DENY + burn +---------+--------+ |Yes v +------------------+ No | Fresh + not used?|----------> DENY + burn +---------+--------+ |Yes v +------------------+ | Atomic consume & |-----> outcome pending | initiate effect | +------------------+ Figure 5: Atomic verify-and-effectuate flowchart 8. Delegated-Code Authority and EIP-7702 Profile For account-code delegation protocols, the delegated implementation address and its measured bytecode or code hash constitute effect- critical attributes. Authorization of a token transfer does not implicitly authorize changing the account implementation. Authorization of a delegate implementation does not automatically authorize every future behavior of that implementation. A delegation profile MUST bind source account, chain identifier, authorization nonce, exact delegated address, code hash or equivalent implementation commitment, authorization validity, allowed call graph or function selector classes, upgrade authority and explicit downstream spending policy. If code can change at the same address, the code-update mechanism and version epoch MUST be covered; an address-only allowlist is insufficient. The EIP-7702 account-delegation model is an informative example because an authorization tuple may install execution delegation while still having a valid cryptographic signature. A PTEF gateway before signing can refuse such a tuple when it falls outside operator Das Expires 4 May 2027 [Page 12] Internet-Draft Protected Transaction Execution Finality October 2026 policy, but it cannot retrospectively invalidate a correctly signed and broadcast tuple. Stronger downstream restrictions may require chain-executed smart-account controls. Implementers SHOULD test alternate authority entry points such as existing delegate contracts, signer APIs, direct private-key usage, upgrade proxy implementations, already-issued signatures, cross-chain representations, relayer permissions, and permission changes that persist after failed transactions. Signed delegation proposed | [hold ineffective] | Chain/account/nonce | Allowed delegate address? / \\ No Yes | | DENY Measured code hash? / \\ No Yes | | DENY Policy + epoch? / \\ No Yes | | DENY FS signing gate Figure 6: Delegation-specific admission flow 9. Execution-Time Reconstruction and Equality The FS MUST compare a canonical representation of the authorized intent with the actual pending operation reconstructed from the sink- facing command. A proxy-provided summary is not sufficient when the proxy is an attacker-controlled element. For a transfer, comparison can include asset identifier, source, destination, decimal units, fee policy, memo, chain and contract address. For delegated code, it includes delegate implementation identity, reachable privileges and change epoch. Das Expires 4 May 2027 [Page 13] Internet-Draft Protected Transaction Execution Finality October 2026 Equality must not rely on a human-readable label when a binding identifier exists. Deployments SHALL normalize Unicode, binary addresses, decimal values, chain identifiers and protocol-specific options before policy evaluation and digest construction; ambiguous or non-canonical representations MUST be denied. Aliases, contact names, DNS results and symbolic destinations must be resolved under approved policy. When transaction bytes will be recomputed after the decision, the final bytes MUST be compared again at the signing boundary. A digest computed before fee selection, address derivation, path translation or delegation serialization is not final. Hashing the requested action rather than the eventual wire operation leaves a time-of- check/time-of-use gap. The final equality predicate SHOULD cover all fields that can change the externally observable consequence. A profile MUST explicitly justify any excluded field; security-related unknown fields require either an authenticated critical-extension mechanism or failure closed. 10. Decision Codes, Failure Classes and Receipts PTEF defines a decision lattice of ALLOW, DENY, and INDETERMINATE. A state of INDETERMINATE SHALL NOT authorize execution. Reason families include malformed input, unknown lineage, unmediated path, context mismatch, stale policy, revoked authorization, invalid time window, disallowed scope, invalid delegation, intent mismatch, failed authority proof, missing witness, nonce reuse, budget exhaustion and effect reconstruction mismatch. Each decision receipt SHOULD include the unique candidate identifier, finality sink identifier, policy and state epochs, authorization digest, request digest, proof of consumption, decision code and a monotonic local sequence number. A system MAY withhold sensitive fields from an unauthenticated requester, but a protected audit facility SHOULD preserve enough detail for forensic reconciliation. A precommit receipt certifies only that the boundary admitted a specific effect. It is not a blockchain inclusion proof, bank settlement record, hardware sensor measurement or downstream delivery acknowledgment. Protocols SHALL attach separately authenticated outcome events and represent uncertainty explicitly. The recipient of DENY MUST NOT be able to turn the same denied handle into ALLOW through a different worker or sink. Denial-state replication and its consistency model are therefore part of the trusted authority design. Das Expires 4 May 2027 [Page 14] Internet-Draft Protected Transaction Execution Finality October 2026 11. Transport, Serialization and Cryptographic Profiles A deployment SHOULD use an established authenticated channel and an existing COSE or JOSE cryptographic profile. All signatures and MACs MUST be domain-separated for purpose, role, algorithm suite, protocol version and sink identity. Algorithm confusion and accepting unsigned profile fallbacks MUST be prohibited. The verifier MUST select a cryptographic algorithm from trusted local policy, not from untrusted candidate assertions alone. Canonicalization must be specified before signatures are generated. For CBOR payloads, deterministic encoding and explicit number handling SHOULD be applied. An application that bridges CBOR, JSON, signing firmware and device-level binary commands MUST show how field equality is preserved under every transformation. Key material belongs in protected custody or a genuinely isolated signing service; a proof of successful HMAC verification from a public demo key is only evidence of software data-flow behavior. Attestation and confidential computing MAY reinforce isolation, but implementation identity alone does not guarantee correct authorization policy. Trust anchors and certifier namespaces MUST have an explicit lifecycle: enrolment, rotation, revocation, expiry, regional scope and auditability. A stolen but still trusted signing credential must be countered by policy scope, independently checked state, signer threshold or other protection outside that credential. 12. Interoperability and Deployment Profiles The base PTEF message exchanges are agnostic to the application layer, but each deployment MUST define its effectuation semantics. The profile identifies the point where a command first becomes externally effective, the resource authority that controls that point, the protected fields of a candidate, and the observation mechanism for external outcome. A banking profile may bind account identifier, recipient, amount, currency, fees, approval role, settlement rail, cutoff time and transfer reference. An autonomous agent profile may bind URL, HTTP method, expected side effects, credential audience, data classification, intended recipient and a tool-call lineage. A radio profile may bind transmitter identifier, band, geography, power, channel, scheduled slot and hardware generation. Das Expires 4 May 2027 [Page 15] Internet-Draft Protected Transaction Execution Finality October 2026 Cross-platform interoperability depends on preserving semantics, not merely converting message syntax. A PTEF mediator SHOULD reject a bridge that drops a critical condition or weakens scoped authority during protocol translation. Portability does not imply that all platforms can provide the same trust guarantees. A legacy endpoint can be placed behind a protected adapter when all effective calls pass through the adapter. An endpoint that accepts unrestricted direct credentials or already signed commands is only partially mediated; this limitation MUST be visible in the conformance declaration. 13. Formal Safety Invariants and Progress Properties Invariant I-1 (non-effectiveness): a candidate in NES has no authority to cause an external effect. I-2 (exact binding): the approved canonical act equals the reconstructed pending act at the FS. I-3 (authority separation): control of a requester alone cannot grant the FS permission. I-4 (non-bearer): an intercepted handle cannot be exercised from another identity, sink or epoch. Invariant I-5 (single-use): at most one consequential commit corresponds to a single-use execution handle, including under contention and crash recovery. I-6 (revocation): no handle can be accepted after the sink observes the governing revocation generation. I-7 (monotonic state): replay, budget and permission generations cannot roll backward without explicit recovery semantics. I-8 (complete mediation): every effectuation path within a conformance claim crosses the enforcing FS. Invariant I-9 (receipt separation): an authorized initiation, external acceptance and final settlement are distinct outcomes. I-10 (fail-closed unknown): invalid lineage, missing state, inability to reconstruct, witness timeout, or an unrecognized critical field yields no effective action. Progress properties are conditional: for valid input, stable policy and an available FS, a request SHOULD reach either a definitive decision or an explicit pending state within a bounded service-level interval. No liveness policy may override a safety invariant to obtain availability. Das Expires 4 May 2027 [Page 16] Internet-Draft Protected Transaction Execution Finality October 2026 ALLOW(c, s, t) := VerifiedLineage(c) and ExclusiveSinkAuthority(s) and Equal(Canonical(Approved(c)), Canonical(Pending(s))) and StateGeneration(c) == ProtectedState(s).generation and RevocationEpoch(c) >= ProtectedState(s).revocation and Fresh(c, t) and not Consumed(c.handle_id, s) and WithinQuota(c, ProtectedState(s)) and AllEffectivePathsMediated(c, s) commit(c,s) is one linearizable state transition: (Unspent, quota=q) -> (Spent, quota=q-cost(c), effect-started) No transition from DENY or INDETERMINATE to EFFECT without fresh approval. Figure 7: Formalized core predicate (illustrative) 14. Security and Privacy Considerations The most severe deployment failure is false completeness: a gate protects a subset of paths while an unmediated key, already signed delegation or privileged hardware channel remains available. Conformance tests MUST attempt those paths. A protected decision may still authorize a socially engineered approval or a malicious administrator; PTEF addresses verifiable execution scope rather than correctness of human intent. Authorization envelopes reveal destinations, amounts, resource identifiers and account relationships. Deployments SHOULD minimize personal data, use privacy-preserving audit commitments where justified, set retention bounds, and segregate policy inputs from untrusted observability or machine-learning systems. Cryptographic digests are not anonymization when input spaces are guessable. Denial burning can create denial-of-service pressure if an attacker can allocate nonce identities; implementations MUST authenticate allocation and rate-limit attempts before consuming scarce quotas. Backpressure, bounded queues and graceful overload denial SHOULD be tested under realistic maximum size and concurrency. All reference implementations shipped with this draft use PUBLIC, hard-coded demonstration keys. They do not operate an HSM, prove remote attestation, implement COSE, sign Ethereum transactions, verify on-chain confirmation or guarantee atomicity with a real distributed ledger. They MUST NOT be used to custody assets or secure production operations. Das Expires 4 May 2027 [Page 17] Internet-Draft Protected Transaction Execution Finality October 2026 15. IANA, IETF IPR and Implementation Maturity This document makes no IANA requests. Future revisions may request registration of a media type, structured-field name, COSE parameter or well-known URI only after a concrete wire format and interoperability evidence are settled. The author identifies potentially related patent filings, including PCT/IB2026/055615 (filed 4 June 2026) and separate earlier filings. These identifiers are supplied as the author's disclosure context and are not legal conclusions about claim coverage or priority for any particular section. IETF participants must follow RFC 8179 and applicable rules for timely, complete IPR disclosures using the IETF process; mentioning an application in this draft is not a substitute for a formal disclosure. The author has expressed an intention to support standards-compatible licensing arrangements, including FRAND discussions and possible royalty-free treatment in identified non-commercial or public- interest contexts. Such statements do not create a license and are subject to written legal terms and any subsequently filed IETF IPR statements. The accompanying code has been executed on a fixed adversarial vector suite in three programming languages. The evidence is limited to deterministic local behavior and does not constitute a production security certification, external independent audit, protocol interoperability event or proof of mitigation of any publicly reported incident. 16. M-01. Canonical Account and Tenant Binding M-01 objective and boundary. This profile addresses tenant identifier, originating account and local account-generation counter. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Attack and counterexample. Consider a sequence in which a signed operation prepared under one tenant is reused under another tenant with a shared signing service. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of Das Expires 4 May 2027 [Page 18] Internet-Draft Protected Transaction Execution Finality October 2026 those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode tenant identifier, originating account and local account- generation counter, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD check the protected tenant namespace and account generation before any signer API is invoked. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a cross-tenant replay must be DENY_CONTEXT even with a cryptographically valid request. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 19] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD rotate the account- specific generation after migration and prevent old tokens from crossing. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant tenant identifier, originating account and local account-generation counter, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: tenant identifier, originating account and local account-generation counter. * Explicit hostile condition: a signed operation prepared under one tenant is reused under another tenant with a shared signing service. * Negative conformance criterion: a cross-tenant replay must be DENY_CONTEXT even with a cryptographically valid request. * Recovery obligation: rotate the account-specific generation after migration and prevent old tokens from crossing. Das Expires 4 May 2027 [Page 20] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-01: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Canonical Account and Te| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 8: M-01 decision flow 17. M-02. Destination and Payee Substitution M-02 objective and boundary. This profile addresses resolved recipient identifier, destination network and ownership attestation. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 21] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a display label remains identical but the binary payee address changes during transaction construction. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode resolved recipient identifier, destination network and ownership attestation, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD reconstruct the binary destination from the actual sink-bound payload and compare it with the approved digest. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that the same name paired with a new address is denied and logged as a distinct attempted effect. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 22] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD re-run approval only after the new destination is explicitly adopted. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant resolved recipient identifier, destination network and ownership attestation, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: resolved recipient identifier, destination network and ownership attestation. * Explicit hostile condition: a display label remains identical but the binary payee address changes during transaction construction. * Negative conformance criterion: the same name paired with a new address is denied and logged as a distinct attempted effect. * Recovery obligation: re-run approval only after the new destination is explicitly adopted. Das Expires 4 May 2027 [Page 23] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-02: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Destination and Payee Su| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 9: M-02 decision flow 18. M-03. Delegation Code Hash Rotation M-03 objective and boundary. This profile addresses delegate address, measured implementation hash and upgrade epoch. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 24] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a proxy implementation is upgraded while a formerly approved delegation address is retained. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode delegate address, measured implementation hash and upgrade epoch, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind the code hash and update authority to the handle and enforce a protected code-generation check. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a matching delegate address with a changed implementation hash is rejected. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 25] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD suspend approval until the new implementation is measured and accepted. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant delegate address, measured implementation hash and upgrade epoch, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: delegate address, measured implementation hash and upgrade epoch. * Explicit hostile condition: a proxy implementation is upgraded while a formerly approved delegation address is retained. * Negative conformance criterion: a matching delegate address with a changed implementation hash is rejected. * Recovery obligation: suspend approval until the new implementation is measured and accepted. Das Expires 4 May 2027 [Page 26] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-03: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Delegation Code Hash Rot| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 10: M-03 decision flow 19. M-04. Chain Identifier and Consensus Domain M-04 objective and boundary. This profile addresses chain identifier, genesis commitment or fork-specific network identity. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 27] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a broadly scoped signature is replayed on an unintended network or fork. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode chain identifier, genesis commitment or fork-specific network identity, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD treat wildcard chain authorization as prohibited unless policy explicitly describes every allowed domain. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that cross-chain reuse is denied even if recipient, payload and nonce text appear identical. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 28] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD require a fresh chain- bound approval and re-check external account nonce. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant chain identifier, genesis commitment or fork-specific network identity, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: chain identifier, genesis commitment or fork-specific network identity. * Explicit hostile condition: a broadly scoped signature is replayed on an unintended network or fork. * Negative conformance criterion: cross-chain reuse is denied even if recipient, payload and nonce text appear identical. * Recovery obligation: require a fresh chain-bound approval and re- check external account nonce. Das Expires 4 May 2027 [Page 29] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-04: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Chain Identifier and Con| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 11: M-04 decision flow 20. M-05. Signer-Service Impersonation M-05 objective and boundary. This profile addresses signer service identity, protected key alias and generation. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 30] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an attacker redirects a trusted request to an unprotected signer with the same public interface. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode signer service identity, protected key alias and generation, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require attestable signer identity and local exclusive key custody rather than relying on endpoint DNS names. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that attempted invocation through any non-designated signing service cannot create a usable signature. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 31] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD rotate key aliases and invalidate stale signer discovery information. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant signer service identity, protected key alias and generation, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: signer service identity, protected key alias and generation. * Explicit hostile condition: an attacker redirects a trusted request to an unprotected signer with the same public interface. * Negative conformance criterion: attempted invocation through any non-designated signing service cannot create a usable signature. * Recovery obligation: rotate key aliases and invalidate stale signer discovery information. Das Expires 4 May 2027 [Page 32] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-05: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Signer-Service Impersona| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 12: M-05 decision flow 21. M-06. Pre-Signature Delegation Screening M-06 objective and boundary. This profile addresses account delegation tuple and the exact eventual transaction envelope. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 33] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a valid authorization tuple is used to install unapproved delegated behavior. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode account delegation tuple and the exact eventual transaction envelope, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD parse authorization tuples before signatures, inspect exact delegate and code constraints, and refuse signer output. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that one matching external nonce does not turn a disallowed delegate into an authorized act. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 34] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD record the denied tuple fingerprint without submitting a partial transaction. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant account delegation tuple and the exact eventual transaction envelope, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: account delegation tuple and the exact eventual transaction envelope. * Explicit hostile condition: a valid authorization tuple is used to install unapproved delegated behavior. * Negative conformance criterion: one matching external nonce does not turn a disallowed delegate into an authorized act. * Recovery obligation: record the denied tuple fingerprint without submitting a partial transaction. Das Expires 4 May 2027 [Page 35] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-06: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Pre-Signature Delegation| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 13: M-06 decision flow 22. M-07. Account Nonce Versus Local One-Shot Capability M-07 objective and boundary. This profile addresses independent local handle nonce and external account nonce. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 36] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an external nonce is valid even though the business approval is expired or consumed. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode independent local handle nonce and external account nonce, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD never equate blockchain consensus nonce validity with protected local authorization validity. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that changing only the external nonce cannot restore an already burned local handle. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 37] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD disambiguate the two nonce namespaces in every audit record. An operator must preserve the one- shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant independent local handle nonce and external account nonce, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: independent local handle nonce and external account nonce. * Explicit hostile condition: an external nonce is valid even though the business approval is expired or consumed. * Negative conformance criterion: changing only the external nonce cannot restore an already burned local handle. * Recovery obligation: disambiguate the two nonce namespaces in every audit record. Das Expires 4 May 2027 [Page 38] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-07: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Account Nonce Versus Loc| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 14: M-07 decision flow 23. M-08. Receipt-Before-Authority Release M-08 objective and boundary. This profile addresses authenticated precommit witness bound to candidate and sink generation. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 39] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which the signer acts before protected validation has been committed to a durable audit ledger. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode authenticated precommit witness bound to candidate and sink generation, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require authenticated witness completion before releasing the sole effective signer capability. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that an absent or incorrect precommit witness causes denial with no signing side effect. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 40] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD reconcile missing receipts using protected transaction IDs, not a new approval. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant authenticated precommit witness bound to candidate and sink generation, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: authenticated precommit witness bound to candidate and sink generation. * Explicit hostile condition: the signer acts before protected validation has been committed to a durable audit ledger. * Negative conformance criterion: an absent or incorrect precommit witness causes denial with no signing side effect. * Recovery obligation: reconcile missing receipts using protected transaction IDs, not a new approval. Das Expires 4 May 2027 [Page 41] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-08: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Receipt-Before-Authority| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 15: M-08 decision flow 24. M-09. Receipt Versus Final Settlement M-09 objective and boundary. This profile addresses precommit decision, downstream acceptance and final settled outcome. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 42] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an initiation receipt is incorrectly interpreted as irreversible completion. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode precommit decision, downstream acceptance and final settled outcome, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD create separately typed receipt classes, each authenticated and linked to the same candidate ID. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that an approved operation can remain outcome UNKNOWN without fabricating success. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 43] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD poll the authoritative downstream ledger and reconcile idempotently. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant precommit decision, downstream acceptance and final settled outcome, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: precommit decision, downstream acceptance and final settled outcome. * Explicit hostile condition: an initiation receipt is incorrectly interpreted as irreversible completion. * Negative conformance criterion: an approved operation can remain outcome UNKNOWN without fabricating success. * Recovery obligation: poll the authoritative downstream ledger and reconcile idempotently. Das Expires 4 May 2027 [Page 44] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-09: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Receipt Versus Final Set| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 16: M-09 decision flow 25. M-10. Policy Revocation Under In-Flight Load M-10 objective and boundary. This profile addresses revocation epoch and application-specific revocation evidence. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 45] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a handle generated before an emergency revocation races with a delayed commit. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode revocation epoch and application-specific revocation evidence, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD compare epochs against sink-local authoritative state under the same lock as consumption. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a stale handle is denied regardless of a valid historical signature. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 46] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD apply a protected revocation barrier before resuming new work. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant revocation epoch and application-specific revocation evidence, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: revocation epoch and application-specific revocation evidence. * Explicit hostile condition: a handle generated before an emergency revocation races with a delayed commit. * Negative conformance criterion: a stale handle is denied regardless of a valid historical signature. * Recovery obligation: apply a protected revocation barrier before resuming new work. Das Expires 4 May 2027 [Page 47] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-10: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Policy Revocation Under | +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 17: M-10 decision flow 26. M-11. Concurrent Quota Reservation M-11 objective and boundary. This profile addresses remaining account quota and reservation identity. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 48] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which two workers independently see the same remaining balance and both spend it. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode remaining account quota and reservation identity, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD apply a linearizable local budget decrement together with handle consumption. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that only one contending operation may consume the final unit of quota. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 49] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD use durable retry reconciliation without creating new authority. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant remaining account quota and reservation identity, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: remaining account quota and reservation identity. * Explicit hostile condition: two workers independently see the same remaining balance and both spend it. * Negative conformance criterion: only one contending operation may consume the final unit of quota. * Recovery obligation: use durable retry reconciliation without creating new authority. Das Expires 4 May 2027 [Page 50] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-11: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Concurrent Quota Reserva| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 18: M-11 decision flow 27. M-12. Multi-Currency and Decimal Normalization M-12 objective and boundary. This profile addresses asset identifier, units and canonical decimal precision. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 51] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which different unit scales turn an approved human-readable amount into a larger binary quantity. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode asset identifier, units and canonical decimal precision, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD normalize to an exact integer base unit under asset-specific precision before comparing effects. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that an input with noncanonical decimals or a changed unit exponent fails authorization. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 52] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD require a fresh approval after any rounding or fee conversion. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant asset identifier, units and canonical decimal precision, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: asset identifier, units and canonical decimal precision. * Explicit hostile condition: different unit scales turn an approved human-readable amount into a larger binary quantity. * Negative conformance criterion: an input with noncanonical decimals or a changed unit exponent fails authorization. * Recovery obligation: require a fresh approval after any rounding or fee conversion. Das Expires 4 May 2027 [Page 53] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-12: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Multi-Currency and Decim| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 19: M-12 decision flow 28. M-13. Fee and Gas-Budget Bounding M-13 objective and boundary. This profile addresses maximum fee, fee payer, resource limit and external fee schedule. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 54] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which the transaction builder inflates fee fields after approval. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode maximum fee, fee payer, resource limit and external fee schedule, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD include maximum fee commitments and permitted adjustment policies in the authorized operation. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a fee outside approved bounds cannot be signed even if principal amount is unchanged. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 55] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD allow bounded repricing only through a verifiable delegated fee policy. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant maximum fee, fee payer, resource limit and external fee schedule, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: maximum fee, fee payer, resource limit and external fee schedule. * Explicit hostile condition: the transaction builder inflates fee fields after approval. * Negative conformance criterion: a fee outside approved bounds cannot be signed even if principal amount is unchanged. * Recovery obligation: allow bounded repricing only through a verifiable delegated fee policy. Das Expires 4 May 2027 [Page 56] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-13: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Fee and Gas-Budget Bound| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 20: M-13 decision flow 29. M-14. Cross-Service Credential Substitution M-14 objective and boundary. This profile addresses credential audience, origin role and protected signer identity. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 57] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a workflow exchanges user approval for a broader backend credential. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode credential audience, origin role and protected signer identity, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD constrain credential substitution to the exact candidate effect and final recipient. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a credential with broad scope cannot authorize an out-of-scope command. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 58] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD revoke the substituted credential and invalidate any queued candidate. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant credential audience, origin role and protected signer identity, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: credential audience, origin role and protected signer identity. * Explicit hostile condition: a workflow exchanges user approval for a broader backend credential. * Negative conformance criterion: a credential with broad scope cannot authorize an out-of-scope command. * Recovery obligation: revoke the substituted credential and invalidate any queued candidate. Das Expires 4 May 2027 [Page 59] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-14: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Cross-Service Credential| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 21: M-14 decision flow 30. M-15. Non-Bearer Execution Handle M-15 objective and boundary. This profile addresses handle identity, sink-specific binding and local protected storage handle. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 60] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a stolen handle string is replayed against another compatible API endpoint. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode handle identity, sink-specific binding and local protected storage handle, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require a private-channel proof plus sink-local matching state and identity. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that mere byte possession without protected context is insufficient to execute. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 61] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD retire captured handle and rotate sink capability binding. An operator must preserve the one- shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant handle identity, sink- specific binding and local protected storage handle, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: handle identity, sink-specific binding and local protected storage handle. * Explicit hostile condition: a stolen handle string is replayed against another compatible API endpoint. * Negative conformance criterion: mere byte possession without protected context is insufficient to execute. * Recovery obligation: retire captured handle and rotate sink capability binding. Das Expires 4 May 2027 [Page 62] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-15: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Non-Bearer Execution Han| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 22: M-15 decision flow 31. M-16. Untrusted Planner and Tool Injection M-16 objective and boundary. This profile addresses tainted instruction origin and provenance of proposed act fields. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 63] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a retrieved page or tool output changes transaction amount or destination. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode tainted instruction origin and provenance of proposed act fields, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD separate untrusted content from approved authority and reconstruct exact action at the FS. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that unauthorized fields inferred from tool text fail intent equality. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 64] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD retain taint lineage and request explicit authorizer confirmation. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant tainted instruction origin and provenance of proposed act fields, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: tainted instruction origin and provenance of proposed act fields. * Explicit hostile condition: a retrieved page or tool output changes transaction amount or destination. * Negative conformance criterion: unauthorized fields inferred from tool text fail intent equality. * Recovery obligation: retain taint lineage and request explicit authorizer confirmation. Das Expires 4 May 2027 [Page 65] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-16: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Untrusted Planner and To| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 23: M-16 decision flow 32. M-17. Code-Execution Sandbox Egress M-17 objective and boundary. This profile addresses process identity, destination API and sandbox egress operation. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 66] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an isolated worker invokes a privileged helper to escape ordinary egress rules. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode process identity, destination API and sandbox egress operation, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD mediate every privileged connector, socket, file-export and signer path at the final boundary. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a valid internal workflow token never authorizes unapproved external egress. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 67] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD disable the privileged helper or enforce mandatory mediation at its entry. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant process identity, destination API and sandbox egress operation, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: process identity, destination API and sandbox egress operation. * Explicit hostile condition: an isolated worker invokes a privileged helper to escape ordinary egress rules. * Negative conformance criterion: a valid internal workflow token never authorizes unapproved external egress. * Recovery obligation: disable the privileged helper or enforce mandatory mediation at its entry. Das Expires 4 May 2027 [Page 68] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-17: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Code-Execution Sandbox E| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 24: M-17 decision flow 33. M-18. Cloud Resource Mutation M-18 objective and boundary. This profile addresses resource ID, account, region, role and expected state generation. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 69] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an authorized deployment command is redirected to a different cloud account. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode resource ID, account, region, role and expected state generation, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind provider-neutral resource identity and current generation at the protected mutation adapter. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a changed account, role or target produces exact-effect denial. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 70] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD require re-observation after infrastructure drift. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant resource ID, account, region, role and expected state generation, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: resource ID, account, region, role and expected state generation. * Explicit hostile condition: an authorized deployment command is redirected to a different cloud account. * Negative conformance criterion: a changed account, role or target produces exact-effect denial. * Recovery obligation: require re-observation after infrastructure drift. Das Expires 4 May 2027 [Page 71] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-18: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Cloud Resource Mutation | +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 25: M-18 decision flow 34. M-19. Device Actuation and Reset Epoch M-19 objective and boundary. This profile addresses device identity, firmware measurement, actuation bounds and reset counter. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 72] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a stale motor or actuator command is replayed after device restart. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode device identity, firmware measurement, actuation bounds and reset counter, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD check device-local reset generation and firmware identity immediately before actuation. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that post-reset replay is denied even when the command bytes match a prior approval. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 73] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD re-enroll device generation and resynchronize monotonic counters. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant device identity, firmware measurement, actuation bounds and reset counter, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: device identity, firmware measurement, actuation bounds and reset counter. * Explicit hostile condition: a stale motor or actuator command is replayed after device restart. * Negative conformance criterion: post-reset replay is denied even when the command bytes match a prior approval. * Recovery obligation: re-enroll device generation and resynchronize monotonic counters. Das Expires 4 May 2027 [Page 74] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-19: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Device Actuation and Res| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 26: M-19 decision flow 35. M-20. Radio Transmission Finality M-20 objective and boundary. This profile addresses radio endpoint, licensed band, location, power and time slot. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 75] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an approved configuration is reused for an out-of-bounds transmission. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode radio endpoint, licensed band, location, power and time slot, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind the final RF enable signal to channel and power policy evaluated locally. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a command prepared for one band cannot effectuate on another. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 76] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD on loss of current policy force transmitter disable and require reauthorization. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant radio endpoint, licensed band, location, power and time slot, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: radio endpoint, licensed band, location, power and time slot. * Explicit hostile condition: an approved configuration is reused for an out-of-bounds transmission. * Negative conformance criterion: a command prepared for one band cannot effectuate on another. * Recovery obligation: on loss of current policy force transmitter disable and require reauthorization. Das Expires 4 May 2027 [Page 77] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-20: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Radio Transmission Final| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 27: M-20 decision flow 36. M-21. Payment Initiation and Clearing M-21 objective and boundary. This profile addresses payer, payee, currency, amount and payment-rail reference. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 78] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which submission success is mistaken for accepted clearing or completed settlement. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode payer, payee, currency, amount and payment-rail reference, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD use a separate finality gate for initiation and authenticated rail-specific outcome tracking. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that initiated and settled states cannot be represented by the same receipt type. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 79] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD reconcile pending transfers through rail idempotency identifiers. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant payer, payee, currency, amount and payment-rail reference, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: payer, payee, currency, amount and payment- rail reference. * Explicit hostile condition: submission success is mistaken for accepted clearing or completed settlement. * Negative conformance criterion: initiated and settled states cannot be represented by the same receipt type. * Recovery obligation: reconcile pending transfers through rail idempotency identifiers. Das Expires 4 May 2027 [Page 80] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-21: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Payment Initiation and C| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 28: M-21 decision flow 37. M-22. Multi-Channel Communications Quota M-22 objective and boundary. This profile addresses virtual identity, communication purpose, channel and usage allowance. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 81] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an authorization for one channel is laundered through another delivery path. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode virtual identity, communication purpose, channel and usage allowance, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind per-channel delivery permissions to a shared protected quota counter. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that parallel attempts cannot exceed cross-channel purpose or count limits. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 82] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD deny further delivery after exhaustion while preserving audit continuity. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant virtual identity, communication purpose, channel and usage allowance, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: virtual identity, communication purpose, channel and usage allowance. * Explicit hostile condition: an authorization for one channel is laundered through another delivery path. * Negative conformance criterion: parallel attempts cannot exceed cross-channel purpose or count limits. * Recovery obligation: deny further delivery after exhaustion while preserving audit continuity. Das Expires 4 May 2027 [Page 83] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-22: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Multi-Channel Communicat| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 29: M-22 decision flow 38. M-23. Data Export and Privacy Boundary M-23 objective and boundary. This profile addresses data classification, intended recipient and exact export bytes. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 84] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a valid API credential is used to export a larger or different dataset. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode data classification, intended recipient and exact export bytes, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind export digest, recipient and retention purpose at the last protected egress route. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that replacing a file after upstream approval is detected at egress. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 85] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD quarantine the changed export and start a new approval. An operator must preserve the one- shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant data classification, intended recipient and exact export bytes, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: data classification, intended recipient and exact export bytes. * Explicit hostile condition: a valid API credential is used to export a larger or different dataset. * Negative conformance criterion: replacing a file after upstream approval is detected at egress. * Recovery obligation: quarantine the changed export and start a new approval. Das Expires 4 May 2027 [Page 86] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-23: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Data Export and Privacy | +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 30: M-23 decision flow 39. M-24. Cryptographic Key-Usage Separation M-24 objective and boundary. This profile addresses protected key object, allowed operation type and algorithm suite. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 87] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a key intended for transfer signing is used to authorize account delegation. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode protected key object, allowed operation type and algorithm suite, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD separate signer policy by message class and require domain-tagged signing requests. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that using one valid key across two unauthorized purposes fails policy checks. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 88] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD rotate or split key usage and invalidate ambiguous historical grants. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant protected key object, allowed operation type and algorithm suite, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: protected key object, allowed operation type and algorithm suite. * Explicit hostile condition: a key intended for transfer signing is used to authorize account delegation. * Negative conformance criterion: using one valid key across two unauthorized purposes fails policy checks. * Recovery obligation: rotate or split key usage and invalidate ambiguous historical grants. Das Expires 4 May 2027 [Page 89] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-24: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Cryptographic Key-Usage | +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 31: M-24 decision flow 40. M-25. Hardware Security Module Integration M-25 objective and boundary. This profile addresses hardware key alias, command template and exclusive invocation path. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 90] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a normal signing API exposes unrestricted raw-message signing. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode hardware key alias, command template and exclusive invocation path, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD enforce typed signing templates within a trusted key boundary. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that raw-digest signing bypass attempts must be blocked or excluded from conformance. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 91] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD disable raw-sign operations and revoke previous unrestricted grants. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant hardware key alias, command template and exclusive invocation path, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: hardware key alias, command template and exclusive invocation path. * Explicit hostile condition: a normal signing API exposes unrestricted raw-message signing. * Negative conformance criterion: raw-digest signing bypass attempts must be blocked or excluded from conformance. * Recovery obligation: disable raw-sign operations and revoke previous unrestricted grants. Das Expires 4 May 2027 [Page 92] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-25: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Hardware Security Module| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 32: M-25 decision flow 41. M-26. Cross-Region Policy Continuity M-26 objective and boundary. This profile addresses policy epoch, region, authority lineage and policy synchronization proof. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 93] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a regional failover restores an older permissive snapshot. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode policy epoch, region, authority lineage and policy synchronization proof, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require monotonic epoch advancement on failover and authenticated policy lineage. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that stale-region approval cannot be resurrected by availability routing. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 94] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD quarantine region until it receives a sufficiently current state snapshot. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant policy epoch, region, authority lineage and policy synchronization proof, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: policy epoch, region, authority lineage and policy synchronization proof. * Explicit hostile condition: a regional failover restores an older permissive snapshot. * Negative conformance criterion: stale-region approval cannot be resurrected by availability routing. * Recovery obligation: quarantine region until it receives a sufficiently current state snapshot. Das Expires 4 May 2027 [Page 95] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-26: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Cross-Region Policy Cont| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 33: M-26 decision flow 42. M-27. Offline Signing and Air-Gapped Approval M-27 objective and boundary. This profile addresses detached request artifact, approval conditions and signing-session identity. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 96] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an offline signer signs bytes that changed after display. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode detached request artifact, approval conditions and signing- session identity, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind digest of final encoded bytes and an unambiguous offline approval transcript. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a changed QR or removable- media payload triggers explicit denial. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 97] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD reconstruct a new approval with independent visual verification. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant detached request artifact, approval conditions and signing-session identity, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: detached request artifact, approval conditions and signing-session identity. * Explicit hostile condition: an offline signer signs bytes that changed after display. * Negative conformance criterion: a changed QR or removable-media payload triggers explicit denial. * Recovery obligation: reconstruct a new approval with independent visual verification. Das Expires 4 May 2027 [Page 98] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-27: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Offline Signing and Air-| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 34: M-27 decision flow 43. M-28. Distributed Ledger Non-Inclusion M-28 objective and boundary. This profile addresses external submission ID, transaction hash and chain finality depth. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 99] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a precommit receipt is logged despite network failure or chain reorganization. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode external submission ID, transaction hash and chain finality depth, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD model broadcast, acceptance, inclusion, confirmation and finality as distinct evidence levels. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that local ALLOW never appears as ledger SETTLED without independent proof. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 100] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD resubmit only using safe idempotent procedures and existing consumed authority. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant external submission ID, transaction hash and chain finality depth, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: external submission ID, transaction hash and chain finality depth. * Explicit hostile condition: a precommit receipt is logged despite network failure or chain reorganization. * Negative conformance criterion: local ALLOW never appears as ledger SETTLED without independent proof. * Recovery obligation: resubmit only using safe idempotent procedures and existing consumed authority. Das Expires 4 May 2027 [Page 101] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-28: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Distributed Ledger Non-I| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 35: M-28 decision flow 44. M-29. External State-Root Drift M-29 objective and boundary. This profile addresses authorized state commitment and current external observation generation. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 102] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a balance, allowance or delegate implementation changes between simulation and commit. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode authorized state commitment and current external observation generation, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD reconstruct all security-critical facts under a bounded consistency window. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that stale simulation hash cannot establish current state equality. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 103] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD obtain fresh external proof and rerun policy before effectuation. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant authorized state commitment and current external observation generation, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: authorized state commitment and current external observation generation. * Explicit hostile condition: a balance, allowance or delegate implementation changes between simulation and commit. * Negative conformance criterion: stale simulation hash cannot establish current state equality. * Recovery obligation: obtain fresh external proof and rerun policy before effectuation. Das Expires 4 May 2027 [Page 104] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-29: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | External State-Root Drif| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 36: M-29 decision flow 45. M-30. Fallback Path and Emergency Operator M-30 objective and boundary. This profile addresses break-glass route identity, emergency rationale and scoped authority. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 105] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an emergency path bypasses mandatory runtime authorization under routine conditions. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode break-glass route identity, emergency rationale and scoped authority, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD treat emergency access as its own protected policy profile with stronger independent approvals. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that no unlogged arbitrary signing operation can be attributed to normal conformance. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 106] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD require explicit emergency epoch, alerting, expiry and post-incident review. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant break-glass route identity, emergency rationale and scoped authority, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: break-glass route identity, emergency rationale and scoped authority. * Explicit hostile condition: an emergency path bypasses mandatory runtime authorization under routine conditions. * Negative conformance criterion: no unlogged arbitrary signing operation can be attributed to normal conformance. * Recovery obligation: require explicit emergency epoch, alerting, expiry and post-incident review. Das Expires 4 May 2027 [Page 107] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-30: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Fallback Path and Emerge| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 37: M-30 decision flow 46. M-31. Service-Mesh and Sidecar Bypass M-31 objective and boundary. This profile addresses workload identity, network boundary and privileged node control. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 108] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an attacker bypasses a proxy with local sockets or direct service addresses. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode workload identity, network boundary and privileged node control, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD combine service proxy checks with sink-local command authentication and mandatory access controls. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a direct route lacking finality evidence cannot trigger the sink. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 109] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD close the direct path or document an unsupported deployment mode. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant workload identity, network boundary and privileged node control, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: workload identity, network boundary and privileged node control. * Explicit hostile condition: an attacker bypasses a proxy with local sockets or direct service addresses. * Negative conformance criterion: a direct route lacking finality evidence cannot trigger the sink. * Recovery obligation: close the direct path or document an unsupported deployment mode. Das Expires 4 May 2027 [Page 110] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-31: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Service-Mesh and Sidecar| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 38: M-31 decision flow 47. M-32. Versioned Policy Rollback Protection M-32 objective and boundary. This profile addresses policy version, approved migration path and protected rollback counter. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 111] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an old permissive policy is restored from backup to authorize previously denied work. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode policy version, approved migration path and protected rollback counter, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require monotonic policy generation and a separately authorized rollback ceremony. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a valid but obsolete approval does not survive policy rollback. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 112] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD maintain an append-only protected rollback log. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant policy version, approved migration path and protected rollback counter, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: policy version, approved migration path and protected rollback counter. * Explicit hostile condition: an old permissive policy is restored from backup to authorize previously denied work. * Negative conformance criterion: a valid but obsolete approval does not survive policy rollback. * Recovery obligation: maintain an append-only protected rollback log. Das Expires 4 May 2027 [Page 113] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-32: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Versioned Policy Rollbac| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 39: M-32 decision flow 48. M-33. Unknown Critical Extension M-33 objective and boundary. This profile addresses critical extension names and profile registry version. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 114] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a bridge silently drops a security-critical condition it cannot parse. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode critical extension names and profile registry version, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD fail closed for unsupported critical fields and preserve extension coverage end-to- end. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that dropping a critical delegate constraint causes denial. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 115] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD negotiate supported profile version before issuing a new approval. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant critical extension names and profile registry version, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: critical extension names and profile registry version. * Explicit hostile condition: a bridge silently drops a security- critical condition it cannot parse. * Negative conformance criterion: dropping a critical delegate constraint causes denial. * Recovery obligation: negotiate supported profile version before issuing a new approval. Das Expires 4 May 2027 [Page 116] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-33: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Unknown Critical Extensi| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 40: M-33 decision flow 49. M-34. Canonical Unicode and Binary Addresses M-34 objective and boundary. This profile addresses canonical string normalization and binary address bytes. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 117] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which two visually identical identifiers encode different recipients. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode canonical string normalization and binary address bytes, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD reject ambiguous encodings and bind canonical binary resource identifiers. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that homoglyph or alternate hexadecimal representation cannot change the final receiver. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 118] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD require stable profile- specific canonicalization before reauthorization. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant canonical string normalization and binary address bytes, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: canonical string normalization and binary address bytes. * Explicit hostile condition: two visually identical identifiers encode different recipients. * Negative conformance criterion: homoglyph or alternate hexadecimal representation cannot change the final receiver. * Recovery obligation: require stable profile-specific canonicalization before reauthorization. Das Expires 4 May 2027 [Page 119] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-34: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Canonical Unicode and Bi| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 41: M-34 decision flow 50. M-35. Delegation Persistence Across Failures M-35 objective and boundary. This profile addresses delegation state after reverted outer transaction and external status. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 120] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an implementation assumes a transaction revert undoes every delegation side effect. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode delegation state after reverted outer transaction and external status, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD independently verify delegation state and do not infer restoration from overall failure. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that post-failure code changes are represented and checked before new operations. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 121] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD revoke, clear or replace delegation through separately authorized recovery. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant delegation state after reverted outer transaction and external status, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: delegation state after reverted outer transaction and external status. * Explicit hostile condition: an implementation assumes a transaction revert undoes every delegation side effect. * Negative conformance criterion: post-failure code changes are represented and checked before new operations. * Recovery obligation: revoke, clear or replace delegation through separately authorized recovery. Das Expires 4 May 2027 [Page 122] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-35: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Delegation Persistence A| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 42: M-35 decision flow 51. M-36. Signer Threshold and Dual Control M-36 objective and boundary. This profile addresses approval quorum, signer identities and attested collective decision. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 123] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which one compromised signing service can manufacture a single administrative approval. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode approval quorum, signer identities and attested collective decision, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require policy-defined independent roles with threshold verification at finality boundary. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that one forged signer share cannot satisfy a two-party quorum. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 124] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD rekey threshold membership and replay historical transcript checks. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant approval quorum, signer identities and attested collective decision, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: approval quorum, signer identities and attested collective decision. * Explicit hostile condition: one compromised signing service can manufacture a single administrative approval. * Negative conformance criterion: one forged signer share cannot satisfy a two-party quorum. * Recovery obligation: rekey threshold membership and replay historical transcript checks. Das Expires 4 May 2027 [Page 125] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-36: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Signer Threshold and Dua| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 43: M-36 decision flow 52. M-37. Remote Attestation and Runtime Measurement M-37 objective and boundary. This profile addresses attestation nonce, measurement, signer identity and binding to CA. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 126] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a genuine enclave measurement is replayed for a different candidate action. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode attestation nonce, measurement, signer identity and binding to CA, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind freshness, workload claims and sink identity to the same authorization transcript. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that valid attestation without the right candidate digest grants no effect. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 127] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD re-attest after code update, migration or compromised endorsement. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant attestation nonce, measurement, signer identity and binding to CA, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: attestation nonce, measurement, signer identity and binding to CA. * Explicit hostile condition: a genuine enclave measurement is replayed for a different candidate action. * Negative conformance criterion: valid attestation without the right candidate digest grants no effect. * Recovery obligation: re-attest after code update, migration or compromised endorsement. Das Expires 4 May 2027 [Page 128] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-37: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Remote Attestation and R| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 44: M-37 decision flow 53. M-38. Source Authority and Instruction Lineage M-38 objective and boundary. This profile addresses originator evidence and immutable ancestry of approval-relevant fields. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 129] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which untrusted generated text is accidentally elevated into policy authority. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode originator evidence and immutable ancestry of approval- relevant fields, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require an authoritative source graph with UNKNOWN default for unresolved nodes. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a missing provenance edge is a denial rather than permission. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 130] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD collect new verified approval evidence without mutating old lineage. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant originator evidence and immutable ancestry of approval-relevant fields, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: originator evidence and immutable ancestry of approval-relevant fields. * Explicit hostile condition: untrusted generated text is accidentally elevated into policy authority. * Negative conformance criterion: a missing provenance edge is a denial rather than permission. * Recovery obligation: collect new verified approval evidence without mutating old lineage. Das Expires 4 May 2027 [Page 131] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-38: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Source Authority and Ins| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 45: M-38 decision flow 54. M-39. Protected Audit Chain and Redaction M-39 objective and boundary. This profile addresses decision sequence, hash-chained records and scoped disclosure keys. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 132] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a compromised application edits audit events to hide an unauthorized attempt. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode decision sequence, hash-chained records and scoped disclosure keys, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD append protected decision records and tie them to consumed state generations. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a missing journal sequence or altered record is independently detectable. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 133] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD reconstruct from protected checkpoint and notify of gaps. An operator must preserve the one- shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant decision sequence, hash- chained records and scoped disclosure keys, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: decision sequence, hash-chained records and scoped disclosure keys. * Explicit hostile condition: a compromised application edits audit events to hide an unauthorized attempt. * Negative conformance criterion: a missing journal sequence or altered record is independently detectable. * Recovery obligation: reconstruct from protected checkpoint and notify of gaps. Das Expires 4 May 2027 [Page 134] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-39: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Protected Audit Chain an| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 46: M-39 decision flow 55. M-40. Crash-Safe Idempotent Commit M-40 objective and boundary. This profile addresses durable prepare journal and external idempotency key. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 135] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which the process crashes after sending an effect but before recording its outcome. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode durable prepare journal and external idempotency key, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD write committed consumption before irreversible dispatch and recover under same operation ID. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that restart cannot issue a second effective command for a prior handle. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 136] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD mark outcome UNKNOWN and query downstream evidence. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant durable prepare journal and external idempotency key, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: durable prepare journal and external idempotency key. * Explicit hostile condition: the process crashes after sending an effect but before recording its outcome. * Negative conformance criterion: restart cannot issue a second effective command for a prior handle. * Recovery obligation: mark outcome UNKNOWN and query downstream evidence. Das Expires 4 May 2027 [Page 137] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-40: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Crash-Safe Idempotent Co| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 47: M-40 decision flow 56. M-41. Multi-Sink Atomicity and Partial Failure M-41 objective and boundary. This profile addresses participating sink list, bounded group authority and explicit partial outcomes. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 138] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which one of several remote effects succeeds while another is rejected. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode participating sink list, bounded group authority and explicit partial outcomes, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD define per-sink commits and a multi-step recovery plan rather than claim global atomicity. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that partial results never masquerade as full completion. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 139] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD initiate compensating actions only under separately authorized policies. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant participating sink list, bounded group authority and explicit partial outcomes, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: participating sink list, bounded group authority and explicit partial outcomes. * Explicit hostile condition: one of several remote effects succeeds while another is rejected. * Negative conformance criterion: partial results never masquerade as full completion. * Recovery obligation: initiate compensating actions only under separately authorized policies. Das Expires 4 May 2027 [Page 140] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-41: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Multi-Sink Atomicity and| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 48: M-41 decision flow 57. M-42. Bounded Clock Uncertainty M-42 objective and boundary. This profile addresses trusted time source, tolerance and monotonic time epoch. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 141] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an attacker exploits clock rollback to reuse expired authority. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode trusted time source, tolerance and monotonic time epoch, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD combine bounded wall clock validation with protected monotonic generation. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that time rollback cannot expand authorization lifetime. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 142] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD enter a safe mode until time trust is restored. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant trusted time source, tolerance and monotonic time epoch, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: trusted time source, tolerance and monotonic time epoch. * Explicit hostile condition: an attacker exploits clock rollback to reuse expired authority. * Negative conformance criterion: time rollback cannot expand authorization lifetime. * Recovery obligation: enter a safe mode until time trust is restored. Das Expires 4 May 2027 [Page 143] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-42: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Bounded Clock Uncertaint| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 49: M-42 decision flow 58. M-43. Revocation Cache and Partition Semantics M-43 objective and boundary. This profile addresses minimum acceptable epoch and local revocation freshness deadline. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 144] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a network partition leaves a signer with obsolete authorization state. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode minimum acceptable epoch and local revocation freshness deadline, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require a profile-defined maximum revocation age and deny beyond it. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that partition never silently converts expired cached approval to valid. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 145] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD restore authenticated epoch continuity before accepting commits. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant minimum acceptable epoch and local revocation freshness deadline, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: minimum acceptable epoch and local revocation freshness deadline. * Explicit hostile condition: a network partition leaves a signer with obsolete authorization state. * Negative conformance criterion: partition never silently converts expired cached approval to valid. * Recovery obligation: restore authenticated epoch continuity before accepting commits. Das Expires 4 May 2027 [Page 146] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-43: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Revocation Cache and Par| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 50: M-43 decision flow 59. M-44. Request Cancellation and Nonce Burn M-44 objective and boundary. This profile addresses cancellation sequence and protected nonce state. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 147] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a canceled operation is restarted from a queued stale candidate. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode cancellation sequence and protected nonce state, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD consume or revoke its reserved one- shot authorization and invalidate cached allow records. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that cancel/restart with same handle cannot create an effect. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 148] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD issue a new candidate ID only after fresh approval. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant cancellation sequence and protected nonce state, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: cancellation sequence and protected nonce state. * Explicit hostile condition: a canceled operation is restarted from a queued stale candidate. * Negative conformance criterion: cancel/restart with same handle cannot create an effect. * Recovery obligation: issue a new candidate ID only after fresh approval. Das Expires 4 May 2027 [Page 149] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-44: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Request Cancellation and| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 51: M-44 decision flow 60. M-45. Quorum Witness Availability M-45 objective and boundary. This profile addresses witness quorum generation and failure domain separation. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 150] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a single witness failure forces an unsafe fallback to unsigned authorization. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode witness quorum generation and failure domain separation, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD fail closed or use independently authenticated quorum per explicit policy. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a missing quorum produces no signer output. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 151] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD degrade availability explicitly without changing safety semantics. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant witness quorum generation and failure domain separation, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: witness quorum generation and failure domain separation. * Explicit hostile condition: a single witness failure forces an unsafe fallback to unsigned authorization. * Negative conformance criterion: a missing quorum produces no signer output. * Recovery obligation: degrade availability explicitly without changing safety semantics. Das Expires 4 May 2027 [Page 152] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-45: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Quorum Witness Availabil| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 52: M-45 decision flow 61. M-46. Semantic Transaction Simulation M-46 objective and boundary. This profile addresses simulation environment, pre-state and interpreted effect fields. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 153] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a dry-run reports harmless output while the real transaction touches other contracts. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode simulation environment, pre-state and interpreted effect fields, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind simulation to its state root, code identity and eventual transaction bytes. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that simulation drift triggers a new policy decision, not silent approval. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 154] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD mark simulation as advisory when exact replay equivalence is unavailable. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant simulation environment, pre- state and interpreted effect fields, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: simulation environment, pre-state and interpreted effect fields. * Explicit hostile condition: a dry-run reports harmless output while the real transaction touches other contracts. * Negative conformance criterion: simulation drift triggers a new policy decision, not silent approval. * Recovery obligation: mark simulation as advisory when exact replay equivalence is unavailable. Das Expires 4 May 2027 [Page 155] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-46: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Semantic Transaction Sim| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 53: M-46 decision flow 62. M-47. Account Abstraction and User Operation M-47 objective and boundary. This profile addresses paymaster identity, bundler, sponsor and operation calldata. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 156] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a sponsor or bundler mutates fee or call data between approval and execution. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode paymaster identity, bundler, sponsor and operation calldata, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind sender, call target, calldata, paymaster fields and beneficiary scope. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that mutation of sponsor- sensitive fields is rejected at finalization. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 157] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD resubmit a newly approved user operation with updated fee constraints. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant paymaster identity, bundler, sponsor and operation calldata, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: paymaster identity, bundler, sponsor and operation calldata. * Explicit hostile condition: a sponsor or bundler mutates fee or call data between approval and execution. * Negative conformance criterion: mutation of sponsor-sensitive fields is rejected at finalization. * Recovery obligation: resubmit a newly approved user operation with updated fee constraints. Das Expires 4 May 2027 [Page 158] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-47: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Account Abstraction and | +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 54: M-47 decision flow 63. M-48. Delegation Scope and Call-Graph Closure M-48 objective and boundary. This profile addresses reachable methods, nested calls and downstream token allowances. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 159] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a delegate remains approved but invokes unreviewed downstream transfer code. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode reachable methods, nested calls and downstream token allowances, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require a defined call-graph policy and change-detection for accessible code. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a newly reachable withdrawal method is not implicitly authorized. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 160] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD pause or constrain delegated calls until measured scope is updated. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant reachable methods, nested calls and downstream token allowances, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: reachable methods, nested calls and downstream token allowances. * Explicit hostile condition: a delegate remains approved but invokes unreviewed downstream transfer code. * Negative conformance criterion: a newly reachable withdrawal method is not implicitly authorized. * Recovery obligation: pause or constrain delegated calls until measured scope is updated. Das Expires 4 May 2027 [Page 161] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-48: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Delegation Scope and Cal| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 55: M-48 decision flow 64. M-49. Constrained Upgrades and Rollback M-49 objective and boundary. This profile addresses upgrade path, approved old and new code hashes and activation epoch. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 162] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an upgrade endpoint changes delegation functionality through hidden administrative routes. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode upgrade path, approved old and new code hashes and activation epoch, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD gate upgrade itself and bind implementation changes to protected policy generations. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that an unauthorized upgrade can neither execute nor inherit old transfer permissions. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 163] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD restore only a separately approved implementation and invalidate stale handles. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant upgrade path, approved old and new code hashes and activation epoch, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: upgrade path, approved old and new code hashes and activation epoch. * Explicit hostile condition: an upgrade endpoint changes delegation functionality through hidden administrative routes. * Negative conformance criterion: an unauthorized upgrade can neither execute nor inherit old transfer permissions. * Recovery obligation: restore only a separately approved implementation and invalidate stale handles. Das Expires 4 May 2027 [Page 164] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-49: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Constrained Upgrades and| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 56: M-49 decision flow 65. M-50. External Withdrawal Destination Registry M-50 objective and boundary. This profile addresses destination registry digest, beneficiary proof and freshness. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 165] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an attacker updates a destination registry after signer policy was checked. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode destination registry digest, beneficiary proof and freshness, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind the registry generation and actual output address at the last signing boundary. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a changed registry causes denial despite a historically approved alias. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 166] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD require protected approval for registry update and withdrawal. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant destination registry digest, beneficiary proof and freshness, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: destination registry digest, beneficiary proof and freshness. * Explicit hostile condition: an attacker updates a destination registry after signer policy was checked. * Negative conformance criterion: a changed registry causes denial despite a historically approved alias. * Recovery obligation: require protected approval for registry update and withdrawal. Das Expires 4 May 2027 [Page 167] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-50: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | External Withdrawal Dest| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 57: M-50 decision flow 66. M-51. Protocol Downgrade and Legacy Credentials M-51 objective and boundary. This profile addresses profile version, credential class and minimum local enforcement version. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 168] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a client negotiates away critical finality fields using an older endpoint. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode profile version, credential class and minimum local enforcement version, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD reject unrecognized or downgraded security-critical profile negotiation. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that legacy-format request cannot bypass requirements for a protected effect. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 169] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD serve only read-only legacy calls or add protected adapters. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant profile version, credential class and minimum local enforcement version, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: profile version, credential class and minimum local enforcement version. * Explicit hostile condition: a client negotiates away critical finality fields using an older endpoint. * Negative conformance criterion: legacy-format request cannot bypass requirements for a protected effect. * Recovery obligation: serve only read-only legacy calls or add protected adapters. Das Expires 4 May 2027 [Page 170] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-51: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Protocol Downgrade and L| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 58: M-51 decision flow 67. M-52. Overload and Resource Exhaustion M-52 objective and boundary. This profile addresses admission quota, challenge allocation and bounded state. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 171] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which attacker- generated requests consume nonce space, witness capacity and signing slots. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode admission quota, challenge allocation and bounded state, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD authenticate before expensive work and rate-limit per subject without granting extra authority. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that overload produces deterministic reject/pending states, never unguarded execution. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 172] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD replay durable requests after resources recover without duplicate side effects. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant admission quota, challenge allocation and bounded state, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: admission quota, challenge allocation and bounded state. * Explicit hostile condition: attacker-generated requests consume nonce space, witness capacity and signing slots. * Negative conformance criterion: overload produces deterministic reject/pending states, never unguarded execution. * Recovery obligation: replay durable requests after resources recover without duplicate side effects. Das Expires 4 May 2027 [Page 173] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-52: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Overload and Resource Ex| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 59: M-52 decision flow 68. M-53. Formal Mediation-Path Enumeration M-53 objective and boundary. This profile addresses complete list of APIs, hardware routes and credential exercise methods. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 174] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an undocumented maintenance interface produces signatures without protected checks. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode complete list of APIs, hardware routes and credential exercise methods, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD inventory and instrument every effective path and test fault injection for each. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a newly discovered route blocks complete-mediation conformance claims. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 175] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD disable the route or upgrade it with sink-local verification. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant complete list of APIs, hardware routes and credential exercise methods, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: complete list of APIs, hardware routes and credential exercise methods. * Explicit hostile condition: an undocumented maintenance interface produces signatures without protected checks. * Negative conformance criterion: a newly discovered route blocks complete-mediation conformance claims. * Recovery obligation: disable the route or upgrade it with sink- local verification. Das Expires 4 May 2027 [Page 176] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-53: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Formal Mediation-Path En| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 60: M-53 decision flow 69. M-54. Multi-Party Administrative Governance M-54 objective and boundary. This profile addresses policy author, approver, deployment signer and independent revoker. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 177] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which one actor changes both the rule and its audit approval in a single action. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode policy author, approver, deployment signer and independent revoker, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD require separation of duties and protected configuration provenance for high- risk commands. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a unilateral unauthorized policy change cannot make a rejected candidate valid. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 178] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD restore governance quorum and quarantine decisions made during compromise. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant policy author, approver, deployment signer and independent revoker, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: policy author, approver, deployment signer and independent revoker. * Explicit hostile condition: one actor changes both the rule and its audit approval in a single action. * Negative conformance criterion: a unilateral unauthorized policy change cannot make a rejected candidate valid. * Recovery obligation: restore governance quorum and quarantine decisions made during compromise. Das Expires 4 May 2027 [Page 179] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-54: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Multi-Party Administrati| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 61: M-54 decision flow 70. M-55. Sensitive Metadata Minimization M-55 objective and boundary. This profile addresses audit field classification, disclosed digest and protected access policy. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 180] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a valid receipt leaks private recipient or account data to unrelated observers. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode audit field classification, disclosed digest and protected access policy, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD separate public commitments from restricted policy inputs and encrypt sensitive evidence. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that external receipts reveal no unnecessary source data for audit correlation. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 181] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD rotate audit access grants and apply bounded retention schedules. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant audit field classification, disclosed digest and protected access policy, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: audit field classification, disclosed digest and protected access policy. * Explicit hostile condition: a valid receipt leaks private recipient or account data to unrelated observers. * Negative conformance criterion: external receipts reveal no unnecessary source data for audit correlation. * Recovery obligation: rotate audit access grants and apply bounded retention schedules. Das Expires 4 May 2027 [Page 182] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-55: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Sensitive Metadata Minim| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 62: M-55 decision flow 71. M-56. On-Device Firmware and Silicon Continuity M-56 objective and boundary. This profile addresses device descriptor hash, memory-translation generation and reset epoch. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 183] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which an approved DMA or accelerator descriptor is modified before hardware consumption. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode device descriptor hash, memory-translation generation and reset epoch, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind hardware-consumed descriptors to protected translation and reset generation. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that stale descriptor approval cannot survive remap or reset. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 184] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD reconstruct device-local state at the hardware effect gate. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant device descriptor hash, memory-translation generation and reset epoch, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: device descriptor hash, memory-translation generation and reset epoch. * Explicit hostile condition: an approved DMA or accelerator descriptor is modified before hardware consumption. * Negative conformance criterion: stale descriptor approval cannot survive remap or reset. * Recovery obligation: reconstruct device-local state at the hardware effect gate. Das Expires 4 May 2027 [Page 185] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-56: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | On-Device Firmware and S| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 63: M-56 decision flow 72. M-57. Non-Repudiable Audit Without False Finality M-57 objective and boundary. This profile addresses signed decision record and separately verified consequence acknowledgment. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink- facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 186] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which auditors assume the existence of a signed ALLOW record proves real-world delivery. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode signed decision record and separately verified consequence acknowledgment, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD type receipt records and audit both initiation and observed consequence. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that no settlement claim is produced without a qualifying external proof. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 187] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD record evidence gaps and schedule independent reconciliation. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant signed decision record and separately verified consequence acknowledgment, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: signed decision record and separately verified consequence acknowledgment. * Explicit hostile condition: auditors assume the existence of a signed ALLOW record proves real-world delivery. * Negative conformance criterion: no settlement claim is produced without a qualifying external proof. * Recovery obligation: record evidence gaps and schedule independent reconciliation. Das Expires 4 May 2027 [Page 188] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-57: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Non-Repudiable Audit Wit| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 64: M-57 decision flow 73. M-58. Independent Verification of Prior Approval M-58 objective and boundary. This profile addresses approved resource pattern and verifier-independent policy state. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 189] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which the same compromised process issues and verifies its own approval. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode approved resource pattern and verifier-independent policy state, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD separate trust roots or require attested independent policy validation at the sink. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that self-asserted approval cannot pass in absence of trusted policy lineage. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 190] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD reprovision witness authority and rotate its key material. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant approved resource pattern and verifier-independent policy state, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: approved resource pattern and verifier- independent policy state. * Explicit hostile condition: the same compromised process issues and verifies its own approval. * Negative conformance criterion: self-asserted approval cannot pass in absence of trusted policy lineage. * Recovery obligation: reprovision witness authority and rotate its key material. Das Expires 4 May 2027 [Page 191] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-58: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Independent Verification| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 65: M-58 decision flow 74. M-59. Post-Authorization Route Mutation M-59 objective and boundary. This profile addresses route ID, recipient address and protected egress network state. The relevant consequential boundary is the final privileged API invocation, signing operation, hardware command acceptance, or network dispatch that first gives the operation external effect. Upstream transport protection and authenticated requests remain necessary but do not substitute for a decision against the sink-facing representation. The implementation MUST identify which component owns that last boundary and how it prevents direct alternative invocations. Das Expires 4 May 2027 [Page 192] Internet-Draft Protected Transaction Execution Finality October 2026 Attack and counterexample. Consider a sequence in which a route changes after acceptance and redirects an otherwise authorized message. A compromised planner, API caller, helper process or state cache may present a conventional signature, previously approved workflow identifier or trusted channel. None of those facts establishes that the candidate act is still approved. The attacker may also schedule the operation just before a revocation becomes visible or just after the state is reloaded from an old checkpoint. The protected checker MUST compare both the current policy generation and the exact effective representation. Binding and reconstruction procedure. The minimal policy object MUST encode route ID, recipient address and protected egress network state, together with a tenant, sink instance, policy version, revocation generation, nonce, expiry interval, bounded use and critical extension set. The protected implementation SHOULD bind last-hop network and application endpoint under the protected dispatch gate. Where the original authorization describes a range of permitted actions, the sink must show that the actual act is within that range, rather than comparing only a generic category name. Where conversion steps occur, their semantics must be included in the proof or verified again at the last boundary. Execution algorithm. First acquire a sink-local protected state snapshot and confirm the identity of the candidate and its lineage. Second, reconstruct the exact effect from the operation bytes or device state about to be consumed. Third, compare the effect against the authority record and reject unknown critical fields. Fourth, test current policy, revocation, freshness, capacity and domain bindings. Fifth, commit one-shot capability consumption atomically with release of the final protected command. On failure, burn or revoke the attempted handle, record a typed denial and preserve external-outcome UNKNOWN unless there is independently authenticated evidence. Validation and negative experiment. An implementation MUST exercise at least one positive case and one adversarial negative case for this profile. The decisive assertion is that a route substitution before egress is detected by execution-time reconstruction. Test designers SHOULD vary message serialization, scheduler ordering, local state generation, duplicate requests and alternate execution routes; a superficial unit test of policy evaluation alone is not sufficient. Record both the reason code and whether any protected signing operation or device actuation took place. A denied response accompanied by a leaked effective signature is a test failure. Das Expires 4 May 2027 [Page 193] Internet-Draft Protected Transaction Execution Finality October 2026 Recovery and operational trade-off. Following inconsistent state or an attempted bypass, the deployment SHOULD repeat protected route validation after each network failover. An operator must preserve the one-shot safety invariant across recovery; a retry with a new request ID but unchanged authorization is unsafe unless a newly approved act is proven. Availability is subordinate to denial correctness. Telemetry may report a suspected incident, but a monitor that cannot actually withhold the effect is not a compliant finality gate. Interoperability note. A foreign system may express this profile through JSON, CBOR, a message queue, a transaction object or device command. Interoperable adapters MUST preserve signed canonical semantics and critical extensions across that translation. When a remote sink cannot enforce the relevant route ID, recipient address and protected egress network state, the gateway MUST narrow its conformance claim to effects completely controlled by its own protected boundary. Mapping a positive local decision to final downstream success without independent evidence is prohibited. * Coverage requirement: route ID, recipient address and protected egress network state. * Explicit hostile condition: a route changes after acceptance and redirects an otherwise authorized message. * Negative conformance criterion: a route substitution before egress is detected by execution-time reconstruction. * Recovery obligation: repeat protected route validation after each network failover. Das Expires 4 May 2027 [Page 194] Internet-Draft Protected Transaction Execution Finality October 2026 +-----------------------------------------------+ | M-59: receive candidate + protected context | +-----------------------+-----------------------+ | verify lineage and epochs | reconstruct final effect | +--------+--------+ | Post-Authorization Route| +--------+--------+ | exact policy match + quota? / \ no yes | | DENY, burn ATOMIC and audit consume | EFFECT boundary | outcome = UNKNOWN until independently confirmed Figure 66: M-59 decision flow 75. Algorithm: Two-Instance Intent-to-Effect Protocol PED-1 captures a candidate before it has effect, binds its requested action to approved authoritative context, and records a policy and revocation generation. PED-2 is invoked at execution time, loads actual sink-bound bytes and current effect environment, and reconstructs the pending action. These two instances SHOULD be separated enough that compromise of the ordinary requester cannot rewrite both approved and pending representations. The protected authority issues an execution handle only after exact eligibility has been established. The FS does not accept the handle merely because it is signed; it also verifies sink instance binding, state generation, remaining quota and whether the exact candidate it is about to effectuate equals the one described by the handle. Atomic consumption must be protected from simultaneous writers and survives the moment at which a signature or command escapes. If a downstream effect is not transactional, the system records possible partial execution and does not silently generate a replacement signature during recovery. Das Expires 4 May 2027 [Page 195] Internet-Draft Protected Transaction Execution Finality October 2026 function PTEF_COMMIT(candidate, handle, sink): lock(sink.monotonic_state) try: if unknown(candidate.lineage): return DENY_UNKNOWN if !authenticated(handle.issuer): return DENY_AUTHORITY if !handle.bound_to(sink.identity): return DENY_SINK if handle.used_or_burned: return DENY_REPLAY actual = sink.reconstruct_pending_effect() if !equivalent(actual, handle.authorized_effect): sink.burn(handle); return DENY_BINDING if !fresh(handle, sink.protected_time): sink.burn(handle); return DENY_STALE if !epochs_match(handle, sink.protected_state): sink.burn(handle); return DENY_REVOKED if !fits_budget(actual, sink.monotonic_state): sink.burn(handle); return DENY_QUOTA sink.journal.record_prepared(candidate.id, handle.id) sink.consume(handle); sink.reserve_budget(actual) result = sink.initiate_effect(actual, idempotency=candidate.id) sink.journal.record_initiated(candidate.id, result) return ALLOW_INITIATED_OUTCOME_UNKNOWN finally: unlock(sink.monotonic_state) Figure 67: Algorithm 1 — PTEF-COMMIT pseudocode 76. Algorithm: Denial, Crash Recovery and Anti-Replay A denial SHOULD consume or revoke the specific capability allocated for the attempted candidate, but an invalid unauthenticated packet must not be able to exhaust an unrelated account-wide nonce namespace. Denial journals need sufficient protected identity to distinguish authentic allocation from arbitrary attacker input. Crash recovery begins by reading the durable state ledger. If an operation is marked consumed but downstream outcome is unknown, the same identifier may be queried or safely reconciled. A new signature, command or debit must not be issued merely because an API caller timed out. Reconciler authority must be independently scoped. A reconciliation task may fetch status or submit a cryptographic proof but must not have unrestricted authority to mutate the original transfer or destination. Recovery MUST preserve the monotonic ordering of revocation, policy and signer generations. Das Expires 4 May 2027 [Page 196] Internet-Draft Protected Transaction Execution Finality October 2026 PREPARED -> VALIDATED -> CONSUMED -> INITIATED -> ACKNOWLEDGED | | | | | v v v v v DENIED DENIED OUTCOME OUTCOME SETTLED UNKNOWN UNKNOWN (external) | | +------RECONCILE-------+ NOTE: OUTCOME UNKNOWN is not permission to execute again. Figure 68: Recovery state machine 77. Algorithm: Policy Epoch and Quota Settlement Quota is a protected state variable attached to a resource principal, purpose and validity interval. The ledger may use serializable transactions, quorum replication or a guarded hardware counter, but the implementation must demonstrate that no two commits can simultaneously spend the same bounded authorization. Policy epoch and revocation epoch need not be numerically equal. The current policy version describes allowed act shape, whereas revocation indicates effective invalidation of previous authorizations. Epoch checks MUST use explicitly defined comparisons and an authenticated issuer domain to prevent false advancement of stale authority. Quota that is externally deducted at effect initiation must not be refunded merely because the downstream outcome is UNKNOWN. Refund logic MAY exist under separately authorized settlement evidence, with a distinct idempotency key and protected audit record. transaction protected_state: assert candidate.effect_digest == reconstruct(effect_bytes) assert candidate.policy_epoch == current_policy_epoch assert candidate.revocation_epoch >= current_revocation_epoch assert candidate.nonce NOT_IN consumed_or_burned assert remaining_quota >= requested_units write consumed_or_burned += candidate.nonce write remaining_quota -= requested_units write journal += PRECOMMIT(candidate.id, state_generation) commit protected_state invoke_exclusive_sink(candidate, idempotency=candidate.id) Figure 69: Algorithm 2 — guarded budget settle Das Expires 4 May 2027 [Page 197] Internet-Draft Protected Transaction Execution Finality October 2026 78. Conformance Levels and Test Methodology Level L0 (advisory) may log or score candidates but cannot claim protected execution-finality enforcement. Level L1 (single boundary) enforces a protected, non-bypassable sink over one consequential effect class. Level L2 (state-continuous) adds revocation, quota, replay and durable recovery. Level L3 (multi-domain) preserves semantic authority across trusted platform boundaries with tested alternate-path closure. The reference repository implements a pedagogical L1/L2-like local decision model only; because keys are public, exclusive signing paths are not implemented, and no external effect is created, it is NOT itself conformant L1 or L2. Its passing tests validate a subset of logic, not the trust properties required for a deployed system. A conformance report SHOULD include a data-flow diagram, trusted computing base, supported profiles, adversary capabilities, alternate-path inventory, cryptographic keys and algorithms, concurrency model, crash windows, failure handling, and evidence that a denied operation produced no usable capability. Test cases are grouped into baseline authorization, altered fields, policy denial after valid authorization, witness tampering, effect mismatch, nonce replay, quota contention, malicious delegate, unknown lineage, malformed input and non-ASCII encoding. Reviewers SHOULD repeat them under concurrent load and injected key-rotation, outage and clock-drift conditions. Inventory every effective path | Determine trusted sink boundary | Derive exact-effect profile fields | Execute baseline + adversarial tests | Inject concurrency, crash, revocation | Audit whether DENY leaked any effect | Publish scope and exclusions only Figure 70: Conformance pipeline Das Expires 4 May 2027 [Page 198] Internet-Draft Protected Transaction Execution Finality October 2026 79. Test-Vector Catalog 001-008 Test 001 (valid-transfer-10). Category: Nominal or exception validation. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-001. Expected protected decisions, in order: ALLOW. Expected final local quota used: 10. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 002 (valid-delegate-0). Category: Delegation authority constraints. Input context: kind=delegate, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=contract-approved, amount=0, nonce=n-002. Expected protected decisions, in order: ALLOW. Expected final local quota used: 0. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 003 (valid-export-1). Category: Nominal or exception validation. Input context: kind=export, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=1, nonce=n-003. Expected protected decisions, in order: ALLOW. Expected final local quota used: 1. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 199] Internet-Draft Protected Transaction Execution Finality October 2026 Test 004 (valid-transmit-1). Category: Nominal or exception validation. Input context: kind=transmit, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=device-approved, amount=1, nonce=n-004. Expected protected decisions, in order: ALLOW. Expected final local quota used: 1. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 005 (valid-actuate-1). Category: Nominal or exception validation. Input context: kind=actuate, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=device-approved, amount=1, nonce=n-005. Expected protected decisions, in order: ALLOW. Expected final local quota used: 1. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 006 (valid-transfer-100). Category: Nominal or exception validation. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=100, nonce=n-006. Expected protected decisions, in order: ALLOW. Expected final local quota used: 100. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 007 (tamper-tenant-tenant-B). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-B, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-007. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 200] Internet-Draft Protected Transaction Execution Finality October 2026 Test 008 (tamper-tenant-TENANT-A). Category: Mutation after approval. Input context: kind=transfer, tenant=TENANT-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-008. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. 80. Test-Vector Catalog 009-016 Test 009 (tamper-tenant-). Category: Mutation after approval. Input context: kind=transfer, tenant=, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-009. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 010 (tamper-sink-unprotected-signer). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=unprotected-signer, chain=chain-17, target=account-approved, amount=10, nonce=n-010. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 011 (tamper-sink-protected-signer-2). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-2, chain=chain-17, target=account-approved, amount=10, nonce=n-011. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 201] Internet-Draft Protected Transaction Execution Finality October 2026 Test 012 (tamper-domain-radio). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-012. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 013 (tamper-domain-payments). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-013. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 014 (tamper-chain-chain-18). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-18, target=account-approved, amount=10, nonce=n-014. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 015 (tamper-chain-0). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=0, target=account-approved, amount=10, nonce=n-015. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 016 (tamper-chain-). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=, target=account-approved, amount=10, nonce=n-016. Expected Das Expires 4 May 2027 [Page 202] Internet-Draft Protected Transaction Execution Finality October 2026 protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. 81. Test-Vector Catalog 017-024 Test 017 (tamper-target-account-attacker). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-attacker, amount=10, nonce=n-017. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 018 (tamper-target-contract-approved). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=contract-approved, amount=10, nonce=n-018. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 019 (tamper-target-). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=, amount=10, nonce=n-019. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 020 (tamper-amount-11). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=11, nonce=n-020. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical Das Expires 4 May 2027 [Page 203] Internet-Draft Protected Transaction Execution Finality October 2026 operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 021 (tamper-amount-0). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=0, nonce=n-021. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 022 (tamper-amount-999). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=999, nonce=n-022. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 023 (tamper-amount--1). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=-1, nonce=n-023. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 204] Internet-Draft Protected Transaction Execution Finality October 2026 Test 024 (tamper-amount-01). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=01, nonce=n-024. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. 82. Test-Vector Catalog 025-032 Test 025 (tamper-code_hash-malicious-codehash). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-025. Expected protected decisions, in order: DENY_DELEGATE. Expected final local quota used: 0. Acceptance rationale: Delegated implementation or unexpected code authority is not permitted. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 026 (tamper-lineage-UNKNOWN). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-026. Expected protected decisions, in order: DENY_UNKNOWN_LINEAGE. Expected final local quota used: 0. Acceptance rationale: Missing or unverified source authority fails closed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 027 (tamper-lineage-UNVERIFIED). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-027. Expected protected decisions, in order: DENY_UNKNOWN_LINEAGE. Expected final local quota used: 0. Acceptance rationale: Missing or unverified source authority fails closed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 205] Internet-Draft Protected Transaction Execution Finality October 2026 Test 028 (tamper-lineage-). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-028. Expected protected decisions, in order: DENY_UNKNOWN_LINEAGE. Expected final local quota used: 0. Acceptance rationale: Missing or unverified source authority fails closed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 029 (tamper-state-state-v2). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-029. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 030 (tamper-state-). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-030. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 031 (tamper-policy_epoch-3). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-031. Expected protected decisions, in order: DENY_POLICY_EPOCH. Expected final local quota used: 0. Acceptance rationale: Stored approval cannot silently survive a policy version change. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 032 (tamper-policy_epoch-5). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-032. Expected protected decisions, in order: DENY_POLICY_EPOCH. Expected Das Expires 4 May 2027 [Page 206] Internet-Draft Protected Transaction Execution Finality October 2026 final local quota used: 0. Acceptance rationale: Stored approval cannot silently survive a policy version change. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. 83. Test-Vector Catalog 033-040 Test 033 (tamper-rev_epoch-1). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-033. Expected protected decisions, in order: DENY_REVOCATION. Expected final local quota used: 0. Acceptance rationale: The approval was created under an obsolete or inapplicable revocation epoch. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 034 (tamper-rev_epoch-3). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-034. Expected protected decisions, in order: DENY_REVOCATION. Expected final local quota used: 0. Acceptance rationale: The approval was created under an obsolete or inapplicable revocation epoch. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 035 (tamper-issuer-compromised-issuer). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-035. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 036 (tamper-kind-unknown). Category: Mutation after approval. Input context: kind=unknown, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-036. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the Das Expires 4 May 2027 [Page 207] Internet-Draft Protected Transaction Execution Finality October 2026 full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 037 (tamper-kind-delegate). Category: Mutation after approval. Input context: kind=delegate, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-037. Expected protected decisions, in order: DENY_DELEGATE. Expected final local quota used: 0. Acceptance rationale: Delegated implementation or unexpected code authority is not permitted. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 038 (tamper-kind-transmit). Category: Mutation after approval. Input context: kind=transmit, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-038. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 039 (tamper-now-2000). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-039. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 040 (tamper-now-0). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-040. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 208] Internet-Draft Protected Transaction Execution Finality October 2026 84. Test-Vector Catalog 041-048 Test 041 (tamper-now-not-a-time). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-041. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 042 (tamper-not_before-2001). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-042. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 043 (tamper-expires-999). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-043. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 044 (tamper-expires-999999). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-044. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 209] Internet-Draft Protected Transaction Execution Finality October 2026 Test 045 (tamper-nonce-predictable-replay). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=predictable-replay. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 046 (tamper-nonce-). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 047 (tamper-id-modified-id). Category: Mutation after approval. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer- 1, chain=chain-17, target=account-approved, amount=10, nonce=n-047. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 048 (signed-policy-deny-tenant-tenant-B). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-B, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-048. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 210] Internet-Draft Protected Transaction Execution Finality October 2026 85. Test-Vector Catalog 049-056 Test 049 (signed-policy-deny-sink-unprotected-signer). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=unprotected-signer, chain=chain- 17, target=account-approved, amount=10, nonce=n-049. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 050 (signed-policy-deny-domain-radio). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-050. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 051 (signed-policy-deny-chain-chain-18). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-18, target=account-approved, amount=10, nonce=n-051. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 211] Internet-Draft Protected Transaction Execution Finality October 2026 Test 052 (signed-policy-deny-target-account-attacker). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-attacker, amount=10, nonce=n-052. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 053 (signed-policy-deny-amount-101). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=101, nonce=n-053. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 054 (signed-policy-deny-amount-251). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=251, nonce=n-054. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 055 (signed-policy-deny-lineage-UNKNOWN). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-055. Expected protected decisions, in order: DENY_UNKNOWN_LINEAGE. Expected final local quota used: 0. Acceptance rationale: Missing or unverified source authority fails closed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 212] Internet-Draft Protected Transaction Execution Finality October 2026 Test 056 (signed-policy-deny-lineage-UNVERIFIED). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-056. Expected protected decisions, in order: DENY_UNKNOWN_LINEAGE. Expected final local quota used: 0. Acceptance rationale: Missing or unverified source authority fails closed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. 86. Test-Vector Catalog 057-064 Test 057 (signed-policy-deny-lineage-). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-057. Expected protected decisions, in order: DENY_UNKNOWN_LINEAGE. Expected final local quota used: 0. Acceptance rationale: Missing or unverified source authority fails closed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 058 (signed-policy-deny-state-state-v2). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-058. Expected protected decisions, in order: DENY_CONTEXT. Expected final local quota used: 0. Acceptance rationale: Tenant, domain, network, sink or observed protected generation mismatches. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 213] Internet-Draft Protected Transaction Execution Finality October 2026 Test 059 (signed-policy-deny-policy_epoch-3). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-059. Expected protected decisions, in order: DENY_POLICY_EPOCH. Expected final local quota used: 0. Acceptance rationale: Stored approval cannot silently survive a policy version change. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 060 (signed-policy-deny-policy_epoch-5). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-060. Expected protected decisions, in order: DENY_POLICY_EPOCH. Expected final local quota used: 0. Acceptance rationale: Stored approval cannot silently survive a policy version change. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 061 (signed-policy-deny-rev_epoch-1). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-061. Expected protected decisions, in order: DENY_REVOCATION. Expected final local quota used: 0. Acceptance rationale: The approval was created under an obsolete or inapplicable revocation epoch. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 062 (signed-policy-deny-rev_epoch-3). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-062. Expected protected decisions, in order: DENY_REVOCATION. Expected final local quota used: 0. Acceptance rationale: The approval was created under an obsolete or inapplicable revocation epoch. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 214] Internet-Draft Protected Transaction Execution Finality October 2026 Test 063 (signed-policy-deny-issuer-compromised-issuer). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-063. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 064 (signed-policy-deny-kind-unknown). Category: Genuine signature with forbidden policy scope. Input context: kind=unknown, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-064. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. 87. Test-Vector Catalog 065-072 Test 065 (signed-policy-deny-now-2000). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-065. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/ suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 215] Internet-Draft Protected Transaction Execution Finality October 2026 Test 066 (signed-policy-deny-now-985). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-066. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/ suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 067 (signed-policy-deny-not_before-1001). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-067. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/ suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 068 (signed-policy-deny-expires-999). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-068. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/ suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 069 (signed-policy-deny-expires-1500). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-069. Expected protected decisions, in order: DENY_TIME. Expected final local quota used: 0. Acceptance rationale: Clock window, expiry and maximum authorized lifetime constraints failed. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/ suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 216] Internet-Draft Protected Transaction Execution Finality October 2026 Test 070 (signed-policy-deny-code_hash-codehash-unapproved). Category: Genuine signature with forbidden policy scope. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-070. Expected protected decisions, in order: DENY_DELEGATE. Expected final local quota used: 0. Acceptance rationale: Delegated implementation or unexpected code authority is not permitted. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 071 (proof-or-effect-authorization_digest-00000000000000000000). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-071. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 072 (proof-or-effect-authorization_digest-not-a-digest). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-072. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. 88. Test-Vector Catalog 073-080 Test 073 (proof-or-effect-authorization_mac-00000000000000000000). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-073. Expected protected decisions, in order: DENY_AUTHENTICITY. Expected final local quota used: 0. Acceptance rationale: The educational authority tag does not match authorized canonical bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated Das Expires 4 May 2027 [Page 217] Internet-Draft Protected Transaction Execution Finality October 2026 by tests/build_vectors.py. Test 074 (proof-or-effect-authorization_mac-not-a-mac). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-074. Expected protected decisions, in order: DENY_AUTHENTICITY. Expected final local quota used: 0. Acceptance rationale: The educational authority tag does not match authorized canonical bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 075 (proof-or-effect-precommit_mac-00000000000000000000). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-075. Expected protected decisions, in order: DENY_PRECOMMIT. Expected final local quota used: 0. Acceptance rationale: The educational witness precommit receipt cannot be authenticated. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 076 (proof-or-effect-precommit_mac-not-a-receipt). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-076. Expected protected decisions, in order: DENY_PRECOMMIT. Expected final local quota used: 0. Acceptance rationale: The educational witness precommit receipt cannot be authenticated. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 218] Internet-Draft Protected Transaction Execution Finality October 2026 Test 077 (proof-or-effect-observed_target-account-attacker). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-077. Expected protected decisions, in order: DENY_EFFECT_MISMATCH. Expected final local quota used: 0. Acceptance rationale: Actual final effect differs from approved destination or value. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 078 (proof-or-effect-observed_target-). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-078. Expected protected decisions, in order: DENY_EFFECT_MISMATCH. Expected final local quota used: 0. Acceptance rationale: Actual final effect differs from approved destination or value. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 079 (proof-or-effect-observed_amount-11). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-079. Expected protected decisions, in order: DENY_EFFECT_MISMATCH. Expected final local quota used: 0. Acceptance rationale: Actual final effect differs from approved destination or value. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 080 (proof-or-effect-observed_amount--1). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-080. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 219] Internet-Draft Protected Transaction Execution Finality October 2026 89. Test-Vector Catalog 081-088 Test 081 (proof-or-effect-observed_amount-0001). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-081. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 082 (proof-or-effect-mediated-False). Category: Integrity witness or effect reconstruction. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-082. Expected protected decisions, in order: DENY_NOT_MEDIATED. Expected final local quota used: 0. Acceptance rationale: A bypass flag means the event lacks the required exclusive path. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/ suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 083 (unauthorized-delegate-code). Category: Delegation authority constraints. Input context: kind=delegate, tenant=tenant- A, sink=protected-signer-1, chain=chain-17, target=contract-approved, amount=10, nonce=n-083. Expected protected decisions, in order: DENY_DELEGATE. Expected final local quota used: 0. Acceptance rationale: Delegated implementation or unexpected code authority is not permitted. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 084 (valid-delegate). Category: Delegation authority constraints. Input context: kind=delegate, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=contract-approved, amount=0, nonce=n-084. Expected protected decisions, in order: DENY_EFFECT_MISMATCH. Expected final local quota used: 0. Acceptance rationale: Actual final effect differs from approved destination or value. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 220] Internet-Draft Protected Transaction Execution Finality October 2026 Test 085 (code-on-transfer). Category: Nominal or exception validation. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-085. Expected protected decisions, in order: DENY_DELEGATE. Expected final local quota used: 0. Acceptance rationale: Delegated implementation or unexpected code authority is not permitted. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 086 (explicit-bypass). Category: Nominal or exception validation. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-086. Expected protected decisions, in order: DENY_NOT_MEDIATED. Expected final local quota used: 0. Acceptance rationale: A bypass flag means the event lacks the required exclusive path. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 087 (replay-after-allow). Category: Stateful replay and quota settlement. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=seq-1. Expected protected decisions, in order: ALLOW, DENY_REPLAY. Expected final local quota used: 10. Acceptance rationale: An authorization nonce has already been consumed or burned. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 088 (deny-burn-replay). Category: Stateful replay and quota settlement. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=seq-2. Expected protected decisions, in order: DENY_AUTHENTICITY, DENY_REPLAY. Expected final local quota used: 0. Acceptance rationale: An authorization nonce has already been consumed or burned. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 221] Internet-Draft Protected Transaction Execution Finality October 2026 90. Test-Vector Catalog 089-096 Test 089 (concurrent-like-duplicate-nonce). Category: Nominal or exception validation. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=seq-3. Expected protected decisions, in order: ALLOW, DENY_BINDING. Expected final local quota used: 10. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 090 (quota-saturation). Category: Stateful replay and quota settlement. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=100, nonce=seq-5. Expected protected decisions, in order: ALLOW, ALLOW, DENY_QUOTA, ALLOW. Expected final local quota used: 250. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 091 (quota-allow-exact). Category: Stateful replay and quota settlement. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=100, nonce=seq-9. Expected protected decisions, in order: ALLOW, ALLOW, ALLOW. Expected final local quota used: 250. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 092 (denial-does-not-charge-quota). Category: Stateful replay and quota settlement. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=seq-12. Expected protected decisions, in order: DENY_EFFECT_MISMATCH, ALLOW, ALLOW. Expected final local quota used: 200. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 222] Internet-Draft Protected Transaction Execution Finality October 2026 Test 093 (unicode-target-not-allowed-0). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-0|"\\u0000, amount=10, nonce=n-093. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 094 (unicode-target-not-allowed-1). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-1|"\\u0000, amount=10, nonce=n-094. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 095 (unicode-target-not-allowed-2). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-2|"\\u0000, amount=10, nonce=n-095. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 096 (unicode-target-not-allowed-3). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-3|"\\u0000, amount=10, nonce=n-096. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 223] Internet-Draft Protected Transaction Execution Finality October 2026 91. Test-Vector Catalog 097-104 Test 097 (unicode-target-not-allowed-4). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-4|"\\u0000, amount=10, nonce=n-097. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 098 (unicode-target-not-allowed-5). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-5|"\\u0000, amount=10, nonce=n-098. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 099 (unicode-target-not-allowed-6). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-6|"\\u0000, amount=10, nonce=n-099. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 224] Internet-Draft Protected Transaction Execution Finality October 2026 Test 100 (unicode-target-not-allowed-7). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-7|"\\u0000, amount=10, nonce=n-100. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 101 (unicode-target-not-allowed-8). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-8|"\\u0000, amount=10, nonce=n-101. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 102 (unicode-target-not-allowed-9). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-9|"\\u0000, amount=10, nonce=n-102. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 103 (unicode-target-not-allowed-10). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-10|"\\u0000, amount=10, nonce=n-103. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 225] Internet-Draft Protected Transaction Execution Finality October 2026 Test 104 (unicode-target-not-allowed-11). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-11|"\\u0000, amount=10, nonce=n-104. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. 92. Test-Vector Catalog 105-112 Test 105 (unicode-target-not-allowed-12). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-12|"\\u0000, amount=10, nonce=n-105. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 106 (unicode-target-not-allowed-13). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-13|"\\u0000, amount=10, nonce=n-106. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 226] Internet-Draft Protected Transaction Execution Finality October 2026 Test 107 (unicode-target-not-allowed-14). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-14|"\\u0000, amount=10, nonce=n-107. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 108 (unicode-target-not-allowed-15). Category: Unicode canonicalization and identity confusion. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=α-15|"\\u0000, amount=10, nonce=n-108. Expected protected decisions, in order: DENY_SCOPE. Expected final local quota used: 0. Acceptance rationale: Operation class, target, amount or issuer violates current policy. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 109 (unique-accepted-0). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=1, nonce=n-109. Expected protected decisions, in order: ALLOW. Expected final local quota used: 1. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 110 (unique-accepted-1). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=2, nonce=n-110. Expected protected decisions, in order: ALLOW. Expected final local quota used: 2. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 227] Internet-Draft Protected Transaction Execution Finality October 2026 Test 111 (unique-accepted-2). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=3, nonce=n-111. Expected protected decisions, in order: ALLOW. Expected final local quota used: 3. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 112 (unique-accepted-3). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=4, nonce=n-112. Expected protected decisions, in order: ALLOW. Expected final local quota used: 4. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. 93. Test-Vector Catalog 113-120 Test 113 (unique-accepted-4). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=5, nonce=n-113. Expected protected decisions, in order: ALLOW. Expected final local quota used: 5. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 228] Internet-Draft Protected Transaction Execution Finality October 2026 Test 114 (unique-accepted-5). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=6, nonce=n-114. Expected protected decisions, in order: ALLOW. Expected final local quota used: 6. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 115 (unique-accepted-6). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=7, nonce=n-115. Expected protected decisions, in order: ALLOW. Expected final local quota used: 7. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 116 (unique-accepted-7). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=8, nonce=n-116. Expected protected decisions, in order: ALLOW. Expected final local quota used: 8. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 117 (unique-accepted-8). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=9, nonce=n-117. Expected protected decisions, in order: ALLOW. Expected final local quota used: 9. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Das Expires 4 May 2027 [Page 229] Internet-Draft Protected Transaction Execution Finality October 2026 Test 118 (unique-accepted-9). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-118. Expected protected decisions, in order: ALLOW. Expected final local quota used: 10. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 119 (unique-accepted-10). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=11, nonce=n-119. Expected protected decisions, in order: ALLOW. Expected final local quota used: 11. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 120 (unique-accepted-11). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=12, nonce=n-120. Expected protected decisions, in order: ALLOW. Expected final local quota used: 12. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. 94. Test-Vector Catalog 121-128 Test 121 (unique-accepted-12). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=13, nonce=n-121. Expected protected decisions, in order: ALLOW. Expected final local quota used: 13. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ Das Expires 4 May 2027 [Page 230] Internet-Draft Protected Transaction Execution Finality October 2026 build_vectors.py. Test 122 (unique-accepted-13). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=14, nonce=n-122. Expected protected decisions, in order: ALLOW. Expected final local quota used: 14. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 123 (unique-accepted-14). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=15, nonce=n-123. Expected protected decisions, in order: ALLOW. Expected final local quota used: 15. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 124 (unique-accepted-15). Category: Legitimate independent candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=16, nonce=n-124. Expected protected decisions, in order: ALLOW. Expected final local quota used: 16. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 125 (modified-after-approval-0). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=1, nonce=n-125. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 231] Internet-Draft Protected Transaction Execution Finality October 2026 Test 126 (modified-after-approval-1). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=2, nonce=n-126. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 127 (modified-after-approval-2). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=3, nonce=n-127. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 128 (modified-after-approval-3). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=4, nonce=n-128. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. 95. Test-Vector Catalog 129-136 Test 129 (modified-after-approval-4). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=5, nonce=n-129. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 232] Internet-Draft Protected Transaction Execution Finality October 2026 Test 130 (modified-after-approval-5). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=6, nonce=n-130. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 131 (modified-after-approval-6). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=7, nonce=n-131. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 132 (modified-after-approval-7). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=8, nonce=n-132. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 133 (modified-after-approval-8). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=9, nonce=n-133. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 134 (modified-after-approval-9). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-134. Expected protected decisions, in order: Das Expires 4 May 2027 [Page 233] Internet-Draft Protected Transaction Execution Finality October 2026 ALLOW. Expected final local quota used: 10. Acceptance rationale: Matching authorized act was committed in the local demonstrator and counted against quota. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 135 (modified-after-approval-10). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=11, nonce=n-135. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 136 (modified-after-approval-11). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=12, nonce=n-136. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. 96. Test-Vector Catalog 137-144 Test 137 (modified-after-approval-12). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=13, nonce=n-137. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 138 (modified-after-approval-13). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=14, nonce=n-138. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance Das Expires 4 May 2027 [Page 234] Internet-Draft Protected Transaction Execution Finality October 2026 rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 139 (modified-after-approval-14). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=15, nonce=n-139. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 140 (modified-after-approval-15). Category: Post-approval intent modification. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=16, nonce=n-140. Expected protected decisions, in order: DENY_BINDING. Expected final local quota used: 0. Acceptance rationale: Approved canonical operation no longer matches the candidate bytes. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 141 (type-and-canonical-amount-1). Category: Malformed or type- ambiguous candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=1, nonce=n-141. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 235] Internet-Draft Protected Transaction Execution Finality October 2026 Test 142 (type-and-canonical-now-1000). Category: Malformed or type- ambiguous candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-142. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 143 (type-and-canonical-target-None). Category: Malformed or type-ambiguous candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=None, amount=10, nonce=n-143. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/ suite.json; the digest and authorization tags are generated by tests/ build_vectors.py. Test 144 (type-and-canonical-nonce-None). Category: Malformed or type-ambiguous candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=None. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. 97. Test-Vector Catalog 145-148 Test 145 (type-and-canonical-expires-99999999999999999999999). Category: Malformed or type-ambiguous candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain- 17, target=account-approved, amount=10, nonce=n-145. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Das Expires 4 May 2027 [Page 236] Internet-Draft Protected Transaction Execution Finality October 2026 Test 146 (type-and-canonical-amount--10). Category: Malformed or type-ambiguous candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=-10, nonce=n-146. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 147 (type-and-canonical-amount-00010). Category: Malformed or type-ambiguous candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=00010, nonce=n-147. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. Test 148 (type-and-canonical-lineage-True). Category: Malformed or type-ambiguous candidate. Input context: kind=transfer, tenant=tenant-A, sink=protected-signer-1, chain=chain-17, target=account-approved, amount=10, nonce=n-148. Expected protected decisions, in order: DENY_MALFORMED. Expected final local quota used: 0. Acceptance rationale: Noncanonical or ill-typed input never reaches protected signature release. The test MUST compare the full typed result and final nonce ledger, not only whether the API returned success. Exact JSON input and expected output are in vectors/suite.json; the digest and authorization tags are generated by tests/build_vectors.py. 98. Reference Implementations: Python, Go and JavaScript Complete standalone command-line reference engines are provided in the informative appendices (Python, Go, JavaScript, plus the Go module file), and are also supplied as separate files in the distribution bundle. The engines accept one JSON bundle containing a policy and ordered events, or suite mode containing multiple bundles; each engine produces decisions and its final local nonce/quota ledger. The appendices also include the full deterministic test- vector generator, complete test-runner, executable extraction instructions and a captured result transcript. All examples use standard libraries and require no third-party dependencies. The Das Expires 4 May 2027 [Page 237] Internet-Draft Protected Transaction Execution Finality October 2026 complete 148-vector fixture is separately available as vectors/ suite.json; all 148 cases are individually described in Section 97. All programs use a version-prefixed binary canonicalization consisting of four fixed ASCII bytes EFIN plus one version byte followed by a 32-bit big-endian UTF-8 byte length and bytes for each of eighteen fixed fields. The fixed order prevents delimiter concatenation ambiguity. The authorized digest is SHA-256 over the canonical bytes. Two HMAC-SHA-256 tags over this digest exercise authority and precommit-binding logic, but the keys are deliberately public constants; they MUST NOT be copied into a production service. The source intentionally separates the untrusted candidate from the sink-local mutable state. The Python implementation locks the sink to make the local verification-and-consumption transition atomic. Go applies a mutex to the same critical section. JavaScript processes events sequentially in one synchronous event loop. None of these properties imply distributed atomicity or resistant HSM custody. The published laboratory run processed 148 vector bundles in each of three language executables, yielding 444 passing CLI-output comparisons and zero mismatches. This is a cross-language parity result over Python-generated expectations, not 444 independent security proofs. Commands, software versions, per-decision totals, complete runnable source and SHA-256 file digests are provided in the appendices. A reviewer can regenerate the suite and rerun every comparison from the XML itself. cd execution_finality_ietf_reference python3 tests/build_vectors.py python3 tests/run_tests.py # One-request demonstration: python3 - <<'PY' | python3 reference/python/finality.py import json s=json.load(open('vectors/suite.json')) print(json.dumps(s['tests'][0]['input'])) PY # The same JSON may be piped to the Node.js or Go engine: node reference/node/finality.mjs < request.json (cd reference/go && go run .) < request.json Figure 71: Run the supplied interoperable tests For runnable extraction and test commands, see Appendix A; for the captured multi-language test evidence, see Appendix B; for the exact source file checksums, see Appendix J. Das Expires 4 May 2027 [Page 238] Internet-Draft Protected Transaction Execution Finality October 2026 99. Reference Implementation Limitations and Required Production Changes The public demo HMAC keys are not secrets, the example policy is not cryptographically delivered, and JSON is accepted from standard input. The code is deliberately incapable of demonstrating non- exportability, hardware-backed key binding, external effectuation, consensus confirmation or formal network authorization. It is a useful model for verifying deterministic decisions and test-vector parity only. Before an operational deployment, replace the public keys with threshold signing or HSM-protected keys; authenticate policies and revocation epochs; use COSE or a comparable specified signature envelope; implement strict size limits and parser hardening; derive chain- or device-specific bytes from the actual signing API; enforce exclusive control of the signer; and test alternate paths under real compromise. The educational engine records denial nonces for parsed events. A real service must authenticate nonce allocation first or an attacker may cause nonce-exhaustion denial of service. The model also lacks crash persistence and distributed state replication; production deployments need a durable journal and verified failover policy. Audit evidence should include external test reports, fuzzing statistics, proof that no protected signing call occurred for denied requests, and explicit treatment of Byzantine or failed components. A passing deterministic test suite is not a substitute for an independent audit. 100. Interoperability Test Playbook and Operator Checklist First, identify the actual point at which an operation becomes externally effective. For a signing service, this may be the first byte of a usable signature; for a connector, the privileged network send; for a device, the hardware acceptance queue. Build the authority map outward from that point, not from a familiar UI approval screen. Second, enumerate every route capable of reaching the effective point. Include direct credentials, maintenance APIs, fallback signers, preauthorized relayers, delegated code, third-party automation, asynchronous queues and cross-domain administrative access. For each route, provide either a protected finality check or an explicit exclusion from coverage. Das Expires 4 May 2027 [Page 239] Internet-Draft Protected Transaction Execution Finality October 2026 Third, execute the shared vectors, capture all decisions and final state, and then add platform-specific fault injection. Exercise timestamp rollback, failing witness, revocation midflight, policy downgrade, two-racer quota, split brain, failed external submission, already issued signatures and device reset. Verify that authorization semantics survive restarts and failovers. Finally, publish a conformance statement describing protected components, exact-effect profile fields, evidence and exclusions. The statement should say which security properties were tested and which remain assumptions. It must not advertise a universal guarantee against every unauthorized cryptocurrency transfer or physical command. 101. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, BCP 14, 2017, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", RFC 8179, BCP 79, 2017, . [RFC7991] Hoffman, P., "The xml2rfc Version 3 Vocabulary", RFC 7991, 2016, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", RFC 9052, 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, 2023, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, 2023, . Das Expires 4 May 2027 [Page 240] Internet-Draft Protected Transaction Execution Finality October 2026 [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, 2023, . [EIP7702] Buterin, V., Wilson, S., Dietrichs, A., and lightclient, "EIP-7702: Set Code for EOAs", 2024, . Appendix A. Runnable Reference Model, Scope and How to Reproduce (Informative) This appendix is self-contained source material: the full code listings, module metadata, fixture generator and CLI test runner are embedded as RFCXML sourcecode elements. To execute them, extract the embedded listings into the relative paths supplied by their name attributes, preserve UTF-8 and run the instructions below. No code is fetched from an unverified external URL. The reference model uses intentionally public demonstration HMAC keys, in-memory nonce state, and a sequential test harness. It DOES NOT secure a real private key, cryptographically authenticate a policy update, prove exclusive custody of a signing interface, or constitute an independently audited implementation. This appendix is informative and is NOT a standards-track executable conformance suite. Prerequisites for all checks: Python 3, Node.js 18 or later, and Go 1.20 or later, standard libraries only. A reviewer without all runtimes can execute a subset; the test-runner automatically omits absent runtimes and reports the reduced number of comparisons. The reported 444 result requires all three runtimes. # From the root directory containing extracted files: python3 tests/build_vectors.py python3 tests/run_tests.py # One reference input, identical for all three engines: python3 -c "import json; s=json.load(open('vectors/suite.json')); print(json.dumps(s['tests'][0]['input']))" > request.json python3 reference/python/finality.py < request.json node reference/node/finality.mjs < request.json (cd reference/go && go run .) < request.json Das Expires 4 May 2027 [Page 241] Internet-Draft Protected Transaction Execution Finality October 2026 The generator computes expected decisions using the Python model and generates the public demonstration tags; the runner additionally checks Python directly and compares the complete JSON result structure from three separate CLI programs against those expected decisions. Cross-language agreement therefore validates consistent interpretation of these specific vectors, rather than asserting that the generator is an independent security oracle. Appendix B. Captured Laboratory Test Results and Coverage (Informative) Recorded laboratory execution on 31 October 2026. Platform: Linux x86_64. Runtimes: Python: Python 3.13.5; Node.js: v22.16.0; Go: go version go1.23.2 linux/amd64. Test workload: 148 separate vector bundles, 158 individual candidate- event evaluations per implementation, and 3 CLI implementations. Assertions: complete JSON output equality for each bundle (decision code, result order, per-event quota, used nonce set, final quota and committed identifiers). $ python3 tests/build_vectors.py 148 vectors/suite.json $ python3 tests/run_tests.py Vectors: 148 Languages: python,node,go CLI checks: 444 Passed: 444 Failed: 0 Decision distribution per language run across 158 individual candidate events: ALLOW=33, DENY_AUTHENTICITY=3, DENY_BINDING=25, DENY_CONTEXT=17, DENY_DELEGATE=5, DENY_EFFECT_MISMATCH=5, DENY_MALFORMED=13, DENY_NOT_MEDIATED=2, DENY_POLICY_EPOCH=4, DENY_PRECOMMIT=2, DENY_QUOTA=1, DENY_REPLAY=2, DENY_REVOCATION=4, DENY_SCOPE=26, DENY_TIME=10, DENY_UNKNOWN_LINEAGE=6. All decisions are simulated; an ALLOW indicates a modeled protected-boundary decision, not a real blockchain transfer, a usable signature, or an external-effect receipt. Result accounting: 148 vector bundles x 3 CLI implementations = 444 bundle-level parity comparisons; no failures observed in this environment. A separate Python in-process check is performed by the runner and is not included in 444. The outcomes are repeatable under the included generator and runner; no claim is made of formal verification, field deployment or tested prevention of a specific incident. Das Expires 4 May 2027 [Page 242] Internet-Draft Protected Transaction Execution Finality October 2026 Appendix C. Python 3 Executable Reference Engine (Informative) File: reference/python/finality.py. Reproduce this listing byte-for- byte under this relative path before running the commands in Appendix A. The following code is a non-production educational implementation and contains publicly known demo keys. #!/usr/bin/env python3 """Execution-finality *educational* reference engine (NOT production custody code). Input: JSON with 'policy' and 'events'; output JSON with 'results' and 'ledger'. HMAC keys are public demonstration constants: this is a testable protocol model, NOT an operational cryptographic enforcement system. """ import hashlib import hmac import json import sys import threading from typing import Any DEMO_AUTH_KEY = b'PUBLIC-EDUCATIONAL-AUTH-KEY-DO-NOT-DEPLOY' DEMO_WITNESS_KEY = b'PUBLIC-EDUCATIONAL-WITNESS-KEY-DO-NOT-DEPLOY' FIELDS = ('id','kind','tenant','sink','domain','chain','target','amount', 'code_hash','nonce','lineage','state','now','not_before','expires', 'policy_epoch','rev_epoch','issuer') REQUIRED = FIELDS + ('observed_target','observed_amount', 'authorization_digest','authorization_mac','precommit_mac') def canonical(event: dict) -> bytes: """U32-big-endian byte length + UTF-8 bytes for every ordered string field. Noncanonical types are forbidden; numbers must be decimal integer strings. The sequence and field count are protocol fixed for version 1. """ encoded = bytearray(b'EFIN\x01') for name in FIELDS: value = event.get(name) if not isinstance(value, str): raise ValueError(f'missing or non-string field: {name}') raw = value.encode('utf-8', 'strict') if len(raw) > 65536: raise ValueError('oversized field') encoded.extend(len(raw).to_bytes(4, 'big')) encoded.extend(raw) return bytes(encoded) def digest(event: dict) -> str: Das Expires 4 May 2027 [Page 243] Internet-Draft Protected Transaction Execution Finality October 2026 return hashlib.sha256(canonical(event)).hexdigest() def tag(key: bytes, text: str) -> str: return hmac.new(key, text.encode('ascii'), hashlib.sha256).hexdigest() def authorize(event: dict) -> dict: """Fixture helper only; signing authority MUST be external in deployment.""" item = dict(event) proof = digest(item) item['authorization_digest'] = proof item['authorization_mac'] = tag(DEMO_AUTH_KEY, 'AUTH|'+proof) item['precommit_mac'] = tag(DEMO_WITNESS_KEY, 'PRECOMMIT|'+proof+'|'+item['state']) return item def integer(s: str) -> int: if not isinstance(s, str) or not s.isascii() or not s.isdecimal(): raise ValueError('expected unsigned decimal string') if len(s) > 1 and s.startswith('0'): raise ValueError('noncanonical integer') result = int(s) if result >= 2**63: raise ValueError('integer overflow') return result class Sink: def __init__(self, policy: dict): self.policy = policy self.used = set() self.quota_used = 0 self.committed = [] self.lock = threading.Lock() def process(self, e: dict) -> dict: with self.lock: # a single atomic verification-and-consumption boundary reason = self._check(e) nonce = e.get('nonce') if isinstance(e, dict) else None # Attempted well-formed nonce is consumed on rejection: fail closed. if isinstance(nonce, str) and nonce and len(nonce) <= 128: self.used.add(nonce) if reason == 'ALLOW': self.quota_used += integer(e['amount']) self.committed.append(e['id']) return {'id': e.get('id','?') if isinstance(e, dict) else '?', 'decision': reason, 'quota_used': self.quota_used} def _check(self, e: Any) -> str: p = self.policy try: Das Expires 4 May 2027 [Page 244] Internet-Draft Protected Transaction Execution Finality October 2026 if not isinstance(e, dict) or any(not isinstance(e.get(k), str) for k in REQUIRED): return 'DENY_MALFORMED' nums = {k:integer(e[k]) for k in ('amount','observed_amount', 'now','not_before','expires','policy_epoch','rev_epoch')} proof = digest(e) except (ValueError, TypeError, OverflowError): return 'DENY_MALFORMED' if e.get('mediated') is False: return 'DENY_NOT_MEDIATED' if e['lineage'] != 'VERIFIED': return 'DENY_UNKNOWN_LINEAGE' if (e['tenant'] != p['tenant'] or e['sink'] != p['sink'] or e['domain'] != p['domain'] or e['chain'] != p['chain'] or e['state'] != p['state']): return 'DENY_CONTEXT' if nums['policy_epoch'] != p['policy_epoch']: return 'DENY_POLICY_EPOCH' if nums['rev_epoch'] != p['rev_epoch']: return 'DENY_REVOCATION' if not (nums['not_before'] <= nums['now'] <= nums['expires'] and nums['expires'] - nums['not_before'] <= p['max_window']): return 'DENY_TIME' if (e['kind'] not in p['allowed_kinds'] or e['target'] not in p['targets'] or nums['amount'] > p['max_amount'] or e['issuer'] != p['issuer']): return 'DENY_SCOPE' if e['kind'] == 'delegate': if e['code_hash'] not in p['allowed_code_hashes']: return 'DENY_DELEGATE' elif e['code_hash'] != 'none': return 'DENY_DELEGATE' if not hmac.compare_digest(e['authorization_digest'], proof): return 'DENY_BINDING' if not hmac.compare_digest(e['authorization_mac'],tag(DEMO_AUTH_KEY,'AUTH|'+proof)): return 'DENY_AUTHENTICITY' if not hmac.compare_digest(e['precommit_mac'],tag(DEMO_WITNESS_KEY,'PRECOMMIT|'+proof+'|'+e['state'])): return 'DENY_PRECOMMIT' if e['nonce'] in self.used: return 'DENY_REPLAY' if self.quota_used + nums['amount'] > p['quota']: return 'DENY_QUOTA' if e['observed_target'] != e['target'] or nums['observed_amount'] != nums['amount']: return 'DENY_EFFECT_MISMATCH' return 'ALLOW' def run(bundle: dict) -> dict: sink = Sink(bundle['policy']) results = [sink.process(item) for item in bundle['events']] return {'results':results, 'ledger':{'used_nonces':sorted(sink.used), Das Expires 4 May 2027 [Page 245] Internet-Draft Protected Transaction Execution Finality October 2026 'quota_used':sink.quota_used,'committed':sink.committed}} if __name__ == '__main__': try: data = json.load(sys.stdin) print(json.dumps([run(x) for x in data['tests']] if isinstance(data.get('tests'), list) else run(data),sort_keys=True,separators=(',',':'))) except (ValueError, KeyError, TypeError) as exc: print(json.dumps({'fatal':str(exc)})) sys.exit(1) Appendix D. Go Executable Reference Engine (Informative) File: reference/go/main.go. Reproduce this listing byte-for-byte under this relative path before running the commands in Appendix A. The following code is a non-production educational implementation and contains publicly known demo keys. // Educational model only. In production use an HSM and authenticated policy store. package main import ( "crypto/hmac" "crypto/sha256" "encoding/binary" "encoding/hex" "encoding/json" "fmt" "io" "os" "sort" "strconv" "strings" "sync" ) var fields=[]string{"id","kind","tenant","sink","domain","chain","target","amount","code_hash","nonce","lineage","state","now","not_before","expires","policy_epoch","rev_epoch","issuer"} var required=append(append([]string{},fields...),"observed_target","observed_amount","authorization_digest","authorization_mac","precommit_mac") const auth="PUBLIC-EDUCATIONAL-AUTH-KEY-DO-NOT-DEPLOY" const witness="PUBLIC-EDUCATIONAL-WITNESS-KEY-DO-NOT-DEPLOY" type Event map[string]interface{} type Policy struct { Tenant string `json:"tenant"`; Sink string `json:"sink"`; Domain string `json:"domain"` Chain string `json:"chain"`; State string `json:"state"`; Issuer string `json:"issuer"` AllowedKinds []string `json:"allowed_kinds"`; Targets []string `json:"targets"` AllowedCodeHashes []string `json:"allowed_code_hashes"` MaxAmount int64 `json:"max_amount"`; Quota int64 `json:"quota"` PolicyEpoch int64 `json:"policy_epoch"`; RevEpoch int64 `json:"rev_epoch"` MaxWindow int64 `json:"max_window"` } type Bundle struct{Policy Policy `json:"policy"`; Events []Event `json:"events"`} Das Expires 4 May 2027 [Page 246] Internet-Draft Protected Transaction Execution Finality October 2026 type Result struct{ID string `json:"id"`; Decision string `json:"decision"`; QuotaUsed int64 `json:"quota_used"`} type Ledger struct{UsedNonces []string `json:"used_nonces"`; QuotaUsed int64 `json:"quota_used"`; Committed []string `json:"committed"`} type Output struct{Results []Result `json:"results"`; Ledger Ledger `json:"ledger"`} type Sink struct{mu sync.Mutex;p Policy;used map[string]bool;quota int64;committed []string} func get(e Event,k string)string{v,_:=e[k].(string);return v} func canonical(e Event)([]byte,error){ b:=[]byte{'E','F','I','N',1} for _,k:=range fields{ v,ok:=e[k].(string);if !ok{return nil,fmt.Errorf("missing %s",k)} raw:=[]byte(v);if len(raw)>65536{return nil,fmt.Errorf("oversized")} var n [4]byte;binary.BigEndian.PutUint32(n[:],uint32(len(raw))) b=append(b,n[:]...);b=append(b,raw...) } return b,nil } func digest(e Event)(string,error){b,err:=canonical(e);if err!=nil{return "",err};v:=sha256.Sum256(b);return hex.EncodeToString(v[:]),nil} func mac(key,msg string)string{h:=hmac.New(sha256.New,[]byte(key));h.Write([]byte(msg));return hex.EncodeToString(h.Sum(nil))} func eq(a,b string)bool{return hmac.Equal([]byte(a),[]byte(b))} func integer(s string)(int64,error){ if len(s)==0 ||(len(s)>1 && s[0]=='0'){return 0,fmt.Errorf("not canonical")} for _,r:=range s{if r<'0'||r>'9'{return 0,fmt.Errorf("not decimal")}} return strconv.ParseInt(s,10,64) } func includes(items []string,s string)bool{for _,x:=range items{if x==s{return true}};return false} func (s *Sink) check(e Event)string{ nums:=map[string]int64{} if e==nil{return "DENY_MALFORMED"} for _,k:=range required{if _,ok:=e[k].(string);!ok{return "DENY_MALFORMED"}} for _,k:=range []string{"amount","observed_amount","now","not_before","expires","policy_epoch","rev_epoch"}{v,err:=integer(get(e,k));if err!=nil{return "DENY_MALFORMED"};nums[k]=v} proof,err:=digest(e);if err!=nil{return "DENY_MALFORMED"} if v,ok:=e["mediated"].(bool);ok && !v{return "DENY_NOT_MEDIATED"} if get(e,"lineage")!="VERIFIED"{return "DENY_UNKNOWN_LINEAGE"} p:=s.p if get(e,"tenant")!=p.Tenant ||get(e,"sink")!=p.Sink ||get(e,"domain")!=p.Domain ||get(e,"chain")!=p.Chain ||get(e,"state")!=p.State{return "DENY_CONTEXT"} if nums["policy_epoch"]!=p.PolicyEpoch{return "DENY_POLICY_EPOCH"} if nums["rev_epoch"]!=p.RevEpoch{return "DENY_REVOCATION"} if !(nums["not_before"]<=nums["now"] && nums["now"]<=nums["expires"] && nums["expires"]-nums["not_before"]<=p.MaxWindow){return "DENY_TIME"} if !includes(p.AllowedKinds,get(e,"kind")) || !includes(p.Targets,get(e,"target")) || nums["amount"]>p.MaxAmount || get(e,"issuer")!=p.Issuer{return "DENY_SCOPE"} if get(e,"kind")=="delegate"{if !includes(p.AllowedCodeHashes,get(e,"code_hash")){return "DENY_DELEGATE"}}else if get(e,"code_hash")!="none"{return "DENY_DELEGATE"} if !eq(get(e,"authorization_digest"),proof){return "DENY_BINDING"} if !eq(get(e,"authorization_mac"),mac(auth,"AUTH|"+proof)){return "DENY_AUTHENTICITY"} if !eq(get(e,"precommit_mac"),mac(witness,"PRECOMMIT|"+proof+"|"+get(e,"state"))){return "DENY_PRECOMMIT"} if s.used[get(e,"nonce")]{return "DENY_REPLAY"} if s.quota+nums["amount"]>p.Quota{return "DENY_QUOTA"} if get(e,"observed_target")!=get(e,"target") || nums["observed_amount"]!=nums["amount"]{return "DENY_EFFECT_MISMATCH"} return "ALLOW" } func (s *Sink) process(e Event)Result{ Das Expires 4 May 2027 [Page 247] Internet-Draft Protected Transaction Execution Finality October 2026 s.mu.Lock();defer s.mu.Unlock() decision:=s.check(e);nonce:=get(e,"nonce") if len(nonce)>0&&len(nonce)<=128{s.used[nonce]=true} if decision=="ALLOW"{v,_:=integer(get(e,"amount"));s.quota+=v;s.committed=append(s.committed,get(e,"id"))} id:=get(e,"id");if id==""{id="?"} return Result{id,decision,s.quota} } func run(b Bundle)Output{ s:=&Sink{p:b.Policy,used:map[string]bool{},committed:[]string{}} results:=[]Result{};for _,e:=range b.Events{results=append(results,s.process(e))} used:=[]string{};for nonce:=range s.used{used=append(used,nonce)};sort.Strings(used) return Output{results,Ledger{used,s.quota,s.committed}} } func main(){ input,err:=io.ReadAll(os.Stdin);if err!=nil{fmt.Println(`{"fatal":"read"}`);os.Exit(1)} var wrapper struct{Tests []Bundle `json:"tests"`} if json.Unmarshal(input,&wrapper)==nil && wrapper.Tests!=nil{ outs:=[]Output{};for _,b:=range wrapper.Tests{outs=append(outs,run(b))} _=json.NewEncoder(os.Stdout).Encode(outs);return } var b Bundle;dec:=json.NewDecoder(strings.NewReader(string(input)));if err:=dec.Decode(&b);err!=nil{fmt.Println(`{"fatal":"json"}`);os.Exit(1)} out:=run(b);encoder:=json.NewEncoder(os.Stdout);_ =encoder.Encode(out) } Appendix E. Go Module Metadata (Informative) File: reference/go/go.mod. Reproduce this listing byte-for-byte under this relative path before running the commands in Appendix A. The following code is a non-production educational implementation and contains publicly known demo keys. module example.org/finality-reference go 1.20 Appendix F. JavaScript Executable Reference Engine (Informative) File: reference/node/finality.mjs. Reproduce this listing byte-for- byte under this relative path before running the commands in Appendix A. The following code is a non-production educational implementation and contains publicly known demo keys. #!/usr/bin/env node // Educational deterministic boundary model. NOT production transaction software. import {createHash, createHmac, timingSafeEqual} from 'node:crypto'; import fs from 'node:fs'; const AUTH='PUBLIC-EDUCATIONAL-AUTH-KEY-DO-NOT-DEPLOY'; const WITNESS='PUBLIC-EDUCATIONAL-WITNESS-KEY-DO-NOT-DEPLOY'; Das Expires 4 May 2027 [Page 248] Internet-Draft Protected Transaction Execution Finality October 2026 const FIELDS=['id','kind','tenant','sink','domain','chain','target','amount', 'code_hash','nonce','lineage','state','now','not_before','expires', 'policy_epoch','rev_epoch','issuer']; const REQUIRED=[...FIELDS,'observed_target','observed_amount', 'authorization_digest','authorization_mac','precommit_mac']; function canonical(e) { const chunks=[Buffer.from([69,70,73,78,1])]; for (const key of FIELDS) { if (typeof e[key] !== 'string') throw Error('non-string field'); const b=Buffer.from(e[key],'utf8'); if (b.length>65536) throw Error('oversized'); const len=Buffer.alloc(4); len.writeUInt32BE(b.length); chunks.push(len,b); } return Buffer.concat(chunks); } function digest(e){return createHash('sha256').update(canonical(e)).digest('hex');} function mac(key,s){return createHmac('sha256',key).update(s,'ascii').digest('hex');} function eq(a,b){if(typeof a !== 'string' || typeof b !== 'string')return false; const x=Buffer.from(a,'utf8'),y=Buffer.from(b,'utf8'); return x.length===y.length && timingSafeEqual(x,y);} function integer(s){ if(typeof s!=='string'|| !/^(0|[1-9][0-9]*)$/.test(s))throw Error('decimal'); const n=BigInt(s); if(n>=9223372036854775808n)throw Error('overflow'); return n; } export function run(bundle){ const p=bundle.policy,used=new Set(),committed=[]; let quota=0n; function check(e){ let n,proof; try{ if(!e || Array.isArray(e) || typeof e!=='object' || REQUIRED.some(k=>typeof e[k]!=='string'))return 'DENY_MALFORMED'; n=Object.fromEntries(['amount','observed_amount','now','not_before','expires','policy_epoch','rev_epoch'].map(k=>[k,integer(e[k])])); proof=digest(e); }catch{return 'DENY_MALFORMED';} if(e.mediated===false)return 'DENY_NOT_MEDIATED'; if(e.lineage!=='VERIFIED')return 'DENY_UNKNOWN_LINEAGE'; if(e.tenant!==p.tenant || e.sink!==p.sink || e.domain!==p.domain || e.chain!==p.chain || e.state!==p.state)return 'DENY_CONTEXT'; if(n.policy_epoch!==BigInt(p.policy_epoch))return 'DENY_POLICY_EPOCH'; if(n.rev_epoch!==BigInt(p.rev_epoch))return 'DENY_REVOCATION'; if(!(n.not_before<=n.now&&n.now<=n.expires&&(n.expires-n.not_before)<=BigInt(p.max_window)))return 'DENY_TIME'; if(!p.allowed_kinds.includes(e.kind)||!p.targets.includes(e.target)||n.amount>BigInt(p.max_amount)||e.issuer!==p.issuer)return 'DENY_SCOPE'; if(e.kind==='delegate'){ if(!p.allowed_code_hashes.includes(e.code_hash))return 'DENY_DELEGATE'; }else if(e.code_hash!=='none')return 'DENY_DELEGATE'; if(!eq(e.authorization_digest,proof))return 'DENY_BINDING'; if(!eq(e.authorization_mac,mac(AUTH,'AUTH|'+proof)))return 'DENY_AUTHENTICITY'; if(!eq(e.precommit_mac,mac(WITNESS,'PRECOMMIT|'+proof+'|'+e.state)))return 'DENY_PRECOMMIT'; Das Expires 4 May 2027 [Page 249] Internet-Draft Protected Transaction Execution Finality October 2026 if(used.has(e.nonce))return 'DENY_REPLAY'; if(quota+n.amount>BigInt(p.quota))return 'DENY_QUOTA'; if(e.observed_target!==e.target || n.observed_amount!==n.amount)return 'DENY_EFFECT_MISMATCH'; return 'ALLOW'; } const results=[]; for(const e of bundle.events){ const decision=check(e); if(e && typeof e.nonce==='string' && e.nonce.length>0 && e.nonce.length<=128)used.add(e.nonce); if(decision==='ALLOW'){quota+=integer(e.amount);committed.push(e.id);} results.push({id:e?.id??'?',decision,quota_used:Number(quota)}); } return {results,ledger:{used_nonces:[...used].sort(),quota_used:Number(quota),committed}}; } if(process.argv[1] && import.meta.url.endsWith(process.argv[1])){ try{const data=JSON.parse(fs.readFileSync(0,'utf8')); console.log(JSON.stringify(Array.isArray(data.tests)?data.tests.map(run):run(data)));} catch(e){console.log(JSON.stringify({fatal:String(e)}));process.exitCode=1;} } Appendix G. Deterministic Test-Vector Generator (Informative) File: tests/build_vectors.py. Reproduce this listing byte-for-byte under this relative path before running the commands in Appendix A. The following code is a non-production educational implementation and contains publicly known demo keys. #!/usr/bin/env python3 """Generate deterministic interoperable adversarial test vectors.""" import copy import importlib.util import json from pathlib import Path ROOT=Path(__file__).resolve().parents[1] spec=importlib.util.spec_from_file_location('finality',ROOT/'reference/python/finality.py') f=importlib.util.module_from_spec(spec);spec.loader.exec_module(f) POLICY={ 'tenant':'tenant-A','sink':'protected-signer-1','domain':'digital-asset', 'chain':'chain-17','state':'state-v1','issuer':'protected-authority', 'allowed_kinds':['transfer','delegate','export','transmit','actuate'], 'targets':['account-approved','contract-approved','device-approved'], 'allowed_code_hashes':['codehash-approved-v1'], 'max_amount':100,'quota':250,'policy_epoch':4,'rev_epoch':2,'max_window':120} BASE={ 'id':'ca-000','kind':'transfer','tenant':'tenant-A','sink':'protected-signer-1', 'domain':'digital-asset','chain':'chain-17','target':'account-approved', 'amount':'10','code_hash':'none','nonce':'n-000','lineage':'VERIFIED', 'state':'state-v1','now':'1000','not_before':'990','expires':'1050', Das Expires 4 May 2027 [Page 250] Internet-Draft Protected Transaction Execution Finality October 2026 'policy_epoch':'4','rev_epoch':'2','issuer':'protected-authority', 'observed_target':'account-approved','observed_amount':'10'} TESTS=[] def scenario(name,mutate=None, *, resign=False,policy=None,events=None): p=copy.deepcopy(POLICY) if policy: p.update(policy) if events is not None: es=events else: e=f.authorize(BASE) e['id']='ca-'+str(len(TESTS)+1).zfill(3) e['nonce']='n-'+str(len(TESTS)+1).zfill(3) # Changing id or nonce requires updated authorization. e=f.authorize(e) if mutate: mutate(e) if resign: e=f.authorize(e) es=[e] bundle={'policy':p,'events':es} expected=f.run(bundle) TESTS.append({'name':name,'input':bundle,'expected':expected}) def change(k,v):return lambda e:e.__setitem__(k,v) # Every kind and accepted boundary values for k,target,code,amount in [ ('transfer','account-approved','none','10'),('delegate','contract-approved','codehash-approved-v1','0'), ('export','account-approved','none','1'),('transmit','device-approved','none','1'), ('actuate','device-approved','none','1'),('transfer','account-approved','none','100')]: def edit(e,k=k,target=target,code=code,amount=amount): e.update(kind=k,target=target,code_hash=code,amount=amount,observed_target=target,observed_amount=amount) scenario('valid-'+k+'-'+amount,edit,resign=True) # Unauthorized intent manipulation: authorized digest must not be recomputed. for field,vals in { 'tenant':['tenant-B','TENANT-A',''], 'sink':['unprotected-signer','protected-signer-2'], 'domain':['radio','payments'], 'chain':['chain-18','0',''], 'target':['account-attacker','contract-approved',''], 'amount':['11','0','999','-1','01'], 'code_hash':['malicious-codehash'], 'lineage':['UNKNOWN','UNVERIFIED',''], 'state':['state-v2',''], 'policy_epoch':['3','5'], 'rev_epoch':['1','3'], 'issuer':['compromised-issuer'], 'kind':['unknown','delegate','transmit'], 'now':['2000','0','not-a-time'], 'not_before':['2001'], 'expires':['999','999999'], 'nonce':['predictable-replay',''], 'id':['modified-id']}.items(): for v in vals: scenario('tamper-'+field+'-'+str(v).replace(' ','_'),change(field,v)) # Properly signed but policy-inappropriate messages for field,vals in { 'tenant':['tenant-B'], 'sink':['unprotected-signer'], 'domain':['radio'], 'chain':['chain-18'], 'target':['account-attacker'], 'amount':['101','251'], 'lineage':['UNKNOWN','UNVERIFIED',''], 'state':['state-v2'], 'policy_epoch':['3','5'], 'rev_epoch':['1','3'], Das Expires 4 May 2027 [Page 251] Internet-Draft Protected Transaction Execution Finality October 2026 'issuer':['compromised-issuer'], 'kind':['unknown'], 'now':['2000','985'], 'not_before':['1001'], 'expires':['999','1500'], 'code_hash':['codehash-unapproved'], }.items(): for v in vals: def edit(e,k=field,v=v): e[k]=v if k=='kind' and v=='unknown':e['code_hash']='none' scenario('signed-policy-deny-'+field+'-'+str(v),edit,resign=True) # Signature/witness manipulation independently for field,vals in { 'authorization_digest':['0'*64,'not-a-digest'], 'authorization_mac':['0'*64,'not-a-mac'], 'precommit_mac':['0'*64,'not-a-receipt'], 'observed_target':['account-attacker',''], 'observed_amount':['11','-1','0001'], 'mediated':[False], }.items(): for v in vals:scenario('proof-or-effect-'+field+'-'+str(v)[:20],change(field,v)) # Nondelegation cannot carry an unexpected delegate code hash, even if signed scenario('unauthorized-delegate-code',lambda e:e.update(kind='delegate',target='contract-approved',code_hash='codehash-evil'),resign=True) scenario('valid-delegate',lambda e:e.update(kind='delegate',target='contract-approved',code_hash='codehash-approved-v1',amount='0',observed_amount='0'),resign=True) scenario('code-on-transfer',change('code_hash','codehash-approved-v1'),resign=True) scenario('explicit-bypass',change('mediated',False),resign=True) # Replay / denial burns / cumulative quota; these are sequential inputs. def signed_event(i,amount='10',target='account-approved'): e=dict(BASE,id=f'ca-seq-{i}',nonce=f'seq-{i}',amount=amount,observed_amount=amount,target=target,observed_target=target) return f.authorize(e) a=signed_event(1) scenario('replay-after-allow',events=[a,copy.deepcopy(a)]) b=signed_event(2);b['authorization_mac']='invalid' scenario('deny-burn-replay',events=[b,f.authorize(signed_event(2))]) scenario('concurrent-like-duplicate-nonce',events=[signed_event(3),dict(signed_event(4),nonce='seq-3')]) scenario('quota-saturation',events=[signed_event(5,'100'),signed_event(6,'100'),signed_event(7,'100'),signed_event(8,'50')]) scenario('quota-allow-exact',events=[signed_event(9,'100'),signed_event(10,'100'),signed_event(11,'50')]) c=signed_event(12);c['observed_target']='account-attacker' scenario('denial-does-not-charge-quota',events=[c,signed_event(13,'100'),signed_event(14,'100')]) # Vary IDs, Unicode and safe length-prefixed canonicalization; test both structures. for i in range(16): s='α-'+str(i)+'|"\\\u0000' scenario('unicode-target-not-allowed-'+str(i),change('target',s),resign=True) for i in range(16): scenario('unique-accepted-'+str(i),lambda e,i=i:e.update(amount=str(i+1),observed_amount=str(i+1)),resign=True) for i in range(16): scenario('modified-after-approval-'+str(i),lambda e,i=i:e.update(amount=str(i+1),observed_amount=str(i+1)),resign=False) # Direct malformed types (includes numbers supplied as numeric JSON, negative time, large overflow) for k,v in [('amount',1),('now',1000),('target',None),('nonce',None),('expires','99999999999999999999999'),('amount','-10'),('amount','00010'),('lineage',True)]: scenario('type-and-canonical-'+str(k)+'-'+str(v),change(k,v)) Das Expires 4 May 2027 [Page 252] Internet-Draft Protected Transaction Execution Finality October 2026 out=ROOT/'vectors'/'suite.json' out.write_text(json.dumps({'protocol':'EFIN-v1-demo','test_count':len(TESTS),'tests':TESTS},indent=2,ensure_ascii=False)+'\n') print(len(TESTS),out) Appendix H. Cross-Language Test Runner (Informative) File: tests/run_tests.py. Reproduce this listing byte-for-byte under this relative path before running the commands in Appendix A. The following code is a non-production educational implementation and contains publicly known demo keys. #!/usr/bin/env python3 """Execute every shared vector through Python, Go and Node.js without dependencies.""" from pathlib import Path import importlib.util,json,subprocess,sys,shutil ROOT=Path(__file__).resolve().parents[1] SUITE=json.loads((ROOT/'vectors/suite.json').read_text()) spec=importlib.util.spec_from_file_location('efin',ROOT/'reference/python/finality.py') f=importlib.util.module_from_spec(spec);spec.loader.exec_module(f) EXEC={'python':[sys.executable,str(ROOT/'reference/python/finality.py')]} if shutil.which('node'):EXEC['node']=['node',str(ROOT/'reference/node/finality.mjs')] if shutil.which('go'): result=subprocess.run(['go','build','-o',str(ROOT/'tests'/'_efin_go'),'.'],cwd=ROOT/'reference/go',capture_output=True,text=True) if result.returncode:raise RuntimeError(result.stderr) EXEC['go']=[str(ROOT/'tests'/'_efin_go')] errors=[] for item in SUITE['tests']: if f.run(item['input'])!=item['expected']:errors.append((item['name'],'python in-process')) payload=json.dumps({'tests':[x['input'] for x in SUITE['tests']]},ensure_ascii=False) for language,cmd in EXEC.items(): out=subprocess.run(cmd,input=payload,capture_output=True,text=True,encoding='utf-8') try:actual=json.loads(out.stdout) except:errors.append(('batch',language,'bad JSON',out.stderr,out.stdout[:200]));continue if out.returncode or not isinstance(actual,list) or len(actual)!=len(SUITE['tests']): errors.append(('batch',language,'failure',out.stderr));continue for item,one in zip(SUITE['tests'],actual): if one!=item['expected']:errors.append((item['name'],language,one,item['expected'])) print('Vectors:',len(SUITE['tests']),'Languages:',','.join(EXEC),'CLI checks:',len(SUITE['tests'])*len(EXEC)) print('Passed:',len(SUITE['tests'])*len(EXEC)-len(errors),'Failed:',len(errors)) for err in errors[:12]:print('FAIL',err) if errors:sys.exit(1) Das Expires 4 May 2027 [Page 253] Internet-Draft Protected Transaction Execution Finality October 2026 Appendix I. Extract Embedded Executable Listings from This RFCXML (Informative) The following short Python standard-library command reconstructs every runnable source file and the Go module directly from this Internet-Draft XML. Save the draft as draft.xml, then execute from a clean empty workspace. It also reconstructs the test generator, which creates vectors/suite.json. Only paths from the fixed allowlist are written. #!/usr/bin/env python3 # Run: python3 extract_reference.py draft.xml import pathlib, sys, xml.etree.ElementTree as ET names = { 'reference/python/finality.py', 'reference/go/main.go', 'reference/go/go.mod', 'reference/node/finality.mjs', 'tests/build_vectors.py', 'tests/run_tests.py' } root = ET.parse(sys.argv[1]).getroot() found = set() for elem in root.iter('sourcecode'): name = elem.attrib.get('name', '') if name not in names: continue target = pathlib.Path(name) target.parent.mkdir(parents=True, exist_ok=True) target.write_text(elem.text or '', encoding='utf-8') found.add(name) if found != names: sys.exit('Missing embedded listings: ' + str(sorted(names - found))) pathlib.Path('vectors').mkdir(parents=True, exist_ok=True) print('Extracted', len(found), 'runnable source files') # First save the Python extraction listing above as extract_reference.py. python3 extract_reference.py draft.xml python3 tests/build_vectors.py python3 tests/run_tests.py Appendix J. Reference Source Fingerprints and Reproducibility Boundaries (Informative) SHA-256 fingerprints of the exact UTF-8 source files embedded in this XML and of the generated full 148-vector suite are listed below. Comparing these fingerprints after extraction provides a simple integrity check; it does not authenticate the author of this document or the security of the protocol. Das Expires 4 May 2027 [Page 254] Internet-Draft Protected Transaction Execution Finality October 2026 a6d054e628115cdd8a5592818764cf7b85ab8009a4ea5ec7a62820225de2c82b reference/python/finality.py 4525c0f1c331b7a7224300f728d06002cc679ee10330e69d95ae430f4a798f0c reference/go/main.go dd58f52c9a8f50ee68adf5cad9f58817a6dfe649b66235390b3a1c8fc1466fc5 reference/go/go.mod de717ecd5375932e3f61bb744c8802664420f492727f8e980323679b958b4b53 reference/node/finality.mjs 07ed0f7653749ba487bfd145bf5b918f209b40f5d6e3019b5fdd7da6ede3cb9b tests/build_vectors.py 6120dcd88624f94d7633a36007f8a3acd50161e8e68666cdb36ae7b05a0208f7 tests/run_tests.py cc7b115a82937fdf8a4dc76af8e904bb628af4000205e22a39703b313cadc5c2 vectors/suite.json The generator will rewrite vectors/suite.json deterministically with its own expected outputs. It does not independently establish that the Python engine has correctly implemented the intended normative protocol. The described threat model requires protected credentials and an authenticated policy authority in any production system. Author's Address Sangam Kumar Das Independent Researcher Balasore Odisha India Phone: +91-9861363532 Email: info@sangamdas.com Das Expires 4 May 2027 [Page 255]