The $6.36 Billion Semantic Decoupling: An Autopsy of the Binance Incident, EIP-7702 Mutations, and the Fallacy of the Blind Signer

<h1>The $6.36 Billion Semantic Decoupling: An Autopsy of the Binance Incident, EIP-7702 Mutations, and the Fallacy of the Blind Signer</h1>

Author: Engineering Lead & Blockchain/Cloud Security Architect

Platform Context: Asset Tokenization & Permissioned Custody Systems (AltDRX)

Date: October 31, 2026

<hr>

<h2>Executive Summary</h2>

On October 29, 2026, the digital asset ecosystem witnessed the largest security failure in financial history: the systematic draining of ~$6.36 billion across 10 blockchains from Binance’s core hot wallet infrastructure.

Within hours, mainstream commentary defaulted to familiar, lazy tropes: "crypto was hacked," "elliptic curve cryptography failed," or "there was a zero-day in Ethereum."

None of these statements are true.

The elliptic curves ($secp256k1$) did not falter. Not a single mathematical invariant of the Ethereum Virtual Machine was violated. Every node in the network executed its state transition functions with flawless, deterministic precision.

What occurred was an architectural and philosophical catastrophe: a total Semantic Decoupling of Intent vs. Cryptographic Signing Authorization.

The adversary (attributed by TRM and Chainalysis to North Korea’s TraderTraitor/Lazarus) did not crack the vault’s steel doors. Instead, they compromised the internal nervous system that orders the door to open, exploited the freshly minted EIP-7702 delegation primitives introduced in Ethereum’s Pectra upgrade, and transformed Binance’s primary hot wallet into an autonomous, self-draining proxy in a single atomic transaction.

As architects building asset tokenization systems—where on-chain permissions, institutional custody, and real-world asset (RWA) state transitions converge—we cannot treat this as an isolated exchange incident. It is a terrifying masterclass in systemic failure.

Here is the exhaustive, technical post-mortem, mathematical state-transition model, systemic failure modes, and first-principles remedies for high-assurance infrastructure.

<hr>

<pre>

THE ANATOMY OF SEMANTIC DECOUPLING

[ REALITY / INTENT ] [ SIGNING ENGINE (HSM/KMS) ]

• Customer wants to withdraw $500 "Payload arrives: Type 4 (EIP-7702)"

• Threat actor breaches worker pod "Is syntax valid? YES."

• Attacker swaps payload to: "Is API token present? YES."

Mutate EOA Code -> Malicious Proxy "Action: SIGN BLINDLY."

│ │

└─────────────────────┬──────────────────────┘

│

▼

[ THE CHINESE ROOM TRAP ]

The signer manipulates symbols without

understanding the semantic catastrophe

it is executing.

</pre>

<hr>

<h2>1. The Epistemic Error: Cryptography Is Not Authorization</h2>

In 1980, the philosopher John Searle proposed the famous Chinese Room Argument to challenge the idea of artificial understanding.

Imagine an English speaker locked in a room with a massive rulebook. Slips of paper with Chinese characters are slid under the door. The person matches the shapes using the rulebook and slides back the corresponding Chinese characters. To an external observer, the room "speaks Chinese." In reality, the room understands nothing. It is merely executing syntactic symbol manipulation completely divorced from semantics.

</blockquote>

Modern cryptographic key management systems (KMS, HSMs, MPC clusters) in Web3 are Chinese Rooms.

We have spent twenty years optimizing the mathematical security of the room:

<ul>

<li>We put keys inside FIPS 140-2 Level 3 hardware security modules.</li>

<li>We split keys across distributed Multi-Party Computation ($t$-of-$n$ threshold) clusters.</li>

<li>We generate zero-knowledge proofs of execution.</li>

</ul>

Yet, we commit a foundational epistemic mistake: we confuse the integrity of the pen with the wisdom of the signature.

The signing service at Binance was treated as an Execution Oracle rather than a State-Aware Policy Enforcer. It asked only:

<ol>

<li>Did this request come over an authenticated mTLS session?</li>

<li>Is the payload correctly serialized for the targeted blockchain?</li>

</ol>

It never asked:

<ul>

<li>What does this transaction mean?</li>

<li>What is the invariant state of this account before and after execution?</li>

