[{"data":1,"prerenderedAt":3669},["ShallowReactive",2],{"tag-smart-contracts":3},[4,746,1773,2540,2850,3284],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"slug":11,"date":12,"lastUpdated":12,"author":13,"readingTime":14,"category":15,"tags":16,"ogImage":22,"featured":7,"body":23,"_type":740,"_id":741,"_source":742,"_file":743,"_stem":744,"_extension":745},"\u002Farticles\u002F38-multisig-contract-wallet-attribution","articles",false,"","One address, many actors: contract wallet attribution","Contract wallets and multisigs are not one-person accounts. Experts reconstruct owners, signers, modules, and relayers to attribute on-chain activity.","multisig-contract-wallet-attribution","2026-08-29","Nick Kampe",12,"Methodology",[17,18,19,20,21],"multisig","wallet","account-abstraction","smart-contracts","evidence","\u002Fog\u002Fmultisig-contract-wallet-attribution.png",{"type":24,"children":25,"toc":715},"root",[26,34,41,57,80,85,90,96,103,108,114,119,125,138,144,165,171,194,200,205,240,253,259,264,270,284,289,295,300,499,504,510,515,528,534,539,544,582,603,609,615,626,632,641,647,656,662,671,677,686],{"type":27,"tag":28,"props":29,"children":30},"element","p",{},[31],{"type":32,"value":33},"text","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.",{"type":27,"tag":35,"props":36,"children":38},"h2",{"id":37},"contract-wallets-are-not-ordinary-accounts",[39],{"type":32,"value":40},"Contract Wallets Are Not Ordinary Accounts",{"type":27,"tag":28,"props":42,"children":43},{},[44,46,55],{"type":32,"value":45},"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 ",{"type":27,"tag":47,"props":48,"children":52},"a",{"href":49,"rel":50},"https:\u002F\u002Fethereum.org\u002Fdevelopers\u002Fdocs\u002Faccounts\u002F",[51],"nofollow",[53],{"type":32,"value":54},"ethereum.org account documentation",{"type":32,"value":56}," describes the EOA and contract-account distinction.",{"type":27,"tag":28,"props":58,"children":59},{},[60,62,69,71,78],{"type":32,"value":61},"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 ",{"type":27,"tag":47,"props":63,"children":66},{"href":64,"rel":65},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-1271",[51],[67],{"type":32,"value":68},"ERC-1271 standard",{"type":32,"value":70}," exists: a contract exposes ",{"type":27,"tag":72,"props":73,"children":75},"code",{"className":74},[],[76],{"type":32,"value":77},"isValidSignature(hash, signature)",{"type":32,"value":79}," 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.",{"type":27,"tag":28,"props":81,"children":82},{},[83],{"type":32,"value":84},"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.",{"type":27,"tag":28,"props":86,"children":87},{},[88],{"type":32,"value":89},"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.",{"type":27,"tag":35,"props":91,"children":93},{"id":92},"the-actors-behind-a-single-address",[94],{"type":32,"value":95},"The Actors Behind a Single Address",{"type":27,"tag":97,"props":98,"children":100},"h3",{"id":99},"owners-and-signers",[101],{"type":32,"value":102},"Owners and Signers",{"type":27,"tag":28,"props":104,"children":105},{},[106],{"type":32,"value":107},"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.",{"type":27,"tag":97,"props":109,"children":111},{"id":110},"the-threshold",[112],{"type":32,"value":113},"The Threshold",{"type":27,"tag":28,"props":115,"children":116},{},[117],{"type":32,"value":118},"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.",{"type":27,"tag":97,"props":120,"children":122},{"id":121},"modules",[123],{"type":32,"value":124},"Modules",{"type":27,"tag":28,"props":126,"children":127},{},[128,130,136],{"type":32,"value":129},"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 ",{"type":27,"tag":72,"props":131,"children":133},{"className":132},[],[134],{"type":32,"value":135},"execTransaction",{"type":32,"value":137}," encoding, and whether owners approved depends on the module logic rather than the threshold.",{"type":27,"tag":97,"props":139,"children":141},{"id":140},"guards",[142],{"type":32,"value":143},"Guards",{"type":27,"tag":28,"props":145,"children":146},{},[147,149,155,157,163],{"type":32,"value":148},"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 ",{"type":27,"tag":72,"props":150,"children":152},{"className":151},[],[153],{"type":32,"value":154},"ChangedGuard",{"type":32,"value":156}," event emitted by Safe's ",{"type":27,"tag":72,"props":158,"children":160},{"className":159},[],[161],{"type":32,"value":162},"setGuard",{"type":32,"value":164}," 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.",{"type":27,"tag":97,"props":166,"children":168},{"id":167},"relayers-bundlers-paymasters-and-delegated-code",[169],{"type":32,"value":170},"Relayers, Bundlers, Paymasters, and Delegated Code",{"type":27,"tag":28,"props":172,"children":173},{},[174,176,183,185,192],{"type":32,"value":175},"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: ",{"type":27,"tag":47,"props":177,"children":180},{"href":178,"rel":179},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-4337",[51],[181],{"type":32,"value":182},"ERC-4337",{"type":32,"value":184}," 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 ",{"type":27,"tag":47,"props":186,"children":189},{"href":187,"rel":188},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-7702",[51],[190],{"type":32,"value":191},"EIP-7702",{"type":32,"value":193},", 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.",{"type":27,"tag":35,"props":195,"children":197},{"id":196},"reconstructing-configuration-at-the-disputed-time",[198],{"type":32,"value":199},"Reconstructing Configuration at the Disputed Time",{"type":27,"tag":28,"props":201,"children":202},{},[203],{"type":32,"value":204},"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:",{"type":27,"tag":206,"props":207,"children":208},"ol",{},[209,215,220,225,230,235],{"type":27,"tag":210,"props":211,"children":212},"li",{},[213],{"type":32,"value":214},"Classify the account: EOA or contract, including any EIP-7702 delegation indicator, and the implementation behind any proxy.",{"type":27,"tag":210,"props":216,"children":217},{},[218],{"type":32,"value":219},"Rebuild the configuration history to the disputed date.",{"type":27,"tag":210,"props":221,"children":222},{},[223],{"type":32,"value":224},"Classify each execution path: owner-signed, module-executed, or delegated call.",{"type":27,"tag":210,"props":226,"children":227},{},[228],{"type":32,"value":229},"Extract approving addresses from signature data where the execution path encodes it.",{"type":27,"tag":210,"props":231,"children":232},{},[233],{"type":32,"value":234},"Identify infrastructure actors: submitter, gas payer, refund receiver, bundler, paymaster.",{"type":27,"tag":210,"props":236,"children":237},{},[238],{"type":32,"value":239},"Map addresses to persons or entities using off-chain evidence.",{"type":27,"tag":28,"props":241,"children":242},{},[243,245,251],{"type":32,"value":244},"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 ",{"type":27,"tag":47,"props":246,"children":248},{"href":247},"\u002Fresources\u002Funderstanding-wallet-ownership-evidence",[249],{"type":32,"value":250},"evidence methods used to tie keys to people",{"type":32,"value":252}," apply here with one twist: a single key is only part of the authorization.",{"type":27,"tag":35,"props":254,"children":256},{"id":255},"account-abstraction-and-the-erc-4337-pipeline",[257],{"type":32,"value":258},"Account Abstraction and the ERC-4337 Pipeline",{"type":27,"tag":28,"props":260,"children":261},{},[262],{"type":32,"value":263},"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.",{"type":27,"tag":35,"props":265,"children":267},{"id":266},"counterfactual-accounts-authorization-before-the-contract-exists",[268],{"type":32,"value":269},"Counterfactual Accounts: Authorization Before the Contract Exists",{"type":27,"tag":28,"props":271,"children":272},{},[273,275,282],{"type":32,"value":274},"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. ",{"type":27,"tag":47,"props":276,"children":279},{"href":277,"rel":278},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-6492",[51],[280],{"type":32,"value":281},"ERC-6492",{"type":32,"value":283}," 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.",{"type":27,"tag":28,"props":285,"children":286},{},[287],{"type":32,"value":288},"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.",{"type":27,"tag":35,"props":290,"children":292},{"id":291},"an-attribution-matrix-for-expert-reports-and-deposition",[293],{"type":32,"value":294},"An Attribution Matrix for Expert Reports and Deposition",{"type":27,"tag":28,"props":296,"children":297},{},[298],{"type":32,"value":299},"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.",{"type":27,"tag":301,"props":302,"children":303},"table",{},[304,333],{"type":27,"tag":305,"props":306,"children":307},"thead",{},[308],{"type":27,"tag":309,"props":310,"children":311},"tr",{},[312,318,323,328],{"type":27,"tag":313,"props":314,"children":315},"th",{},[316],{"type":32,"value":317},"Actor",{"type":27,"tag":313,"props":319,"children":320},{},[321],{"type":32,"value":322},"What the chain shows",{"type":27,"tag":313,"props":324,"children":325},{},[326],{"type":32,"value":327},"Off-chain evidence needed",{"type":27,"tag":313,"props":329,"children":330},{},[331],{"type":32,"value":332},"Typical dispute question",{"type":27,"tag":334,"props":335,"children":336},"tbody",{},[337,361,384,407,430,453,476],{"type":27,"tag":309,"props":338,"children":339},{},[340,346,351,356],{"type":27,"tag":341,"props":342,"children":343},"td",{},[344],{"type":32,"value":345},"Owner signer",{"type":27,"tag":341,"props":347,"children":348},{},[349],{"type":32,"value":350},"Approving address in executed signature data",{"type":27,"tag":341,"props":352,"children":353},{},[354],{"type":32,"value":355},"Which person controlled the key",{"type":27,"tag":341,"props":357,"children":358},{},[359],{"type":32,"value":360},"Did this person approve?",{"type":27,"tag":309,"props":362,"children":363},{},[364,369,374,379],{"type":27,"tag":341,"props":365,"children":366},{},[367],{"type":32,"value":368},"Threshold",{"type":27,"tag":341,"props":370,"children":371},{},[372],{"type":32,"value":373},"Current value and every change, each with signatures",{"type":27,"tag":341,"props":375,"children":376},{},[377],{"type":32,"value":378},"Who pushed the change and why",{"type":27,"tag":341,"props":380,"children":381},{},[382],{"type":32,"value":383},"Was control concentrated?",{"type":27,"tag":309,"props":385,"children":386},{},[387,392,397,402],{"type":27,"tag":341,"props":388,"children":389},{},[390],{"type":32,"value":391},"Module",{"type":27,"tag":341,"props":393,"children":394},{},[395],{"type":32,"value":396},"Module executions and enable\u002Fdisable records; signatures depend on the module",{"type":27,"tag":341,"props":398,"children":399},{},[400],{"type":32,"value":401},"Module code and operator",{"type":27,"tag":341,"props":403,"children":404},{},[405],{"type":32,"value":406},"Who could move funds without threshold signers?",{"type":27,"tag":309,"props":408,"children":409},{},[410,415,420,425],{"type":27,"tag":341,"props":411,"children":412},{},[413],{"type":32,"value":414},"Guard",{"type":27,"tag":341,"props":416,"children":417},{},[418],{"type":32,"value":419},"Guard address and change events; whether that guard ran on this execution path",{"type":27,"tag":341,"props":421,"children":422},{},[423],{"type":32,"value":424},"Guard code and operator",{"type":27,"tag":341,"props":426,"children":427},{},[428],{"type":32,"value":429},"Why did no check stop it?",{"type":27,"tag":309,"props":431,"children":432},{},[433,438,443,448],{"type":27,"tag":341,"props":434,"children":435},{},[436],{"type":32,"value":437},"Relayer or bundler",{"type":27,"tag":341,"props":439,"children":440},{},[441],{"type":32,"value":442},"Submitter and gas records on the execution",{"type":27,"tag":341,"props":444,"children":445},{},[446],{"type":32,"value":447},"Operator identity and logs",{"type":27,"tag":341,"props":449,"children":450},{},[451],{"type":32,"value":452},"Does submission equal authorization?",{"type":27,"tag":309,"props":454,"children":455},{},[456,461,466,471],{"type":27,"tag":341,"props":457,"children":458},{},[459],{"type":32,"value":460},"Paymaster",{"type":27,"tag":341,"props":462,"children":463},{},[464],{"type":32,"value":465},"UserOperation paymaster data and EntryPoint deposits",{"type":27,"tag":341,"props":467,"children":468},{},[469],{"type":32,"value":470},"Sponsorship terms and operator",{"type":27,"tag":341,"props":472,"children":473},{},[474],{"type":32,"value":475},"Who paid for the move?",{"type":27,"tag":309,"props":477,"children":478},{},[479,484,489,494],{"type":27,"tag":341,"props":480,"children":481},{},[482],{"type":32,"value":483},"Deployer or factory",{"type":27,"tag":341,"props":485,"children":486},{},[487],{"type":32,"value":488},"Deployment transaction and factory parameters",{"type":27,"tag":341,"props":490,"children":491},{},[492],{"type":32,"value":493},"Factory operator records",{"type":27,"tag":341,"props":495,"children":496},{},[497],{"type":32,"value":498},"What configuration was fixed at creation?",{"type":27,"tag":28,"props":500,"children":501},{},[502],{"type":32,"value":503},"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.",{"type":27,"tag":35,"props":505,"children":507},{"id":506},"hypothetical-the-two-of-three-corporate-wallet",[508],{"type":32,"value":509},"Hypothetical: The Two-of-Three Corporate Wallet",{"type":27,"tag":28,"props":511,"children":512},{},[513],{"type":32,"value":514},"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.",{"type":27,"tag":28,"props":516,"children":517},{},[518,520,526],{"type":32,"value":519},"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 ",{"type":27,"tag":47,"props":521,"children":523},{"href":522},"\u002Fresources\u002Fself-custody-vs-custodial-wallets",[524],{"type":32,"value":525},"self-custody discovery playbook",{"type":32,"value":527},".",{"type":27,"tag":35,"props":529,"children":531},{"id":530},"limitations-and-the-questions-to-ask",[532],{"type":32,"value":533},"Limitations and the Questions to Ask",{"type":27,"tag":28,"props":535,"children":536},{},[537],{"type":32,"value":538},"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.",{"type":27,"tag":28,"props":540,"children":541},{},[542],{"type":32,"value":543},"The discovery questions that follow:",{"type":27,"tag":206,"props":545,"children":546},{},[547,552,557,562,567,572,577],{"type":27,"tag":210,"props":548,"children":549},{},[550],{"type":32,"value":551},"Was the address an EOA or a contract at the relevant date, including any EIP-7702 delegation indicator, and what implementation is behind it?",{"type":27,"tag":210,"props":553,"children":554},{},[555],{"type":32,"value":556},"Produce the full configuration history: every owner, threshold, module, and guard change, with transaction hashes.",{"type":27,"tag":210,"props":558,"children":559},{},[560],{"type":32,"value":561},"Produce raw transaction input data and event logs for each disputed transaction, not block explorer summaries.",{"type":27,"tag":210,"props":563,"children":564},{},[565],{"type":32,"value":566},"Which disputed transactions ran through modules, and what code was each module running?",{"type":27,"tag":210,"props":568,"children":569},{},[570],{"type":32,"value":571},"Who submitted each execution and who paid gas, including bundler and paymaster activity?",{"type":27,"tag":210,"props":573,"children":574},{},[575],{"type":32,"value":576},"Produce confirmation and signing records from any wallet provider interface used before execution.",{"type":27,"tag":210,"props":578,"children":579},{},[580],{"type":32,"value":581},"Document key custody for every owner address: devices, seed phrases, corporate policy, personnel changes.",{"type":27,"tag":28,"props":583,"children":584},{},[585,587,593,595,601],{"type":32,"value":586},"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 ",{"type":27,"tag":47,"props":588,"children":590},{"href":589},"\u002Fresources\u002Fsmart-contract-disputes",[591],{"type":32,"value":592},"smart contract disputes article",{"type":32,"value":594}," covers how courts treat it. Our ",{"type":27,"tag":47,"props":596,"children":598},{"href":597},"\u002Fmethodology",[599],{"type":32,"value":600},"methodology page",{"type":32,"value":602}," explains how expert reports separate chain facts from inference.",{"type":27,"tag":35,"props":604,"children":606},{"id":605},"frequently-asked-questions",[607],{"type":32,"value":608},"Frequently Asked Questions",{"type":27,"tag":97,"props":610,"children":612},{"id":611},"q-is-a-multisig-address-owned-by-any-single-person",[613],{"type":32,"value":614},"Q: Is a multisig address owned by any single person?",{"type":27,"tag":28,"props":616,"children":617},{},[618,624],{"type":27,"tag":619,"props":620,"children":621},"strong",{},[622],{"type":32,"value":623},"A:",{"type":32,"value":625}," 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.",{"type":27,"tag":97,"props":627,"children":629},{"id":628},"q-if-a-transaction-was-signed-by-enough-owners-who-is-responsible-for-it",[630],{"type":32,"value":631},"Q: If a transaction was signed by enough owners, who is responsible for it?",{"type":27,"tag":28,"props":633,"children":634},{},[635,639],{"type":27,"tag":619,"props":636,"children":637},{},[638],{"type":32,"value":623},{"type":32,"value":640}," 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.",{"type":27,"tag":97,"props":642,"children":644},{"id":643},"q-can-activity-from-an-erc-4337-smart-account-be-traced-to-the-person-who-initiated-it",[645],{"type":32,"value":646},"Q: Can activity from an ERC-4337 smart account be traced to the person who initiated it?",{"type":27,"tag":28,"props":648,"children":649},{},[650,654],{"type":27,"tag":619,"props":651,"children":652},{},[653],{"type":32,"value":623},{"type":32,"value":655}," 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.",{"type":27,"tag":97,"props":657,"children":659},{"id":658},"q-what-does-it-mean-if-a-wallet-was-not-deployed-when-the-disputed-authorization-happened",[660],{"type":32,"value":661},"Q: What does it mean if a wallet was not deployed when the disputed authorization happened?",{"type":27,"tag":28,"props":663,"children":664},{},[665,669],{"type":27,"tag":619,"props":666,"children":667},{},[668],{"type":32,"value":623},{"type":32,"value":670}," 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.",{"type":27,"tag":97,"props":672,"children":674},{"id":673},"q-what-discovery-should-you-request-when-the-other-side-controls-a-contract-wallet",[675],{"type":32,"value":676},"Q: What discovery should you request when the other side controls a contract wallet?",{"type":27,"tag":28,"props":678,"children":679},{},[680,684],{"type":27,"tag":619,"props":681,"children":682},{},[683],{"type":32,"value":623},{"type":32,"value":685}," 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.",{"type":27,"tag":28,"props":687,"children":688},{},[689,691,697,699,705,707,713],{"type":32,"value":690},"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, ",{"type":27,"tag":47,"props":692,"children":694},{"href":693},"\u002Fcontact",[695],{"type":32,"value":696},"contact us",{"type":32,"value":698}," to discuss the evidence picture, or see how ",{"type":27,"tag":47,"props":700,"children":702},{"href":701},"\u002Fservices#blockchain-tracing",[703],{"type":32,"value":704},"blockchain tracing engagements",{"type":32,"value":706}," and ",{"type":27,"tag":47,"props":708,"children":710},{"href":709},"\u002Fservices#litigation-consulting",[711],{"type":32,"value":712},"litigation consulting",{"type":32,"value":714}," are structured.",{"title":8,"searchDepth":716,"depth":716,"links":717},2,[718,719,727,728,729,730,731,732,733],{"id":37,"depth":716,"text":40},{"id":92,"depth":716,"text":95,"children":720},[721,723,724,725,726],{"id":99,"depth":722,"text":102},3,{"id":110,"depth":722,"text":113},{"id":121,"depth":722,"text":124},{"id":140,"depth":722,"text":143},{"id":167,"depth":722,"text":170},{"id":196,"depth":716,"text":199},{"id":255,"depth":716,"text":258},{"id":266,"depth":716,"text":269},{"id":291,"depth":716,"text":294},{"id":506,"depth":716,"text":509},{"id":530,"depth":716,"text":533},{"id":605,"depth":716,"text":608,"children":734},[735,736,737,738,739],{"id":611,"depth":722,"text":614},{"id":628,"depth":722,"text":631},{"id":643,"depth":722,"text":646},{"id":658,"depth":722,"text":661},{"id":673,"depth":722,"text":676},"markdown","content:articles:38-multisig-contract-wallet-attribution.md","content","articles\u002F38-multisig-contract-wallet-attribution.md","articles\u002F38-multisig-contract-wallet-attribution","md",{"_path":747,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":748,"description":749,"slug":750,"date":751,"lastUpdated":751,"author":13,"readingTime":14,"category":15,"tags":752,"ogImage":755,"featured":7,"body":756,"_type":740,"_id":1770,"_source":742,"_file":1771,"_stem":1772,"_extension":745},"\u002Farticles\u002F27-evm-receipts-logs-execution-traces","Beyond the transaction hash: receipts, logs, and EVM traces","A transaction hash proves submission, not success. Receipts, event logs, and EVM traces answer whether execution succeeded and what assets moved.","evm-receipts-logs-execution-traces","2026-06-13",[753,20,754,21],"ethereum","blockchain-tracing","\u002Fog\u002Fevm-receipts-logs-execution-traces.png",{"type":24,"children":757,"toc":1751},[758,770,776,843,876,882,942,972,978,1029,1035,1048,1123,1158,1164,1209,1236,1293,1299,1304,1341,1367,1373,1381,1393,1426,1460,1486,1521,1526,1532,1537,1542,1547,1552,1557,1562,1568,1637,1643,1648,1652,1658,1681,1687,1696,1702,1724,1730,1739],{"type":27,"tag":28,"props":759,"children":760},{},[761,763,769],{"type":32,"value":762},"A transaction hash is where most investigations start and where too many stop. The hash identifies the envelope: the signed message broadcast to the network, containing the sender, the recipient, the value, and the input data. It does not say whether execution succeeded, which contracts actually ran, or what assets moved. Those facts live in other artifacts: the receipt, the event logs, the call tree, and the execution trace. Each answers a different question and each carries different evidentiary weight. Explorer pages fuse these layers into one screen, which is exactly why lawyers overstate what a hash proves. For the fundamentals of reading a single transaction, ",{"type":27,"tag":47,"props":764,"children":766},{"href":765},"\u002Fresources\u002Fhow-to-read-a-blockchain-transaction",[767],{"type":32,"value":768},"start with the basic guide",{"type":32,"value":527},{"type":27,"tag":35,"props":771,"children":773},{"id":772},"why-the-transaction-hash-proves-submission-not-execution",[774],{"type":32,"value":775},"Why the Transaction Hash Proves Submission, Not Execution",{"type":27,"tag":28,"props":777,"children":778},{},[779,781,787,789,796,798,804,806,812,813,819,820,826,828,834,836,841],{"type":32,"value":780},"The hash is a cryptographic fingerprint of the signed transaction, computed from the transaction data at signing time. Retrieving the transaction object through ",{"type":27,"tag":72,"props":782,"children":784},{"className":783},[],[785],{"type":32,"value":786},"eth_getTransactionByHash",{"type":32,"value":788},", a method in the ",{"type":27,"tag":47,"props":790,"children":793},{"href":791,"rel":792},"https:\u002F\u002Fgithub.com\u002Fethereum\u002Fexecution-apis",[51],[794],{"type":32,"value":795},"execution-apis JSON-RPC collection",{"type":32,"value":797},", returns the envelope: ",{"type":27,"tag":72,"props":799,"children":801},{"className":800},[],[802],{"type":32,"value":803},"from",{"type":32,"value":805},", ",{"type":27,"tag":72,"props":807,"children":809},{"className":808},[],[810],{"type":32,"value":811},"to",{"type":32,"value":805},{"type":27,"tag":72,"props":814,"children":816},{"className":815},[],[817],{"type":32,"value":818},"value",{"type":32,"value":805},{"type":27,"tag":72,"props":821,"children":823},{"className":822},[],[824],{"type":32,"value":825},"input",{"type":32,"value":827}," data, ",{"type":27,"tag":72,"props":829,"children":831},{"className":830},[],[832],{"type":32,"value":833},"nonce",{"type":32,"value":835},", gas parameters, fee fields, block number, and index. The ",{"type":27,"tag":72,"props":837,"children":839},{"className":838},[],[840],{"type":32,"value":803},{"type":32,"value":842}," address is derived from the cryptographic signature, so the envelope establishes which account signed the message, not which person held that account.",{"type":27,"tag":28,"props":844,"children":845},{},[846,848,853,855,860,862,867,869,874],{"type":32,"value":847},"If ",{"type":27,"tag":72,"props":849,"children":851},{"className":850},[],[852],{"type":32,"value":811},{"type":32,"value":854}," is a contract address, the ",{"type":27,"tag":72,"props":856,"children":858},{"className":857},[],[859],{"type":32,"value":825},{"type":32,"value":861}," field is an encoded function call, and the envelope alone does not reveal what that function did, whether it succeeded, or whether any token changed hands. The ",{"type":27,"tag":72,"props":863,"children":865},{"className":864},[],[866],{"type":32,"value":818},{"type":32,"value":868}," field carries only native ETH and only the top-level amount: a 5,000 USDC transfer typically appears with a ",{"type":27,"tag":72,"props":870,"children":872},{"className":871},[],[873],{"type":32,"value":818},{"type":32,"value":875}," of zero. Confirm finality before treating a mined hash as settled: a transaction in a block reorganized out of the canonical chain can disappear from the record.",{"type":27,"tag":35,"props":877,"children":879},{"id":878},"the-receipt-the-networks-verdict-on-success",[880],{"type":32,"value":881},"The Receipt: The Network's Verdict on Success",{"type":27,"tag":28,"props":883,"children":884},{},[885,887,893,895,902,904,910,912,918,919,925,926,932,934,940],{"type":32,"value":886},"Unlike a trace, a receipt is consensus data. Blocks commit a receipts root, and a node that still holds the relevant history can serve the receipt via ",{"type":27,"tag":72,"props":888,"children":890},{"className":889},[],[891],{"type":32,"value":892},"eth_getTransactionReceipt",{"type":32,"value":894},". The ",{"type":27,"tag":47,"props":896,"children":899},{"href":897,"rel":898},"https:\u002F\u002Fgithub.com\u002Fethereum\u002Fexecution-apis\u002Fblob\u002Fmain\u002Fsrc\u002Fschemas\u002Freceipt.yaml",[51],[900],{"type":32,"value":901},"execution-apis receipt schema",{"type":32,"value":903}," requires ",{"type":27,"tag":72,"props":905,"children":907},{"className":906},[],[908],{"type":32,"value":909},"status",{"type":32,"value":911}," (after Byzantium), ",{"type":27,"tag":72,"props":913,"children":915},{"className":914},[],[916],{"type":32,"value":917},"gasUsed",{"type":32,"value":805},{"type":27,"tag":72,"props":920,"children":922},{"className":921},[],[923],{"type":32,"value":924},"cumulativeGasUsed",{"type":32,"value":805},{"type":27,"tag":72,"props":927,"children":929},{"className":928},[],[930],{"type":32,"value":931},"logs",{"type":32,"value":933},", and ",{"type":27,"tag":72,"props":935,"children":937},{"className":936},[],[938],{"type":32,"value":939},"effectiveGasPrice",{"type":32,"value":941},", the amount actually deducted per gas. Some clients prune old receipts and return a \"pruned history unavailable\" error, so confirm the node still holds the block before treating a missing receipt as proof that the transaction never existed.",{"type":27,"tag":28,"props":943,"children":944},{},[945,947,954,956,963,965,970],{"type":32,"value":946},"Status semantics come from ",{"type":27,"tag":47,"props":948,"children":951},{"href":949,"rel":950},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-658",[51],[952],{"type":32,"value":953},"EIP-658",{"type":32,"value":955},", which replaced the receipt's intermediate state root with a status code: 1 for success, 0 for failure. The change activated with the ",{"type":27,"tag":47,"props":957,"children":960},{"href":958,"rel":959},"https:\u002F\u002Fblog.ethereum.org\u002F2017\u002F10\u002F12\u002Fbyzantium-hf-announcement",[51],[961],{"type":32,"value":962},"Byzantium hard fork",{"type":32,"value":964}," at block 4,370,000 on October 16, 2017. Transactions before that fork have no status field, and failure was inferred by comparing ",{"type":27,"tag":72,"props":966,"children":968},{"className":967},[],[969],{"type":32,"value":917},{"type":32,"value":971}," against the gas limit. EIP-658's own motivation explains why that heuristic became unsound: with the REVERT opcode, \"it is no longer possible for users to assume that a transaction failed iff it consumed all gas.\" For pre-Byzantium transactions, the outcome can only be reconstructed by replaying execution.",{"type":27,"tag":97,"props":973,"children":975},{"id":974},"failed-transactions-still-cost-money",[976],{"type":32,"value":977},"Failed Transactions Still Cost Money",{"type":27,"tag":28,"props":979,"children":980},{},[981,983,990,992,998,999,1005,1007,1012,1014,1019,1021,1027],{"type":32,"value":982},"A status of 0 means the top-level call failed and every state change rolled back. The transaction is still recorded, its nonce is consumed, and the sender pays for gas actually used. After Byzantium that is often well below the gas limit: ",{"type":27,"tag":47,"props":984,"children":987},{"href":985,"rel":986},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-140",[51],[988],{"type":32,"value":989},"EIP-140",{"type":32,"value":991}," added REVERT so a contract can \"stop execution and revert state changes, without consuming all provided gas.\" Solidity ",{"type":27,"tag":72,"props":993,"children":995},{"className":994},[],[996],{"type":32,"value":997},"require",{"type":32,"value":706},{"type":27,"tag":72,"props":1000,"children":1002},{"className":1001},[],[1003],{"type":32,"value":1004},"revert",{"type":32,"value":1006}," use that opcode. Exceptional failures such as out-of-gas still consume remaining gas. ",{"type":27,"tag":72,"props":1008,"children":1010},{"className":1009},[],[1011],{"type":32,"value":917},{"type":32,"value":1013}," multiplied by ",{"type":27,"tag":72,"props":1015,"children":1017},{"className":1016},[],[1018],{"type":32,"value":939},{"type":32,"value":1020}," (or ",{"type":27,"tag":72,"props":1022,"children":1024},{"className":1023},[],[1025],{"type":32,"value":1026},"gasPrice",{"type":32,"value":1028}," where that is the legacy price) is the fee figure, usable for damages even when the transfer failed. Success means only that the call did not revert, so no asset conclusion should rest on the status field alone.",{"type":27,"tag":35,"props":1030,"children":1032},{"id":1031},"event-logs-the-contracts-own-testimony",[1033],{"type":32,"value":1034},"Event Logs: The Contract's Own Testimony",{"type":27,"tag":28,"props":1036,"children":1037},{},[1038,1040,1046],{"type":32,"value":1039},"Logs are stored inside the receipt and emitted by contract code during execution. Each log carries the emitting contract address, up to four indexed topics, and a data payload, and history can be queried with ",{"type":27,"tag":72,"props":1041,"children":1043},{"className":1042},[],[1044],{"type":32,"value":1045},"eth_getLogs",{"type":32,"value":1047},", filtered by address and topic signature. The \"token transfers\" panels on explorers are decodes of these logs, not independent data.",{"type":27,"tag":28,"props":1049,"children":1050},{},[1051,1053,1060,1062,1068,1070,1076,1077,1083,1085,1091,1093,1099,1101,1106,1108,1114,1116,1121],{"type":32,"value":1052},"The ",{"type":27,"tag":47,"props":1054,"children":1057},{"href":1055,"rel":1056},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-20",[51],[1058],{"type":32,"value":1059},"ERC-20 standard (EIP-20)",{"type":32,"value":1061}," requires a ",{"type":27,"tag":72,"props":1063,"children":1065},{"className":1064},[],[1066],{"type":32,"value":1067},"Transfer",{"type":32,"value":1069}," event on every ",{"type":27,"tag":72,"props":1071,"children":1073},{"className":1072},[],[1074],{"type":32,"value":1075},"transfer",{"type":32,"value":706},{"type":27,"tag":72,"props":1078,"children":1080},{"className":1079},[],[1081],{"type":32,"value":1082},"transferFrom",{"type":32,"value":1084}," call, including zero-value transfers, and an ",{"type":27,"tag":72,"props":1086,"children":1088},{"className":1087},[],[1089],{"type":32,"value":1090},"Approval",{"type":32,"value":1092}," event on every successful ",{"type":27,"tag":72,"props":1094,"children":1096},{"className":1095},[],[1097],{"type":32,"value":1098},"approve",{"type":32,"value":1100},". A token that creates new tokens SHOULD emit a ",{"type":27,"tag":72,"props":1102,"children":1104},{"className":1103},[],[1105],{"type":32,"value":1067},{"type":32,"value":1107}," with ",{"type":27,"tag":72,"props":1109,"children":1111},{"className":1110},[],[1112],{"type":32,"value":1113},"_from",{"type":32,"value":1115}," set to the zero address. Those conventions are why ",{"type":27,"tag":72,"props":1117,"children":1119},{"className":1118},[],[1120],{"type":32,"value":1067},{"type":32,"value":1122}," logs are the backbone of token-flow reconstruction.",{"type":27,"tag":28,"props":1124,"children":1125},{},[1126,1128,1133,1135,1140,1142,1148,1150,1156],{"type":32,"value":1127},"The protocol does not enforce any of it. Events are emitted by whatever code the contract runs, and the EVM does not check whether an emitted ",{"type":27,"tag":72,"props":1129,"children":1131},{"className":1130},[],[1132],{"type":32,"value":1067},{"type":32,"value":1134}," corresponds to a real balance change. A noncompliant contract can emit a ",{"type":27,"tag":72,"props":1136,"children":1138},{"className":1137},[],[1139],{"type":32,"value":1067},{"type":32,"value":1141}," without moving a token, or move tokens while emitting nothing. EIP-140 notes that reverting an EVM execution means \"all changes, including LOGs, are lost,\" so a failed transaction's receipt carries no logs, and an event from a failed subcall disappears even when the surrounding transaction succeeds. Fee-on-transfer and rebasing tokens can log an amount that differs from the balance delta. Treat logs as admissions by the contract, not ground truth. Corroborate with ",{"type":27,"tag":72,"props":1143,"children":1145},{"className":1144},[],[1146],{"type":32,"value":1147},"balanceOf",{"type":32,"value":1149}," at the relevant block via ",{"type":27,"tag":72,"props":1151,"children":1153},{"className":1152},[],[1154],{"type":32,"value":1155},"eth_call",{"type":32,"value":1157},", check that an allowance was consumed, and confirm the flow against the call tree.",{"type":27,"tag":35,"props":1159,"children":1161},{"id":1160},"the-call-tree-what-actually-executed",[1162],{"type":32,"value":1163},"The Call Tree: What Actually Executed",{"type":27,"tag":28,"props":1165,"children":1166},{},[1167,1169,1175,1177,1184,1186,1191,1192,1198,1200,1207],{"type":32,"value":1168},"One envelope can fan out into many internal executions, and the shape of that tree is often the entire case. A contract that calls another executes the callee's code in the callee's context, with the caller as ",{"type":27,"tag":72,"props":1170,"children":1172},{"className":1171},[],[1173],{"type":32,"value":1174},"msg.sender",{"type":32,"value":1176},". Delegatecall, the opcode ",{"type":27,"tag":47,"props":1178,"children":1181},{"href":1179,"rel":1180},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-7",[51],[1182],{"type":32,"value":1183},"added in the Homestead fork (EIP-7)",{"type":32,"value":1185},", inverts that: the callee's code runs in the caller's storage context, preserving ",{"type":27,"tag":72,"props":1187,"children":1189},{"className":1188},[],[1190],{"type":32,"value":1174},{"type":32,"value":706},{"type":27,"tag":72,"props":1193,"children":1195},{"className":1194},[],[1196],{"type":32,"value":1197},"msg.value",{"type":32,"value":1199},". This is the mechanism behind ",{"type":27,"tag":47,"props":1201,"children":1204},{"href":1202,"rel":1203},"https:\u002F\u002Fwww.openzeppelin.com\u002Fnews\u002Fproxy-patterns",[51],[1205],{"type":32,"value":1206},"upgradeable proxies",{"type":32,"value":1208},", where a user calls a proxy address and the proxy delegatecalls an implementation contract. The forensic consequence is direct: the address that received the call is not necessarily the address whose code ran, and a plain transaction page will not tell you which is which.",{"type":27,"tag":28,"props":1210,"children":1211},{},[1212,1214,1219,1221,1227,1229,1234],{"type":32,"value":1213},"Routers and aggregators add a third layer. A swap transaction shows ",{"type":27,"tag":72,"props":1215,"children":1217},{"className":1216},[],[1218],{"type":32,"value":811},{"type":32,"value":1220}," equal to a router address; the call tree shows the router calling pair contracts, which move tokens on their own ledgers. ETH that a contract forwards onward appears only in the trace, and ERC-20 movement appears only in the token contract's logs and ledger. Where holdings pass through several protocol contracts inside one transaction, ",{"type":27,"tag":47,"props":1222,"children":1224},{"href":1223},"\u002Fresources\u002Fwhat-lawyers-need-to-know-about-defi",[1225],{"type":32,"value":1226},"tracing through DeFi mechanics",{"type":32,"value":1228}," is where that analysis gets its teeth, while ",{"type":27,"tag":47,"props":1230,"children":1231},{"href":589},[1232],{"type":32,"value":1233},"smart contract disputes",{"type":32,"value":1235}," covers the contract interpretation and remedies side of the same record.",{"type":27,"tag":28,"props":1237,"children":1238},{},[1239,1241,1248,1250,1257,1259,1266,1268,1274,1276,1283,1285,1291],{"type":32,"value":1240},"Retrieval is where standardization ends. Tracing RPCs are client-specific: geth exposes trace methods in its ",{"type":27,"tag":47,"props":1242,"children":1245},{"href":1243,"rel":1244},"https:\u002F\u002Fgeth.ethereum.org\u002Fdocs\u002Finteracting-with-geth\u002Frpc\u002Fns-debug",[51],[1246],{"type":32,"value":1247},"debug namespace",{"type":32,"value":1249}," and documents tracing as ",{"type":27,"tag":47,"props":1251,"children":1254},{"href":1252,"rel":1253},"https:\u002F\u002Fgeth.ethereum.org\u002Fdocs\u002Fdevelopers\u002Fevm-tracing",[51],[1255],{"type":32,"value":1256},"re-running transactions locally",{"type":32,"value":1258},". ",{"type":27,"tag":47,"props":1260,"children":1263},{"href":1261,"rel":1262},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-3155",[51],[1264],{"type":32,"value":1265},"EIP-3155",{"type":32,"value":1267}," proposed a JSON format for EVM traces during state tests; it remains at Last Call and is not a finalized ",{"type":27,"tag":72,"props":1269,"children":1271},{"className":1270},[],[1272],{"type":32,"value":1273},"debug_traceTransaction",{"type":32,"value":1275}," standard. ",{"type":27,"tag":47,"props":1277,"children":1280},{"href":1278,"rel":1279},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-1474",[51],[1281],{"type":32,"value":1282},"EIP-1474",{"type":32,"value":1284},", which cataloged JSON-RPC methods, is stagnant; the maintained specification is the ",{"type":27,"tag":47,"props":1286,"children":1288},{"href":791,"rel":1287},[51],[1289],{"type":32,"value":1290},"execution-apis repository",{"type":32,"value":1292},". Because output depends on the client, its version, and the tracer, an expert's methodology documentation matters as much as the trace itself.",{"type":27,"tag":35,"props":1294,"children":1296},{"id":1295},"node-and-archive-requirements-for-reproducible-tracing",[1297],{"type":32,"value":1298},"Node and Archive Requirements for Reproducible Tracing",{"type":27,"tag":28,"props":1300,"children":1301},{},[1302],{"type":32,"value":1303},"Traces are re-execution, not stored data. Reproducing what a transaction did requires the state that existed at that block.",{"type":27,"tag":28,"props":1305,"children":1306},{},[1307,1309,1316,1317,1323,1325,1331,1333,1339],{"type":32,"value":1308},"A full node caches only recent state, on the order of the last 128 blocks, per ",{"type":27,"tag":47,"props":1310,"children":1313},{"href":1311,"rel":1312},"https:\u002F\u002Fethereum.org\u002Fdevelopers\u002Fdocs\u002Fnodes-and-clients\u002Farchive-nodes\u002F",[51],[1314],{"type":32,"value":1315},"ethereum.org's archive-node documentation",{"type":32,"value":706},{"type":27,"tag":47,"props":1318,"children":1320},{"href":1252,"rel":1319},[51],[1321],{"type":32,"value":1322},"geth's tracing notes",{"type":32,"value":1324},". Older states can be regenerated from checkpoints, which becomes expensive the further back you go. Geth's default ",{"type":27,"tag":72,"props":1326,"children":1328},{"className":1327},[],[1329],{"type":32,"value":1330},"reexec",{"type":32,"value":1332}," window is 128 blocks; beyond it, a trace fails unless the window is increased or the node is an archive node. An ",{"type":27,"tag":47,"props":1334,"children":1336},{"href":1311,"rel":1335},[51],[1337],{"type":32,"value":1338},"archive node",{"type":32,"value":1340}," stores historical states so those queries return immediately, at the cost of multiple terabytes of disk. Confirm archive-state access or provider tracing support before promising a trace of an old transaction, and record the node type, client version, sync mode, tracer, and block height.",{"type":27,"tag":28,"props":1342,"children":1343},{},[1344,1346,1351,1353,1358,1359,1365],{"type":32,"value":1345},"Opcode-level traces can run to hundreds of megabytes for a busy transaction, which makes them impractical to attach wholesale; high-level call tracers are compact but capture a different layer. Execution is deterministic given the same client, state, and tracer, but different client versions can produce different output. Our ",{"type":27,"tag":47,"props":1347,"children":1348},{"href":597},[1349],{"type":32,"value":1350},"methodology",{"type":32,"value":1352}," treats reproducibility and documented retrieval as core requirements of blockchain forensic work; for packaging this evidence for court, ConsensusIntel offers ",{"type":27,"tag":47,"props":1354,"children":1355},{"href":701},[1356],{"type":32,"value":1357},"blockchain tracing",{"type":32,"value":706},{"type":27,"tag":47,"props":1360,"children":1362},{"href":1361},"\u002Fservices#evidence-review",[1363],{"type":32,"value":1364},"evidence review",{"type":32,"value":1366}," built around artifact-level preservation rather than explorer screenshots.",{"type":27,"tag":35,"props":1368,"children":1370},{"id":1369},"hypothetical-example-one-transaction-four-evidence-layers",[1371],{"type":32,"value":1372},"Hypothetical Example: One Transaction, Four Evidence Layers",{"type":27,"tag":28,"props":1374,"children":1375},{},[1376],{"type":27,"tag":619,"props":1377,"children":1378},{},[1379],{"type":32,"value":1380},"Hypothetical example: the addresses and amounts below are invented for illustration; no real matter is described.",{"type":27,"tag":28,"props":1382,"children":1383},{},[1384,1386,1391],{"type":32,"value":1385},"A victim account (V) has an outstanding ",{"type":27,"tag":72,"props":1387,"children":1389},{"className":1388},[],[1390],{"type":32,"value":1098},{"type":32,"value":1392}," to an attacker-controlled contract (D) for 5,000 USDC. D was deployed with code that delegatecalls a reusable template (T). V signs a single transaction to D. The explorer shows \"Method: transfer\", \"Status: Success\", and a tokens-transferred panel reading \"USDC 5,000 from V to A\".",{"type":27,"tag":28,"props":1394,"children":1395},{},[1396,1398,1403,1405,1410,1412,1417,1419,1424],{"type":32,"value":1397},"Layer 1, the envelope: ",{"type":27,"tag":72,"props":1399,"children":1401},{"className":1400},[],[1402],{"type":32,"value":803},{"type":32,"value":1404}," V, ",{"type":27,"tag":72,"props":1406,"children":1408},{"className":1407},[],[1409],{"type":32,"value":811},{"type":32,"value":1411}," D, ",{"type":27,"tag":72,"props":1413,"children":1415},{"className":1414},[],[1416],{"type":32,"value":818},{"type":32,"value":1418}," 0, a small ",{"type":27,"tag":72,"props":1420,"children":1422},{"className":1421},[],[1423],{"type":32,"value":825},{"type":32,"value":1425}," payload. V submitted a message to D; no ETH moved to D; there is no USDC in this artifact.",{"type":27,"tag":28,"props":1427,"children":1428},{},[1429,1431,1436,1438,1443,1445,1450,1452,1458],{"type":32,"value":1430},"Layer 2, the receipt: status 1, ",{"type":27,"tag":72,"props":1432,"children":1434},{"className":1433},[],[1435],{"type":32,"value":917},{"type":32,"value":1437}," 94,220, and three logs: ",{"type":27,"tag":72,"props":1439,"children":1441},{"className":1440},[],[1442],{"type":32,"value":1067},{"type":32,"value":1444}," from V to D of 5,000 USDC, ",{"type":27,"tag":72,"props":1446,"children":1448},{"className":1447},[],[1449],{"type":32,"value":1067},{"type":32,"value":1451}," from D to A of 5,000 USDC, and ",{"type":27,"tag":72,"props":1453,"children":1455},{"className":1454},[],[1456],{"type":32,"value":1457},"RewardsClaimed",{"type":32,"value":1459}," for V. Execution succeeded, the sender paid for the gas, and the USDC contract recorded two transfers.",{"type":27,"tag":28,"props":1461,"children":1462},{},[1463,1465,1470,1472,1477,1479,1484],{"type":32,"value":1464},"Layer 3, logs plus ledger state: ",{"type":27,"tag":72,"props":1466,"children":1468},{"className":1467},[],[1469],{"type":32,"value":1147},{"type":32,"value":1471}," at the final block shows V's USDC fell by 5,000, D's rose and then fell, and A's rose by 5,000. The ledger corroborates the two ",{"type":27,"tag":72,"props":1473,"children":1475},{"className":1474},[],[1476],{"type":32,"value":1067},{"type":32,"value":1478}," logs. ",{"type":27,"tag":72,"props":1480,"children":1482},{"className":1481},[],[1483],{"type":32,"value":1457},{"type":32,"value":1485}," corresponds to no balance change: a fabricated reward event with no asset behind it.",{"type":27,"tag":28,"props":1487,"children":1488},{},[1489,1491,1496,1498,1504,1506,1512,1514,1519],{"type":32,"value":1490},"Layer 4, the call tree: D delegatecalled T, so template code ran in D's storage with ",{"type":27,"tag":72,"props":1492,"children":1494},{"className":1493},[],[1495],{"type":32,"value":1174},{"type":32,"value":1497}," still V. D then called ",{"type":27,"tag":72,"props":1499,"children":1501},{"className":1500},[],[1502],{"type":32,"value":1503},"USDC.transferFrom",{"type":32,"value":1505}," to pull the allowance, ",{"type":27,"tag":72,"props":1507,"children":1509},{"className":1508},[],[1510],{"type":32,"value":1511},"USDC.transfer",{"type":32,"value":1513}," to send on to A, and forwarded 0.02 ETH to A internally. The executing code was T's, running in D's context, and 0.02 ETH reached A inside a transaction whose ",{"type":27,"tag":72,"props":1515,"children":1517},{"className":1516},[],[1518],{"type":32,"value":818},{"type":32,"value":1520}," field says zero.",{"type":27,"tag":28,"props":1522,"children":1523},{},[1524],{"type":32,"value":1525},"A careless report says \"V transferred USDC to A.\" A defensible report stacks the layers: the envelope proves V signed to D; the ledger plus logs prove the USDC flow; the trace proves which code ran and where the ETH landed.",{"type":27,"tag":35,"props":1527,"children":1529},{"id":1528},"a-hierarchy-of-claims-an-expert-can-defend",[1530],{"type":32,"value":1531},"A Hierarchy of Claims an Expert Can Defend",{"type":27,"tag":28,"props":1533,"children":1534},{},[1535],{"type":32,"value":1536},"From the envelope alone: submission, sender account, recipient, payload, fee parameters, and block inclusion.",{"type":27,"tag":28,"props":1538,"children":1539},{},[1540],{"type":32,"value":1541},"From the receipt: inclusion, success or failure, execution cost, and the set of logs emitted. Nothing about assets.",{"type":27,"tag":28,"props":1543,"children":1544},{},[1545],{"type":32,"value":1546},"From logs plus ledger reads: token flows as recorded by the token contract, always subject to that contract's truthfulness about its own state.",{"type":27,"tag":28,"props":1548,"children":1549},{},[1550],{"type":32,"value":1551},"From the call tree: which code executed, in whose storage context, in what order, and where ETH flowed internally.",{"type":27,"tag":28,"props":1553,"children":1554},{},[1555],{"type":32,"value":1556},"From state at a block: balances, allowances, and storage as the network recorded them, the ground-truth layer for assets.",{"type":27,"tag":28,"props":1558,"children":1559},{},[1560],{"type":32,"value":1561},"Below the line sit claims no artifact supports: who physically held the private key, what the sender intended, and anything that happened off-chain. Label every conclusion with its source layer. A report that lets a receipt's status carry the weight of a token movement, or a log carry the weight of a balance, has overstated the evidence.",{"type":27,"tag":35,"props":1563,"children":1565},{"id":1564},"a-practitioner-checklist-for-preserving-execution-evidence",[1566],{"type":32,"value":1567},"A Practitioner Checklist for Preserving Execution Evidence",{"type":27,"tag":206,"props":1569,"children":1570},{},[1571,1576,1600,1605,1617,1622,1627,1632],{"type":27,"tag":210,"props":1572,"children":1573},{},[1574],{"type":32,"value":1575},"Confirm the transaction is on the canonical chain and check finality before treating the hash as settled.",{"type":27,"tag":210,"props":1577,"children":1578},{},[1579,1581,1586,1587,1592,1593,1598],{"type":32,"value":1580},"Capture raw JSON output for ",{"type":27,"tag":72,"props":1582,"children":1584},{"className":1583},[],[1585],{"type":32,"value":786},{"type":32,"value":805},{"type":27,"tag":72,"props":1588,"children":1590},{"className":1589},[],[1591],{"type":32,"value":892},{"type":32,"value":933},{"type":27,"tag":72,"props":1594,"children":1596},{"className":1595},[],[1597],{"type":32,"value":1045},{"type":32,"value":1599}," at query time; record the timestamp, the node or provider, the client and version, and the exact parameters.",{"type":27,"tag":210,"props":1601,"children":1602},{},[1603],{"type":32,"value":1604},"Preserve a hash of every exported file and note whether the data came from a direct node query, a provider API, or an explorer, because those sources differ in provenance.",{"type":27,"tag":210,"props":1606,"children":1607},{},[1608,1610,1615],{"type":32,"value":1609},"Read token balances and relevant storage at the final block with ",{"type":27,"tag":72,"props":1611,"children":1613},{"className":1612},[],[1614],{"type":32,"value":1155},{"type":32,"value":1616},", and check that allowances were consumed.",{"type":27,"tag":210,"props":1618,"children":1619},{},[1620],{"type":32,"value":1621},"Obtain a call-level trace with call types and depths, plus a state diff showing pre and post values for the balances at issue.",{"type":27,"tag":210,"props":1623,"children":1624},{},[1625],{"type":32,"value":1626},"If the transaction failed, preserve the revert reason from the trace alongside the receipt.",{"type":27,"tag":210,"props":1628,"children":1629},{},[1630],{"type":32,"value":1631},"For transactions older than roughly the state-retention window, confirm archive-state access or provider tracing before commissioning a trace, and record the tracer configuration.",{"type":27,"tag":210,"props":1633,"children":1634},{},[1635],{"type":32,"value":1636},"Cross-check at least one field against a second independent source. Use explorer screenshots only as supporting exhibits; the raw JSON is the primary record.",{"type":27,"tag":35,"props":1638,"children":1640},{"id":1639},"limitations",[1641],{"type":32,"value":1642},"Limitations",{"type":27,"tag":28,"props":1644,"children":1645},{},[1646],{"type":32,"value":1647},"Traces and logs reconstruct execution, not people. They cannot prove who held a private key, what a party intended, or any off-chain fact. Explorer \"internal transactions\" tabs are client-generated renderings, not consensus data. Reorganizations can orphan a transaction, log queries can be range-limited, and some nodes prune old receipts. On layer-2 rollups, receipts describe sequencer-era execution and the layer-1 commitments are a separate artifact. Everything before October 2017 on Ethereum lacks a receipt status, and the absence of an event proves nothing. How a court weighs these artifacts depends on the forum's evidence rules.",{"type":27,"tag":35,"props":1649,"children":1650},{"id":605},[1651],{"type":32,"value":608},{"type":27,"tag":97,"props":1653,"children":1655},{"id":1654},"q-the-explorer-shows-method-transfer-and-status-success-does-that-prove-the-tokens-were-sent",[1656],{"type":32,"value":1657},"Q: The explorer shows \"Method: transfer\" and \"Status: Success\". Does that prove the tokens were sent?",{"type":27,"tag":28,"props":1659,"children":1660},{},[1661,1665,1667,1672,1674,1679],{"type":27,"tag":619,"props":1662,"children":1663},{},[1664],{"type":32,"value":623},{"type":32,"value":1666}," No. Status proves only that the transaction did not revert. Token movement is evidenced by the token contract's ",{"type":27,"tag":72,"props":1668,"children":1670},{"className":1669},[],[1671],{"type":32,"value":1067},{"type":32,"value":1673}," logs and by ",{"type":27,"tag":72,"props":1675,"children":1677},{"className":1676},[],[1678],{"type":32,"value":1147},{"type":32,"value":1680}," at the relevant block. The explorer's \"transfer\" label is a decode of the input data and says nothing about whether tokens moved.",{"type":27,"tag":97,"props":1682,"children":1684},{"id":1683},"q-what-is-the-difference-between-a-receipt-and-a-trace",[1685],{"type":32,"value":1686},"Q: What is the difference between a receipt and a trace?",{"type":27,"tag":28,"props":1688,"children":1689},{},[1690,1694],{"type":27,"tag":619,"props":1691,"children":1692},{},[1693],{"type":32,"value":623},{"type":32,"value":1695}," A receipt is consensus data: status, gas used, and logs, stored with the block. A trace is a reconstruction: a node re-executes the transaction locally. Receipts exist for every included transaction the node still holds. Traces depend on the client, the tracer, and historical state, which generally means an archive node for old transactions. There is no finalized trace-format standard.",{"type":27,"tag":97,"props":1697,"children":1699},{"id":1698},"q-a-failed-transaction-still-costs-gas-what-can-the-fee-evidence-prove",[1700],{"type":32,"value":1701},"Q: A failed transaction still costs gas. What can the fee evidence prove?",{"type":27,"tag":28,"props":1703,"children":1704},{},[1705,1709,1711,1716,1717,1722],{"type":27,"tag":619,"props":1706,"children":1707},{},[1708],{"type":32,"value":623},{"type":32,"value":1710}," ",{"type":27,"tag":72,"props":1712,"children":1714},{"className":1713},[],[1715],{"type":32,"value":917},{"type":32,"value":1013},{"type":27,"tag":72,"props":1718,"children":1720},{"className":1719},[],[1721],{"type":32,"value":939},{"type":32,"value":1723}," is the fee the sender paid, which can support damages even when the transfer failed. The receipt also proves the failure: status 0, state changes rolled back, nonce consumed. That pairing can establish that the account was operated, that an attempt occurred, and what it cost.",{"type":27,"tag":97,"props":1725,"children":1727},{"id":1726},"q-how-far-back-can-execution-traces-be-recovered",[1728],{"type":32,"value":1729},"Q: How far back can execution traces be recovered?",{"type":27,"tag":28,"props":1731,"children":1732},{},[1733,1737],{"type":27,"tag":619,"props":1734,"children":1735},{},[1736],{"type":32,"value":623},{"type":32,"value":1738}," Envelope, receipt, and logs are available only if the node still holds that history; some clients prune old receipts. Traces require state as of the target block. Recent transactions can be traced on a full node; old ones generally need an archive node or a tracing provider. Pre-Byzantium transactions (before October 2017) have no receipt status and can only be reconstructed by replay.",{"type":27,"tag":28,"props":1740,"children":1741},{},[1742,1744,1749],{"type":32,"value":1743},"Every matter turns on its own facts, and the weight a court gives these artifacts depends on the jurisdiction, the claims, and how the evidence was collected and preserved. If you are litigating or investigating a matter where EVM execution details matter, ",{"type":27,"tag":47,"props":1745,"children":1746},{"href":693},[1747],{"type":32,"value":1748},"contact ConsensusIntel",{"type":32,"value":1750}," to discuss what a forensic analysis can defensibly establish from your specific transactions.",{"title":8,"searchDepth":716,"depth":716,"links":1752},[1753,1754,1757,1758,1759,1760,1761,1762,1763,1764],{"id":772,"depth":716,"text":775},{"id":878,"depth":716,"text":881,"children":1755},[1756],{"id":974,"depth":722,"text":977},{"id":1031,"depth":716,"text":1034},{"id":1160,"depth":716,"text":1163},{"id":1295,"depth":716,"text":1298},{"id":1369,"depth":716,"text":1372},{"id":1528,"depth":716,"text":1531},{"id":1564,"depth":716,"text":1567},{"id":1639,"depth":716,"text":1642},{"id":605,"depth":716,"text":608,"children":1765},[1766,1767,1768,1769],{"id":1654,"depth":722,"text":1657},{"id":1683,"depth":722,"text":1686},{"id":1698,"depth":722,"text":1701},{"id":1726,"depth":722,"text":1729},"content:articles:27-evm-receipts-logs-execution-traces.md","articles\u002F27-evm-receipts-logs-execution-traces.md","articles\u002F27-evm-receipts-logs-execution-traces",{"_path":1774,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":1775,"description":1776,"slug":1777,"date":1778,"lastUpdated":1778,"author":13,"readingTime":1779,"category":1780,"tags":1781,"ogImage":1784,"featured":7,"body":1785,"_type":740,"_id":2537,"_source":742,"_file":2538,"_stem":2539,"_extension":745},"\u002Farticles\u002F26-token-approvals-permit-signatures","Token approvals, permits, and transfer attribution","Explains how ERC-20 approvals and permit signatures separate token ownership, transfer submission, delegated authority, and proof of owner intent.","token-approvals-permit-signatures","2026-06-06",10,"Education",[21,20,1782,1783],"wallet-ownership","litigation","\u002Fog\u002Ftoken-approvals-permit-signatures.png",{"type":24,"children":1786,"toc":2519},[1787,1792,1797,1803,1808,1843,1855,1861,1866,1958,1977,1988,1994,2022,2035,2082,2088,2093,2190,2202,2208,2235,2247,2261,2266,2278,2284,2289,2294,2300,2312,2317,2323,2328,2371,2383,2389,2394,2417,2430,2434,2440,2463,2469,2478,2484,2493,2499,2508],{"type":27,"tag":28,"props":1788,"children":1789},{},[1790],{"type":32,"value":1791},"An ERC-20 token leaving a wallet does not necessarily mean the wallet owner submitted the transfer transaction or approved that particular recipient. The owner may previously have granted another address authority to spend tokens through an allowance. A signed permit can create the same authority even though the owner never broadcasts an approval transaction.",{"type":27,"tag":28,"props":1793,"children":1794},{},[1795],{"type":32,"value":1796},"That distinction matters in fraud, commercial, and probate matters. The blockchain can establish that a token balance changed, but the investigator still must separate the transaction sender, token owner, authorized spender, recipient, and signature author before drawing conclusions about human intent.",{"type":27,"tag":35,"props":1798,"children":1800},{"id":1799},"why-is-a-token-transfer-different-from-a-native-asset-transfer",[1801],{"type":32,"value":1802},"Why is a token transfer different from a native-asset transfer?",{"type":27,"tag":28,"props":1804,"children":1805},{},[1806],{"type":32,"value":1807},"In an ordinary top-level transfer of a blockchain's native asset, such as ETH, the transaction sender signs a transaction containing its destination and value. Contract execution can produce additional native-asset movements, so even that record may require a trace. ERC-20 tokens add another layer because the token contract maintains the balances.",{"type":27,"tag":28,"props":1809,"children":1810},{},[1811,1812,1818,1820,1826,1828,1834,1836,1841],{"type":32,"value":1052},{"type":27,"tag":47,"props":1813,"children":1815},{"href":1055,"rel":1814},[51],[1816],{"type":32,"value":1817},"ERC-20 token standard",{"type":32,"value":1819}," defines two relevant transfer paths. A holder can call ",{"type":27,"tag":72,"props":1821,"children":1823},{"className":1822},[],[1824],{"type":32,"value":1825},"transfer(to, value)",{"type":32,"value":1827}," from the holder's own address. Alternatively, another address can call ",{"type":27,"tag":72,"props":1829,"children":1831},{"className":1830},[],[1832],{"type":32,"value":1833},"transferFrom(from, to, value)",{"type":32,"value":1835}," after the token owner has authorized that spender. Both paths can produce the same ",{"type":27,"tag":72,"props":1837,"children":1839},{"className":1838},[],[1840],{"type":32,"value":1067},{"type":32,"value":1842}," event showing tokens moving from the owner's balance to the recipient.",{"type":27,"tag":28,"props":1844,"children":1845},{},[1846,1848,1853],{"type":32,"value":1847},"A block explorer's token-transfer display therefore answers an accounting question: which token contract recorded a debit, a credit, and an amount? It does not, by itself, answer who signed the outer transaction or why the debit was authorized. For the foundational transaction fields, see ",{"type":27,"tag":47,"props":1849,"children":1850},{"href":765},[1851],{"type":32,"value":1852},"how to read a blockchain transaction",{"type":32,"value":1854},". The unique issue here is delegated token authority.",{"type":27,"tag":35,"props":1856,"children":1858},{"id":1857},"which-addresses-perform-the-relevant-roles",[1859],{"type":32,"value":1860},"Which addresses perform the relevant roles?",{"type":27,"tag":28,"props":1862,"children":1863},{},[1864],{"type":32,"value":1865},"A defensible analysis identifies each role separately rather than using \"sender\" for all of them:",{"type":27,"tag":1867,"props":1868,"children":1869},"ul",{},[1870,1894,1911,1921,1938,1948],{"type":27,"tag":210,"props":1871,"children":1872},{},[1873,1878,1880,1885,1887,1892],{"type":27,"tag":619,"props":1874,"children":1875},{},[1876],{"type":32,"value":1877},"Token owner:",{"type":32,"value":1879}," The address whose token balance is debited. In a ",{"type":27,"tag":72,"props":1881,"children":1883},{"className":1882},[],[1884],{"type":32,"value":1082},{"type":32,"value":1886}," call, this is the ",{"type":27,"tag":72,"props":1888,"children":1890},{"className":1889},[],[1891],{"type":32,"value":803},{"type":32,"value":1893}," argument.",{"type":27,"tag":210,"props":1895,"children":1896},{},[1897,1902,1904,1909],{"type":27,"tag":619,"props":1898,"children":1899},{},[1900],{"type":32,"value":1901},"Spender:",{"type":32,"value":1903}," The address whose allowance permits it to withdraw from the owner's balance. In a standard direct ",{"type":27,"tag":72,"props":1905,"children":1907},{"className":1906},[],[1908],{"type":32,"value":1082},{"type":32,"value":1910}," call, this is the immediate caller seen by the token contract.",{"type":27,"tag":210,"props":1912,"children":1913},{},[1914,1919],{"type":27,"tag":619,"props":1915,"children":1916},{},[1917],{"type":32,"value":1918},"Transaction sender:",{"type":32,"value":1920}," The address recovered as the signer of the outer blockchain transaction. It may be the owner, the spender, or an address interacting with another contract.",{"type":27,"tag":210,"props":1922,"children":1923},{},[1924,1929,1931,1936],{"type":27,"tag":619,"props":1925,"children":1926},{},[1927],{"type":32,"value":1928},"Recipient:",{"type":32,"value":1930}," The address credited in the token contract's ",{"type":27,"tag":72,"props":1932,"children":1934},{"className":1933},[],[1935],{"type":32,"value":1067},{"type":32,"value":1937}," event.",{"type":27,"tag":210,"props":1939,"children":1940},{},[1941,1946],{"type":27,"tag":619,"props":1942,"children":1943},{},[1944],{"type":32,"value":1945},"Token contract:",{"type":32,"value":1947}," The contract that enforces balances and allowances and emits the relevant events.",{"type":27,"tag":210,"props":1949,"children":1950},{},[1951,1956],{"type":27,"tag":619,"props":1952,"children":1953},{},[1954],{"type":32,"value":1955},"Signature author:",{"type":32,"value":1957}," For a permit, the address whose private key produced the authorization signature. A relayer can submit that signature on-chain later.",{"type":27,"tag":28,"props":1959,"children":1960},{},[1961,1963,1968,1970,1975],{"type":32,"value":1962},"These roles can collapse into fewer addresses. An owner may call ",{"type":27,"tag":72,"props":1964,"children":1966},{"className":1965},[],[1967],{"type":32,"value":1075},{"type":32,"value":1969}," directly. In a routed transaction, the owner may call an application contract, that contract may be the approved spender, and the token contract may debit the owner through ",{"type":27,"tag":72,"props":1971,"children":1973},{"className":1972},[],[1974],{"type":32,"value":1082},{"type":32,"value":1976},". In a disputed delegated transfer, the owner's address may appear only as the debited account.",{"type":27,"tag":28,"props":1978,"children":1979},{},[1980,1982,1987],{"type":32,"value":1981},"The next question is attribution to a person. An address-level finding does not establish who controlled the address at the relevant time. That requires the separate analysis described in ",{"type":27,"tag":47,"props":1983,"children":1984},{"href":247},[1985],{"type":32,"value":1986},"understanding wallet ownership evidence",{"type":32,"value":527},{"type":27,"tag":35,"props":1989,"children":1991},{"id":1990},"how-does-an-erc-20-allowance-create-delegated-authority",[1992],{"type":32,"value":1993},"How does an ERC-20 allowance create delegated authority?",{"type":27,"tag":28,"props":1995,"children":1996},{},[1997,1999,2005,2007,2012,2014,2020],{"type":32,"value":1998},"Under ERC-20, ",{"type":27,"tag":72,"props":2000,"children":2002},{"className":2001},[],[2003],{"type":32,"value":2004},"approve(spender, value)",{"type":32,"value":2006}," sets the amount that a spender may withdraw from the owner's account. Calling ",{"type":27,"tag":72,"props":2008,"children":2010},{"className":2009},[],[2011],{"type":32,"value":1098},{"type":32,"value":2013}," again overwrites the existing allowance for that owner-spender pair. The standard's ",{"type":27,"tag":72,"props":2015,"children":2017},{"className":2016},[],[2018],{"type":32,"value":2019},"allowance(owner, spender)",{"type":32,"value":2021}," function reports how much the spender is still allowed to withdraw.",{"type":27,"tag":28,"props":2023,"children":2024},{},[2025,2027,2033],{"type":32,"value":2026},"An approval for a specific amount bounds the spender's authority by that value, subject to prior uses and the token's implementation. An approval set to the maximum ",{"type":27,"tag":72,"props":2028,"children":2030},{"className":2029},[],[2031],{"type":32,"value":2032},"uint256",{"type":32,"value":2034}," value is commonly treated as effectively unlimited because it may support repeated withdrawals. Standard ERC-20 approval data identifies a spender and amount, not the later recipient or business purpose.",{"type":27,"tag":28,"props":2036,"children":2037},{},[2038,2040,2045,2047,2052,2054,2059,2061,2066,2068,2073,2075,2080],{"type":32,"value":2039},"The events also have limits. ERC-20 requires an ",{"type":27,"tag":72,"props":2041,"children":2043},{"className":2042},[],[2044],{"type":32,"value":1090},{"type":32,"value":2046}," event after a successful ",{"type":27,"tag":72,"props":2048,"children":2050},{"className":2049},[],[2051],{"type":32,"value":1098},{"type":32,"value":2053}," call and a ",{"type":27,"tag":72,"props":2055,"children":2057},{"className":2056},[],[2058],{"type":32,"value":1067},{"type":32,"value":2060}," event when tokens move. It does not require an ",{"type":27,"tag":72,"props":2062,"children":2064},{"className":2063},[],[2065],{"type":32,"value":1090},{"type":32,"value":2067}," event every time ",{"type":27,"tag":72,"props":2069,"children":2071},{"className":2070},[],[2072],{"type":32,"value":1082},{"type":32,"value":2074}," consumes allowance. An investigator should not assume the latest visible ",{"type":27,"tag":72,"props":2076,"children":2078},{"className":2077},[],[2079],{"type":32,"value":1090},{"type":32,"value":2081}," event equals the remaining allowance immediately before a disputed transfer.",{"type":27,"tag":35,"props":2083,"children":2085},{"id":2084},"how-should-counsel-reconstruct-the-approval-timeline",[2086],{"type":32,"value":2087},"How should counsel reconstruct the approval timeline?",{"type":27,"tag":28,"props":2089,"children":2090},{},[2091],{"type":32,"value":2092},"The key sequence is authority first, use second. A useful reconstruction proceeds as follows:",{"type":27,"tag":206,"props":2094,"children":2095},{},[2096,2106,2129,2139,2163,2180],{"type":27,"tag":210,"props":2097,"children":2098},{},[2099,2104],{"type":27,"tag":619,"props":2100,"children":2101},{},[2102],{"type":32,"value":2103},"Fix the chain, token contract, and block range.",{"type":32,"value":2105}," Record the contract address, chain identifier, transaction hashes, block numbers, and UTC timestamps. A ticker symbol is not enough.",{"type":27,"tag":210,"props":2107,"children":2108},{},[2109,2114,2116,2121,2122,2127],{"type":27,"tag":619,"props":2110,"children":2111},{},[2112],{"type":32,"value":2113},"Classify the movement.",{"type":32,"value":2115}," Decode the input and trace to determine whether the token received ",{"type":27,"tag":72,"props":2117,"children":2119},{"className":2118},[],[2120],{"type":32,"value":1075},{"type":32,"value":805},{"type":27,"tag":72,"props":2123,"children":2125},{"className":2124},[],[2126],{"type":32,"value":1082},{"type":32,"value":2128},", or an intermediary-contract call. Do not rely solely on an explorer's summary label.",{"type":27,"tag":210,"props":2130,"children":2131},{},[2132,2137],{"type":27,"tag":619,"props":2133,"children":2134},{},[2135],{"type":32,"value":2136},"Identify the immediate caller.",{"type":32,"value":2138}," The outer transaction sender and the contract that called the token may differ. The trace shows which address acted as spender at the token contract.",{"type":27,"tag":210,"props":2140,"children":2141},{},[2142,2147,2149,2154,2156,2161],{"type":27,"tag":619,"props":2143,"children":2144},{},[2145],{"type":32,"value":2146},"Locate the grant of authority.",{"type":32,"value":2148}," Search backward for relevant ",{"type":27,"tag":72,"props":2150,"children":2152},{"className":2151},[],[2153],{"type":32,"value":1090},{"type":32,"value":2155}," events and transactions involving the same owner, spender, and token. Determine whether authority arose from ",{"type":27,"tag":72,"props":2157,"children":2159},{"className":2158},[],[2160],{"type":32,"value":1098},{"type":32,"value":2162},", a permit, or a token-specific mechanism.",{"type":27,"tag":210,"props":2164,"children":2165},{},[2166,2171,2173,2178],{"type":27,"tag":619,"props":2167,"children":2168},{},[2169],{"type":32,"value":2170},"Calculate intervening use.",{"type":32,"value":2172}," Review prior ",{"type":27,"tag":72,"props":2174,"children":2176},{"className":2175},[],[2177],{"type":32,"value":1082},{"type":32,"value":2179}," calls, replacements, revocations, and failed calls. Where available, query contract state immediately before execution.",{"type":27,"tag":210,"props":2181,"children":2182},{},[2183,2188],{"type":27,"tag":619,"props":2184,"children":2185},{},[2186],{"type":32,"value":2187},"Preserve the data.",{"type":32,"value":2189}," Retain input, receipts, logs, traces, relevant contract code, ABI, and retrieval method. A screenshot is an orientation aid, not the complete record.",{"type":27,"tag":28,"props":2191,"children":2192},{},[2193,2195,2200],{"type":32,"value":2194},"Proxy contracts and upgrades can change the relevant code over time. The correct question is what logic governed the token at the disputed block, not what a current block-explorer page displays today. Our ",{"type":27,"tag":47,"props":2196,"children":2197},{"href":1361},[2198],{"type":32,"value":2199},"evidence review work",{"type":32,"value":2201}," treats decoded explorer labels as leads to verify against contract data, not as substitutes for it.",{"type":27,"tag":35,"props":2203,"children":2205},{"id":2204},"what-changes-when-authority-comes-from-a-permit-signature",[2206],{"type":32,"value":2207},"What changes when authority comes from a permit signature?",{"type":27,"tag":28,"props":2209,"children":2210},{},[2211,2218,2220,2226,2228,2233],{"type":27,"tag":47,"props":2212,"children":2215},{"href":2213,"rel":2214},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-2612",[51],[2216],{"type":32,"value":2217},"ERC-2612",{"type":32,"value":2219}," adds a ",{"type":27,"tag":72,"props":2221,"children":2223},{"className":2222},[],[2224],{"type":32,"value":2225},"permit",{"type":32,"value":2227}," function that can set an ERC-20 allowance from a signed message. The signed fields include the owner, spender, value, nonce, and deadline. The token contract verifies the signature, updates the allowance, increments the owner's nonce, and emits an ",{"type":27,"tag":72,"props":2229,"children":2231},{"className":2230},[],[2232],{"type":32,"value":1090},{"type":32,"value":2234}," event if the standard's conditions are satisfied.",{"type":27,"tag":28,"props":2236,"children":2237},{},[2238,2240,2245],{"type":32,"value":2239},"The permit caller can be any address. The owner can sign off-chain, while a relayer, application, spender, or unrelated address pays gas and submits the permit. The permit transaction sender is therefore not necessarily the signature author. The permit grants allowance; it does not prove that the owner submitted or separately approved a later ",{"type":27,"tag":72,"props":2241,"children":2243},{"className":2242},[],[2244],{"type":32,"value":1082},{"type":32,"value":2246}," transaction.",{"type":27,"tag":28,"props":2248,"children":2249},{},[2250,2252,2259],{"type":32,"value":2251},"ERC-2612 uses ",{"type":27,"tag":47,"props":2253,"children":2256},{"href":2254,"rel":2255},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-712",[51],[2257],{"type":32,"value":2258},"EIP-712 typed structured-data signing",{"type":32,"value":2260},". Its domain can include a name, version, chain identifier, and verifying-contract address, helping distinguish similar messages intended for different applications or contracts. EIP-712 supplies the format and domain separation, but leaves replay protection to the application.",{"type":27,"tag":28,"props":2262,"children":2263},{},[2264],{"type":32,"value":2265},"ERC-2612 uses an owner nonce that must match and then increments, plus a deadline after which the permit must revert. The deadline can be set so far out that the authorization is effectively nonexpiring. Examine the domain, nonce, and deadline together. A signature image or shortened wallet prompt does not establish the complete signed data.",{"type":27,"tag":28,"props":2267,"children":2268},{},[2269,2271,2276],{"type":32,"value":2270},"Not every token with a function called ",{"type":27,"tag":72,"props":2272,"children":2274},{"className":2273},[],[2275],{"type":32,"value":2225},{"type":32,"value":2277}," implements ERC-2612 exactly. The standard itself notes preexisting variants with different fields and semantics. The analyst must use the deployed contract's code and ABI at the relevant block rather than forcing every signed approval into the ERC-2612 template.",{"type":27,"tag":35,"props":2279,"children":2281},{"id":2280},"what-does-the-transfer-prove-and-what-remains-unresolved",[2282],{"type":32,"value":2283},"What does the transfer prove, and what remains unresolved?",{"type":27,"tag":28,"props":2285,"children":2286},{},[2287],{"type":32,"value":2288},"A verified on-chain record can establish that contract execution changed token balances and emitted specified logs. Decoded input and traces can identify the outer transaction sender, immediate callers, owner argument, recipient, amount, and method. A valid permit can establish that a signature associated with the owner address covered the exact typed fields under the contract's rules.",{"type":27,"tag":28,"props":2290,"children":2291},{},[2292],{"type":32,"value":2293},"Those facts do not prove that a particular human knowingly authorized the disputed transfer. They do not establish who possessed the key, what the wallet displayed, whether the signer understood the authority, or whether another person had device access. They also do not resolve consent, agency, capacity, mistake, breach of duty, or fraud. Those conclusions depend on governing law and evidence beyond the ledger.",{"type":27,"tag":97,"props":2295,"children":2297},{"id":2296},"hypothetical-example",[2298],{"type":32,"value":2299},"Hypothetical example",{"type":27,"tag":28,"props":2301,"children":2302},{},[2303,2305,2311],{"type":32,"value":2304},"Assume Wallet O holds 80,000 units of Token T. On January 4, O signs an ERC-2612 permit authorizing Contract S to spend up to 80,000 units, with a deadline six months later. Relayer R submits the permit and pays the gas. On February 12, Address A calls S, and S executes ",{"type":27,"tag":72,"props":2306,"children":2308},{"className":2307},[],[2309],{"type":32,"value":2310},"transferFrom(O, B, 30,000)",{"type":32,"value":527},{"type":27,"tag":28,"props":2313,"children":2314},{},[2315],{"type":32,"value":2316},"The February transfer shows Token T debited O and credited B during execution initiated by A. The trace may show S as the spender, while the January permit identifies R as its submitter. Neither transaction proves that the human associated with O selected B or understood that the signature let S choose a later recipient. The investigation should recover the typed message, identify who controlled O and A, inspect S's code and call parameters, and seek device and communications evidence.",{"type":27,"tag":35,"props":2318,"children":2320},{"id":2319},"what-evidence-should-counsel-request-beyond-the-chain",[2321],{"type":32,"value":2322},"What evidence should counsel request beyond the chain?",{"type":27,"tag":28,"props":2324,"children":2325},{},[2326],{"type":32,"value":2327},"Discovery should target the authorization event as closely as the transfer event. Useful requests and examination questions include:",{"type":27,"tag":1867,"props":2329,"children":2330},{},[2331,2336,2341,2346,2351,2356,2361,2366],{"type":27,"tag":210,"props":2332,"children":2333},{},[2334],{"type":32,"value":2335},"The wallet application, browser extension, hardware wallet, or custodial interface used when the approval or permit was created.",{"type":27,"tag":210,"props":2337,"children":2338},{},[2339],{"type":32,"value":2340},"Wallet records, device logs, browser history, notifications, and prompts showing what the user was presented.",{"type":27,"tag":210,"props":2342,"children":2343},{},[2344],{"type":32,"value":2345},"The exact EIP-712 typed-data payload, signature, domain fields, nonce, deadline, and originating website or application.",{"type":27,"tag":210,"props":2347,"children":2348},{},[2349],{"type":32,"value":2350},"Communications concerning the spender, transaction purpose, expected amount, intended recipient, and any claimed revocation.",{"type":27,"tag":210,"props":2352,"children":2353},{},[2354],{"type":32,"value":2355},"Evidence of remote access, malicious extensions, credential compromise, or shared key material.",{"type":27,"tag":210,"props":2357,"children":2358},{},[2359],{"type":32,"value":2360},"Exchange, custodian, or account records connecting the relevant addresses to identified persons.",{"type":27,"tag":210,"props":2362,"children":2363},{},[2364],{"type":32,"value":2365},"Source code, deployment records, upgrade history, and administrative controls for the token and spender contracts.",{"type":27,"tag":210,"props":2367,"children":2368},{},[2369],{"type":32,"value":2370},"Testimony explaining why the approval amount was chosen and whether the signer understood that approval and transfer were separate acts.",{"type":27,"tag":28,"props":2372,"children":2373},{},[2374,2376,2381],{"type":32,"value":2375},"Preserve timestamps, time zones, file metadata, and acquisition methods. Wallet prompts and local artifacts may disappear even though the on-chain record remains. The ",{"type":27,"tag":47,"props":2377,"children":2378},{"href":597},[2379],{"type":32,"value":2380},"ConsensusIntel methodology",{"type":32,"value":2382}," explains how technical findings are separated from attribution opinions and legal conclusions.",{"type":27,"tag":35,"props":2384,"children":2386},{"id":2385},"how-should-an-expert-describe-the-result",[2387],{"type":32,"value":2388},"How should an expert describe the result?",{"type":27,"tag":28,"props":2390,"children":2391},{},[2392],{"type":32,"value":2393},"Avoid language such as \"the owner sent the tokens\" unless the evidence actually establishes that proposition. A more precise formulation is:",{"type":27,"tag":2395,"props":2396,"children":2397},"blockquote",{},[2398],{"type":27,"tag":28,"props":2399,"children":2400},{},[2401,2403,2408,2410,2415],{"type":32,"value":2402},"Transaction X was signed by Address A. Its execution caused Token Contract T to emit a ",{"type":27,"tag":72,"props":2404,"children":2406},{"className":2405},[],[2407],{"type":32,"value":1067},{"type":32,"value":2409}," event debiting Owner Address O and crediting Recipient Address B. The execution trace shows Spender Contract S called ",{"type":27,"tag":72,"props":2411,"children":2413},{"className":2412},[],[2414],{"type":32,"value":1082},{"type":32,"value":2416},". An earlier approval authorized S to spend up to V units from O. The on-chain evidence does not, without additional attribution evidence, establish who controlled A or O, what a human signer understood, or whether O intended this specific transfer.",{"type":27,"tag":28,"props":2418,"children":2419},{},[2420,2422,2428],{"type":32,"value":2421},"If a permit is involved, the report should separately state whether the signature validated for the owner address, the exact fields covered, who submitted the permit transaction, and which later call exercised the allowance. This phrasing preserves strong technical conclusions while avoiding one of the ",{"type":27,"tag":47,"props":2423,"children":2425},{"href":2424},"\u002Fresources\u002Fcommon-mistakes-crypto-investigations",[2426],{"type":32,"value":2427},"common mistakes in cryptocurrency investigations",{"type":32,"value":2429},": treating address activity as self-proving evidence of a person's identity or intent.",{"type":27,"tag":35,"props":2431,"children":2432},{"id":605},[2433],{"type":32,"value":608},{"type":27,"tag":97,"props":2435,"children":2437},{"id":2436},"q-does-a-transfer-event-prove-the-token-owner-sent-the-transaction",[2438],{"type":32,"value":2439},"Q: Does a Transfer event prove the token owner sent the transaction?",{"type":27,"tag":28,"props":2441,"children":2442},{},[2443,2447,2449,2454,2456,2461],{"type":27,"tag":619,"props":2444,"children":2445},{},[2446],{"type":32,"value":623},{"type":32,"value":2448}," No. A ",{"type":27,"tag":72,"props":2450,"children":2452},{"className":2451},[],[2453],{"type":32,"value":1067},{"type":32,"value":2455}," event proves that the token contract recorded a movement from one address to another. If the movement resulted from ",{"type":27,"tag":72,"props":2457,"children":2459},{"className":2458},[],[2460],{"type":32,"value":1082},{"type":32,"value":2462},", an approved spender may have initiated it. The transaction input and execution trace are needed to identify the actual call path.",{"type":27,"tag":97,"props":2464,"children":2466},{"id":2465},"q-does-signing-a-permit-authorize-one-specific-transfer",[2467],{"type":32,"value":2468},"Q: Does signing a permit authorize one specific transfer?",{"type":27,"tag":28,"props":2470,"children":2471},{},[2472,2476],{"type":27,"tag":619,"props":2473,"children":2474},{},[2475],{"type":32,"value":623},{"type":32,"value":2477}," Not necessarily. A standard ERC-2612 permit authorizes a named spender up to a stated value, subject to a nonce and deadline. It does not name the eventual transfer recipient. The spender may use the resulting allowance in one or more later transactions within the authorization's bounds.",{"type":27,"tag":97,"props":2479,"children":2481},{"id":2480},"q-can-a-relayer-submit-a-permit-without-owning-the-tokens",[2482],{"type":32,"value":2483},"Q: Can a relayer submit a permit without owning the tokens?",{"type":27,"tag":28,"props":2485,"children":2486},{},[2487,2491],{"type":27,"tag":619,"props":2488,"children":2489},{},[2490],{"type":32,"value":623},{"type":32,"value":2492}," Yes. ERC-2612 does not tie the permit caller to the owner. Any address can submit a valid signed permit, while the token contract verifies that the signature corresponds to the owner and that the nonce and deadline conditions are satisfied.",{"type":27,"tag":97,"props":2494,"children":2496},{"id":2495},"q-what-is-the-most-important-evidence-outside-the-blockchain",[2497],{"type":32,"value":2498},"Q: What is the most important evidence outside the blockchain?",{"type":27,"tag":28,"props":2500,"children":2501},{},[2502,2506],{"type":27,"tag":619,"props":2503,"children":2504},{},[2505],{"type":32,"value":623},{"type":32,"value":2507}," The most useful evidence often includes the exact signed payload, wallet or device artifacts showing the signing context, records identifying who controlled each address, and communications about the spender and transaction purpose. Those materials address identity, knowledge, and intent that the ledger does not record.",{"type":27,"tag":28,"props":2509,"children":2510},{},[2511,2513,2517],{"type":32,"value":2512},"If a disputed token transfer turns on delegated authority, ",{"type":27,"tag":47,"props":2514,"children":2515},{"href":693},[2516],{"type":32,"value":1748},{"type":32,"value":2518}," to discuss the approval timeline, permit evidence, and limits of the available attribution.",{"title":8,"searchDepth":716,"depth":716,"links":2520},[2521,2522,2523,2524,2525,2526,2529,2530,2531],{"id":1799,"depth":716,"text":1802},{"id":1857,"depth":716,"text":1860},{"id":1990,"depth":716,"text":1993},{"id":2084,"depth":716,"text":2087},{"id":2204,"depth":716,"text":2207},{"id":2280,"depth":716,"text":2283,"children":2527},[2528],{"id":2296,"depth":722,"text":2299},{"id":2319,"depth":716,"text":2322},{"id":2385,"depth":716,"text":2388},{"id":605,"depth":716,"text":608,"children":2532},[2533,2534,2535,2536],{"id":2436,"depth":722,"text":2439},{"id":2465,"depth":722,"text":2468},{"id":2480,"depth":722,"text":2483},{"id":2495,"depth":722,"text":2498},"content:articles:26-token-approvals-permit-signatures.md","articles\u002F26-token-approvals-permit-signatures.md","articles\u002F26-token-approvals-permit-signatures",{"_path":2541,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":2542,"description":2543,"slug":2544,"date":2545,"lastUpdated":2545,"author":13,"readingTime":2546,"category":1780,"tags":2547,"ogImage":2552,"featured":7,"body":2553,"_type":740,"_id":2847,"_source":742,"_file":2848,"_stem":2849,"_extension":745},"\u002Farticles\u002F17-cryptocurrency-wrong-address-irrecoverability","What happens when cryptocurrency is sent to the wrong address","Learn why a cryptocurrency transfer to the wrong address is usually irreversible, which recovery paths may remain, and how counsel can assess them.","cryptocurrency-wrong-address-irrecoverability","2026-05-16",7,[2548,2549,2550,20,2551,753],"irreversibility","blockchain-evidence","recovery","bitcoin","\u002Fog\u002Fcryptocurrency-wrong-address-irrecoverability.png",{"type":24,"children":2554,"toc":2834},[2555,2560,2566,2571,2576,2581,2587,2597,2607,2617,2627,2637,2663,2669,2674,2691,2701,2711,2717,2722,2727,2732,2737,2743,2754,2759,2770,2774,2780,2789,2795,2804,2810,2819,2825],{"type":27,"tag":28,"props":2556,"children":2557},{},[2558],{"type":32,"value":2559},"One of the most consequential properties of public blockchain systems is the near-total irreversibility of confirmed transactions. When cryptocurrency is sent to the wrong address: through a typographical error, a scam, a technical mistake, or a moment of confusion, recovery is rarely possible through the same mechanisms that allow bank wire reversals or credit card chargebacks. Understanding why, and what options actually exist, is essential for attorneys handling client matters involving this scenario.",{"type":27,"tag":35,"props":2561,"children":2563},{"id":2562},"why-transfers-cannot-be-reversed",[2564],{"type":32,"value":2565},"Why Transfers Cannot Be Reversed",{"type":27,"tag":28,"props":2567,"children":2568},{},[2569],{"type":32,"value":2570},"Blockchain transactions are irreversible by design. When a transaction is confirmed and included in a block, the record of that transfer is incorporated into an append-only ledger replicated across thousands of nodes worldwide. No single party, not an exchange, not a developer, not any government, has the technical authority to reach into the ledger and undo a confirmed transaction.",{"type":27,"tag":28,"props":2572,"children":2573},{},[2574],{"type":32,"value":2575},"This is not a policy choice that can be reversed by calling customer service. It is an architectural feature. The value of the immutability guarantee, which makes blockchain records trustworthy as evidence, is inseparable from the fact that no one can alter records after the fact, including to correct a mistake.",{"type":27,"tag":28,"props":2577,"children":2578},{},[2579],{"type":32,"value":2580},"The private key controls the funds. Whoever possesses the private key for the destination address can authorize the next transaction from that address. If the destination address is controlled by an unintended third party, recovery requires that party's cooperation. If the destination address has no known controller, a burned or unspendable address, recovery is impossible.",{"type":27,"tag":35,"props":2582,"children":2584},{"id":2583},"scenarios-and-what-each-means",[2585],{"type":32,"value":2586},"Scenarios and What Each Means",{"type":27,"tag":28,"props":2588,"children":2589},{},[2590,2595],{"type":27,"tag":619,"props":2591,"children":2592},{},[2593],{"type":32,"value":2594},"Typo resulting in a valid but unintended address",{"type":32,"value":2596},": If a sender mistypes a wallet address and the resulting address is a valid address that happens to exist on the blockchain, the funds are received by whoever controls that address, or they sit at an address with no known controller. Most addresses generated by random typos will be uncontrolled, no one has the private key, but the funds are still irretrievable because no private key exists to authorize a transaction out.",{"type":27,"tag":28,"props":2598,"children":2599},{},[2600,2605],{"type":27,"tag":619,"props":2601,"children":2602},{},[2603],{"type":32,"value":2604},"Hypothetical example:",{"type":32,"value":2606}," A sender transposes characters while entering an address and sends funds to a valid address with no known controller. Once the transfer is confirmed, the sender cannot authorize a new transaction from that destination without its private key.",{"type":27,"tag":28,"props":2608,"children":2609},{},[2610,2615],{"type":27,"tag":619,"props":2611,"children":2612},{},[2613],{"type":32,"value":2614},"Funds sent to a known exchange address",{"type":32,"value":2616},": If the destination address belongs to a centralized exchange (Coinbase, Kraken, Binance, etc.), the exchange controls the private key. Exchanges generally have processes for recovering mistakenly sent funds into their hot wallet infrastructure, but these processes are discretionary, may require extensive documentation, and often involve fees. Some exchanges refuse to assist at all. There is no legal obligation in most jurisdictions requiring an exchange to return mistakenly sent funds, though restitution and unjust enrichment theories may provide an equitable basis for a claim.",{"type":27,"tag":28,"props":2618,"children":2619},{},[2620,2625],{"type":27,"tag":619,"props":2621,"children":2622},{},[2623],{"type":32,"value":2624},"Funds sent to a smart contract address",{"type":32,"value":2626},": Many cryptocurrency tokens sent to a smart contract that has no function to return or handle them are permanently locked. The classic example is ERC-20 tokens sent to the ERC-20 token contract itself: a common mistake. The contract typically has no function to recover such tokens, and because the contract is code (not a human-controlled wallet), no one can override it. Hundreds of millions of dollars in ERC-20 tokens have been permanently locked this way.",{"type":27,"tag":28,"props":2628,"children":2629},{},[2630,2635],{"type":27,"tag":619,"props":2631,"children":2632},{},[2633],{"type":32,"value":2634},"Funds sent through a scam",{"type":32,"value":2636},": When a victim sends cryptocurrency in response to a phishing email, impersonation scam, or other fraud, the destination address was provided by the scammer, who controls the private key and will immediately move the funds. This is a theft scenario, not a transaction error, and is analyzed differently forensically.",{"type":27,"tag":28,"props":2638,"children":2639},{},[2640,2645,2647,2653,2655,2661],{"type":27,"tag":619,"props":2641,"children":2642},{},[2643],{"type":32,"value":2644},"The \"burned\" address scenario",{"type":32,"value":2646},": Some addresses are known to be unspendable by design. The most common is address ",{"type":27,"tag":72,"props":2648,"children":2650},{"className":2649},[],[2651],{"type":32,"value":2652},"0x000...0000",{"type":32,"value":2654}," (the zero address on Ethereum) or ",{"type":27,"tag":72,"props":2656,"children":2658},{"className":2657},[],[2659],{"type":32,"value":2660},"1BitcoinEaterAddressDoNotSend...",{"type":32,"value":2662}," on Bitcoin. Sending to these addresses permanently destroys the asset: the transaction is confirmed, the funds are received at the address, and no private key exists to move them.",{"type":27,"tag":35,"props":2664,"children":2666},{"id":2665},"legal-options-for-recovery",[2667],{"type":32,"value":2668},"Legal Options for Recovery",{"type":27,"tag":28,"props":2670,"children":2671},{},[2672],{"type":32,"value":2673},"Because blockchain transactions cannot be reversed by the sender, legal recovery requires either cooperation from the recipient or legal process compelling that cooperation.",{"type":27,"tag":28,"props":2675,"children":2676},{},[2677,2682,2684,2690],{"type":27,"tag":619,"props":2678,"children":2679},{},[2680],{"type":32,"value":2681},"Against a known exchange",{"type":32,"value":2683},": If forensic tracing establishes that the funds reached a centralized exchange wallet, and the exchange maintains customer records for that wallet, a legal demand or civil action may compel the exchange to hold and return the funds. The legal theory typically involves unjust enrichment, constructive trust, or restitution. The success of this approach depends on whether the exchange has a segregated customer account for the receiving address or pooled funds in an omnibus wallet. Counsel considering that path may also need to evaluate ",{"type":27,"tag":47,"props":2685,"children":2687},{"href":2686},"\u002Fresources\u002Fsubpoenaing-cryptocurrency-exchange-records",[2688],{"type":32,"value":2689},"subpoenaing cryptocurrency exchange records",{"type":32,"value":527},{"type":27,"tag":28,"props":2692,"children":2693},{},[2694,2699],{"type":27,"tag":619,"props":2695,"children":2696},{},[2697],{"type":32,"value":2698},"Against an identified scammer",{"type":32,"value":2700},": If the recipient is identified through exchange KYC records or other evidence, conventional fraud and theft remedies apply. The blockchain evidence establishing the fund flow is an essential component of the claim.",{"type":27,"tag":28,"props":2702,"children":2703},{},[2704,2709],{"type":27,"tag":619,"props":2705,"children":2706},{},[2707],{"type":32,"value":2708},"Against a party who made the error",{"type":32,"value":2710},": In some disputes, the wrongly addressed transaction was a mistake by a third party, a business partner, an employee, a financial professional, who sent funds to the wrong address. Negligence or breach of fiduciary duty claims against that party may be available regardless of whether the funds themselves are recoverable.",{"type":27,"tag":35,"props":2712,"children":2714},{"id":2713},"what-cannot-be-done",[2715],{"type":32,"value":2716},"What Cannot Be Done",{"type":27,"tag":28,"props":2718,"children":2719},{},[2720],{"type":32,"value":2721},"It is important to be clear with clients about what is not possible:",{"type":27,"tag":28,"props":2723,"children":2724},{},[2725],{"type":32,"value":2726},"No authority can reverse a confirmed blockchain transaction. The FBI, the SEC, and federal courts do not have the technical ability to reverse blockchain transfers. Courts can compel parties to transfer assets from their controlled addresses. They cannot reach into the blockchain and rearrange already-confirmed records.",{"type":27,"tag":28,"props":2728,"children":2729},{},[2730],{"type":32,"value":2731},"Blockchain analytics firms cannot recover funds. They can trace where funds went, identify the controlling party, and assist in locating the funds within the system, but that is investigation, not recovery.",{"type":27,"tag":28,"props":2733,"children":2734},{},[2735],{"type":32,"value":2736},"Exchange customer support cannot typically assist when the receiving address is not an exchange address. If the funds went to a private wallet that neither the sender nor the exchange controls, the exchange has no access to those funds.",{"type":27,"tag":35,"props":2738,"children":2740},{"id":2739},"the-forensic-role",[2741],{"type":32,"value":2742},"The Forensic Role",{"type":27,"tag":28,"props":2744,"children":2745},{},[2746,2748,2752],{"type":32,"value":2747},"A blockchain forensic expert can establish: the exact transaction details (hash, timestamp, amount, source, destination), confirmation that the transaction was final and included in the blockchain, the current state of the destination address (whether funds remain there or were subsequently moved), and, if funds were moved, where they went and whether they can be attributed to an identified party. This type of ",{"type":27,"tag":47,"props":2749,"children":2750},{"href":701},[2751],{"type":32,"value":1357},{"type":32,"value":2753}," helps determine whether recovery efforts can focus on an identifiable recipient or institution.",{"type":27,"tag":28,"props":2755,"children":2756},{},[2757],{"type":32,"value":2758},"This establishes the evidentiary record for any legal proceeding. The tracing analysis also determines whether legal process against an exchange or other institution is viable. If the funds reached an exchange wallet and remain there, the case for legal intervention is much stronger than if they moved through multiple wallets to a private address that cannot be attributed to anyone.",{"type":27,"tag":28,"props":2760,"children":2761},{},[2762,2764,2768],{"type":32,"value":2763},"The irreversibility of blockchain transactions is one of the most important practical realities attorneys must communicate to clients early in a matter. Setting accurate expectations while pursuing available legal remedies requires understanding both what the technology makes impossible and what the law may still provide. The ",{"type":27,"tag":47,"props":2765,"children":2766},{"href":597},[2767],{"type":32,"value":1350},{"type":32,"value":2769}," for documenting transaction evidence can help counsel assess the available next steps.",{"type":27,"tag":35,"props":2771,"children":2772},{"id":605},[2773],{"type":32,"value":608},{"type":27,"tag":97,"props":2775,"children":2777},{"id":2776},"q-what-information-should-counsel-preserve-before-deciding-whether-recovery-is-realistic",[2778],{"type":32,"value":2779},"Q: What information should counsel preserve before deciding whether recovery is realistic?",{"type":27,"tag":28,"props":2781,"children":2782},{},[2783,2787],{"type":27,"tag":619,"props":2784,"children":2785},{},[2786],{"type":32,"value":623},{"type":32,"value":2788}," Preserve the transaction hash, timestamp, amount, source address, destination address, and records showing how the address was obtained or used. A forensic expert can verify the confirmed transfer, determine whether the funds remain at the destination, and trace later movements. Those facts help show whether an identifiable recipient, exchange, or other institution is a viable target for legal process.",{"type":27,"tag":97,"props":2790,"children":2792},{"id":2791},"q-can-a-court-order-a-confirmed-cryptocurrency-transfer-to-be-reversed",[2793],{"type":32,"value":2794},"Q: Can a court order a confirmed cryptocurrency transfer to be reversed?",{"type":27,"tag":28,"props":2796,"children":2797},{},[2798,2802],{"type":27,"tag":619,"props":2799,"children":2800},{},[2801],{"type":32,"value":623},{"type":32,"value":2803}," No. A court cannot alter an already confirmed blockchain record. It can order a person or entity that controls the destination address to transfer assets, so the available remedy depends on identifying a party with control of the funds.",{"type":27,"tag":97,"props":2805,"children":2807},{"id":2806},"q-when-is-it-worth-seeking-records-or-relief-from-an-exchange",[2808],{"type":32,"value":2809},"Q: When is it worth seeking records or relief from an exchange?",{"type":27,"tag":28,"props":2811,"children":2812},{},[2813,2817],{"type":27,"tag":619,"props":2814,"children":2815},{},[2816],{"type":32,"value":623},{"type":32,"value":2818}," It is worth evaluating when tracing shows that the funds reached an exchange wallet. Exchange records may identify the customer associated with the wallet, but the result can depend on whether the exchange used a segregated customer account or pooled funds in an omnibus wallet. Documentation, fees, and the exchange's willingness to assist may also affect a practical recovery effort.",{"type":27,"tag":97,"props":2820,"children":2822},{"id":2821},"q-how-should-counsel-distinguish-a-wrong-address-error-from-a-cryptocurrency-scam",[2823],{"type":32,"value":2824},"Q: How should counsel distinguish a wrong-address error from a cryptocurrency scam?",{"type":27,"tag":28,"props":2826,"children":2827},{},[2828,2832],{"type":27,"tag":619,"props":2829,"children":2830},{},[2831],{"type":32,"value":623},{"type":32,"value":2833}," A mistaken transfer can place funds at a valid address with no known controller, while a scam transfer is made to an address supplied by a fraudster who controls the private key. The distinction depends on the surrounding evidence, such as phishing or impersonation communications, not on the transaction record alone. If the recipient can be identified through exchange KYC records or other evidence, fraud and theft remedies may be available.",{"title":8,"searchDepth":716,"depth":716,"links":2835},[2836,2837,2838,2839,2840,2841],{"id":2562,"depth":716,"text":2565},{"id":2583,"depth":716,"text":2586},{"id":2665,"depth":716,"text":2668},{"id":2713,"depth":716,"text":2716},{"id":2739,"depth":716,"text":2742},{"id":605,"depth":716,"text":608,"children":2842},[2843,2844,2845,2846],{"id":2776,"depth":722,"text":2779},{"id":2791,"depth":722,"text":2794},{"id":2806,"depth":722,"text":2809},{"id":2821,"depth":722,"text":2824},"content:articles:17-cryptocurrency-wrong-address-irrecoverability.md","articles\u002F17-cryptocurrency-wrong-address-irrecoverability.md","articles\u002F17-cryptocurrency-wrong-address-irrecoverability",{"_path":2851,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":2852,"description":2853,"slug":2854,"date":2855,"lastUpdated":2855,"author":13,"readingTime":2856,"category":1780,"tags":2857,"ogImage":2863,"featured":7,"body":2864,"_type":740,"_id":3281,"_source":742,"_file":3282,"_stem":3283,"_extension":745},"\u002Farticles\u002F10-smart-contract-disputes","Smart contract disputes: when code is not law","A plain-language guide to smart contract disputes, explaining code execution, common conflicts, forensic analysis, and expert evidence in litigation.","smart-contract-disputes","2026-05-08",14,[20,2858,2859,2860,2861,2862],"solidity","disputes","protocol","exploit","governance","\u002Fog\u002Fsmart-contract-disputes.png",{"type":24,"children":2865,"toc":3255},[2866,2871,2876,2882,2887,2892,2897,2902,2908,2913,2918,2923,2929,2935,2940,2945,2950,2956,2961,2966,2971,2977,2982,2987,2993,2998,3003,3009,3014,3019,3025,3031,3036,3041,3047,3060,3065,3071,3076,3081,3087,3092,3097,3103,3108,3113,3118,3124,3135,3155,3167,3171,3175,3181,3190,3196,3205,3211,3220,3226,3235,3240,3246],{"type":27,"tag":28,"props":2867,"children":2868},{},[2869],{"type":32,"value":2870},"Smart contracts are frequently described using a phrase that sounds definitive: \"code is law.\" The idea is that once a smart contract is deployed on a blockchain, it executes exactly as programmed, without any possibility of human intervention or deviation from the rules encoded in its code. This framing has rhetorical appeal in the context of technology that is specifically designed to remove trust and intermediaries from financial transactions. It is also, from a legal standpoint, incorrect.",{"type":27,"tag":28,"props":2872,"children":2873},{},[2874],{"type":32,"value":2875},"Courts do not stop functioning because a computer program executed. Fraud is still fraud. Misrepresentation is still misrepresentation. Property that is taken without authority remains taken. The fact that the taking was accomplished through a computer program that executed on a blockchain does not place the conduct beyond judicial reach. What changes is the investigative and evidentiary work required to understand what happened, who caused it, and what the blockchain record shows.",{"type":27,"tag":35,"props":2877,"children":2879},{"id":2878},"what-smart-contracts-are-and-how-they-execute",[2880],{"type":32,"value":2881},"What Smart Contracts Are and How They Execute",{"type":27,"tag":28,"props":2883,"children":2884},{},[2885],{"type":32,"value":2886},"A smart contract is a program stored on a blockchain that executes automatically when triggered by a transaction. Like any program, it has code that defines what it does and data that represents its current state. Unlike most programs, it runs on a distributed network where thousands of nodes independently verify that each execution produced the correct result, and the record of every execution is stored permanently on the blockchain.",{"type":27,"tag":28,"props":2888,"children":2889},{},[2890],{"type":32,"value":2891},"The most common language for writing smart contracts is Solidity, which compiles to EVM bytecode, the low-level instruction set that runs on the Ethereum Virtual Machine. When a user sends a transaction to a smart contract address, the EVM executes the contract's bytecode, updating the contract's state according to the program's logic and recording the entire execution trace on the blockchain.",{"type":27,"tag":28,"props":2893,"children":2894},{},[2895],{"type":32,"value":2896},"Every transaction that interacts with a smart contract produces a detailed record: the calling address, the function called, the parameters passed, the state changes that resulted, and any events (structured log entries) that the contract emitted. This execution trace is permanent and publicly accessible. For litigation purposes, this means the complete history of a contract's operation is available for forensic analysis.",{"type":27,"tag":28,"props":2898,"children":2899},{},[2900],{"type":32,"value":2901},"Smart contracts can hold cryptocurrency, execute transfers, interact with other contracts, and implement arbitrarily complex business logic. A single Ethereum transaction might invoke a chain of contract calls that moves funds through a dozen different protocols before the transaction completes, and the entire chain of events is recorded as a single traceable unit.",{"type":27,"tag":35,"props":2903,"children":2905},{"id":2904},"why-code-is-law-is-a-myth-in-legal-reality",[2906],{"type":32,"value":2907},"Why \"Code Is Law\" Is a Myth in Legal Reality",{"type":27,"tag":28,"props":2909,"children":2910},{},[2911],{"type":32,"value":2912},"The phrase captures something real: a smart contract executes exactly as its code specifies, and there is no central authority that can override it while it runs. If a contract is programmed to send funds to a specific address when certain conditions are met, it will do exactly that, regardless of whether the parties had a different understanding.",{"type":27,"tag":28,"props":2914,"children":2915},{},[2916],{"type":32,"value":2917},"But the phrase obscures more than it reveals. Smart contracts are written by human beings who make decisions about what the code should do. Those decisions can reflect misrepresentation, fraud, or breach of the legal obligations that exist between the parties before the contract runs. A user who deposits funds into a protocol based on representations about how it works has a legal relationship with the people who wrote and deployed that protocol. If those representations were false, or if the protocol was designed with a hidden function that allowed the developers to drain user funds, the legal claims that arise are not foreclosed by the fact that the theft was accomplished through code.",{"type":27,"tag":28,"props":2919,"children":2920},{},[2921],{"type":32,"value":2922},"Courts in a growing number of jurisdictions have handled smart contract disputes. They have applied fraud, misrepresentation, breach of contract, and securities law theories to conduct that happened on blockchains. What changes in smart contract disputes is not the applicable legal framework; it is the nature of the factual investigation required to understand and prove what happened.",{"type":27,"tag":35,"props":2924,"children":2926},{"id":2925},"common-dispute-scenarios",[2927],{"type":32,"value":2928},"Common Dispute Scenarios",{"type":27,"tag":97,"props":2930,"children":2932},{"id":2931},"rug-pulls-and-exit-scams",[2933],{"type":32,"value":2934},"Rug Pulls and Exit Scams",{"type":27,"tag":28,"props":2936,"children":2937},{},[2938],{"type":32,"value":2939},"A rug pull occurs when the developers of a DeFi protocol attract user deposits and then use a concealed administrative function in the smart contract to withdraw all user funds. The term is colloquial, but the underlying conduct is, in most cases, a straightforward fraud: investors were induced to deposit funds based on false representations about the protocol's operation, and the developers used a mechanism they did not disclose to steal those funds.",{"type":27,"tag":28,"props":2941,"children":2942},{},[2943],{"type":32,"value":2944},"Forensically, a rug pull investigation begins with the smart contract itself. Analysts examine the contract's source code (if verified and publicly available) or its compiled bytecode (if source code is unavailable) to identify the functions that the deployers used to drain funds. The transaction history shows exactly when those functions were called, how much was extracted, and where the extracted funds went. The deployer address, which is the blockchain address that deployed the contract, is a key starting point for attribution: identifying the real-world person behind the deployer address follows the same investigative path as any wallet attribution exercise.",{"type":27,"tag":28,"props":2946,"children":2947},{},[2948],{"type":32,"value":2949},"Hypothetical example: a protocol launches with public documentation describing a mechanism that distributes trading fees to depositors. The documentation does not mention that the contract contains an admin withdrawal function. After attracting substantial deposits, the deployer calls the admin function, transfers all deposited funds to a series of new addresses, and moves them through a DEX to obscure the trail. The forensic record of this entire sequence is on the blockchain. The dispute centers on connecting the deployer and the subsequent addresses to identifiable individuals.",{"type":27,"tag":97,"props":2951,"children":2953},{"id":2952},"protocol-exploits",[2954],{"type":32,"value":2955},"Protocol Exploits",{"type":27,"tag":28,"props":2957,"children":2958},{},[2959],{"type":32,"value":2960},"A protocol exploit occurs when a third party identifies and exploits a vulnerability in a smart contract to extract funds that the protocol did not intend to release. This is distinct from a rug pull because the actor is external to the protocol, not its developer. Exploit cases raise questions of liability among multiple potential parties: the protocol developers (whose code contained the vulnerability), the protocol's investors (who may have recourse against the developers), and the exploiter (who may face legal claims for the unauthorized extraction).",{"type":27,"tag":28,"props":2962,"children":2963},{},[2964],{"type":32,"value":2965},"Forensic analysis of an exploit involves reading the exploit transaction itself, identifying the specific sequence of function calls that triggered the vulnerability, and understanding the contract code to explain what the vulnerability was and why it could be triggered in that way. This analysis requires the ability to read and interpret smart contract code, including compiled bytecode for contracts that were not deployed with verified source code.",{"type":27,"tag":28,"props":2967,"children":2968},{},[2969],{"type":32,"value":2970},"Exploits frequently involve flash loans: uncollateralized loans that are borrowed and repaid within a single transaction. Flash loan-enabled exploits allow an attacker to briefly control enormous amounts of capital, manipulate a protocol's price or state, profit from that manipulation, and repay the loan, all within seconds. The entire sequence is visible on the blockchain and can be reconstructed in detail.",{"type":27,"tag":97,"props":2972,"children":2974},{"id":2973},"governance-attacks",[2975],{"type":32,"value":2976},"Governance Attacks",{"type":27,"tag":28,"props":2978,"children":2979},{},[2980],{"type":32,"value":2981},"Decentralized protocols are often governed by a token-weighted voting system: holders of the protocol's governance token can vote on proposed changes to the protocol. A party who accumulates enough governance tokens, including by borrowing them through DeFi lending protocols, can execute a governance attack: pushing through a proposal that changes the protocol in ways that benefit the attacker at the expense of other stakeholders.",{"type":27,"tag":28,"props":2983,"children":2984},{},[2985],{"type":32,"value":2986},"Governance attacks are on-chain events. The votes are recorded, the token balances are visible, and the subsequent protocol changes and fund movements follow from the governance decision. Forensic analysis can reconstruct who voted, what token balances they held, how those tokens were acquired, and what the practical effect of the governance change was on other participants.",{"type":27,"tag":97,"props":2988,"children":2990},{"id":2989},"nft-minting-disputes",[2991],{"type":32,"value":2992},"NFT Minting Disputes",{"type":27,"tag":28,"props":2994,"children":2995},{},[2996],{"type":32,"value":2997},"Non-fungible tokens (NFTs) are created through smart contracts that record ownership of unique digital items on the blockchain. NFT minting disputes arise in several forms: disputed rights to mint (where two parties claim the right to create NFTs representing a specific asset), disputes about the terms of an NFT project (where the minting contract operates differently from what was represented to buyers), and disputes about royalty distributions (where the contract's royalty mechanism does not operate as buyers were told).",{"type":27,"tag":28,"props":2999,"children":3000},{},[3001],{"type":32,"value":3002},"For an NFT dispute, the forensic analysis examines the minting contract's code, the actual sequence of minting transactions, the distribution of royalty payments, and whether the contract's actual behavior matched its public representation. These cases often involve both smart contract analysis and review of communications and marketing materials made to purchasers.",{"type":27,"tag":97,"props":3004,"children":3006},{"id":3005},"escrow-failures-and-ambiguous-contract-terms",[3007],{"type":32,"value":3008},"Escrow Failures and Ambiguous Contract Terms",{"type":27,"tag":28,"props":3010,"children":3011},{},[3012],{"type":32,"value":3013},"Smart contracts are sometimes used to implement escrow arrangements: one party deposits funds, and the contract is supposed to release them to the other party when specified conditions are met. When the conditions in the contract do not match the parties' actual agreement, or when the conditions were so loosely specified that the contract can be triggered in unintended ways, the result is a dispute about what the contract was supposed to do.",{"type":27,"tag":28,"props":3015,"children":3016},{},[3017],{"type":32,"value":3018},"These cases require both reading the smart contract code to understand what it actually does and examining the parties' communications about what they intended. Unlike a document escrow, a smart contract does not have a human escrow agent to exercise judgment. If the code is ambiguous or incomplete relative to the parties' actual agreement, that gap is where the legal dispute lives.",{"type":27,"tag":35,"props":3020,"children":3022},{"id":3021},"how-smart-contract-behavior-is-analyzed-forensically",[3023],{"type":32,"value":3024},"How Smart Contract Behavior Is Analyzed Forensically",{"type":27,"tag":97,"props":3026,"children":3028},{"id":3027},"verified-source-code-and-bytecode",[3029],{"type":32,"value":3030},"Verified Source Code and Bytecode",{"type":27,"tag":28,"props":3032,"children":3033},{},[3034],{"type":32,"value":3035},"Smart contract source code is not automatically public. Developers choose whether to publish and verify the source code on platforms like Etherscan. When source code is verified, it is possible to read and understand the contract at a high level. When it is not verified, analysis proceeds from the compiled bytecode, which is more difficult to read but fully recoverable through decompilation and reverse engineering.",{"type":27,"tag":28,"props":3037,"children":3038},{},[3039],{"type":32,"value":3040},"An expert who can read Solidity source code and trace the execution path of specific transactions through that code can explain, in plain terms, what the contract was programmed to do and whether the execution matched expectations. For bytecode analysis without verified source code, the same analysis is possible but requires more specialized skills.",{"type":27,"tag":97,"props":3042,"children":3044},{"id":3043},"transaction-traces",[3045],{"type":32,"value":3046},"Transaction Traces",{"type":27,"tag":28,"props":3048,"children":3049},{},[3050,3052,3058],{"type":32,"value":3051},"Every smart contract interaction produces a transaction trace: a detailed record of every step of execution, including every function call, every state change, and every event emitted. On Ethereum and compatible chains, these traces are available through archive nodes or trace APIs and can be reconstructed in full detail. ",{"type":27,"tag":47,"props":3053,"children":3055},{"href":3054},"\u002Fresources\u002Fevm-receipts-logs-execution-traces",[3056],{"type":32,"value":3057},"Receipts, logs, and EVM traces",{"type":32,"value":3059}," provide the underlying record for that reconstruction.",{"type":27,"tag":28,"props":3061,"children":3062},{},[3063],{"type":32,"value":3064},"A transaction trace analysis explains the sequence of events in a specific transaction: what function was called first, what data it read and modified, what other contracts it called in sequence, and what ultimately happened to the funds involved. For exploit transactions, this trace is the primary forensic document.",{"type":27,"tag":97,"props":3066,"children":3068},{"id":3067},"event-logs",[3069],{"type":32,"value":3070},"Event Logs",{"type":27,"tag":28,"props":3072,"children":3073},{},[3074],{"type":32,"value":3075},"Smart contracts emit structured log entries called events when significant actions occur. Events are a permanent part of the blockchain record and are indexed in a way that makes them searchable. A contract designed to emit events on deposit and withdrawal actions creates a complete log of all deposit and withdrawal activity, which can be reconstructed from the blockchain without needing to trace individual transactions.",{"type":27,"tag":28,"props":3077,"children":3078},{},[3079],{"type":32,"value":3080},"Event log analysis is one of the most accessible forms of smart contract forensic work because the data is structured and directly interpretable. For many DeFi dispute scenarios, the event log record is sufficient to reconstruct the complete history of user interactions with the protocol.",{"type":27,"tag":97,"props":3082,"children":3084},{"id":3083},"internal-call-analysis",[3085],{"type":32,"value":3086},"Internal Call Analysis",{"type":27,"tag":28,"props":3088,"children":3089},{},[3090],{"type":32,"value":3091},"Smart contracts frequently call other contracts as part of their execution. A transaction that appears on the blockchain as a single transfer may actually involve a complex chain of contract-to-contract calls, each of which modifies state on multiple contracts. Understanding the full scope of a transaction's effects requires analyzing the internal calls, not just the top-level transaction.",{"type":27,"tag":28,"props":3093,"children":3094},{},[3095],{"type":32,"value":3096},"For exploit cases especially, the critical events often occur in internal calls that are not visible at the top-level transaction record. An analyst who does not examine the internal call tree may miss the substance of what happened.",{"type":27,"tag":35,"props":3098,"children":3100},{"id":3099},"expert-testimony-on-smart-contract-disputes",[3101],{"type":32,"value":3102},"Expert Testimony on Smart Contract Disputes",{"type":27,"tag":28,"props":3104,"children":3105},{},[3106],{"type":32,"value":3107},"Smart contract disputes require expert testimony that serves two distinct functions. The first is technical: explaining what the smart contract code does, how a specific transaction executed, and what the relevant records show. The second is contextual: helping the court understand why the technical facts are legally significant, what the parties' likely expectations were given the code's actual design, and how the conduct fits into the applicable legal framework.",{"type":27,"tag":28,"props":3109,"children":3110},{},[3111],{"type":32,"value":3112},"An expert witness in a smart contract matter should be able to read and explain smart contract code, reconstruct the execution of specific transactions, and explain the significance of those transactions in terms that a non-technical judge or jury can follow. The ability to translate between the technical record and its legal significance is the essential qualification.",{"type":27,"tag":28,"props":3114,"children":3115},{},[3116],{"type":32,"value":3117},"For attorneys evaluating potential experts, the relevant qualifications include direct experience with the specific blockchain and contract language at issue (Solidity and EVM for most Ethereum-based disputes), familiarity with the specific type of dispute (DeFi exploits are different from NFT minting disputes in their technical details), and the ability to produce clear written analysis and testimony.",{"type":27,"tag":35,"props":3119,"children":3121},{"id":3120},"what-consensusintel-analyzes",[3122],{"type":32,"value":3123},"What ConsensusIntel Analyzes",{"type":27,"tag":28,"props":3125,"children":3126},{},[3127,3133],{"type":27,"tag":47,"props":3128,"children":3130},{"href":3129},"\u002Fservices#smart-contract",[3131],{"type":32,"value":3132},"ConsensusIntel's smart contract forensic analysis",{"type":32,"value":3134}," covers the full range of dispute scenarios described in this article. That work includes reading and explaining contract source code and bytecode, reconstructing transaction traces and internal call histories, analyzing event logs to reconstruct the history of user interactions with a protocol, valuing positions held in DeFi protocols at specific points in time, and preparing expert reports and testimony that explain technical findings to legal audiences.",{"type":27,"tag":28,"props":3136,"children":3137},{},[3138,3140,3145,3147,3153],{"type":32,"value":3139},"The common thread across these engagements is translating the on-chain record, which contains a comprehensive account of what happened, into a form that is useful in litigation. See ",{"type":27,"tag":47,"props":3141,"children":3142},{"href":597},[3143],{"type":32,"value":3144},"our methodology",{"type":32,"value":3146}," for how this work is structured, or visit ",{"type":27,"tag":47,"props":3148,"children":3150},{"href":3149},"\u002Fcase-types",[3151],{"type":32,"value":3152},"case types",{"type":32,"value":3154}," to see the range of matters where smart contract forensic analysis has been relevant.",{"type":27,"tag":28,"props":3156,"children":3157},{},[3158,3160,3165],{"type":32,"value":3159},"\"Code is law\" is a description of how a program runs, not a description of how courts operate. When disputes arise from smart contract conduct, the technical record is detailed and permanent. What it takes is an analyst who can read it. ",{"type":27,"tag":47,"props":3161,"children":3162},{"href":693},[3163],{"type":32,"value":3164},"Contact ConsensusIntel",{"type":32,"value":3166}," to discuss how forensic analysis can support your specific smart contract matter.",{"type":27,"tag":3168,"props":3169,"children":3170},"hr",{},[],{"type":27,"tag":35,"props":3172,"children":3173},{"id":605},[3174],{"type":32,"value":608},{"type":27,"tag":97,"props":3176,"children":3178},{"id":3177},"q-can-you-sue-the-developers-of-a-defi-protocol-for-an-exploit",[3179],{"type":32,"value":3180},"Q: Can you sue the developers of a DeFi protocol for an exploit?",{"type":27,"tag":28,"props":3182,"children":3183},{},[3184,3188],{"type":27,"tag":619,"props":3185,"children":3186},{},[3187],{"type":32,"value":623},{"type":32,"value":3189}," The legal claims depend on the facts: who the developers are and where they are located, what they represented to users about the protocol's security, whether the vulnerability resulted from negligence or intentional design, and what jurisdiction's law applies. Forensic analysis can establish what the contract was designed to do and what actually happened. The legal theory is a question of law that follows from those facts.",{"type":27,"tag":97,"props":3191,"children":3193},{"id":3192},"q-what-if-the-smart-contracts-source-code-was-never-published",[3194],{"type":32,"value":3195},"Q: What if the smart contract's source code was never published?",{"type":27,"tag":28,"props":3197,"children":3198},{},[3199,3203],{"type":27,"tag":619,"props":3200,"children":3201},{},[3202],{"type":32,"value":623},{"type":32,"value":3204}," Smart contracts that are deployed without verified source code can still be analyzed through their compiled bytecode. Decompilation tools recover a machine-readable representation of the logic, and experienced analysts can reconstruct the contract's behavior from that representation. The analysis is more involved and carries slightly more uncertainty than source code analysis, but the fundamental questions about what the contract does and how specific transactions executed can be addressed.",{"type":27,"tag":97,"props":3206,"children":3208},{"id":3207},"q-how-is-a-protocol-exploit-distinguished-from-authorized-use-of-a-contracts-functions",[3209],{"type":32,"value":3210},"Q: How is a protocol exploit distinguished from authorized use of a contract's functions?",{"type":27,"tag":28,"props":3212,"children":3213},{},[3214,3218],{"type":27,"tag":619,"props":3215,"children":3216},{},[3217],{"type":32,"value":623},{"type":32,"value":3219}," This is often the central factual question in exploit cases. The distinction is established by examining the contract's design: what functions were intended for ordinary users, what functions were restricted to specific roles (such as admin functions), and whether the exploit involved using functions as designed or circumventing the contract's intended access controls. An expert can analyze the contract code to identify which functions were called and whether their invocation was within the scope of what a legitimate user would be expected to do.",{"type":27,"tag":97,"props":3221,"children":3223},{"id":3222},"q-what-records-and-timelines-matter-if-the-protocol-developers-were-anonymous",[3224],{"type":32,"value":3225},"Q: What records and timelines matter if the protocol developers were anonymous?",{"type":27,"tag":28,"props":3227,"children":3228},{},[3229,3233],{"type":27,"tag":619,"props":3230,"children":3231},{},[3232],{"type":32,"value":623},{"type":32,"value":3234}," Anonymous developers present the same attribution challenge as any self-custody wallet: the on-chain record is complete, but connecting the blockchain addresses to specific individuals requires additional evidence. Developer wallets often interact with exchanges to fund development activities, and those exchange interactions may be traceable to specific accounts. Code repositories, deployment records, and communications platforms may hold additional attribution evidence. The investigation is harder but not categorically impossible.",{"type":27,"tag":28,"props":3236,"children":3237},{},[3238],{"type":32,"value":3239},"The timeline varies substantially based on complexity. Analyzing a single exploit transaction in a well-understood protocol might take days. Reconstructing the full operation of a complex protocol over months of activity, or reverse-engineering unverified bytecode, can take longer. Early engagement, with a clear definition of the specific questions to be answered, allows the analysis to be scoped and scheduled to fit the litigation timeline.",{"type":27,"tag":97,"props":3241,"children":3243},{"id":3242},"q-can-a-smart-contracts-behavior-after-deployment-be-changed",[3244],{"type":32,"value":3245},"Q: Can a smart contract's behavior after deployment be changed?",{"type":27,"tag":28,"props":3247,"children":3248},{},[3249,3253],{"type":27,"tag":619,"props":3250,"children":3251},{},[3252],{"type":32,"value":623},{"type":32,"value":3254}," Some contracts include upgrade mechanisms that allow the deployed code to be changed after deployment. These mechanisms are common in larger protocols but are not universal. Whether a specific contract can be upgraded, and who has the authority to upgrade it, is established by reading the contract code. If a contract was upgraded in a way that changed its behavior relevantly to a dispute, the timing and authorization of that upgrade is itself a fact to be established through the blockchain record.",{"title":8,"searchDepth":716,"depth":716,"links":3256},[3257,3258,3259,3266,3272,3273,3274],{"id":2878,"depth":716,"text":2881},{"id":2904,"depth":716,"text":2907},{"id":2925,"depth":716,"text":2928,"children":3260},[3261,3262,3263,3264,3265],{"id":2931,"depth":722,"text":2934},{"id":2952,"depth":722,"text":2955},{"id":2973,"depth":722,"text":2976},{"id":2989,"depth":722,"text":2992},{"id":3005,"depth":722,"text":3008},{"id":3021,"depth":716,"text":3024,"children":3267},[3268,3269,3270,3271],{"id":3027,"depth":722,"text":3030},{"id":3043,"depth":722,"text":3046},{"id":3067,"depth":722,"text":3070},{"id":3083,"depth":722,"text":3086},{"id":3099,"depth":716,"text":3102},{"id":3120,"depth":716,"text":3123},{"id":605,"depth":716,"text":608,"children":3275},[3276,3277,3278,3279,3280],{"id":3177,"depth":722,"text":3180},{"id":3192,"depth":722,"text":3195},{"id":3207,"depth":722,"text":3210},{"id":3222,"depth":722,"text":3225},{"id":3242,"depth":722,"text":3245},"content:articles:10-smart-contract-disputes.md","articles\u002F10-smart-contract-disputes.md","articles\u002F10-smart-contract-disputes",{"_path":3285,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":3286,"description":3287,"slug":3288,"date":3289,"lastUpdated":3289,"author":13,"readingTime":3290,"category":1780,"tags":3291,"ogImage":3295,"featured":7,"body":3296,"_type":740,"_id":3666,"_source":742,"_file":3667,"_stem":3668,"_extension":745},"\u002Farticles\u002F06-what-lawyers-need-to-know-about-defi","What lawyers need to know about DeFi","A plain-language guide for attorneys on how DeFi protocols work, why they complicate asset tracing, and what forensic analysis can establish.","what-lawyers-need-to-know-about-defi","2026-04-24",11,[3292,3293,20,3294],"defi","decentralized-finance","forensics","\u002Fog\u002Fwhat-lawyers-need-to-know-about-defi.png",{"type":24,"children":3297,"toc":3642},[3298,3303,3308,3313,3319,3324,3329,3334,3344,3354,3364,3374,3380,3386,3391,3396,3402,3407,3412,3418,3423,3428,3434,3439,3444,3450,3454,3459,3464,3468,3473,3485,3489,3494,3500,3505,3510,3516,3521,3526,3532,3537,3542,3567,3570,3574,3580,3585,3591,3596,3602,3607,3613,3618,3624,3629,3637],{"type":27,"tag":28,"props":3299,"children":3300},{},[3301],{"type":32,"value":3302},"Decentralized finance, commonly abbreviated as DeFi, has grown from an experiment to a substantial segment of the cryptocurrency ecosystem. Billions of dollars move through DeFi protocols daily. That means DeFi is now appearing in litigation: in divorce proceedings where a party holds assets in a liquidity pool rather than an exchange account, in fraud cases where victims' funds were routed through DeFi before disappearing, and in securities and regulatory matters where the structure of a protocol is itself at issue.",{"type":27,"tag":28,"props":3304,"children":3305},{},[3306],{"type":32,"value":3307},"For attorneys handling these matters, DeFi presents distinct challenges compared to conventional cryptocurrency holdings. There is no exchange to subpoena for account records. The assets are controlled by smart contract code running on a public blockchain. The terminology is unfamiliar, and the mechanics require some explanation to be useful in court.",{"type":27,"tag":28,"props":3309,"children":3310},{},[3311],{"type":32,"value":3312},"This article covers what DeFi is, how it works in practice, why it complicates asset tracing, and what forensic analysis can realistically produce when DeFi is part of the picture.",{"type":27,"tag":35,"props":3314,"children":3316},{"id":3315},"what-defi-is",[3317],{"type":32,"value":3318},"What DeFi Is",{"type":27,"tag":28,"props":3320,"children":3321},{},[3322],{"type":32,"value":3323},"Traditional finance relies on intermediaries: banks that hold deposits, brokers that execute trades, exchanges that match buyers and sellers, and lenders that manage loans. Each intermediary maintains records, is subject to regulatory oversight, and can be compelled through legal process to produce those records.",{"type":27,"tag":28,"props":3325,"children":3326},{},[3327],{"type":32,"value":3328},"DeFi replaces those intermediaries with software: specifically, with smart contracts deployed on a blockchain. A smart contract is a program stored permanently on the blockchain that executes automatically when specific conditions are met. The contract holds the funds and enforces the rules of the protocol without requiring a company or person to manage each transaction.",{"type":27,"tag":28,"props":3330,"children":3331},{},[3332],{"type":32,"value":3333},"The four most litigation-relevant DeFi categories are:",{"type":27,"tag":28,"props":3335,"children":3336},{},[3337,3342],{"type":27,"tag":619,"props":3338,"children":3339},{},[3340],{"type":32,"value":3341},"Decentralized exchanges (DEXs)",{"type":32,"value":3343}," allow users to trade one cryptocurrency for another by interacting directly with a smart contract. Unlike a traditional exchange, there is no order book maintained by a company, no account registration, and no KYC process. The user connects a wallet, initiates a trade, and the smart contract executes it based on an automated pricing formula.",{"type":27,"tag":28,"props":3345,"children":3346},{},[3347,3352],{"type":27,"tag":619,"props":3348,"children":3349},{},[3350],{"type":32,"value":3351},"Lending protocols",{"type":32,"value":3353}," allow users to deposit cryptocurrency as collateral and borrow against it, or to deposit assets that others borrow. The interest rates are set algorithmically based on supply and demand. A party might hold a substantial amount of cryptocurrency deposited as collateral in a lending protocol while simultaneously holding borrowed funds in a separate wallet.",{"type":27,"tag":28,"props":3355,"children":3356},{},[3357,3362],{"type":27,"tag":619,"props":3358,"children":3359},{},[3360],{"type":32,"value":3361},"Liquidity pools",{"type":32,"value":3363}," are how most DEXs maintain the assets needed to execute trades. Users deposit pairs of tokens (for example, equal values of ETH and USDC) into a pool and receive liquidity provider tokens in return. Those liquidity provider tokens represent the depositor's share of the pool and accumulate trading fees over time. Liquidity positions are meaningful financial interests that may not be visible without specific knowledge of where to look.",{"type":27,"tag":28,"props":3365,"children":3366},{},[3367,3372],{"type":27,"tag":619,"props":3368,"children":3369},{},[3370],{"type":32,"value":3371},"Yield farming",{"type":32,"value":3373}," involves moving assets among protocols to maximize returns, often in combination with the protocols above. A user might deposit collateral in a lending protocol, borrow against it, deposit the borrowed assets into a liquidity pool, and stake the resulting liquidity tokens in a rewards contract. The resulting position is complex, multi-layered, and difficult to value without reconstructing each step.",{"type":27,"tag":35,"props":3375,"children":3377},{"id":3376},"why-defi-complicates-tracing",[3378],{"type":32,"value":3379},"Why DeFi Complicates Tracing",{"type":27,"tag":97,"props":3381,"children":3383},{"id":3382},"no-kyc-and-no-account-records",[3384],{"type":32,"value":3385},"No KYC and No Account Records",{"type":27,"tag":28,"props":3387,"children":3388},{},[3389],{"type":32,"value":3390},"The absence of an intermediary means the absence of the records an intermediary would maintain. There is no exchange database containing a user's identity, no linked bank account, and no account statement documenting the position. A party who holds the majority of their cryptocurrency wealth in DeFi positions has not necessarily done anything to conceal it, but the evidence path is fundamentally different.",{"type":27,"tag":28,"props":3392,"children":3393},{},[3394],{"type":32,"value":3395},"The on-chain record is there. Every interaction with every DeFi protocol is recorded permanently on the blockchain, in more detail than a simple transfer between wallets. The challenge is interpreting that record, not finding it.",{"type":27,"tag":97,"props":3397,"children":3399},{"id":3398},"smart-contract-intermediaries",[3400],{"type":32,"value":3401},"Smart Contract Intermediaries",{"type":27,"tag":28,"props":3403,"children":3404},{},[3405],{"type":32,"value":3406},"When a user interacts with a DeFi protocol, their funds often pass through multiple smart contract addresses before reaching their effective destination. A party who deposits funds into a lending protocol might see their funds move to a contract address, then an internal accounting address, then a reserve address, all in a single transaction. Without knowledge of the protocol's architecture, that transaction flow looks complex and may appear to terminate at an address with no obvious connection to the depositor.",{"type":27,"tag":28,"props":3408,"children":3409},{},[3410],{"type":32,"value":3411},"Analysts who are not familiar with specific DeFi protocols may misread this activity as an attempt at concealment when it is simply the normal operation of the protocol. Correctly interpreting DeFi transaction traces requires knowing which contract addresses belong to which protocols and understanding how those protocols internally account for user positions.",{"type":27,"tag":97,"props":3413,"children":3415},{"id":3414},"cross-chain-bridges",[3416],{"type":32,"value":3417},"Cross-Chain Bridges",{"type":27,"tag":28,"props":3419,"children":3420},{},[3421],{"type":32,"value":3422},"DeFi operates across many different blockchains. A user who moves funds from Ethereum to a different chain through a bridge creates a gap in the on-chain trace: funds go into the bridge contract on one chain and emerge from the bridge contract on the other. The analyst following the money must identify the bridge protocol, understand how it operates, and follow the transaction on the destination chain from the corresponding bridge output.",{"type":27,"tag":28,"props":3424,"children":3425},{},[3426],{"type":32,"value":3427},"Bridge protocols are not nefarious by design, but they are used in cases of intentional fund movement across chains specifically because they create trace complexity. Identifying bridge activity and following funds across chains is possible but requires specific technical knowledge.",{"type":27,"tag":97,"props":3429,"children":3431},{"id":3430},"liquidity-positions-are-not-cash-balances",[3432],{"type":32,"value":3433},"Liquidity Positions Are Not Cash Balances",{"type":27,"tag":28,"props":3435,"children":3436},{},[3437],{"type":32,"value":3438},"A party with $500,000 deposited in a liquidity pool does not hold $500,000 in a wallet balance. They hold liquidity provider tokens representing a share of the pool. The value of those tokens fluctuates based on the pool's composition and the exchange rates of the underlying assets. Valuing that position at a specific point in time requires knowing the pool's state at that moment.",{"type":27,"tag":28,"props":3440,"children":3441},{},[3442],{"type":32,"value":3443},"This creates both a valuation challenge and a disclosure problem. A party instructed to disclose all cryptocurrency holdings may list only their wallet balances, omitting the liquidity positions that represent the bulk of their holdings. Those positions are assets with real value, but they do not look like cryptocurrency balances unless the investigator knows to look for them and knows how to read them.",{"type":27,"tag":35,"props":3445,"children":3447},{"id":3446},"defi-in-litigation-relevant-scenarios",[3448],{"type":32,"value":3449},"DeFi in Litigation-Relevant Scenarios",{"type":27,"tag":97,"props":3451,"children":3452},{"id":2931},[3453],{"type":32,"value":2934},{"type":27,"tag":28,"props":3455,"children":3456},{},[3457],{"type":32,"value":3458},"A rug pull is a scenario where the developers of a DeFi protocol launch a project, attract user deposits, and then drain the protocol's funds by exploiting features of the smart contract they deployed. From a forensic perspective, tracing funds after a rug pull involves following the movement of stolen assets through the blockchain, identifying any exchange addresses where the funds were converted to other assets or cashed out, and establishing the connection between the protocol's developers and the addresses that received the stolen funds.",{"type":27,"tag":28,"props":3460,"children":3461},{},[3462],{"type":32,"value":3463},"Hypothetical example: A protocol raises $10 million in user deposits over a two-week period before its developers withdraw everything to a set of wallets they control. The blockchain records every deposit, every internal movement, and every withdrawal. The forensic challenge is connecting the withdrawal addresses to specific individuals. That connection typically requires a combination of blockchain tracing to exchanges and subpoenas for the exchange account records.",{"type":27,"tag":97,"props":3465,"children":3466},{"id":2952},[3467],{"type":32,"value":2955},{"type":27,"tag":28,"props":3469,"children":3470},{},[3471],{"type":32,"value":3472},"A protocol exploit occurs when a third party identifies a vulnerability in a DeFi protocol's smart contract code and uses it to extract funds beyond what they legitimately deposited. Unlike a rug pull, the funds leave through a mechanism the protocol's designers did not intend. Forensic analysis in exploit cases typically begins with the exploit transaction itself, follows the extracted funds through subsequent movements, and attempts to identify any point where the funds touched a KYC exchange.",{"type":27,"tag":28,"props":3474,"children":3475},{},[3476,3478,3483],{"type":32,"value":3477},"Exploit cases are often also analyzed through review of the ",{"type":27,"tag":47,"props":3479,"children":3480},{"href":589},[3481],{"type":32,"value":3482},"smart contract's source code",{"type":32,"value":3484},", to understand how the vulnerability worked and whether anyone with access to the protocol's development history could have known about it in advance.",{"type":27,"tag":97,"props":3486,"children":3487},{"id":2973},[3488],{"type":32,"value":2976},{"type":27,"tag":28,"props":3490,"children":3491},{},[3492],{"type":32,"value":3493},"DeFi protocols are often governed by token holders, who vote on protocol changes. An attacker who acquires enough governance tokens can vote to change the protocol in ways that benefit themselves at the expense of other users. These attacks are on-chain events with a complete record. Forensic analysis can reconstruct the governance votes, the token holdings that determined the outcome, and the subsequent protocol changes and fund movements.",{"type":27,"tag":35,"props":3495,"children":3497},{"id":3496},"what-records-exist-and-what-do-not",[3498],{"type":32,"value":3499},"What Records Exist and What Do Not",{"type":27,"tag":28,"props":3501,"children":3502},{},[3503],{"type":32,"value":3504},"On-chain records for DeFi activity are comprehensive: every transaction, every contract interaction, every token movement. The public blockchain captures all of it. Off-chain records, meaning records held by institutions, are minimal to nonexistent. Most DeFi protocols do not maintain user databases, do not verify identities, and do not retain logs in a form subject to legal process.",{"type":27,"tag":28,"props":3506,"children":3507},{},[3508],{"type":32,"value":3509},"The exception is the protocol developers themselves. DeFi protocols are built by teams, and those teams maintain their own records: code repositories, deployment records, communications, and in some cases access to administrative functions of the protocol. When the protocol developers are parties to the litigation, or when their conduct is relevant, discovery directed at them can produce evidence that supplements the on-chain record.",{"type":27,"tag":35,"props":3511,"children":3513},{"id":3512},"how-defi-activity-is-analyzed",[3514],{"type":32,"value":3515},"How DeFi Activity Is Analyzed",{"type":27,"tag":28,"props":3517,"children":3518},{},[3519],{"type":32,"value":3520},"Forensic analysis of DeFi activity follows the same fundamental methodology as other blockchain analysis, with the added requirement that the analyst understand the specific protocols involved. The analyst identifies the user's wallet address, traces all interactions with DeFi protocol contracts, reconstructs the positions held and the movements of funds, and values those positions at the relevant points in time.",{"type":27,"tag":28,"props":3522,"children":3523},{},[3524],{"type":32,"value":3525},"Commercial blockchain intelligence platforms have developed tools specifically for DeFi analysis, including databases of protocol contract addresses, decoding of protocol-specific transaction data, and position valuation tools. The quality of the analysis depends on the analyst's familiarity with the relevant protocols and the tools available.",{"type":27,"tag":35,"props":3527,"children":3529},{"id":3528},"jurisdictional-questions",[3530],{"type":32,"value":3531},"Jurisdictional Questions",{"type":27,"tag":28,"props":3533,"children":3534},{},[3535],{"type":32,"value":3536},"DeFi protocols are deployed by developers who may be located anywhere in the world and who may operate with varying degrees of anonymity. The protocol itself is software running on a blockchain, not a legal entity. These facts create genuine jurisdictional complexity.",{"type":27,"tag":28,"props":3538,"children":3539},{},[3540],{"type":32,"value":3541},"When a DeFi protocol is used in connection with fraud or theft, identifying the responsible parties and bringing them within a court's jurisdiction requires connecting the on-chain activity to real-world individuals. That connection is the forensic challenge. Once individuals are identified, standard jurisdictional analysis applies, but the identification step is often the hardest part.",{"type":27,"tag":28,"props":3543,"children":3544},{},[3545,3547,3552,3554,3559,3561,3565],{"type":32,"value":3546},"For matters involving DeFi, ",{"type":27,"tag":47,"props":3548,"children":3549},{"href":3129},[3550],{"type":32,"value":3551},"smart contract analysis",{"type":32,"value":3553}," can include protocol-specific forensic analysis that goes beyond conventional blockchain tracing to address the mechanics of specific protocols, the valuation of DeFi positions, and the interpretation of DeFi transaction data for a legal audience. For DeFi-related matters and other complex cryptocurrency investigations, see the ",{"type":27,"tag":47,"props":3555,"children":3556},{"href":3149},[3557],{"type":32,"value":3558},"case types we handle",{"type":32,"value":3560}," or ",{"type":27,"tag":47,"props":3562,"children":3563},{"href":693},[3564],{"type":32,"value":696},{"type":32,"value":3566}," to discuss whether your matter is a fit.",{"type":27,"tag":3168,"props":3568,"children":3569},{},[],{"type":27,"tag":35,"props":3571,"children":3572},{"id":605},[3573],{"type":32,"value":608},{"type":27,"tag":97,"props":3575,"children":3577},{"id":3576},"q-does-a-defi-interaction-leave-any-record-that-can-be-used-in-court",[3578],{"type":32,"value":3579},"Q: Does a DeFi interaction leave any record that can be used in court?",{"type":27,"tag":28,"props":3581,"children":3582},{},[3583],{"type":32,"value":3584},"Yes. Every interaction with a DeFi protocol is recorded permanently on the public blockchain. The blockchain captures the wallet address that initiated the transaction, the protocol contract that was called, the function within the contract that executed, the assets moved, and the exact timestamp. This record is more detailed than a conventional cryptocurrency transfer because DeFi transactions involve complex contract interactions that are all preserved on-chain.",{"type":27,"tag":97,"props":3586,"children":3588},{"id":3587},"q-can-a-party-hide-assets-in-defi-positions",[3589],{"type":32,"value":3590},"Q: Can a party hide assets in DeFi positions?",{"type":27,"tag":28,"props":3592,"children":3593},{},[3594],{"type":32,"value":3595},"A party can decline to disclose DeFi positions, and those positions will not appear in exchange records or conventional financial statements. However, the on-chain record is public. If an investigator knows to look for DeFi activity and has a known wallet address to start from, the full picture of DeFi positions held from that address can be reconstructed. The practical question is whether the investigator knows to look and has the right starting point.",{"type":27,"tag":97,"props":3597,"children":3599},{"id":3598},"q-how-are-liquidity-pool-positions-valued-for-litigation-purposes",[3600],{"type":32,"value":3601},"Q: How are liquidity pool positions valued for litigation purposes?",{"type":27,"tag":28,"props":3603,"children":3604},{},[3605],{"type":32,"value":3606},"Liquidity pool positions are valued by identifying the pool's composition at the relevant point in time, calculating the depositor's proportional share, and applying the token prices at that moment. This requires historical data from the blockchain and the relevant price oracles. Valuation is more involved than reading a wallet balance but is tractable given the right tools and data.",{"type":27,"tag":97,"props":3608,"children":3610},{"id":3609},"q-what-is-the-difference-between-a-rug-pull-and-a-legitimate-project-failure",[3611],{"type":32,"value":3612},"Q: What is the difference between a rug pull and a legitimate project failure?",{"type":27,"tag":28,"props":3614,"children":3615},{},[3616],{"type":32,"value":3617},"In a rug pull, the developers retain the ability to withdraw user funds and exercise that ability intentionally. In a legitimate project failure, the funds may be lost due to market conditions, technical failures, or unforeseen circumstances, but there is no intentional extraction. The distinction is often a matter of smart contract design and the on-chain record of what the developers' addresses did. A forensic analysis of the contract code and the transaction history can often distinguish the two.",{"type":27,"tag":97,"props":3619,"children":3621},{"id":3620},"q-are-defi-developers-subject-to-us-jurisdiction",[3622],{"type":32,"value":3623},"Q: Are DeFi developers subject to U.S. jurisdiction?",{"type":27,"tag":28,"props":3625,"children":3626},{},[3627],{"type":32,"value":3628},"This is genuinely contested legal territory. Courts have approached questions of DeFi developer liability differently, and the law is evolving. What forensic analysis can contribute is the identification of the individuals or entities who deployed and controlled the relevant protocol, which is a prerequisite for any jurisdictional analysis. Whether jurisdiction exists over those individuals is a separate legal question.",{"type":27,"tag":28,"props":3630,"children":3631},{},[3632],{"type":27,"tag":619,"props":3633,"children":3634},{},[3635],{"type":32,"value":3636},"Can I compel a DeFi protocol to produce records?",{"type":27,"tag":28,"props":3638,"children":3639},{},[3640],{"type":32,"value":3641},"There is no centralized entity to compel for most DeFi protocols. The protocol is software on a blockchain. However, if the protocol was developed by an identifiable team, those individuals or entities may be subject to discovery. And the on-chain records are publicly available without any compulsion; the challenge is interpreting them, not accessing them.",{"title":8,"searchDepth":716,"depth":716,"links":3643},[3644,3645,3651,3656,3657,3658,3659],{"id":3315,"depth":716,"text":3318},{"id":3376,"depth":716,"text":3379,"children":3646},[3647,3648,3649,3650],{"id":3382,"depth":722,"text":3385},{"id":3398,"depth":722,"text":3401},{"id":3414,"depth":722,"text":3417},{"id":3430,"depth":722,"text":3433},{"id":3446,"depth":716,"text":3449,"children":3652},[3653,3654,3655],{"id":2931,"depth":722,"text":2934},{"id":2952,"depth":722,"text":2955},{"id":2973,"depth":722,"text":2976},{"id":3496,"depth":716,"text":3499},{"id":3512,"depth":716,"text":3515},{"id":3528,"depth":716,"text":3531},{"id":605,"depth":716,"text":608,"children":3660},[3661,3662,3663,3664,3665],{"id":3576,"depth":722,"text":3579},{"id":3587,"depth":722,"text":3590},{"id":3598,"depth":722,"text":3601},{"id":3609,"depth":722,"text":3612},{"id":3620,"depth":722,"text":3623},"content:articles:06-what-lawyers-need-to-know-about-defi.md","articles\u002F06-what-lawyers-need-to-know-about-defi.md","articles\u002F06-what-lawyers-need-to-know-about-defi",1790145013676]