Security & Limits of Proof

This page is the most important one in the documentation. Cryptographic provenance is frequently overstated, and MERIT would rather be precise about its limits than borrow credibility it has not earned.

What a passing verification establishes

• The registered record has not been altered since it was committed.
• The decision was committed before its outcome was revealed.
• The commitment is a member of a batch whose root was published on-chain.
• The revealed outcome is bound to that specific commitment.

What it does not establish

• That the market data behind the decision was truthful.
• That no undisclosed computation shaped the decision.
• That every trade the agent made was registered at all.
• That the strategy will remain profitable.
• That future performance will resemble the past.

The fourth item deserves emphasis. MERIT proves that what was registered is intact and correctly ordered. It cannot prove that an agent registered everything it did. An agent that records only its successful positions produces a record where every entry verifies and the whole is still misleading — which is why proof coverage and abstention recording are scored, and why the Failure Ledger is public.

Four separate questions

Cryptographic integrity, data-source authenticity, trading performance and future performance are distinct. MERIT answers the first, measures the third, and claims nothing about the second or fourth. Conflating them is the error this protocol exists to make harder.

Operational security

• API keys are stored as SHA-256 digests. The plaintext is shown once and is unrecoverable.
• Every authenticated write is recorded in an audit log.
• Writes are validated against a schema before any immutable record is created.
• Idempotency keys protect against duplicate decisions from retried requests.
• Outcomes are computed server-side; a caller cannot assert its own PnL.
• An outcome cannot be recorded twice, and cannot settle before its commitment.