<li>Why is an exchange withdrawal hot wallet signing an operational bytecode mutation delegating its identity to an unverified contract deployed 4 hours ago via Tornado Cash?</li>

</ul>

In the vocabulary of cybernetics, this violates W. Ross Ashby’s Law of Requisite Variety:

"Only variety can destroy variety."

</blockquote>

If an attacker has an infinite variety of states they can inject into a system (arbitrary bytecode, arbitrary contract delegations, arbitrary multi-chain parameters), but your defensive policy engine has only binary variety (sign or reject based on API key), the system cannot maintain control.

The signer was intellectually blind. And in complex systems, blindness combined with absolute cryptographic authority is guaranteed suicide.

<hr>

<h2>2. Step-by-Step Technical Execution & State Changes</h2>

Let us dissect the precise forensic timeline and state mechanics of the attack.

<pre>

+---------------------------------------------------------------------------------------------------------+

| THE KILL-CHAIN TOPOLOGY |

+---------------------------------------------------------------------------------------------------------+

| |

| [PHASE A: CLOUD INGRESS] |

| DevOps Endpoint ──(Phish/Trojan)──> Stolen Session ──> Kube API ──> Compromised Worker Pod |

| |

| [PHASE B: ORCHESTRATION HIJACK] |

| Compromised Pod ──(Internal gRPC)──> KMS / HSM Signer ──(Blind Signs)──> 50x EIP-7702 Auth Tuples |

| |

| [PHASE C: ATOMIC EXECUTION] |

| Batch Transaction (Auth Tuple Match) ──> Binance 14 Mutates to Attacker Proxy |

| |

| [PHASE D: CASCADE & SWEEP] |

| Single-Call Sweep ──> 167k ETH + $1.61B USDT + $823M USDC Vault ──> Drained to Tornado/Cross-Chain |

| |

+---------------------------------------------------------------------------------------------------------+

</pre>

<h3>Phase A: Ingress & Lateral Movement (Off-Chain Boundary Collapse)</h3>

<ol>

<li>Endpoint Infiltration: The initial vector was neither blockchain-native nor cloud-native. It was human. A DevOps engineer with cluster administrative credentials was compromised via a weaponized NPM dependency in a local development toolchain.</li>

<li>Pivoting to the Control Plane: Stolen short-lived session tokens and an active internal VPN bridge allowed the adversary to authenticate against Binance’s production Kubernetes cluster.</li>

<li>Container Ingress: The attacker bypassed network policies and deployed an interactive shell inside a container residing within the Withdrawal Orchestration Subnet.</li>

<li>Internal RPC Discovery: The compromised pod had direct internal network access (via private DNS and service discovery) to the internal gRPC daemon interfacing with the exchange's signing engine (a hybrid cloud KMS / MPC network).</li>

</ol>

At this stage, the adversary did not need to steal private keys. Possessing the key is irrelevant when you possess the entity permitted to command the key.

<h3>Phase B: Weaponizing EIP-7702 & Overcoming the Nonce Horizon</h3>

To understand why this was devastating, one must understand EIP-7702, introduced into the Ethereum Virtual Machine during the Pectra hard fork.

<h4>What EIP-7702 Actually Does</h4>

Prior to EIP-7702, an Externally Owned Account (EOA) could never possess code. It could only initiate transactions. Smart contract wallets required migrating assets to new contract addresses.

EIP-7702 introduced a new transaction type (Type 4, <code>0x04</code>) that allows an EOA to sign an authorization tuple:

$$\text{Auth} = (\text{chain\_id}, \text{address}, \text{nonce}, y\_parity, r, s)$$

When this authorization is included in a transaction, the EVM temporarily (or persistently, depending on client implementation flags) sets the code of the signing EOA to point to <code>address</code> (the delegated smart contract). The EOA’s address remains unchanged, but its execution context is rewritten.

<h4>The Race Condition Barrier</h4>

The attacker faced a severe technical challenge:

<code>Binance 14</code> is one of the highest-throughput hot wallets in existence. It processes dozens of customer withdrawals every minute. Every withdrawal increments the account’s transaction counter:

$$\text{Nonce}_{t+1} = \text{Nonce}_t + 1$$

Under EIP-7702, an authorization tuple is valid if and only if the <code>nonce</code> in the signed tuple matches the exact active on-chain nonce of the EOA at the moment of execution.

