Skip to main content

Onchain Attribution

What decision requires an offchain source to be linked to an onchain outcome, and what identity data is unnecessary for that decision?

Onchain attribution is conditional measurement. It connects permitted source events to a relevant chain event while keeping consent, retention, confidence, and unmeasured gaps visible. A transaction proves an event occurred; it does not by itself prove why it occurred.

Changes my mind: The attribution cannot change a legitimate decision, or the required identity linkage creates more privacy risk than decision value.

Model​

source event → consented join → onchain event → confidence → decision

Onchain Attribution​

  • Valuable outcome: a consented acquisition source can be connected to a relevant onchain outcome at a stated confidence without exposing more identity than the decision requires.
  • Trigger and inputs: a material onchain outcome, approved privacy model, event definitions, source identifiers, contract addresses, and retention rules.
  • Required business skills: attribution design, data governance, privacy, measurement, onchain analysis, and causal humility.
  • Tool categories and selection: use consent management, analytics, privacy-preserving identifiers, chain data, indexers, and reconciliation tools selected for completeness, explainability, deletion, and access control.
  • Concrete outputs: attribution model, event and consent contract, gap log, privacy guardrails, baseline, and confidence-labelled report.
  • Human edge and safe AI: humans own consent, identity linkage, retention, incident response, and interpretation. AI may join permitted events and flag gaps; it must not infer real-world identity or present correlation as cause.
  • Proof, cadence, and kill signals: verify one end-to-end permitted path and publish attribution gaps internally. Review continuously for incidents and weekly for decisions. Stop collection on unapproved linkage, unexplained gaps, or when the data cannot change a legitimate decision.

Practice​

Start from the decision, then define the minimum source event, join event, onchain event, retention period, access rule, deletion route, and confidence label. Test one consented end-to-end path. Record every event that remains unattributed instead of silently filling gaps.

Run It​

Use this prompt only with approved, non-sensitive evidence. Do not paste wallet or identity data that the decision does not require.

Help me design the minimum legitimate onchain attribution path.

Decision the attribution may change: [decision]
Material onchain outcome: [event and contract]
Approved source events: [events]
Permitted join method: [method or unknown]
Consent and privacy authority: [policy owner and evidence]
Retention, access, and deletion rules: [rules]
Known gaps: [unattributed or unavailable events]
Review date: [date]

Separate observed events, inferred joins, causal hypotheses, and unknowns. Do
not infer a person's identity, invent consent, fill missing events, or present
correlation as cause.

Produce:
1. the minimum event and consent contract;
2. the source-to-join-to-onchain path;
3. required fields with a decision-specific justification for each;
4. confidence labels and an explicit unattributed gap log;
5. access, retention, deletion, and incident controls;
6. one consented end-to-end proof test;
7. weekly review and stop conditions;
8. the final human decision: approve, revise, or reject collection.

The privacy and business owners retain approval and stop authority. If the attribution cannot change the named decision, do not collect the linkage.

Learning Return​

Return unexplained joins, unattributed outcomes, deletion failures, incidents, and decision usefulness to the attribution model review. Narrow the event set when a retained field adds risk without improving the decision.

Failure modes​

Offchain analytics that stop before the material outcome measure intent, not completion. Wallet-to-person linkage without explicit need and consent expands risk. Last-touch certainty applied to a multi-touch route creates a comfortable story, not causal proof.

Context​

  • depends-on Verifiable Intent — keep delegated authority distinct from measurement.
  • pairs-with Ecosystem Distribution — distinguish native sources only when it changes a decision.
  • applies-to GTM Distribution — add onchain attribution only when the outcome is material.
  • proved-by Marketing Performance — keep the intended outcome above the instrument.
  • uses Tight Five — keep the instrument connected to principles, platform, performance, and players.

Questions​

Next question: Which returned gap or incident should narrow the event contract before the next attribution decision?

  • Which join is consented?
  • Which retained field no longer earns its privacy cost?