The Vendor Event Layer

A portable proof history the counterparty owns — and the network that compounds from it.

When a vendor confirms a payment, a bilateral event is written to the CAST log, a lineage hash is computed, and the buyer’s system records it permanently. But the vendor sees only a confirmation screen that disappears when they close the browser.

If a dispute arises ninety days later, the vendor’s evidence is: “I got a message and tapped a button.” That is not a proof record. It is a memory.

The Vendor Event Layer closes that gap. It gives every vendor a persistent, queryable, exportable record of every bilateral event they have co-authored — across all of their buyers on the CAST network — that they own and can share with any third party.

One source of truth, not a second ledger

The bilateral event already exists in the canonical event log. The vendor layer does not create new events or a parallel record. It is a vendor-scoped projection of events the vendor already co-authored, plus the ability to export them.

Export is a read operation. Generating a proof export does not append an event, modify a Work Order, or change the lineage chain. The export is a signed snapshot of existing events at a point in time. The canonical log remains the single source of truth.

Why it matters

Dispute evidence

The vendor holds durable proof of exactly what they confirmed, when, for how much, and to which account — not a recollection of an SMS.

A network asset

A vendor who has confirmed 200 transactions across 12 buyers has built a trust history. That history becomes an asset they carry, not data trapped on each buyer’s side.

Downstream verification

Auditors, lenders, and insurers get a structured, signed way to verify a vendor’s payment history — without contacting either counterparty.

Scoping is structural, and buyer data stays private

A vendor can only see bilateral events where they are the confirming party. They cannot see other vendors’ events, other buyers’ payment flows, or proposed events that never became bilateral. This is enforced at the query and row-level security layer — not by application code.

What the vendor sees is deliberately narrow: their own confirmation, the amount, the pay date, the bank last-four they confirmed, the policy version pinned at confirmation, and the lineage hash. What they never see: the buyer’s GL codes, cost centers, budgets, approval chains, or other vendors. The buyer is identified only by entity type (for example, MFG/US-MW), never legal name.

The portable proof export

A vendor can request a signed export — a single transaction or a date range. The package contains the bilateral event records, their lineage hashes, and a CAST signature over the whole payload.

proof export — what a third party receives

{
  "export_type": "date_range",
  "bilateral_events": [ ... ],     // the events the vendor co-authored
  "lineage_hashes":   [ ... ],     // independently checkable
  "cast_signature":   "…"          // verify without contacting CAST
}

The CAST signature is the point: a lender or auditor can verify the export is authentic and unmodified without contacting CAST or the buyer. The proof travels with the vendor.

This is Validation-as-a-Service, made concrete

The Liability-as-a-Service argument says the downstream economy will pay to verify proof on demand. The Vendor Event Layer is the mechanism. A new event type — third_party_verification_requested — logs each time an auditor, lender, or insurer calls the verification API to confirm a specific bilateral event, recording the requester type and the outcome.

The events behind this layer

See the vendor event category in the full taxonomy.

Why this is the network effect

Confirm & Pay’s value to a single buyer is fraud prevention. But every confirmation a vendor makes also thickens their portable history — which makes them easier for the next buyer to trust, easier for a lender to underwrite, easier for an auditor to clear. The proof asset compounds on the counterparty’s side, across the whole network, from events that were going to be created anyway.

The same vendor layer spans every vertical — accounts payable, association and HOA payments, GPU compute financing, and institutional grant disbursement — because it projects the one thing they all share: a bilateral event the vendor co-authored.