Entangled Accounts: protocol native multisig with parity gated debits

Account abstraction made the case that wallets should be programmable, so we can build things like multisig, social recovery, new signature schemes, post quantum safety, and upgradeability without being boxed in by the EOA transaction model according to the EIP-4337 https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a

PPC entangled accounts comes from a different angle. It asks a narrower question: can we make a specific kind of shared control, exactly two principals acting as one logical account, into a tiny consensus primitive, so it is legible to every client and auditor without deploying a wallet contract.

What follows extends the earlier writeup by explicitly borrowing the 2021 Vitalik Butarin framing on the said ERC 4337 on account abstraction but we’ll go for Ethereum protocol changes, then walking through the common AA use cases and what entanglement does or does not contribute.

1. What is PPC entanglement?

PPC entanglement links two EOAs into one logical class using a deterministic partner mapping. Once enabled, both endpoints share one balance and one nonce at consensus.

The partner mapping is pure computation, partner(a) = (~a) XOR 0x01

Two modes are provided, based on the parity of the class.

Even parity authority: a standard transaction signed by either endpoint can debit the shared balance and advance the shared nonce.

Odd parity classes behave like vault mode: a debit executes only when two independently signed authorizations over the same unsigned payload are included together in the same block. Execution happens once, fees happen once, nonce increments once, and the second transaction becomes a witness receipt with zero state effects and zero gas used in receipt accounting.

In our spec terms, those two authorizations are the two matching PPCAuthTx transactions, one signed by each partner address, with the same intent hash.

A canonical representative canon(a) defines the class identifier.

2. How does the entanglement protocol work?

At a high level, the protocol turns two EOAs into one logical account class, without deploying a wallet contract. It does that by defining a deterministic partner mapping, a canonical class identifier, and two new typed transactions that only become valid when they appear as an exact matched pair in the same block.

a. Deterministic pairing and a single canonical state slot

Every address a has a deterministic PPC partner, entangled address, computed as partner(a) = (~a) XOR 0x01, which preserves parity. The protocol defines canon(a) = min(a, partner(a)), and uses classId(a) = canon(a) as the class identifier. This means every node, wallet, and auditor can derive the same partner and the same class id with no registry.

Clients maintain a consensus flag Entangled[c] per canonical class c, committed under the execution state root.

b. Opt in activation via a paired enable transaction

Entanglement is opt in. Before activation, both endpoints behave like ordinary EOAs.

Activation uses a new typed transaction PPCEnableTx (EIP 2718 envelope). Each endpoint signs the same unsigned payload, producing two ordinary ECDSA signatures. The payload includes fee fields and an enableTag that must equal the canonical class id being enabled.

Block validity rule: for each enable intent hash I = keccak256(rlp(unsignedPayload)), the block must contain exactly two PPCEnableTx with that same I, and the recovered senders must be PPC partners. If an enable intent appears once, more than twice, or the two senders are not partners, the block is invalid.

On successful paired enablement, clients set Entangled[c] := true, merge the two endpoint balances into Balance[c], set Nonce[c] := 0, and zero out the endpoint balances and nonces. The draft uses a strict zero nonce precondition on both endpoints to keep activation unambiguous.

c. Shared balance and shared nonce, enforced by consensus

Once Entangled[classId(a)] is true, all balance and nonce reads and writes for either endpoint are redirected to the canonical representative. In other words, Balance[a] and Nonce[a] are interpreted as Balance[classId(a)] and Nonce[classId(a)] for both endpoints.

That’s the key difference from wallet level multisig patterns: it’s not a contract holding funds, It’s the base account state being canonicalized.

d. Spending in even classes uses existing transaction types

If the class parity is even, existing transaction types remain valid as usual, except nonce and balance checks use the canonical state via the redirection rule. Any standard transaction signed by either endpoint debits the shared balance and increments the shared nonce once.

e. Spending in odd classes uses paired authorizations

Odd classes use a second typed transaction, PPCAuthTx, which is “authorization only” unless paired. Its unsigned payload includes the shared nonce, fee fields, gasLimit, to, value, data, and optional accessList, and it is signed with standard ECDSA.

