Beyond Secure Storage, Part 1: Designing Secure Payment and Signing Workflows

Binance's preliminary account of its October 30, 2026 incident describes a stolen deployment token leading to internal signing-service access and transactions outside the normal withdrawal process [1]. On that disclosed path, the attacker could request signatures without first reading the wallet's private key.

Here, the attacker targets the system's ability to sign. Secure storage, including encryption and hardware isolation, can protect the key but cannot determine whether a payment has valid business authorization. This raises the question: how does an unauthorized operation obtain a valid signature?

Answering that question requires tracing how a business request becomes a signed and executed transaction. A payment executed through a wallet passes through business authorization, transaction construction, signing, and execution and settlement [2, 3]. The figure places abuse of that workflow alongside another route to signing capability: recovering the key through cryptographic implementation flaws.

The Beyond Secure Storage series uses real incidents to derive design and implementation principles for addressing these risks. Part 1, Designing Secure Payment and Signing Workflows, examines how attackers misuse the original system's signing capability without obtaining its private keys. Part 2, Implementing Wallet Cryptography Securely, examines implementation flaws that let attackers recover keys and sign independently. Neither path requires directly stealing the protected secret.

Section 1 uses real incidents to examine risks and overlooked assumptions along the payment workflow, then derives design and implementation checks to address them. Section 2 assumes that these checks have not prevented an unauthorized operation and examines how to limit the resulting losses. Section 3 explains how design reviews, audits, penetration tests and exercises can verify both prevention and loss containment.

1. Designing to Prevent Unauthorized Operations

The same payment workflow can serve different business purposes. The figure uses three representative custodial operations: deposits establish account entitlement, withdrawals act on customer instructions, and treasury transfers implement institutional funding decisions.

Validated deposits create account credit, not an automatic instruction to pay. A withdrawal requires a separate customer request and approval; a treasury transfer starts from an institutional funding decision. Both proceed through transaction construction, signing, execution and settlement. In pooled custody, the ledger records customer entitlements without requiring assets to remain at a dedicated address for each customer.

Three representative custodial operations. Functional separation does not itself establish independent identities or permission boundaries.

These operations have different reasons for moving funds. Other business operations may follow the same stages but require different evidence or approval. At each stage, the security question is whether the payment basis, transaction, use of signing authority and settlement still match the intended operation.

Each of these stages can become a point where an attacker influences what gets signed or executed. A forged request can create an apparent payment obligation; transaction construction can substitute an unapproved operation; compromised permissions can expose signing access; and execution or settlement failures can leave unwanted authority usable or trigger an unjustified payment.

The table below maps the risks to their workflow stages and the cases used to examine them.

Workflow Stage	Security Question	Case Used
1.1 · Payment Basis and Authorization	Is the payment backed by a genuine request, spending entitlement and valid approval?	Bitget's forged withdrawal requests [4]; BigONE's account/risk-logic compromise [5, 6]
1.2 · Transaction Construction and Verification	Does the complete payload express the approved operation?	Bybit's deceptive transfer-to-takeover path [7, 8]; Kiln/SwissBorg's altered transaction response [9, 10]
1.3 · Signing Authorization and Key Use	Who can sign, or change who is allowed to sign?	Resolv's key-policy takeover [11]; Binance's reported signing-service access [1]
1.4 · Execution and Settlement	When can signed authority execute, and what justifies the next payout?	Drift's delayed execution and Chainflip's erroneous refund [12, 13, 14]

1.1 Payment Basis and Authorization

Before a payment proceeds to transaction construction and signing, the institution must establish a genuine request, the requester’s entitlement to move the funds, and valid approval for the specified operation. A customer balance or an authenticated internal request alone does not establish all three.

Failure Cases: Fabricated Payment Basis

In Bitget's September 24, 2026 incident, the attacker exploited a third-party security product to obtain high-level internal credentials. According to Bitget's official account, those credentials were used to send fraudulent withdrawal commands to the wallet system, producing transfers that bypassed its existing risk controls [4]. The commands reached the payment process through internal access, but that access did not establish a legitimate customer instruction or treasury decision.

