Wallet-based attribution, referral records, and wallet marketing measurement

This implementation treats wallet-based attribution as a first-party event system, not an excuse for surveillance. It accepts explicit attribution records, and its published scope excludes cross-site tracking and covert ad enrichment.

My assessment: The code implements explicit first-party event persistence. It does not create a cookie-replacement graph, and production persistence remains unverified.

Where wallet attribution fits

Partnership referrals: credit a wallet-linked partner, contributor, or community referrer for a disclosed action.
Builder campaigns: associate a product activation or docs referral with a wallet-controlled identity the partner already uses.
Publisher constraints: do not merge wallet IDs with ad-network profiles or private off-site browsing history.

How this differs from third-party tracking

Traditional marketing stacks infer identity through cookies, pixels, or vendor-controlled graphs. The model documented here is simpler and narrower: a known wallet address is credited for a specific first-party event, and that record is stored only because the workflow explicitly asked for it.

Ask for purpose-specific consent before collecting a wallet identifier.
Store the minimum event, purpose, source, and retention fields; do not copy public transaction history into a profile.
Do not infer employer, identity, wealth, travel pattern, or relationship graphs from public activity.
Provide deletion and unlinking paths, and keep aggregate measurement separate from a person's event history.

Read the machine policy →Read the attribution spec

Common questions

Does this implementation do cross-site wallet tracking?

No. The published model limits collection to explicit first-party event records and rules out ad-network or cross-site tracking.

Is wallet attribution verified in production?

No. The code supports first-party attribution persistence for explicit event posts, but production persistence still needs independent verification.

Evidence, freshness, and corrections

Written and edited by: Rachel Julian, founder and editor
Last reviewed: 2026-08-13
Readiness rule: Scaffold means designed, not implemented. Beta means implemented with production verification pending. Live means independently verified end to end. Source code, ABI files, endpoints, or configuration never prove production availability.
Correction path: Report a correction or compare the capability changelog.

Source hierarchy

Primary standards: Protocol specifications and standards bodies define what an implementation must do.
Security guidance: Threat-model and identity guidance define controls, failure handling, and recovery expectations.
Deployment evidence: Independent end-to-end checks establish whether a configured production capability is live.
Editorial judgment: I apply those sources to revenue-travel decisions and state where the evidence stops.