Block validity rule: for each debit intent hash I, the block must contain exactly two PPCAuthTx with that I, and the recovered senders must be PPC partners. A singleton authorization cannot appear in a valid block.

Execution rule: when a matched pair is present, the protocol executes exactly one EVM call, charges gas and fees exactly once from the shared canonical balance, and increments the shared nonce exactly once. The executed msg.sender is deterministically defined as exec = min(r, rp) for the two partner senders.

Receipt ordering is also deterministic: within the block transaction list, the first occurrence of the intent is treated as the executor for receipt ordering, and the second occurrence is the witness.

e. Gas, fees, and witness receipts

The protocol treats the pair as the gas unit. For each matched enable or debit intent, there is exactly one execution, one gas charge, one fee charge (paid from the shared canonical balance), and the second transaction becomes a witness with zero effects.

Witness receipt rules are explicit: status success, gasUsed = 0, empty logs, unchanged cumulativeGasUsed, and no state changes.

f. Mempool and block production behavior

Nodes may accept PPCEnableTx and PPCAuthTx into the local pool, but block producers must include them only as matched pairs. Wallets are expected to submit paired bundles to avoid inert singletons and improve same block inclusion probability.

The spec is explicit about the tradeoff: odd mode can be censored by a block producer who withholds one half of the pair, and that is accepted as “vault semantics prefers safety over liveness”.

g. What a client implementation actually does

A straightforward client implementation pre-scans the block, groups PPCEnableTx and PPCAuthTx by intent hash, validates exact pairing and partner relation, then executes only the first occurrence per intent and emits a witness receipt for the second. Separately, the StateDB accessors redirect balance and nonce for entangled endpoints to the canonical representative.

Further comment on “Native entanglement MUST be opt in. Before enablement, both addresses behave as ordinary EOAs.”:

What’s happening is that “protocol native” and “opt in” are talking about two different things.

“Protocol native” means the rules live in consensus, not in a wallet contract or offchain coordination. You still only enter that rule set after both endpoints explicitly activate it via the paired enablement flow (two matching PPCEnableTx in the same block).

The reason opt in is basically mandatory with your PPC complement mapping is safety and backward compatibility. If entanglement were automatic for every address, then every EOA would be forcibly linked to its PPC partner, which could be controlled by someone else. That would be catastrophic in even mode, and disruptive even in odd mode. Your disclosure calls out opt in activation specifically to avoid affecting existing accounts and to keep existing addresses and transactions behaving normally unless users explicitly enable entanglement.

The point is that “native entanglement isn’t opt in” because “users don’t have to deploy a contract and choose a multisig scheme”, and it’s native because it’s a protocol primitive. Therefore, in the draft we’ve written, it’s opt in because the chain cannot safely assume two unrelated addresses consent to being merged into one logical account.

3. What properties does this design add, maintain, and sacrifice Vitalik’s ERC 4337 post frames the alt mempool design in terms of maintained properties, new benefits, and weaknesses.

Here is the same lens, but comparing PPC entanglement to ERC 4337

Properties entanglement largely maintains

It keeps the default transaction and fee model for EOAs. Even mode uses ordinary transactions, and odd mode uses typed transactions but still lives inside normal block validity and normal inclusion economics, rather than introducing a separate mempool and bundler role.

It also keeps signer UX simple. In odd mode, each signer performs a standard single signature action, rather than participating in threshold signing or having to go through a contract wallet approval flow.

Properties entanglement adds that AA does not give by default

It adds a protocol legible relationship between two principals. The partner mapping is deterministic and registry free, and the shared balance and shared nonce are enforced by consensus.

It adds a very specific audit artifact for dual authorization. In odd mode, the second authorization is a consensus recognized witness receipt with explicitly constrained receipt semantics, rather than an application level event emitted by a contract wallet.

It reduces contract surface for the particular “two keys, one account, optional vault mode” shape. The patent text is explicit that the goal is to move shared control from application conventions into a small protocol primitive.

Properties entanglement sacrifices relative to AA

