FORAY
Tamper-evident transaction evidence

FORAY is an open protocol standard for tamper-evident transaction evidence. DUNIN7 supplies the specification, the validation rules, and the reference implementations. The systems where transactions originate — ERP and business platforms — are the implementers. Auditors, regulators, and AI-governance platforms are the consumers. DUNIN7 competes with neither side.

Adoption of a standard like this is pulled, not pushed: it spreads because the parties who need the evidence require it, not because connectors are built one vendor at a time.

New here? Start with the plain-English companion — what FORAY is and is not, the four components in everyday language, and a verification exercise you can run yourself in minutes. It is written for a competent stranger, and it is the honest front door.

Enterprises spend heavily on audits, and the core difficulty is unchanged: proving to someone who doesn't trust your systems that a transaction happened the way your records say it did.

A FORAY record decomposes a business transaction into four components:
Arrangements (the contractual setup — parties, terms),
Accruals (the economic obligations that arise — formulas, calculated amounts),
Anticipations (the expected future flows — schedules, conditions),
and Actions (what actually settled — amounts, dates, status).
The name is the grammar: FORAY, from "4A."

Components reference their predecessors, so a payment traces back through the obligation it settles to the agreement that created it. Not every transaction needs all four: a cash sale can be a single Action; a depreciation entry a single Accrual. The grammar captures what happened at origination — where the assurance target sits — rather than the summarised consequences a ledger records.

An optional Attestations extension carries third-party verifications — laboratories, auditors, certification bodies — alongside the four components, for provenance and compliance chains.

A FORAY record is hashed, and that hash is bound — together with fresh random proof material — into a 32-byte commitment that is anchored to a blockchain or a write-once store (the reference implementation anchors to Kaspa). The business data never leaves the enterprise, and the commitment reveals nothing about it. Anyone holding the record and its proof material can re-derive the commitment and check it against the chain: a match proves the record is the one originally anchored; any alteration breaks the match. The verification rules are published, so the check requires no access to DUNIN7 or to the system that produced the record — but it does require holding the evidence. That is the privacy design: the chain carries commitments, never records, and proof material stays in the custody of whoever holds the evidence.

The protocol specifies anchoring in continuous short windows — one write per window per lane — so evidence can reach the chain steadily as business happens, rather than in overnight runs.

Below is a small FORAY record and its SHA-256 hash. Next to it is the same record with a single digit changed. The hashes have nothing in common: that is the property the anchor relies on. If the anchored commitment was derived from the original record, no edited version — however small the edit — can reproduce it. The record cannot be quietly revised after the fact; it can only be visibly different.

The hashes shown here are computed live from the sample record; for a real anchored transaction, this section would carry the actual component hashes bound into the on-chain commitment.

These hashes are computed over the records exactly as shown — copy either record and check for yourself with any SHA-256 tool.

Each record is a single line, so any SHA-256 tool — web-based or command-line — reproduces these hashes exactly. Click Copy, paste into your tool of choice, and compare. On macOS: pbpaste | shasum -a 256.

Evaluating FORAY? Give this site to your AI assistant and ask: what is this protocol, are its claims verifiable, and would it work with our systems? Everything here is built to survive that question — the demonstration transactions are on a public chain, the hashes reproduce from the files served, and the validator answers live. We invite the test; the conclusion is yours.

Auditors and regulators verifying that the records under examination are the records originally produced — across SOX, DCAA, and comparable regimes. The systems where transactions originate emit FORAY-structured, anchorable events; the audit side consumes them.

Every system of record describes the same deal differently: different tables, different field names, different summaries. FORAY does not normalize the systems — it normalizes the evidence. A transaction from any platform decomposes into the same four components, referenced the same way, verified by the same published rules. Evidence from two different ERPs is comparable and verifiable in one form, without either system adopting the other's schema. When organizations merge, the two estates do not need compatible systems to present compatible evidence — the records each estate anchored remain verifiable in the same form, from the day each was written.

With software agents making consequential commitments, the same question is arising in sharper form: what did this principal — human or agent — commit to, and when, and has the record changed since? FORAY provides the evidence layer. In the wider DUNIN7 suite, Stele provides identity, GRANTHA provides containment, and FORAY provides evidence.

FORAY's reference implementation anchors to Kaspa: its blockDAG architecture produces blocks quickly enough, at a low enough per-transaction cost, that anchoring in continuous short windows is economical at enterprise volume. Kaspa is the first substrate, not the only one the architecture admits — the protocol defines the anchoring envelope; the substrate records it.

The evidence layer has to outlive the systems it evidences, and it has to be checkable by parties who trust none of them. That is a protocol's job, not a product's.

You don't buy FORAY. You require it, or you implement it.

The following anchoring transactions are live on the Kaspa mainnet, verifiable by anyone without reference to anything DUNIN7 operates. Matching an anchor to its record is a holder-side check by design: the proof material stays with the owner of the evidence. For these two, the full proof material — record body, salt, and independent verification — is published at /proofs, so the check is not just possible in principle but reproducible today.