Attribution

When an agent buys, the merchant sees who paid and what for. It does not see the assistant or platform surface the agent acted through, or the referral that led to the purchase, which is the field commissions are paid on. Today that arrives as a URL parameter: an unsigned string the party being paid for it can write itself. An agent can emit any string, so the mechanism attributes whatever it is told to.

The claim

A claim binds the acting agent, the platform it acted through, an optional referrer, the merchant, and a validity window. It is signed by the issuer's own key, and the claim's issuer field must equal that key, so the claim is self-certifying and there is no attribution server in the middle.

const signed = issueAttributionClaim({
  issuer:     platformKey.publicKeyHex,
  issuedBy:   "platform",
  agent:      "agent-1",
  platform:   platformKey.publicKeyHex,
  referrer:   "ref-1",
  merchant:   "merchant-1",
  validFrom:  "2026-07-30T00:00:00.000Z",
  validUntil: "2026-07-31T00:00:00.000Z",
}, platformKey);

Who may issue, and who may not

Only two parties can issue: the agent that spent, and the platform it acted through. There is deliberately no third option. The referrer and the merchant are the parties value moves toward, and a claim signed by the beneficiary attests nothing.

Verification is deny-first and total

Every check runs, every failure is named, and a claim that fails any check attributes nothing. There is no partial credit, because the only consumer is a payout and a half-verified referral is an unverified referral.

Parties declared

Agent, platform, merchant and issuer are all present. An attribution missing a party attributes to nobody.

Issuer is the key

The claim's issuer equals the signing public key, and the signature verifies over the canonical claim.

Issuer holds the role

A claim marked issuedBy: "platform" signed by a key that is not the platform's is a platform impersonation, which is the whole attack.

Window

The window is not inverted, and the instant being evaluated falls inside it.

Referrer is not the merchant

A merchant cannot refer itself a commission.

Merchant scope

A claim is scoped to one merchant, so a real referral cannot be replayed onto another merchant's book.

Bound to the payment

The binding hashes the whole signed claim, signature included, and records it against the payment's own key. So a receipt is provably the receipt of the attribution it was made under, and a claim cannot be re-pointed at a larger purchase after the fact. A substituted claim fails, because the recomputed hash diverges.

Reconciliation

A merchant's book becomes per-platform and per-referrer volume. Each claim is verified at the instant its payment settled, not at report time. A claim with a one-hour window that was valid when the agent bought does not stop having been valid because the month closed, and a claim that had already expired cannot be rescued by running the report earlier.

Unverified volume is reported, never distributed. A payment whose claim fails, whose binding no longer matches, or that carries no claim at all lands in its own list with its failed checks attached. It is never spread pro rata and never folded into the largest bucket. An estimate in a payout report is a transfer from the parties who can prove their share to the parties who cannot.

verified + unverified   = total
sum(byPlatform)         = verified
sum(byReferrer) + direct = verified

Direct is not a bucket named unknown. It is volume whose claim positively asserted no referral, which is a different statement from a referrer we could not identify.

What it does not do

• It does not set commission rates or choose an attribution model. Last-touch, multi-touch and time-decay are merchant business policy and live outside.
• It does not track a person across merchants.
• It does not gate a payment. A missing claim makes a purchase unattributed, never refused.