BigONE disclosed unauthorized hot-wallet movements on July 16, 2025 and stated that its private keys remained secure. BigONE Eurasia attributed the global platform's incident to changes in production account and risk-control logic [5, 6]. This points to a related concern: the records and rules used to justify a payment can themselves be altered. The public account does not disclose the detailed request records or signing API, so it does not establish the same attack mechanism as Bitget.

These cases expose a risk in treating internal access or account records as sufficient grounds for payment: an attacker may alter the credentials, records or rules on which that decision relies.

Controls to Verify

Design and implementation reviews should therefore check whether each request can be traced to a genuine business basis, and whether the party submitting it can also fabricate its supporting records or approve it.

Verify request provenance, integrity and authorization. Each payment must trace to a genuine customer instruction, business event or institutional decision, with evidence of spending entitlement and approval. Verify that changes to the request and its supporting records remain traceable, and that fabricated or altered evidence cannot establish authorization merely because it comes from an internal service or agrees with an account balance.
Keep validation and approval independent of request creation. The party submitting a request must not also be able to fabricate its supporting evidence or approve it. Preserve this separation in both operational and administrative permissions. Verify whether changes to records, approval rules or role assignments—including manual exceptions and recovery procedures—could let one party control the request and the checks meant to reject it.

Once the payment basis is independently established, the next question is whether the transaction expresses the approved operation.

1.2 Transaction Construction and Verification

Once a payment request is approved, the transaction builder converts it into the unsigned data submitted for signing. The complete payload—including destination, amount, operation and any change to wallet control—must express the approved request. Approval of a transfer does not authorize additional operations; verification must examine the actual data to be signed, not only its description in an interface.

Failure Cases: Signed Operations Diverge from Approval

Bybit intended to transfer ETH from a cold wallet to a warm wallet. Its official update attributes the intrusion to compromised Safe developer credentials that enabled access to the provider's infrastructure and deception of the signers [7]. Safe verifies signatures over transaction fields including to, value, data and operation through execTransaction [15]. But the compromised interface preserved the expected transfer's appearance while substituting malicious fields before signing. The signatures were valid for those substituted bytes [7].

The resulting transaction used DELEGATECALL to change the wallet's implementation, enabling the attacker to drain assets without fresh approval from the original owners [7, 8]. The approved business operation was a transfer; the signed operation changed who could control the wallet. Checking a displayed recipient or the transaction's immediate value would not have established that the full operation matched the approval.

The Kiln/SwissBorg incident shows that malicious transactions can also be introduced by modifying a running transaction-building service. Kiln reported that a compromised GitHub token led through CI workflows to production credentials. The attacker modified a running Kubernetes pod, without changing its deployed image, to return a withdrawal-authority change alongside a legitimate Solana stake-deactivation transaction. The customer's custody signers approved the added transaction; Kiln dates the signing to August 31 and detection to September 8, 2025 [9]. SwissBorg also attributed the transaction tampering to the provider's infrastructure. The parties differed over the usability and integration of the decoding tools available at the time [10].

Controls to Verify

Bybit and Kiln/SwissBorg show how a transaction can diverge from what the signer intended to approve. The design must bind approval to the complete operation, and verification must examine the actual transaction independently of the service that constructed or displayed it.

Bind approval to the complete operation. Approval must cover the transaction’s full effects, including any change to asset control or delegation of execution authority [16]. Changes outside that scope require fresh approval. Verify that substituted or added operations cannot inherit approval for a legitimate payment, and that retries cannot reuse one approval to authorize additional payments.
Independently verify the transaction and its effects. Compare the actual data submitted for signing with the approved business operation, covering every transaction in a batch and its effects on assets and permissions. Verification must be independent of the service that constructs or displays the transaction. Check whether that service can alter the verifier or bypass its checks, and whether misleading displays or modified transactions are rejected.

The checks above address whether the transaction matches the approved request. The signing stage raises another question: can someone use the key without the required business authorization, directly or by changing access permissions?

