Learn

Safety

Conformance, Audits and Mainnet Gates for Agent Payment Rails

Conformance is necessary for interoperability, but mainnet readiness requires separate audit evidence, rail review, verifier review and operational controls.

Compatibility is the first gate, not the last gate

Conformance tells builders whether their objects, transports, rails, security checks and registry metadata match Accord's current v0 expectations. That is essential for interoperability. It is also easy to overstate.

A compatible implementation can still have a vulnerable contract, weak signer operations, bad verifier incentives, bridge risk, replay gaps or poor incident response.

What conformance should prove

Conformance should prove that an implementation speaks the protocol correctly. Agreement objects should validate. Receipts should bind to the correct agreement. Rail adapters should expose the expected behavior. Registry metadata should be coherent. Security guardrails should exist where the protocol expects them.

That is a strong claim, but it is not the same as saying real funds are safe.

What audits must cover separately

External audits should evaluate code paths and assumptions that conformance cannot prove: smart contracts, ErgoScript or EVM behavior, facilitator trust, bridge assumptions, signer isolation, private-key handling, verifier incentives and operational recovery.

The audit scope should name exact artifacts. A vague audit badge is not enough for a rail that can move value.

Why signed manifests are better than vibes

A signed audit manifest gives software and operators something concrete to check. It can say which script hash, bytecode, package version or deployment is covered and whether mainnet use is allowed.

Without that explicit evidence, the safer default is denial. This is especially important for agent systems because agents can act quickly, repeatedly and without the judgment a human would apply to every transaction.

A mainnet readiness checklist

Before a real-fund rail launch, require passing conformance, signed audit evidence, documented verifier assumptions, buyer policy caps, signer isolation, replay protection, incident response, monitoring, rollback paths and public status language that does not overclaim.

The checklist should include negative tests and failure drills. Happy-path settlement evidence is useful, but production credibility comes from knowing what happens when something fails.

The current Accord posture

Accord v0 is alpha / testnet-first and NOT CERTIFIED FOR MAINNET. That is not weak positioning; it is professional positioning. It tells developers where the system is useful today and where stronger evidence is still required.

The right path is to make local demos, conformance and testnet work excellent while keeping production claims gated by signed evidence.

FAQ

Does passing L4 conformance mean production-ready?

No. It means registry and compatibility checks pass. Production readiness requires separate audit and operational evidence.

Why use signed audit manifests?

They let software and operators check exact covered artifacts instead of relying on broad claims.

Can testnet evidence support a future audit?

Yes. Testnet evidence is useful, but it does not replace external review or mainnet-specific risk assessment.

Sources and references

Accord conformance package

Reference L0-L4 conformance tooling for Accord implementations.

Accord audit docs

Repository audit-gate materials and manifest format documentation.

ErgoScript documentation

Official ErgoScript documentation for understanding Ergo's contract model and eUTXO assumptions.

Next action

Check public status

Keep production claims audit-gated and deny-by-default until signed evidence exists.

Open