Account abstraction’s biggest “new benefits” are flexibility: arbitrary signature and nonce rules, quantum safe migration at the wallet level, wallet upgradeability, and rich execution logic like atomic multi operations.

Entanglement does not try to compete on that axis. By design it hard codes exactly two endpoints and two modes, and it does not introduce a general verification hook like validateUserOp.

It also sacrifices fee abstraction. ERC 4337 highlights paymasters and calls out two commonly cited sponsorship goals: apps paying user fees, and users paying fees in ERC20 via an intermediary. Entanglement charges fees from the shared canonical balance, so you still need ETH in that shared state unless you combine it with separate mechanisms.

It also sacrifices some liveness in its vault mode. Odd mode requires same block pairing, which is censorship sensitive at the block producer level, and wallets are expected to submit paired bundles through builder channels to improve inclusion probability.

4. Use cases: where entanglement helps, where AA still wins

Multisig

AA multisig is “policy in code”. You can do M of N, weighted signers, time locks, spending limits, and more. The patent disclosure even acknowledges that AA can approximate even and odd mode behavior and can support session keys and spending limits, with the tradeoff that it depends on a particular smart account implementation and its upgrade discipline.

Entanglement is “policy as a relation”. You only get 1 of 2 (even) and 2 of 2 (odd), but you get it as a consensus rule with a standardized witness artifact.

Two concrete multisig workflows that map cleanly to entanglement are already in the disclosure:

1. Maker checker enterprise payments. One endpoint initiates, the other approves, and odd mode produces a direct on chain dual approval artifact without a custom wallet contract.
2. Joint accounts across organizations. Odd mode ensures neither party can debit unilaterally, with receipts that do not require reverse engineering a contract wallet state machine.

Social recovery

AA social recovery typically means multiple guardians, delayed recovery windows, and configurable policies, all living in contract code. That is squarely in the “multisigs and social recovery” bucket that AA is meant to unlock.

Entanglement supports a simpler, sharper version: one guardian. The disclosure explicitly frames the entangled pair as “an automated key and a guardian key” and ties it to continuity and recovery.

A practical pattern looks like this. You keep an operational key on a device, and the partner key is held by a guardian entity or secure module. Even mode lets either endpoint act for routine continuity, and odd mode can be used when you want withdrawals to require co approval.

The obvious limitation is that this is not N guardian social recovery. If you want “my phone plus any 2 of 5 friends can recover”, that still belongs in AA or contract wallets.

Sponsorship and paying fees in ERC20

This is where AA has a direct, named mechanism. ERC 4337 paymasters are designed specifically for sponsorship, and the article calls out the two most common desired cases: apps paying fees, and users paying fees in ERC20 through an intermediary.

Entanglement does not include a paymaster equivalent. It charges fees once from the shared canonical balance when a matched intent executes.

That doesn’t make sponsorship impossible, but it means sponsorship is external to the primitive, for example via separate relayers, L2 features, or a contract system that pays ETH for the user. Entanglement itself does not standardize it.

Session keys, spending limits, atomic multi operations

These are classic AA wins because both validation and execution logic are programmable per account. You can issue temporary session keys for apps, enforce daily limits, require extra approval above a threshold, batch multiple calls into one atomic operation, and generally evolve the wallet policy without changing the base protocol. (This is exactly the class of flexibility Vitalik Buterin is pointing at in the ERC 4337 article).

Entanglement can still interact with any contract, so you can call a multicall contract, a spending limit contract, or any policy module you like. But at that point you’re relying on application level code and audits again, because entanglement is not a general-purpose programmable validation system. Its scope is narrower: the shared control relationship and, in odd mode, the consensus enforced dual authorization rule.

Where the two fit together nicely is in layering.

A practical architecture is to use an AA smart account as the programmable wallet, and treat the entangled pair as the root control. Day to day operations happen as UserOperations from the AA account, with session keys and spending limits enforced in validateUserOp. When you want to change something sensitive, like rotating the session key policy, raising limits, changing guardians, or upgrading the wallet code, you route that action through a rule that effectively requires both entangled endpoints to approve. The simplest way is that the AA account exposes admin methods, and those admin methods require a proof of dual authorization, for example two signatures or a fresh onchain witness that can only exist if the entangled odd mode pairing happened.

