We're a fintech and need proof our transaction logic is correct. What are our options?

The install is the same shape as the other audit: one component, about four weeks, a fee fixed after scoping. We draft the requirements from the code, the tracker, and the docs nobody updated. Owners approve every clause before any line is judged. A person validates every finding before you see it. What stays is not a PDF. The graph, the records, and the gate land in the repository.

proof audit --check spec_lint_ac_subset_of_satisfies
proof audit --check acceptance_criteria_witnessed

spec_lint_ac_subset_of_satisfies fails if an acceptance criterion is not a subset of a shall. acceptance_criteria_witnessed fails if a shall has no witnessed criterion. A SOC 2 control does not have those exits. Neither does a PCI ROC.

The public payments example on the graph uses shalls of that shape: a refund never exceeds the captured amount; a declined card is never charged twice; an idempotency key replays the same response; a ledger entry is written before a charge is reported. Those are owner-signed promises, not glossary terms.

If the job is “can card data leave the CDE,” keep the QSA. If the job is “did we follow the controls we wrote,” keep the Type II firm. If the job is “this capture must not fire twice, and the ledger must exist first,” those firms are the wrong instrument. That is the audit we run.

Unsafe configuration: the governor executes a treasury-changing call in the same block. Fixed configuration: execution routes through a timelock with a non-zero delay. The release gate is red until the delay, the executor identity, and the Governor-to-Timelock path have witnesses.

proof audit --fail-level warn

Slither still reports signals. Foundry still runs the tests. forge coverage is line and branch, not MC/DC. Proof’s job on that repo is to force those signals onto requirements, or to leave the gate red. We have not claimed a dollar figure for a public incident we did not audit.

Z3 on that demo is a set of data-domain predicates (delay elapsed, predecessor done, cancelled stays inactive). It is not TLA+ for cross-service consensus. For distributed transactions, keep TLA+ or Jepsen. That split is already in the research notes; we will not pretend Kind2 covers a saga.

We have not run Proof and Certora, or Proof and a QSA, on the same frozen corpus. A green proof audit means the checks we selected passed on the approved shalls. It does not mean the card-data scope is clean, and it does not mean we selected every promise a salesperson ever made.

Slither still owns the Solidity scanner. Certora still owns on-chain formal specs if that is the job. Jama still wins at programme authoring. The commercial shape of the install is on the audit page. The independent-check seed that does not name money stays on software correctness audit. The security wedge stays on correctness vs security.

Is there a way to get a signed, evidence-backed verification of a critical code path? Yes. The finding is a reproducer a named reviewer signed. That is this install, not a second URL.

How can I prove to an enterprise customer that our software behaves as specified? The graph and the gate land in their repo. The commercial shape is on the audit page.

We passed a security audit but still ship functional bugs. What kind of audit catches those? A pentest does not read the shall. Correctness vs security.

How do I get an independent check that the software does what we promised? One component, approved shalls, the same gate in CI. That seed is on the independent-check page.