1.3 Signing Authorization and Key Use

A verified transaction must reach the signing service through an authorized caller. Key policies and administrative roles determine who can use the relevant key and who can change that access. Permission to invoke signing does not authorize every transaction, and permission to administer the service must not create an unchecked signing route. This stage therefore covers both key use for the approved operation and authority over key access.

Failure Cases: Compromised Signing Access

Resolv's March 22, 2026 incident shows how changing key-access policy can open a signing path. Its minting process required a user to deposit collateral and an authorized off-chain service to finalize issuance. The official post-mortem traces repository and cloud access to a higher-privileged role that changed the signing key's access policy after earlier access attempts were denied. That change granted the attacker signing authority in a cloud key-management service that required both identity-level permissions and a key-level access policy [11].

Changing who could sign let the attacker authorize issuance outside the intended collateral relationship without persuading the original signer. The account establishes control of signing authority, not extraction of raw private-key material.

Binance’s preliminary update on its October 30, 2026 incident describes another route to signing authority. According to Binance, compromised employee devices and an internal AI tool enabled access to wallet engineers’ devices; a stolen container-deployment token was then used to deploy a container and run malicious scripts. The attacker obtained unauthorized access to the internal wallet signing service and initiated transactions outside the normal withdrawal process [1]. This account connects deployment authority to signing-service access, but does not disclose the exact internal permission checks that were bypassed. Unlike Resolv’s reported key-policy change, the disclosed entry here is through the signing service’s operating environment.

Controls to Verify

These cases expose the risk of acquiring or using signing access outside the intended business workflow. Reviews should check whether every signing route enforces business authorization, including routes opened through policy changes or deployment privileges.

Enforce business authorization on every signing path. Permission to use a key does not establish authorization for a particular operation [17, 18, 19]. Restrict key use to the approved business scope and verify that alternative callers or direct access cannot bypass that restriction. Authorization enforcement must remain independent of a caller able to submit arbitrary signing requests. Where a path cannot enforce this requirement, record the gap and assess its consequences under Section 2.
Control changes to signing authority. Administrative and deployment permissions can create signing access even when the initial identity cannot sign [20, 21, 22]. Separate key use from the authority to change signing policies, identities or deployed code, and require independent approval of those changes. Verify that no party can use its combined permissions to grant itself signing access or remove the business checks governing that access.

Authorization checks cannot end when a signature is issued: the transaction must still execute within the approved conditions, and its result must be settled correctly.

1.4 Execution and Settlement

Authorization also needs to hold after signing, through broadcast, execution and settlement of the associated business records and balance reservations. A signature is not proof of completed payment. Execution must remain within the authorization’s scope and validity conditions; settlement must establish which obligation was fulfilled and whether a further payment is actually due. An existing signature or an observed transfer alone cannot establish a new payment obligation.

Failure Cases: Misused Signed Authority and Settlement Feedback

Drift illustrates how a misleading signing request can leave behind authority usable later. In its April 1, 2026 incident, approvals obtained in advance were preserved in Solana durable-nonce transactions and later submitted to take over administrative authority [12]. A durable nonce controls transaction validity; it is distinct from the secret nonce used in cryptographic signing. It supports offline or delayed submission without the usual recent-blockhash expiry, although changes in account or program state can still prevent execution. Advancing it invalidates transactions tied to the old value [23].

Drift's April 16 recovery update proposed dedicated signing devices, verification outside the primary signing interface, timelocks on critical administrative actions, and disabling durable nonces for signers [24]. These measures address both what signers approve and when the signed operation can execute. They were announced as a recovery plan; the update does not establish that they had been deployed.

Chainflip distinguishes customer swaps, liquidity-provider (LP) withdrawals, and internal deposit-collection operations called fetches [25]. On Tron, transaction memos can carry swap instructions. In Chainflip's September 15 account of its September 12, 2026 incident, an attacker submitted a validator-signed fetch with an attacker-controlled malformed memo. The witnessing layer misread the context as a failed swap and issued refunds in addition to normal LP withdrawals, causing six withdrawals to be paid twice [13, 14].