Another practical pattern is separating hot and vault funds. Keep a small balance in the AA account for high frequency use, sponsored flows, and atomic batches. Keep reserves in an odd entangled class. Refilling the AA account becomes a vault action that requires co approval at the protocol level, while spending from the AA account remains smooth and programmable. In other words, AA gives you rich UX and automation, and entanglement gives you a hard to bypass brake pedal for value movements and configuration changes.

Finally, the summary is: AA owns expressiveness. Entanglement owns a small, consensus legible shared control primitive. If you combine them, you get programmable wallets with a stronger story for how the most dangerous actions are authorized and evidenced onchain.

5. Does entanglement contribute to Schnorr, BLS, post quantum signatures, or upgradeability?

Vitalik Buterin lists “more efficient signature algorithms like Schnorr and BLS”, “post quantum safe signatures like Lamport and Winternitz”, and “upgradeability” as major AA motivations in https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a

Entanglement’s contribution here is mostly indirect.

Signature algorithms

The draft EIP keeps standard secp256k1 ECDSA signatures for enable and authorization typed transactions.

So entanglement doesn’t let a user unilaterally choose BLS or a post quantum scheme the way AA can, because AA can implement arbitrary signature checks inside validateUserOp.

What entanglement can claim is compatibility. If Ethereum later adds new signature verification options at the protocol level, the entanglement pattern could ride along, since it isn’t tied to a specific contract wallet validation logic. That’s not a new capability by itself, and it depends on separate protocol work.

Post quantum safety

AA’s pitch here is very explicit: if users can upgrade their wallet verification logic to post quantum schemes, the execution layer can become quantum safe without another protocol upgrade.

What that really means in practice is cryptographic agility at the account level. An AA wallet can start with secp256k1 today, then later accept a different signature scheme by changing its validation logic, or by upgrading the account code. It can even support multiple schemes in parallel for a while, like letting the owner sign with the old scheme but letting recovery or high value actions require a newer scheme. That kind of gradual migration is exactly what you get when verification is programmable.

Entanglement doesn’t provide that migration lever, because it doesn’t embed per wallet verification logic. Its verification rule lives in consensus. If entanglement transactions are defined to use a particular signature format, then changing that format is not something a single user can do by upgrading their wallet. It would require either a protocol level addition of new signature verification options for the entanglement transaction types, or a migration away from entanglement as the spending control point.

The good news is that entanglement can still benefit from AA here, just indirectly. A practical hybrid path is to move the user facing wallet into an AA smart account that you can upgrade to post quantum verification when needed, and keep entanglement as the root control for the most sensitive actions. For example, you can require odd mode dual approval to authorize upgrades, key rotations, guardian changes, or large transfers out of a reserve, while everyday spending happens from the AA account that you can evolve cryptographically over time. In that setup, AA is where signature migration happens, and entanglement is where you enforce a simple, hard to bypass co approval rule over the actions that would be catastrophic if a single key is compromised.

If Ethereum eventually adds native post quantum signature verification at the protocol level, entanglement could adopt it by introducing new typed transactions that keep the same pairing and witness semantics but carry the new signature form. Until then, AA is the realistic way to get post quantum migration without waiting for a base layer change.

Upgradeability

AA wallets can rotate keys and upgrade code because the wallet is a contract and its validation logic can be stateful.

Entanglement instead frames continuity as a relationship between two endpoints, often an operational key plus a guardian key. It also explicitly targets long lived agents that can survive key rotation and partial compromise.

In the current draft, the practical approach isn’t “upgrade in place” but to migrate to a new entangled pair when you rotate keys, with the old guardian endpoint co authorizing the migration. That keeps the primitive simple, but it’s a different shape than AA’s in place upgradeability.

What about the AA properties list: DoS safety, overhead, and one transaction at a time?

ERC 4337 explicitly calls out a slight increase in DoS risk and gas overhead due to more complex verification, plus limits like accounts not being able to queue multiple operations, partially offset by atomic multi operations.

