Attribution & evidence

An EntryPoint transaction proves authorisation and execution on this chain very precisely. Identity, intent, off-chain billing and other chains sit outside it. So every attribution is a separate claim, in one dimension, with its own evidence.

Attribution dimensions and their traps

The central rule from the earlier research: each dimension is a separate claim with its own evidence. A strong answer on one does not lift the others. "Unknown" is a valid, honest value.

The habit to build: for any label, ask "which of these columns does my evidence actually sit in?"

Evidence grades: how a value was obtained

Strongest first. Each fact on an example page carries one.

• grade: observed read directly from the receipt, logs or transaction
• grade: decoded decoded from calldata and re-encoded byte-for-byte
• grade: recomputed independently recomputed (e.g. the userOpHash)
• grade: recovered recovered cryptographically (signature recovery)
• grade: contract read read from a contract getter at a stated block
• grade: registry taken from the address registry at the stated level
• grade: inferred derived from other facts (e.g. log order); weaker than an observation
• grade: hint a clue only
• grade: unknown not established

Evidence levels: how strong an address label is

A name is never a real-world identity. EOAs (bundlers, signers, owners) are keys; we never infer who controls them.

Carry-forward rules, in plain language

1. Keep every dimension separate: what was requested, what actually happened, which app, which asset, which route, which wallet software, which key, who bundled, who sponsored. A strong answer on one never settles another.
2. Outer success does not prove inner success; a successful UserOperation can still hide a caught failure in one of its calls.
3. Count the outer fee exactly once per transaction. The per-operation charge (actualGasCost) is a different layer and is never added to it, and fees are never split across legs and summed.
4. Sponsored is not free: a paymaster paying the gas says nothing about who paid the paymaster.
5. A signer is a key. Signature recovery proves control of a key, never a person’s identity.
6. A third-party label (explorer tag, dashboard, another vendor’s list) is a hint and can never raise an evidence level.
7. A claim is only as strong as its weakest link: a log that is observed but tied to an operation by log order is “inferred”.
8. Capability is not usage: a version supporting a feature (EIP-7702, block-number validity) does not mean anyone used it.
9. “Unknown” is a valid, honest answer. Leave it unknown until the evidence exists.

The ontology

The rules above are also written down as a small formal vocabulary (OWL + SKOS + PROV-O in Turtle) with SHACL shapes that reject data breaking them. Download: epi-ontology.ttl · epi-shapes.ttl.

1. Four ideas

