One address, many actors: contract wallet attribution

When a disputed wallet is a smart contract, the address is an execution account, not a person. Authority over it is defined by code: an owner list, a signature threshold, enabled modules, guards, and sometimes delegation or account-abstraction infrastructure. For fraud, corporate, and probate counsel the question is therefore not "who owns this address" but "whose authorization moved these assets," and where that answer stops being a chain fact and becomes inference.

Contract Wallets Are Not Ordinary Accounts

Ethereum distinguishes externally owned accounts (EOAs) from contract accounts. An EOA is controlled by its private key; a contract account has no private key and acts according to its code when called. EIP-7702 adds a third fact an analyst may need to account for: an EOA can carry a delegation indicator that causes calls to execute delegated code. The ethereum.org account documentation describes the EOA and contract-account distinction.

A transaction that appears "signed by the wallet" is signed by whatever actors the wallet's code accepts. Contracts cannot sign the way key-based accounts do, which is why the ERC-1271 standard exists: a contract exposes isValidSignature(hash, signature) and returns a fixed magic value when the signature is valid for it. Validation can be context dependent, keyed to time, state, or a signer's authorization level.

An analyst who treats a contract-wallet address as an EOA misattributes everything downstream, because the assumption of one key, one signer, one person does not hold.

Safe Smart Account, formerly Gnosis Safe, is a common multisig implementation. A Safe stores an owner list and a threshold, the minimum number of owner approvals needed to execute, on-chain. Changes to the owner set or threshold are Safe transactions, so the same address can have different control arrangements at different times.

The Actors Behind a Single Address

Owners and Signers

Owners are the addresses permitted to approve transactions; each approval is a signature over the transaction hash. Owners can themselves be contracts, a configuration ERC-1271 anticipated, so owner lists can nest. In Safe's standard execution path, transaction input contains a packed signature value that can include an ECDSA signature, an ERC-1271 contract signature identifying its verifying contract, or a pre-validated hash. For that execution path, the analyst can often enumerate which approving addresses were presented: a chain fact.

The Threshold

The threshold is a control setting, not a person; a change from 2-of-3 to 1-of-1 is a concentration-of-control event that leaves its own signed record. The threshold in force on the transfer date is usually the first thing to pin down.

Modules

Modules are contracts an owner set enables through an approved wallet transaction. Once enabled, a module can execute transactions through the wallet without collecting the owner-threshold signatures used in ordinary Safe execution. Evidentiary significance: a transfer executed through a module does not carry owner signatures in the standard execTransaction encoding, and whether owners approved depends on the module logic rather than the threshold.

Guards

Guards add pre- and post-execution checks; unlike modules they cannot originate transactions, only pass or block them. A guard change is recorded on-chain, including the ChangedGuard event emitted by Safe's setGuard function. That interface is a transaction guard on ordinary Safe execution. A module-executed transfer is a different path, so a claim that the guard should have stopped it requires showing the guard actually ran on that execution.

Relayers, Bundlers, Paymasters, and Delegated Code

Submission is not approval. Safe contracts allow relayed execution, so the account submitting an execution can differ from the owners who signed it. Under account abstraction the separation is structural: ERC-4337 defines UserOperations, a pseudo-transaction naming the sender account, factory data, gas limits and fees, optional paymaster data, and a signature the account itself validates. Bundlers collect valid UserOperations and submit them to a shared EntryPoint contract, so the on-chain transaction's sender is the bundler, not the smart-account address. Paymasters can sponsor fees. A related mechanism is EIP-7702, under which an EOA signs an authorization tuple writing a persistent delegation indicator into its account code. The authorization list is processed before that transaction's execution, and the indicator remains in effect on later calls until it is updated, so attribution requires reading the delegation indicator in effect at the disputed date along with the delegate contract.

Reconstructing Configuration at the Disputed Time

For an identified wallet implementation, configuration changes may be recoverable from its transactions, event logs, and historical state. The analyst must establish from the code and records which changes are observable, then reconstruct the configuration to the relevant date rather than reading today's state. The reconstruction runs in six layers:

1. Classify the account: EOA or contract, including any EIP-7702 delegation indicator, and the implementation behind any proxy.
2. Rebuild the configuration history to the disputed date.
3. Classify each execution path: owner-signed, module-executed, or delegated call.
4. Extract approving addresses from signature data where the execution path encodes it.
5. Identify infrastructure actors: submitter, gas payer, refund receiver, bundler, paymaster.
6. Map addresses to persons or entities using off-chain evidence.

What is not on-chain deserves equal emphasis. Which human held each key is almost always an off-chain question, and confirmations collected before a transaction reached threshold may live only in the wallet provider's services. The evidence methods used to tie keys to people apply here with one twist: a single key is only part of the authorization.

Account Abstraction and the ERC-4337 Pipeline

ERC-4337 changes how wallets are created and run. The sender account can be deployed for the first time inside the UserOperation via factory data, so the wallet can be created and transacted in one flow. The EntryPoint contract validates gas, calls the account's validation function, then calls it to execute; what counts as a valid signature is defined by the account's own code. Safe's ERC-4337 integration uses a module that validates a UserOperation against Safe owner signatures, then executes a module transaction. The forensic consequence: the chain identifies the account and the executor infrastructure, while authority lives in the account's code.

Counterfactual Accounts: Authorization Before the Contract Exists

Deterministic deployment means an account's address can be computed before any code exists at it, using a factory and a salt; funds can sit at an address with no bytecode. ERC-6492 standardizes signature validation for predeploy contracts: the signature is wrapped with the factory address, deployment calldata, and the underlying ERC-1271 signature, ending in magic bytes that cannot collide with a key-based signature. The specification requires a verifier to detect the magic bytes first and, when they are present, call the factory with the deployment calldata (deploying if the wallet is not already deployed) before validating the inner ERC-1271 signature; then perform standard ERC-1271 checks if code exists; if that ERC-1271 call failed and the factory call was skipped because the wallet already had code, execute the factory calldata and retry; and attempt ecrecover only as a final step.