If the attacker generated an authorization for nonce $N$, but legitimate customer withdrawals pushed the state to $N+1$ before the attacker’s transaction was mined, the authorization would revert.

<h4>The Pre-Computation Attack Vector</h4>

The attacker resolved this dynamic race condition with algorithmic precision:

<ol>

<li>Pre-Deploying the Malicious Sweeper: At 15:59 UTC, the attacker deployed contract <code>0x63e8...6fae</code>. The contract was minimal, ruthless, and tightly controlled:

<ul>

<li>Protected by an immutable <code>onlyOwner</code> modifier tied strictly to the attacker’s external address.</li>

<li>Contained an execution harness designed to execute within the context of the calling address via <code>DELEGATECALL</code>.</li>

<li>Included automated loops to iterate over an array of ERC-20 token addresses, query <code>balanceOf(address(this))</code>, and execute <code>transfer(attacker, balance)</code>.</li>

</ul>

</li>

<li>The Nonce Horizon Sweep: The attacker used their compromised access to the internal withdrawal pipeline to flood the signing engine with requests. Instead of asking for a single signature, they forced the signer to generate 50 distinct EIP-7702 authorization payloads covering an incremental range of sequential nonces: $$\text{Range} = [N_{\text{current}}, N_{\text{current}} + 50ujukan]$$ Because the signing engine lacked transaction-type awareness, it treated these payloads as routine cryptographic operations and signed all 50.</li>

<li>Atomic Execution: At <code>20:20:59 UTC</code>, the attacker submitted a Type-4 transaction to the public Ethereum mempool via private RPC (bypassing public frontrunning). The transaction bundled the array of 50 pre-signed authorizations. As the block was produced, the EVM evaluated the array sequentially. 49 authorizations failed the nonce check; exactly one matched the active state nonce. In that millisecond, the identity of <code>Binance 14</code> was hijacked.</li>

</ol>

<h3>Phase C: State Mutation & The Atomic Sweeping Cascade</h3>

<pre>

+------------------------------------------------------------------------------------+

| THE EIP-7702 STATE MUTATION |

+------------------------------------------------------------------------------------+

| |

| PRE-ATTACK STATE (Block 23,456,788): |

| Address: 0x28C6c06298d514Db089934071355E5743bf21d60 ("Binance 14") |

| CodeHash: 0xc5d246... (EMPTY_CODE) |

| Storage: None |

| |

| ⬇ |

| EIP-7702 AUTHORIZATION APPLIED |

| ⬇ |

| |

| POST-ATTACK STATE (Block 23,456,789): |

| Address: 0x28C6c06298d514Db089934071355E5743bf21d60 ("Binance 14") |

| Code: DELEGATED -> Points to Attacker Contract (0x63e8...6fae) |

| Context: Any call to Binance 14 now executes 0x63e8 logic under Binance's identity|

| Modifier: msg.sender == AttackerOnly |

| |

+------------------------------------------------------------------------------------+

</pre>

<h4>1. The Single-Call Atomic Drain</h4>

At <code>20:24:23 UTC</code>, the attacker called <code>Binance 14</code> directly.

Under normal EVM mechanics, calling an EOA does nothing except transfer ETH. But <code>Binance 14</code> was no longer an EOA. It was a proxy executing the attacker’s sweeper contract.

Because the code ran in the context of <code>Binance 14</code>:

<ul>

<li><code>address(this)</code> resolved to <code>0x28C6...21d60</code> (Binance 14).</li>

<li>The contract executed internal calls to the USDT, DAI, and WBTC contracts.</li>

<li>In a single block, 167,464 ETH and 63 ERC-20 tokens (including $1.615 billion in USDT) were transferred directly to the attacker’s cold addresses.</li>

</ul>

<h4>2. The Privilege Inheritance Cascade (The Vault Drain)</h4>

The disaster did not stop with tokens directly held in the wallet.

<code>Binance 14</code> was also registered in on-chain smart contracts as the Authorized Admin / Guardian for a secondary institutional Circle USDC liquidity vault holding $823 million.

Because the EIP-7702 code mutation remained attached to <code>Binance 14</code>, the attacker used the wallet’s delegated identity to call the vault’s administrative contract, invoking <code>emergencyWithdraw(attacker_address)</code>. The vault contract inspected <code>msg.sender</code>, verified it was <code>Binance 14</code>, and released the entire $823 million balance.