The error turned an internal asset movement into evidence of a new customer obligation. Chainflip had interpreted memos even when transfers into its vault were wrapped inside other contract calls. Its fix restricted swap-memo interpretation to plain TRX or direct TRC-20 transfers, excluding wrapped calls [14]. A validly signed fetch had its own purpose; its execution did not justify an additional refund.

Controls to Verify

Signed transactions can remain executable longer than expected, and execution feedback can be mistaken for a new payment obligation. Reviews should therefore check that execution conditions are actually enforced and that each payout or refund corresponds to a genuine, unsettled obligation.

Enforce the approved conditions for execution. Signed transactions must remain subject to the approved scope, validity period and cancellation conditions. Verify whether old transactions can still execute after expiry, cancellation or a change in authorization. Bind the relevant conditions to the signed operation and verify that chain rules or wallet execution logic enforce them; a business-system record alone is insufficient.
Settle only genuine, outstanding obligations. Each payout or refund must correspond to a real obligation that has not already been settled. Preserve the connection between the original business event, payment attempts and confirmed results. Verify that retries, duplicate notifications, uncertain outcomes or internal transfers cannot create an unjustified payment, and that the rules interpreting execution evidence cannot be altered to bypass these checks.

2. Designing to Limit Losses and Enable Incident Response

Section 1 used incident evidence to identify workflow risks and the design and implementation checks needed to address them. Here, we assume that those checks have failed to prevent an unauthorized operation, whether through an omission, an implementation error or a bypass. The design must then limit how much the attacker can move, account for funds that remain exposed, and preserve the ability to detect abuse and stop further outflows. These loss-containment measures must be designed and tested before an incident, alongside the preventive controls.

The table summarizes three design objectives for limiting losses and enabling incident response.

Design Objective	Security Question	Verification Focus
2.1 · Independently Enforced Spending Limits	Can the system cap cumulative outflows when unauthorized payments occur?	Independent enforcement; consistent cumulative accounting; protection against changing or bypassing limits
2.2 · Inventory, Refills and Outstanding Signed Transactions	How much could be lost before the attack is contained?	Accessible balances and later inflows; refill constraints; funds exposed to outstanding signed authority
2.3 · Independent Monitoring and Incident Response	Can the system detect unauthorized operations and stop further outflows?	Trustworthy evidence; actionable alerts; effective and independently available response controls

2.1 Independently Enforced Spending Limits

Even if an unauthorized payment passes the earlier checks, the system should cap how much it and subsequent payments can move. This requires a budget enforced outside the attacker's assumed control, covering both individual transactions and cumulative spending. A configured limit provides no such bound if the compromised approval service or signer can disable or bypass it.

Enforce limits independently of payment approval. A payment that passes authorization checks must still be subject to spending limits enforced outside the attacker's assumed control. Verify that every signing and execution route respects these limits, including alternative execution routes [26, 27], and that the attacker cannot change or disable their enforcement. Where no independent limit can be enforced, do not present a configured budget as a bound on losses.
Limit cumulative spending, not just individual payments. Define the scope, period and valuation basis of each budget, with consistent accounting for completed payments and reserved amounts. Verify that repeated requests, concurrency and retries cannot collectively exceed it or prematurely release reservations. Where limits depend on asset prices, verify that manipulated, stale or unavailable prices cannot inflate the permitted spending.

2.2 Inventory, Refills and Outstanding Signed Transactions

The next question is which funds remain at risk while the institution detects and contains the attack. Wallet balances, refills and outstanding signed authority determine that exposure, including funds that arrive after the incident begins. Assess them together with the enforceable limits in Section 2.1; a current balance alone is not a loss estimate.