1. Chain artifacts are the skeleton. An OuterTransaction (in a Block) carries one or more Envelopes (a handleOps call; DirectEnvelope when tx.to is the EntryPoint, EmbeddedEnvelope when found inside a wrapper's calldata). An envelope holds UserOperations. A UserOperation has Legs: the calls the account was asked to make. A ContainerLeg (e.g. Safe MultiSend) has sub-legs. The transaction has Logs, each placed in a lifecycle phase (validation, execution, compensation ...). These are facts read or decoded from the chain.

2. Addresses play roles; they are not roles. An address is a ChainAddress: an EOA or a Contract. Some contract kinds follow from protocol semantics (EntryPoint, SmartAccount, Paymaster, Factory, AccountImplementation, Module/Validator, Token, WrapperContract). What an address did in a given transaction is a RoleAssignment: player + role + context. The roles are bundler, beneficiary, entrypoint, sender, factory, paymaster, signer, aggregator, account implementation, validator module, leg target, wrapper and token-payment recipient. The same address can play several roles at once. A bundler is usually also the beneficiary, and in one v0.8 bundle the beneficiary is the paymaster. That is a coincidence of addresses, not an identity. epio:Bundler and epio:Beneficiary are defined classes: "any address that played that role somewhere".

Signers are different: the signer role is played by a SignerKey, never by an address or a person. An EOAKey (secp256k1) controlsAddress exactly one EOA. A PasskeyP256 (WebAuthn) has a public key (x, y) and no address.

3. Every attribution is a claim, in one independent dimension. An epio:Claim has a claimSubject, a dimension, a claimPredicate and claimValue, an evidenceGrade, an evidenceLevel for labels, sourceLocator (URL, file or field), method, qualification (caveats), observedAtBlock and prov:wasDerivedFrom / prov:generatedAtTime. The dimensions (epio:DimensionScheme) are the ones in the research notes: operation, outcome (outer status / UserOp success / leg evidence as three separate sub-dimensions), application, asset, route, wallet implementation, control, bundling, compensation, sponsorship, deployment, automation, fees (receipt fee / actualGasCost as two separate sub-dimensions) and labelling. Knowing one dimension never settles another. The paymaster being Pimlico tells you nothing about who runs the bundler, and "unknown application" does not erase a well-evidenced asset transfer.

4. Evidence has two orthogonal scales.

• Grade: how a value was obtained (epio:EvidenceGradeScheme, from epi/attribution/claims.py): observed > decoded_canonical > recomputed > recovered > endpoint_getter > registry > inferred > hint > unknown.
• Level: how strong an address label is (epio:EvidenceLevelScheme, from epi/registry.py): primary_source > self_description > cluster > hint, with epio:rank 1–4 and the transitive epio:strongerThan.

The registry's protocol field becomes one of three distinct relations so that a weak claim can't pass for a strong one:

Third-party sources (epio:Arkham, epio:Snowtrace, epio:BundleBear, epio:Stats4337, epio:DuneSpellbook, epio:OtherVendorPublication) are typed epio:ThirdPartySource. Any claim prov:wasDerivedFrom one of them must be level hint, so a third party can never raise a level. Each one becomes an epio:ThirdPartyClaim, carrying the explorer URL, the verbatim tag and the fetch date (2026-10-19).

2. Core class diagram

This diagram is wider than the screen: scroll sideways inside its frame.

classDiagram
    direction TB
    class OuterTransaction { txHash; gasUsed }
    class Envelope { handleFunction; canonical }
    class DirectEnvelope
    class EmbeddedEnvelope
    class UserOperation { userOpHash; versionLabel; nonceKey }
    class Leg { legForm; selector; valueWei }
    class Log { logKind; index }
    class ChainAddress { address }
    class EOA
    class Contract
    class EntryPoint
    class SmartAccount
    class Paymaster
    class Factory
    class AccountImplementation
    class SignerKey
    class EOAKey
    class PasskeyP256 { publicKeyX; publicKeyY }
    class Organization
    class Claim { sourceLocator; method; qualification; observedAtBlock }
    class RoleAssignment
    class LabelClaim
    class ThirdPartyClaim
    class FeeObservation { amountWei }
    class ReceiptFee
    class ActualGasCharge
    class Source
    class ThirdPartySource

    OuterTransaction "1" --> "1..*" Envelope : hasEnvelope
    Envelope <|-- DirectEnvelope
    Envelope <|-- EmbeddedEnvelope
    Envelope --> EntryPoint : envelopeEntryPoint
    Envelope "1" --> "1..*" UserOperation : hasUserOperation
    UserOperation "1" --> "*" Leg : hasLeg
    OuterTransaction --> Log : hasLog
    ChainAddress <|-- EOA
    ChainAddress <|-- Contract
    Contract <|-- EntryPoint
    Contract <|-- SmartAccount
    Contract <|-- Paymaster
    Contract <|-- Factory
    Contract <|-- AccountImplementation
    SignerKey <|-- EOAKey
    SignerKey <|-- PasskeyP256
    EOAKey --> EOA : controlsAddress
    Claim <|-- RoleAssignment
    Claim <|-- LabelClaim
    Claim <|-- ThirdPartyClaim
    Claim <|-- FeeObservation
    FeeObservation <|-- ReceiptFee
    FeeObservation <|-- ActualGasCharge
    RoleAssignment --> ChainAddress : player (or SignerKey)
    RoleAssignment --> UserOperation : inContext (or Leg)
    ReceiptFee --> OuterTransaction : feeOf (exactly one)
    ActualGasCharge --> UserOperation : feeOf
    Claim --> Source : prov wasDerivedFrom
    Source <|-- ThirdPartySource
    LabelClaim --> Organization : publishedBy / sharesMachineryWith
    ThirdPartyClaim --> Organization : thirdPartyAttributedTo (hint)

Every Claim also points to a dimension, a grade and (for labels) a level, which are SKOS concepts. They are left out of the diagram for space.

4. What SHACL enforces (epi-shapes.ttl)

Result on real data: registry + 7 showcases = 20,570 triples (with the ontology), 1,497 claims, 0 violations. With --all, every explain record (17 transactions, 1,974 claims) also conforms. tests/test_ontology.py adds 14 deliberately bad fixtures, one per rule. Each one fails with the expected message.

Competency questions, answered over the example data

CQ1: Which vendors' infrastructure touched this UserOperation (tx 0x0c9f5c6d..., v0.6 Pimlico ERC20 paymaster + Safe), through which role, and at what evidence level?

ontology/queries/cq1-vendors-touching-userop.rq - 10 row(s)

CQ4: Which organisation attributions rest ONLY on third-party sources (no primary_source or cluster claim links the address to that organisation)? Restricted to addresses that played a role in the example transactions.

ontology/queries/cq4-third-party-only.rq - 7 row(s)

CQ9: For the addresses that played each role in the examples, how strong are their labels? (Distinct addresses per role and evidence level; 'none' = unlabelled.)

ontology/queries/cq9-label-levels-by-role.rq - 25 row(s)