The evidentiary upshot: a party can produce a signature for a counterfactual wallet before that wallet exists on-chain. The intended configuration may then be reconstructed from the factory address and deployment calldata in the ERC-6492 wrap, from any later on-chain deployment if one exists, and from off-chain records of the planned owner set; on-chain state alone may under-describe what happened.

An Attribution Matrix for Expert Reports and Deposition

The table below is the organizing device I use in expert reports and at deposition; it forces a separate answer for each actor type and labels each as fact or inference.

This matrix operationalizes the six-layer reconstruction order. Each step yields either an on-chain fact or an inference needing its own evidence, and the expert report must state which.

Hypothetical: The Two-of-Three Corporate Wallet

Illustrative scenario: a company runs a 2-of-3 Safe holding operating funds. The owners are keys held by two officers and one outside investor. Over ten months the threshold is raised to 3, then lowered to 2, and a spending-limit module is enabled. The disputed transfer, a large payment to a new address, executes with two signatures: one key-based and one ERC-1271 contract signature from a second Safe added as an owner eight months prior. Gas is paid by a relayer address that is not an owner.

Replaying the Safe's history shows the second Safe entering the owner set, the threshold change that made two approvals sufficient, and the module enable with its authorizing transaction. Parsing the disputed transaction's signature data shows the two approving addresses and their types, including the nested Safe's verifying contract address. What the chain does not show is which humans held the officer keys or whether the module was operated by an employee with no owner status; those answers require device forensics, exchange records, custody policies, and depositions, following the self-custody discovery playbook.

Limitations and the Questions to Ask

Proposals that never reached threshold exist only off-chain. Recovered signature addresses can identify an approving key or verifying contract, not a human. Implementations can be upgraded through proxies, so authority can change without the address changing; the upgrade is on-chain, but its effect requires code review. The same address can be deployed deterministically across chains with different states, so each chain is analyzed separately. ERC-1271 validation is context dependent by design: a signature valid on one date may be invalid on another, so validity at the relevant date, not today, is the question. A smart account has no native KYC record comparable to an exchange account, although a related service may hold records.

The discovery questions that follow:

1. Was the address an EOA or a contract at the relevant date, including any EIP-7702 delegation indicator, and what implementation is behind it?
2. Produce the full configuration history: every owner, threshold, module, and guard change, with transaction hashes.
3. Produce raw transaction input data and event logs for each disputed transaction, not block explorer summaries.
4. Which disputed transactions ran through modules, and what code was each module running?
5. Who submitted each execution and who paid gas, including bundler and paymaster activity?
6. Produce confirmation and signing records from any wallet provider interface used before execution.
7. Document key custody for every owner address: devices, seed phrases, corporate policy, personnel changes.

These are forensic facts and methods that apply in any U.S. forum. How a court weighs them depends on the jurisdiction's evidence rules, and the legal responsibility of each actor is a conclusion built on the factual record under corporate, agency, probate, or criminal law. Conduct executed through code is still conduct; the smart contract disputes article covers how courts treat it. Our methodology page explains how expert reports separate chain facts from inference.

Frequently Asked Questions

Q: Is a multisig address owned by any single person?

A: No, not in the way an ordinary wallet is. The address is a contract with an owner list and threshold stored on-chain; control is defined by code, by the threshold number of owner approvals or the module's rules. "Ownership" is a legal characterization, resolved by who holds which key and what the parties agreed. No single owner key is sufficient unless the threshold is one.

Q: If a transaction was signed by enough owners, who is responsible for it?

A: The approvals are on-chain facts, but responsibility is a legal question depending on the signers' relationships. Signature evidence shows which addresses approved and the exact approval set; mapping those to persons, and deciding whether an approval binds the entity, the signer, or both, requires off-chain evidence and applicable law. The forensic contribution is pinning down who approved, when, and through which mechanism.

Q: Can activity from an ERC-4337 smart account be traced to the person who initiated it?

A: Only partially, and not from the chain alone. Under ERC-4337 the on-chain transaction is submitted by a bundler; the actor is the sender account, a contract whose code defines what signatures it accepts. The UserOperation contains signature data, but whether that data identifies approving keys depends on the account implementation. Connecting any approving address to a human, and separating the initiator from the infrastructure, requires the same off-chain evidence used for any self-custody wallet.

Q: What does it mean if a wallet was not deployed when the disputed authorization happened?

A: The address existed as a computation, a deterministic deployment waiting to happen, with no bytecode on-chain at the time. ERC-6492 standardizes validating signatures for such predeploy accounts by wrapping the signature with factory and deployment data. For attribution, the intended owner set must be reconstructed from the factory address and deployment calldata in that wrap, from any later on-chain deployment if one exists, and from off-chain records, because the chain holds no configuration for a contract that did not yet exist.

Q: What discovery should you request when the other side controls a contract wallet?

A: Go beyond the address. Request the implementation and proxy records, the full history of owner, threshold, module, and guard changes with transaction hashes, raw input data for each disputed transaction, module code, submission and gas records, wallet provider confirmation logs, and key custody documentation for every owner address. Without that layer, a contract-wallet attribution rests on the false premise that one address equals one person.

Each matter turns on its own facts, and the line between what the chain proves and what must be proven around it varies with the wallet design and the parties' records. If you are facing that line, contact us to discuss the evidence picture, or see how blockchain tracing engagements and litigation consulting are structured.