Limit the funds an attacker could access. Assess the full asset reach of the affected signing authority, including other wallets, chains and contracts. Include existing balances and subsequent inflows. Replenishment must have independent authorization and a cumulative limit. Verify that repeated outflows cannot trigger continuing refills from treasury, and that new funding can be redirected or stopped without overlooking deposits that still arrive.
Include funds exposed to outstanding signed authority. Stopping new signing does not necessarily invalidate transactions or authorizations already issued. Identify the funds they can still move without counting the same assets twice. Verify that confirmed payments are recorded as spent and their reservations reconciled, while unexecuted transactions retain reservations until reliable evidence establishes they can no longer execute. A local timeout or cancellation request alone must not reduce the recorded exposure.

2.3 Independent Monitoring and Incident Response

Limits and funding controls constrain potential losses; monitoring and response determine how long an attacker can continue operating. The institution needs evidence that reveals abuse even when the payment service treats the operations as valid, and a response path that remains usable if the normal operating environment is unavailable or compromised.

Binance's preliminary account shows why an application shutdown alone may not achieve that: shutting it down did not clear an existing EIP-7702 delegation. Revocation required on-chain transactions and, in its MPC deployment, a separately designed procedure [1]. This was a constraint of that deployment, not an inherent inability of MPC to revoke authority. Detection and containment therefore need separate validation: reliable evidence must lead to an action that actually interrupts the loss path.

Detect unauthorized activity using independently protected evidence. Compare business approvals with signing activity and execution results, and monitor changes to permissions and control rules. The affected service must not be able to rewrite the evidence on which monitoring relies. Verify that operations accepted by the workflow can still trigger actionable alerts when inconsistent with business authorization, even if local records are missing or manipulated.
Keep response controls available and effective. Maintain independent authority to stop new signing and funding, and invalidate outstanding transactions or revoke continuing authority where supported. Verify that response remains possible when ordinary operating access is unavailable or compromised, and that the actions actually block further outflows. Identify residual exposure and external coordination needs; stopping an application does not itself revoke signed authority, and asset recovery cannot be assumed.

3. Validating the Design and Implementation

The preceding sections ask whether workflow checks prevent unauthorized operations and whether losses can be limited when they do not. Validation must examine both goals in the deployed system, including how controls interact across the funds flow. The following methods provide complementary evidence:

Architecture and security-design assessment checks whether the funds flow, authority boundaries and control dependencies support the intended prevention and loss-containment goals. It should make the assumptions behind independence and loss limits explicit.
Code and configuration audit verifies that deployed code, configuration and permissions implement the intended checks, including exceptions and alternative paths that could bypass them.
Penetration testing examines whether weaknesses across applications and infrastructure can be combined to bypass authorization or loss controls. Its scope should follow complete funds paths, not stop at individual components.
Attack-and-response exercises verify that monitoring leads to timely action and that spending limits, pauses and revocation work together. They should establish what funds remain at risk and how long effective containment takes.

For each validation scenario, specify the operation that should be rejected or the loss that should be contained, together with the assumed attacker capabilities. Record the observed outcome, any remaining exposure and the conditions behind a claimed loss limit. Repeat relevant checks after material changes to code, configuration or permissions.

Third-party security teams or experts can complement internal teams across these assessments, audits, tests and exercises. Their review should cover how payment logic, signing infrastructure and operational permissions interact, and provide evidence for the system's preventive and loss-containment capabilities.

4. Conclusion

The attacks examined here expose authorization failures from the initial payment request through transaction construction, signing, execution and settlement. They also show what a system needs to limit losses once an attacker gets through. The resulting design principles cover prevention, containment and the tests needed to assess both in practice.

The central conclusion is that protecting private keys does not, by itself, ensure that signed operations are authorized. The operation actually executed must match a genuine business decision, and independent controls must limit the consequences when workflow checks fail to prevent an unauthorized operation. This requires reviewing the full workflow, including the permissions that can change its checks and the tools needed to detect and stop further losses.

This analysis focused on misuse of the original system's signing capability. Part 2, Implementing Wallet Cryptography Securely, turns to a different route: implementation flaws that let attackers predict or recover private keys without directly stealing the protected secrets, and then sign outside the original workflow.