<h4>3. The Continuous Re-Sweeping Loop</h4>

Unlike standard private-key theft where a wallet is drained once and abandoned, an EIP-7702 delegation persists on the account identity until overwritten by another valid signature from the EOA.

Binance’s automated backend infrastructure—unaware that the core identity had been mutated—continued to execute scheduled internal deposit sweeps from user sub-wallets into <code>Binance 14</code>.

Every time hundreds of thousands of dollars flowed in from retail users, the attacker called the sweeper again. Additional sweeps executed at <code>20:41</code>, <code>20:59</code>, <code>21:04</code>, <code>21:44</code>, <code>22:39</code>, and <code>23:56 UTC</code>, siphoning millions more before Binance’s engineers halted all node daemons.

<h4>4. The Multi-Chain Parallel Sweep</h4>

Simultaneously, the attacker’s automated scripts exploited the compromised internal withdrawal service to dispatch valid withdrawal calls across 9 other chains:

<ul>

<li>Bitcoin: Drained 18,270 BTC via high-fee native segwit transfers.</li>

<li>Solana: Drained 970,000 SOL via parallel SPL token instructions.</li>

<li>XRP Ledger: Siphoned 233,000,000 XRP.</li>

<li>L2s / EVM Chains (Arbitrum, Optimism, Base, Avalanche, Polygon, Tron): Drained multi-hundred-million-dollar balances of native gas tokens and bridged assets.</li>

</ul>

Total estimated damages: $6.36 Billion.

<hr>

<h2>3. The Systemic Vulnerability Matrix: How Did We Get Here?</h2>

<pre>

+-----------------------------------------------------------------------------------------------------+

| THE SWISS CHEESE FAILURE MODEL |

+-----------------------------------------------------------------------------------------------------+

| |

| [Layer 1: Signing Engine] FAILED: Signed Type-4 transactions without schema or semantic checks |

| │ |

| ▼ |

| [Layer 2: Policy Engine] FAILED: Zero volume-rate circuit breakers across sliding time-windows |

| │ |

| ▼ |

| [Layer 3: Network Topology] FAILED: Microservices enjoyed flat, lateral trust to the signer |

| │ |

| ▼ |

| [Layer 4: Custody Primitives]FAILED: Relied on naked EOAs with unconstrained delegatecall surface |

| │ |

| ▼ |

| [ $6.36B CATASTROPHE ] |

| |

+-----------------------------------------------------------------------------------------------------+

</pre>

To engineer a solution, we must categorize each catastrophic failure across the stack:

<table>

<thead>

<tr>

<th>Architectural Layer</th>

<th>The Failure Mechanism</th>

<th>Root Cause / Systemic Flaw</th>

<th>First-Principles Remedy</th>

</tr>

</thead>

<tbody>

<tr>

<td>Hardware / Signing Layer (HSM/KMS)</td>

<td>Blind Transaction-Type Signing: The signer signed EIP-7702 authorization payloads (<code>0x04</code>) without inspecting transaction type.</td>

<td>The HSM was treated as a mathematical black box rather than a state-validating firewall.</td>

<td>Strict Transaction-Type Whitelisting: Hardware signers must reject all <code>0x04</code> payloads for operational custody keys at firmware level.</td>

</tr>

<tr>

<td>Policy & Orchestration Engine</td>

<td>Absence of Invariant Rate-Limiting: The system permitted billions in outflow within minutes across 10 networks.</td>

<td>Policy engines validated requests individually (stateless) rather than globally across time (stateful).</td>

<td>Sliding-Window Volume Invariants: Hard caps on USD velocity ($XM per 10-minute epoch) backed by multi-party time-locks.</td>

</tr>

<tr>

<td>Cloud Infrastructure (K8s/ECS)</td>

<td>Lateral Network Trust: A compromised container could issue arbitrary gRPC signing requests to internal signers.</td>

<td>Incomplete zero-trust microsegmentation; ambient authorization within internal VPC boundaries.</td>

<td>Hardware Attestation (Nitro/TPM): Ephemeral mTLS bound to verifiable cryptographic enclaves; zero static internal trust.</td>

</tr>

<tr>

<td>Smart Contract / Account Architecture</td>