Entanglement shifts these tradeoffs.

The DoS surface is different. Verification stays close to today’s EOA rules, but odd mode adds a paired inclusion validity rule, and clients must be careful about inert singletons in the txpool.

Overhead is different too. Even mode has almost no additional on chain footprint, while odd mode adds bandwidth because two transactions appear for one execution, even though the witness receipt has zero gas used in receipt accounting.

“One transaction at a time” becomes stricter in one sense. The shared nonce is literally a single lane for the class, so concurrent attempts contend and wallet software is expected to coordinate and serialize.

As a conclusion, Account Abstraction (AA) is a general framework: it turns wallet verification and execution into programmable logic, unlocking everything from social recovery to post quantum signatures and upgradeability.

Entanglement is a narrow protocol primitive: it makes “two endpoints as one account” first class, and it gives you a built-in vault mode whose evidence is simply “two independent signatures co included in one block”, plus a standardized witness receipt.

The strong thesis here is that some policies are so common, and so safety sensitive, that it can be worth standardizing them as consensus rules to reduce contract surface and make auditing trivial. Everything else remains in AA’s wheelhouse.

6. Can AA and Entanglement work together? How they leverage each other?

Yes, and the clean way to think about it is: entanglement is a small consensus primitive for shared control, and AA is the programmable layer you use to get all the wallet features Vitalik lists. Vitalik’s list is exactly the stuff entanglement does not try to encode in consensus: multisig and social recovery, new signature schemes like Schnorr and BLS, post quantum schemes like Lamport and Winternitz, and upgradeability.

So “entanglement leverages AA benefits” when you use AA for flexibility and UX, and you use entanglement to harden the highest risk control points.

Here are the main leverage points.

a. Use AA for policy, keep entanglement for root control. Your patent text already says AA smart accounts can approximate even and odd mode behavior and add session keys and spending limits, but the tradeoff is that it depends on the specific smart account implementation and its upgrade discipline. In practice, that means you put the rich policy in an AA account, and you policy” actions are gated by an entangled pair in odd mode. That gives you AA features day to day, with an entanglement backed lock on the dangerous knobs.

b. Use AA sponsorship for gas, and keep entanglement for governance over who can sponsor. Buterin highlights paymasters and says the most commonly cited sponsorship use cases are apps paying for users and users paying fees in ERC20 via an intermediary. Entanglement by itself does not include paymasters, but it can control the actions that configure or change paymaster relationships inside the AA wallet. So you get gas abstraction through AA, and you reduce “someone changed my paymaster settings” risk by requiring entangled odd mode approval for those configuration calls.

c. Use AA infrastructure to make odd mode operationally smooth. ERC 4337 uses UserOperation objects, bundlers, and an EntryPoint execution flow. Our entanglement spec and benchmark both assume paired inclusion mechanisms like private bundling for odd mode liveness. The practical connection is that the same kind of bundling pipeline AA relies on can also be used to reliably co include the two PPCAuthTx in the same block.

d. Let AA deliver signature agility and upgradeability, and let entanglement secure the upgells out flexible verification logic in validateUserOp, quantum safety via user upgrades, and wallet upgradeability. Entanglement doesn’t give you Schnorr, BLS, Lamport, or Winternitz directly, because it’s a fixed consensus rule for EOAs. But you can build an AA wallet that supports new signature schemes and upgrades, and then require that any upgrade, key rotation, or guardian set change is approved through an entangled odd mode control, so upgrades are not a single point of failure.

A concrete mental model is: AA is your “hot programmable wallet” for normal operations, sponsorship, batching, session keys, and spending limits. Entanglement is your “root of trust and brake pedal” for upgrades, recovery, and any action that should never be executable by one compromised key. That matches our own positioning that AA is infrastructure mediated validation while entanglement is a protocol level relation with shared state and a strict paired authorization rule in odd mode.

How far along is this proposal?

Our entanglement draft is positioned as a Core standards track EIP with new typed transactions for enablement and odd mode authorization, plus client changes to canonicalize balance and nonce and to pre-scan blocks for exact pairing. A hard fork is necessary then.