> ## Documentation Index
> Fetch the complete documentation index at: https://paralens.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# attribution — Signer and Economic Actor Relationship

> The attribution object in TxReport explains who signed the transaction versus who economically acted — critical for smart wallets, routers, and MEV bots.

In a simple transfer, the wallet that signed the transaction and the wallet that received value are the same person. But in aggregator swaps, smart contract wallets, and MEV bots, the signer and the economic actor are different addresses. `attribution` makes this relationship explicit.

## Example

```json theme={null}
{
  "tx_signer": "0x5b43453fce04b92e190f391a83136bfbecedefd1",
  "authority_subject": "0x5b43453fce04b92e190f391a83136bfbecedefd1",
  "operating_subject": "0xbdb3ba9ffe392549e1f8658dd2630c141fdf47b6"
}
```

## Fields

<ResponseField name="tx_signer" type="string" required>
  The Ethereum `tx.from` — the address that paid for gas and submitted the transaction. This is always present and corresponds directly to the raw transaction origin.
</ResponseField>

<ResponseField name="authority_subject" type="string | null">
  The subject that authorized the action, when inferred. Often the same as `tx_signer` in straightforward transactions. May differ in delegated execution patterns such as Safe modules or relayer setups.
</ResponseField>

<ResponseField name="operating_subject" type="string | null">
  The subject that economically acted — the address that received or sent the primary value. In routed or delegated transactions, this will differ from `tx_signer` and represents the true beneficial actor.
</ResponseField>

## When they differ

In many real-world transactions, `tx_signer` and `operating_subject` are not the same address. Common patterns where they diverge:

<AccordionGroup>
  <Accordion title="Aggregator (1inch, Paraswap, 0x)">
    The user signs the transaction and the aggregator contract routes the swap through one or more liquidity pools. `tx_signer` is the user's EOA, while `operating_subject` is identified as the aggregator contract that orchestrated the value flow.
  </Accordion>

  <Accordion title="Smart wallet (Safe / Gnosis)">
    An EOA calls the Safe contract, which executes the actual action on behalf of the multisig owners. `tx_signer` is the EOA that submitted the transaction, while `operating_subject` is the Safe contract address that held and moved the funds.
  </Accordion>

  <Accordion title="MEV bot">
    The bot's EOA submits the transaction (and pays gas), but the profit accrues to a separate bot contract. `tx_signer` is the EOA, while `operating_subject` is the bot contract that captured the arbitrage or sandwich profit.
  </Accordion>
</AccordionGroup>

## Relationship to `classification.actor`

`classification.actor` is the elected economic actor for the transaction as a whole — it is equivalent to `attribution.operating_subject` when available. If `classification.actor_matches_signer` is `false`, inspect `attribution` to understand the full delegated relationship between the submitting address and the address that economically acted.

## Usage guidance

<Warning>
  When building compliance tools or identity attribution, never rely solely on `tx_signer`. Always check `attribution.operating_subject` for the true economic actor.
</Warning>

* Use `operating_subject` as the primary identity anchor for economic actions.
* Use `tx_signer` when you need to attribute gas costs or submission responsibility.
* Use `authority_subject` when modeling authorization chains — for example, in smart wallet or relayer contexts where the authorizing party is neither the submitter nor the contract.