You don't have to trust us. That's the design.

Most services ask for trust and offer promises. Redeal is built so that cheating is structurally impossible, then it hands you the tools to check. Everything below is a mechanism, not a policy.

Why we can't cheat, even if we wanted to

1. The engine is open

   The computation engine is built to be audited: no floats, no external data feeds, simple enough to re-implement from prose. Each algorithm ships with published test vectors generated by an independent Python reference implementation, and the engine matches them bit-for-bit. The source repo opens as a launch act; until then, the running service exposes the same algorithm contracts the tests pin down.

   Check: GET /v1/algorithms lists every algorithm with its input contract, live.

2. Inputs are sealed until lock-in

   Parties commit SHA-256 hashes before anyone reveals anything. The server stores hashes first and values second, and the protocol refuses to compute until every commitment is in. We never see an input early enough to act on it.

   Revealed inputs are stored encrypted at rest (AES-256-GCM) in a dedicated table with its own access path. They never appear in certificates, logs, or any third-party telemetry. The data policy states this plainly.

3. Computation is deterministic

   No floating point, no external price feeds, no AI anywhere near the engine, and randomness comes only from inputs sealed by the parties plus the public drand beacon at a round pinned before the deal opens. Given the same inputs, any machine on earth gets our result.

   Check: redeal verify <cert> re-executes the algorithm and compares bit-for-bit.

4. Every certificate enters a public log

   Each certificate is appended to a Merkle transparency log. The log is append-only: removing or altering an entry breaks the tree, and the breakage is visible to anyone holding an earlier tree head. We cannot quietly rewrite history.

   current signed tree head · tree_size 2 · root sha256:7b7d…1760 · checked 2026-08-12 · GET /v1/log/tree-head ↗

5. Signatures are publicly checkable

   Certificates are digitally signed (ECDSA P-256 via AWS KMS; certificates from before 2026-08-12 are Ed25519). The verifying public keys are published at GET /v1/status, and anyone can check any signature offline. The key lives in a managed HSM used sign-via-API: the server can request signatures but can never hold or export the key. Custody and rotations are recorded on the status page.

   If the key ever rotates, old certificates still verify against the key that signed them; the rotation history records which key was active when.

6. Flaking is on the record

   A party who commits and then refuses to reveal voids the deal, and the void produces its own artifact: a non-participation certificate naming their commitment hash. Portable evidence, usable by any reputation system. Walking away quietly is the one move the protocol doesn't offer.

   Miss the commit deadline and the deal simply expires with no certificate. The difference between the two is deliberate.

Trust pages