Abstract

In one line: A valid signature, token or delegated credential is not permission to perform the exact act. A protected Finality Sink reconstructs the pending operation at the last trustworthy point and allows it only if it exactly equals the approved intent.

This technical disclosure presents a transport-independent, computer-implemented execution-finality protocol for protected authorization of delegated transactions, AI-agent operations, digital-asset transfers, payment instructions, privileged API calls and other consequential digital or physical actions. It addresses transaction substitution, stale authorization, replay, policy revocation, quota exhaustion, time-of-check-to-time-of-use (TOCTOU) inconsistencies and unauthorized effectuation after otherwise valid authentication or signing, a gap exposed by publicly reported misuse of legitimately signed account-delegation and asset-transfer operations.

The system uses two logically separated protected enforcement instances and a protected Finality Sink. At authorization-collection time, the first instance binds a Candidate Act, held in a non-effective state, to the approved intent, transaction parameters, authority, policy epoch, revocation epoch and execution constraints. At execution time, the second instance independently reconstructs the actual pending operation and current execution environment, and only then issues a scoped, cryptographically protected, sink-specific, single-use, non-bearer Execution Handle.

Before signing, dispatch, transmission, asset transfer, data export, payment execution or physical actuation, the Finality Sink, under a monotonic lock, verifies issuer authenticity, sink binding, prior consumption, exact equality of the reconstructed operation with the approved intent, freshness against protected time, policy and revocation epochs, transaction limits and remaining quota. Handle consumption, quota spending and a precommit receipt are completed in one serializable transaction. A sink-local one-shot nonce is burned on every outcome, separately from blockchain account nonces or other external identifiers.

Example: an AI agent obtains approval for a payment, but an untrusted tool response substitutes the beneficiary address. The Finality Sink detects the mismatch between the approved recipient and the actual destination, burns the handle and denies execution.

Decisions follow an ALLOW / DENY / INDETERMINATE lattice. Unverifiable operations remain non-effective; unknown external outcomes are reconciled, never re-executed; authorization receipt, ledger inclusion and final settlement are distinct states with separate evidence.

Fifty-nine mechanism profiles (M-01 to M-59), each with an attack and a decisive negative test, cover payee substitution, address poisoning, wallet-drainer and approval-phishing patterns, blind signing, EIP-7702 delegation code-hash rotation, ERC-4337 account abstraction, chain-ID replay, signer impersonation, HSM raw-digest bypass, threshold/MPC and air-gapped signing, revocation races, concurrent quotas, fee and decimal bounding, credential substitution, planner and tool injection, sandbox egress, cloud mutation, service-mesh bypass, policy rollback, Unicode homoglyphs, state-root drift and post-authorization route mutation.

The validation package includes reference implementations in Python, Go and JavaScript with a deterministic generator producing 148 test vectors and 444 of 444 passing cross-language checks. These use demonstration keys only and do not constitute production custody software, payment-system certification or independent security assurance.

The technical contribution is enforcement of exact authorized effects at the last trustworthy execution boundary, independently of the cryptographic validity of any upstream signature, token, approval or delegated credential.

Related applications: PCT/IB2026/055615 (filed 4 June 2026, published as WO 2026/150382) and follow-on applications PCT/IB2026/055760, 055870, 056058, 056571, 056771, 056809, 056941, 057198, 057540 and 058236. Companion Internet-Draft: draft-das-protected-transaction-execution-finality-00.

Author: Sangam Kumar Das, Independent Researcher, Balasore, Odisha, India. Publication date: 31 October 2026. Open to acquihire, strategic collaboration, licensing or joint development: [email protected], +91-9861363532.

Protected transaction execution finality; signed is not authorized; execution-time transaction authorization; exact intent-to-effect verification; last-point authorization; Finality Sink; Candidate Act; non-effective pending state; protected enforcement domain; dual-instance authorization; execution-time reconstruction; exact-effect equality; transaction substitution detection; payee substitution; beneficiary address substitution; address poisoning; wallet drainer; approval phishing; blind signing; transaction simulation; TOCTOU resistance; single-use non-bearer Execution Handle; sink-specific cryptographic capability; nonce burn; replay protection; chain identifier replay; anti-replay; policy epoch; revocation epoch; quota enforcement; serializable authorization commit; serializable quota reservation; precommit receipt; idempotent execution; crash recovery; outcome unknown reconciliation; receipt vs inclusion vs settlement; payment settlement verification; ALLOW DENY INDETERMINATE; hardware security module; HSM signing control; HSM raw-digest bypass; threshold signature; MPC wallet; dual control; key-usage separation; air-gapped signing; digital asset custody; crypto wallet security; signer impersonation; account abstraction; EIP-7702 set-code delegation; delegation code hash; ERC-4337; Ethereum transaction authorization; blockchain transaction signing; state-root drift; fee and gas budget; withdrawal allowlist; AI agent transaction safety; AI-agent payment security; agentic payments; agentic commerce; delegated digital operations; prompt injection; planner and tool injection; tool output manipulation; sandbox egress security; human-in-the-loop approval; API authorization; open banking; strong customer authentication; OAuth 2.0 Rich Authorization Requests; DPoP; CBOR; COSE; remote attestation; RATS; Unicode confusables; homoglyph attack; service-mesh sidecar bypass; policy rollback; EU AI Act; DORA; MiCA

G06Q 20/40; G06Q 20/401; G06Q 20/405; G06Q 20/38; G06Q 20/382; G06Q 20/3825; G06Q 20/3827; H04L 9/32; H04L 9/3213; H04L 9/3228; H04L 9/40; H04L 9/50; H04L 63/10; H04L 63/12; G06F 21/53; G06F 21/57; G06F 21/62; G06F 21/64; G06N 5/04

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Share

COinS