<td>Naked EOAs as Master Hot Wallets: Using an EOA for multi-billion dollar custody allowed identity delegation mutations.</td>

<td>Technical debt and reluctance to adopt modern smart contract account abstraction due to gas costs.</td>

<td>ERC-4337 Smart Accounts / Canonical Multi-Sigs: Strict plugin execution filters; absolute prohibition of unverified delegate calls.</td>

</tr>

</tbody>

</table>

<hr>

<h2>4. Potential Similar Loopholes in Modern Web3 & Cloud Systems</h2>

The Binance hack was the first multi-billion-dollar weaponization of EIP-7702, but the vulnerability pattern is endemic across Web3. If your engineering team relies on any of the following architectures, you are exposed to identical failure modes:

<h3>Loophole 1: ERC-4337 Paymaster & UserOp Validation Deception</h3>

In Account Abstraction (ERC-4337), bundlers and paymasters validate <code>UserOperations</code> before submitting them on-chain.

<ul>

<li>The Vulnerability: Many protocols allow backend signers to blindly sign <code>paymasterAndData</code> or validate arbitrary <code>callData</code> arrays. If an attacker breaches the backend worker, they can craft malicious <code>UserOps</code> that drain paymaster gas deposits or use the smart account's execution module to sweep protocol vaults.</li>

<li>The Vector: Blind signing of ERC-712 structured data that disguises privileged administrative calls inside complex nested structs.</li>

</ul>

<h3>Loophole 2: MPC Pre-Computation Cache Poisoning</h3>

High-speed trading firms and exchanges use Multi-Party Computation (MPC) with pre-computed signature shares to achieve sub-millisecond signing speeds.

<ul>

<li>The Vulnerability: Pre-generation protocols generate cryptographic nonces ($R$ values) in advance. If an internal adversary can manipulate the task assignment queue feeding the pre-signature engine, they can force the cluster to bind pre-generated nonce shares to unauthorized transaction hashes, bypassing real-time consensus.</li>

</ul>

<h3>Loophole 3: Cross-Chain Bridge Relayer Blind Verification</h3>

Cross-chain protocols (bridges, intent networks, oracle networks) rely on off-chain "relayers" or "watchers" to sign state updates on destination chains.

<ul>

<li>The Vulnerability: Relayer daemons often monitor source-chain RPC endpoints directly. If an attacker compromises the RPC node (or carries out an eclipse/reorg attack), the relayer blindly ingests the spoofed event log, passes it to the HSM, and signs a multi-million dollar asset release on the destination chain.</li>

</ul>

<hr>

<h2>5. The Architectural Manifesto for Asset Tokenization (The AltDRX Invariant Model)</h2>

When building an Asset Tokenization Platform (AltDRX), we do not have the luxury of treating security as a reactive monitoring layer.

In tokenization, on-chain tokens represent real-world assets: commercial real estate, private credit, fractional infrastructure, debt instruments. A corrupted state transition does not just lose digital tokens; it creates an unresolvable collision between on-chain registry truth and legal real-world title.

Here is the architectural manifesto we enforce from first principles:

<pre>

+----------------------------------------------------------------------------------------------------+

| THE VERIFYING STATE MACHINE SIGNER PATTERN |

+----------------------------------------------------------------------------------------------------+

| |

| [ Business Event: "Distribute Yield" ] |

| │ |

| ▼ |

| [ Backend Microservice A ] ──(Intent Token A)──┐ |

| ├──> [ Enclave Boundary: AWS Nitro / Confidential] |

| [ Compliance Engine B ] ──(Intent Token B)──┘ │ |

| ▼ |

| [ 1. Decode Full ABI & AST ] |

| [ 2. Assert Tx Type != 0x04 ] |

| [ 3. Assert Callee ∈ Whitelist] |

| [ 4. Query Real-Time RWA Ledger] |

| [ 5. Check Global Velocity Limit] |

| │ |

| ▼ (All Invariants Pass) |

| [ Sign Hash via Private Key ] |

| |

+----------------------------------------------------------------------------------------------------+

</pre>

<h3>Principle 1: Cryptographic Separation of Duties (Intent $\neq$ Signing)</h3>

<ul>

<li>The Anti-Pattern: A backend microservice receives a trigger, serializes a raw transaction, and dispatches a request to the signer saying: <code>"Sign this hash: 0x8f4c..."</code></li>

