The independent layer for binding contracts.
We generate, sign, and seal — then step out of the trust chain. Every sealed PDF is independently verifiable, forever.
Live demo
A sealed residential lease, ready to verify
- Envelope ID
- env_019e7e023f9e7eb29415666e2a268b5b
- Sealed
- 2026-05-31
Live API call that fetches the JSON verification record. It does not check the seal — that happens offline in Adobe Reader.
What just happened
You watched your browser ask our deployment for proof.
The verifier did not take our word for it. It fetched the cryptographic artefact and rendered the three things that actually matter.
- 01
PAdES-B-T level
Confirmation that the PDF contains an embedded PKCS#7/CMS detached signature and a trusted RFC 3161 timestamp. PAdES-B-T is an ETSI standard, not something we invented.
- 02
RFC 3161 stamp time
The moment a third-party Timestamping Authority (DigiCert, with FreeTSA fallback) attested the signed bytes existed in that exact form. That third party — not us — is what anchors the timestamp in court.
- 03
Signing certificate chain
The ECDSA P-256 leaf, intermediate, and root that signed the envelope — verifiable against the CA root we publish at /.well-known/contractgen-ca.pem.
None of those three depend on us being online. Download the sealed PDF, open it in Adobe Reader, import the CA cert. Adobe will report the signature as valid using only the PDF and what's on your laptop.
The technical stack
Three layers, none of them invented here.
Cryptography
- ECDSA P-256 signing keys
- SHA-256 hash chain
- PKCS#7/CMS detached signatures embedded in the PDF byte stream
Standards
- PAdES-B-T (ETSI EN 319 142)
- RFC 3161 trusted timestamps
- ECTA s.13/14/15 (advanced electronic signature alignment for South African parties)
Audit
- Hash-chained SHA-256 log
- Every signing event recorded
- Chain head embedded in the sealed PDF metadata so post-hoc tampering is detectable
Try it yourself
Generate a sealed contract right now.
The production deployment accepts envelope creation requests. With a tenant API key you can issue a real envelope. A sealed PAdES-B-T PDF comes back in under a minute.
# Create an envelope curl -X POST https://contractgen-production.up.railway.app/v1/envelopes \ -H "Authorization: Bearer <your-tenant-key>" \ -H "Content-Type: application/json" \ --data-binary @your-envelope.json
Built for three different readers.
For developers
The whole API in one spec
OpenAPI 3.1 spec with try-it-out, code samples in curl, Rust, and JavaScript, and an honest authentication model.
Browse the API →For legal teams
What the verification artefact actually proves
Field-by-field deep dive on the verification.json output, with the ECTA framing and honest limits.
Read the deep dive →About the engineering
Read the source
Open source under MIT. Rust workspace; design specs and per-feature plans committed alongside the code.
Open on GitHub ↗