<li>The Architecture: The signer must be a Verifying State Machine, never a raw signing worker.

<ol>

<li>The signer must reside inside a Confidential Computing Enclave (e.g., AWS Nitro Enclave, GCP Confidential Space).</li>

<li>The enclave receives the un-serialized business intent, along with cryptographic proofs from two independent services (e.g., the Application Worker and an independent Compliance/Risk Engine).</li>

<li>The enclave independently compiles the transaction from source ABI, validates that all parameters adhere to the platform's immutable registry whitelist, asserts that no EIP-7702 delegation flags exist, and signs only if the internal invariant checks evaluate to <code>true</code>.</li>

</ol>

</li>

</ul>

<h3>Principle 2: Complete Prohibition of Master EOAs</h3>

Naked EOAs must never hold administrative authority, custody, or mint/burn permissions over tokenized assets.

All custody and operational roles must belong to ERC-4337 Smart Accounts or canonical Safe Multi-Sigs.

<ul>

<li>In on-chain token contracts and compliance registries, implement explicit guards against delegated EOAs:</li>

</ul>

<pre>

// SPDX-License-Identifier: MIT

pragma solidity 0.8.28;

abstract contract InvariantSecured {

/// @notice Prevents execution from hijacked EOAs via EIP-7702 delegation

modifier nonDelegatedCaller() {

// Under EIP-7702, a delegated EOA has code at its address

// Administrative accounts in our platform must be strictly registered contracts

// or un-delegated, multi-signature identities verified at deployment.

address sender = msg.sender;

uint256 codeSize;

assembly {

codeSize := extcodesize(sender)

}

// If the platform design requires an EOA, assert codeSize == 0

// If it requires a smart account, verify against the Canonical Factory Registry

require(isValidCaller(sender, codeSize), "Security: Invalid Caller Code Topology");

}

function isValidCaller(address caller, uint256 size) internal view virtual returns (bool);

}

</pre>

<h3>Principle 3: Thermodynamic Delays (Why Instant Settlement is an Anti-Pattern for High-Value Assets)</h3>

In consumer payments, latency is the enemy. In multi-million dollar asset tokenization, instantaneous finality without recourse is an existential liability.

In classical thermodynamics, rapid state transitions generate destructive shockwaves. High-stakes financial systems require damping factors.

<ul>

<li>The Invariant: No single state transition should ever be permitted to transfer more than $5\%$ of a tokenized vault's market value in a single block.</li>

<li>Optimistic Settlement Windows: Large transfers must enter a Settlement Challenge Window (e.g., a 15–30 minute optimistic queue).</li>

<li>If an anomalous transfer is initiated, automated monitoring nodes (watchtowers running outside the platform's cloud boundary) can trigger a cryptographic pause before the assets are irreversibly bridged or liquidated.</li>

</ul>

<h3>Principle 4: The Off-Chain / On-Chain Parity Invariant</h3>

In asset tokenization, on-chain tokens are mere mirrors of physical and legal assets (title deeds, bank accounts, SPVs).

<ul>

<li>The Invariant:</li>

</ul>

$$\sum \text{On-Chain Tokens} \equiv \text{Verified Off-Chain Asset Balance}$$

Implement an Automated Circuit Breaker Protocol (Chainlink Proof of Reserve / Custom Attestation Enclaves): If the mint/transfer velocity threatens the equivalence invariant, the token contract automatically enters a <code>READ_ONLY_SAFE_MODE</code>.

<hr>

<h2>6. Concluding Thoughts: Beyond the Illusion of Control</h2>

The $6.36 billion Binance hack will be studied for decades. But the industry must learn the right lesson.

The lesson is not that EIP-7702 is evil.

The lesson is not that cloud containers are insecure.

The lesson is not that North Korean hackers are supernatural.

The lesson is that complexity without semantics is an invitation to catastrophe.

When we design systems that handle billions of dollars, we must stop behaving like naive carpenters who assume that because their hammer is made of titanium, whatever they build will withstand a hurricane.

A private key is just a hammer.

Cryptography is just math.

Security is not the strength of your keys.

Security is the structural integrity of your entire causal chain.

Build verifying state machines. Eliminate ambient trust. Respect the limits of human cognition.

Because in the unforgiving physics of distributed systems, whatever can be decoupled will eventually be weaponized.