AlphaCurve ContractPowered by frontier AI modelsOpenAIClaude

Draft it, argue it, finalize it —then leave behind evidence that holds up

AI reads the whole contract and points out missing clauses and internal contradictions. Once it is finalized, every signature leaves the other side evidence they cancheck for themselves, without trusting you.

Sign in / Register

The demo runs the full product on sample data. Nothing is saved to our servers.

Content fingerprint
SHA-256
Third-party timestamp
RFC 3161
Version differences
Line by line

The question procurement always asks

If we disappear tomorrow, the evidence still stands

Procurement tends to ask a vendor three things: what if you go under? what if you alter the record? and what if the party we end up suing is you? Here are the answers — no technical vocabulary required.

  1. The documents only count because they are not held by us

    The moment signing completes, the contract PDF and the evidence report are delivered to both mailboxes as real attachments — not download links. If this platform shuts down, those two files are still in your inbox.

  2. Anyone can check it themselves, with no account here

    We publish an open-source verifier: drop the evidence package in and it recomputes every item inside your own browser, offline if you like. If you would rather not use it, the package ships the commands to do the same thing with free standard tools.

  3. The point in time is witnessed outside, not asserted by us

    Each day's signatures are folded into a single value and sent to three unrelated places, one of which is Bitcoin. Colluding would mean colluding with all of them — and one of them cannot be colluded with by anybody.

The ceiling, stated plainly: none of this makes the terms of a contract valid, and none of it proves who the signer is as a natural person. What it proves is that this document was exactly this at that point in time, and has not been altered since.

The day it goes wrong

When they open their mouth, what have you got

A contract is usually taken out of the drawer at the point where nobody is being polite any more. Each line below is something the other side might say. Turn a card over to see what produces the answer — and what that particular thing fails to prove.

This isn't the one you gave me. Something was changed.

What you can put on the table

The content fingerprint from the moment of finalization, plus a time attestation issued by a third party. They can compute it and check it themselves, without going through us.

Mechanism and limits

This isn't the one you gave me. Something was changed.

At finalization we compute SHA-256 over that version's content as UTF-8 text. The fingerprint is printed in the evidence report and in the “certified digital fingerprint” block on the last page of the A4 document. The same fingerprint goes to a third-party timestamping authority, which returns an RFC 3161 token; the .tsr file can be downloaded and verified independently with openssl ts -verify — no account here, and no need to trust us. The evidence report compares the hash the timestamp covers against the current fingerprint and labels it either “timestamp matches: covers the current fingerprint” or “timestamp does not match: not the current fingerprint”.

What this does not prove: A timestamp proves that hash existed before the moment of issuance. It does not prove the content is true, does not prove who signed, and is not notarization.

The records are in your database. You can change them whenever you like.

What you can put on the table

We are not going to argue this one: a hash chain cannot protect you from us. What counts is the part handed to a third party — and the report marks, section by section, which parts have that and which do not.

Mechanism and limits

The records are in your database. You can change them whenever you like.

The audit trail is an append-only hash chain: each event's hash includes the previous event's hash, so changing one entry without recomputing everything after it is detected immediately. But the party who can recompute the whole chain — us — produces a chain that verifies perfectly. So the head of the chain is sent to a third-party timestamping authority for an RFC 3161 timestamp, and from that moment everything before it is beyond our reach. The evidence report labels each stretch “anchored” or “unanchored” and states in plain words that unanchored means only that our own records are internally consistent, with no third-party corroboration. The database adds two more: written signature rows are blocked from UPDATE by an append-only trigger, and every foreign key touching signature evidence is ON DELETE RESTRICT — once a contract or invitation carries signature evidence, the database refuses to delete it.

What this does not prove: The hash chain by itself carries no weight against this platform, and unanchored stretches have only passed our own consistency check. That sentence is not marketing; it is printed on the evidence report.

Even with a third-party timestamp — you picked the timestamping company.

What you can put on the table

Which is why each day's aggregate goes to three unrelated places at once, and one of them is Bitcoin. Collusion would have to cover all three, and nobody can collude with that one.

Mechanism and limits

Even with a third-party timestamp — you picked the timestamping company.

At the end of each day, that day's signatures are aggregated into a Merkle tree. A leaf is SHA-256(0x00 ‖ canonical record); an internal node is SHA-256(0x01 ‖ left ‖ right). The prefix separates the two, so a leaf cannot be passed off as an internal node; an odd node is promoted unchanged rather than paired with itself. The leaf record uses a length-prefixed format (name=byteLength:value) with a fixed field order — v, signature_id, request_id, contract_id, chain_head_hash, chain_head_seq, signed_at — published in the evidence report so it can be recomputed. The root, together with a self-describing statement (date, format version, root, that day's count), goes to three places: an RFC 3161 timestamp (several authorities as fallback, recording which one actually signed), the Sigstore Rekor public transparency log, and OpenTimestamps, which ends up in a Bitcoin transaction. Rekor is queried by looking the statement's SHA-256 up in the index, so a third party never has to accept our word for which entry is yours. Once an OpenTimestamps receipt is confirmed by Bitcoin, verifying it needs only Bitcoin — not us, not Sigstore, and not OpenTimestamps still being around. The evidence report lists all three separately with their own status, including the OTS wait before confirmation and the Bitcoin block height after it. What is printed is your day's actual values — the root, Rekor's logIndex, the Bitcoin block height — not examples from the explanatory text; each one can be looked up in the corresponding public system, and those systems have nothing to do with this platform.

What this does not prove: What leaves this building is a 64-character hash and a date. The contract text, the names and the amounts are not in it — which is necessary for privacy and also means it proves nothing about what the content was. Aggregation is per DAY and the tree is only built after the day closes, so something signed today waits until today is over. Signatures older than the audit hash chain will never be covered, and the report says so. While OpenTimestamps reads “submitted, not yet confirmed”, that receipt is not yet an independently verifiable time attestation, and that usually lasts hours — during which the report still shows no block height even if the digest has in fact already been written into a Bitcoin transaction, because until the receipt is completed, “your digest is under that transaction” is the calendar's claim rather than a verifiable path. We would rather the report said it late than said it early on someone else's authority. And finally: no law gives a document more standing because its hash appeared on Bitcoin. What improves is your ability to prove things.

I didn't sign that.

What you can put on the table

To sign, they first had to receive a code at the mailbox you specified in advance. Every step after that records the time, the source IP and the device.

Mechanism and limits

I didn't sign that.

The recipient address is filled in by the initiator; the signing page only shows it masked, and the counterparty cannot change it. The six-digit code is valid for 10 minutes, is void after 5 wrong attempts, can be resent no sooner than every 60 seconds, and no more than 5 times per invitation. The signing history records, one by one, the invitation being sent, verification passing, the contract being opened for the first time, the consent declaration being ticked, and the signature being completed — each with time, source IP and User-Agent. The evidence report records the level actually reached and prints the whole L1–L4 scale beside it — L3 multi-factor (e-mail plus a Passkey device check, e-mail plus a sign-in to the Google/Microsoft account matching the specified mailbox, or e-mail plus an SMS code sent to the initiator-specified mobile number — an opt-in add-on granted per organisation) is stated when achieved, and L4 certificate-based signing (a TWCA-issued certificate digitally signing the contract PDF after TWID identity verification — likewise an opt-in add-on granted per organisation) is stated when achieved — precisely so that no level is read as the ceiling.

What this does not prove: L2 proves that at the moment of signing they could receive mail at that specified address. It is not proof of a natural person's identity: a mailbox may be shared, forwarded, or read by someone else. We do not write “identity verified”, and the system performs no check against any ID document, personal certificate or company certificate.

I signed it, but I had no authority to bind the company.

What you can put on the table

Whatever they said about their own authority at the time is kept word for word, and the company details you filled in beforehand are printed alongside the ones they filled in themselves.

Mechanism and limits

I signed it, but I had no authority to bind the company.

The consent declaration includes “I confirm that the signer name, title and company details above are correct, and that I am authorised to sign this contract on behalf of the party named above”, and the full text as submitted is snapshotted into the signature record. The evidence report additionally sets “initiator's expectation” against “signer's declaration” field by field, across five fields: company name, business number, signer name, title, and e-mail domain. Each is marked matches / does not match / declared only, nothing to compare against / expected only, never declared / neither side provided. A mismatch does not block signing; both versions are kept exactly as given and are never reconciled — the discrepancy is itself a fact.

What this does not prove: The comparison normalises only full-width versus half-width characters, case, whitespace and the company's legal form (“股份有限公司” against “(股)”). There is no fuzzy matching. A third column, “public registry”, is a snapshot of what Taiwan's company register (MOEA Department of Commerce open data) said about the business number at the moment of signing — which proves only what was registered at that time. The report therefore says “Company Registry Match: MATCH”, never “representative verified”: a register cannot prove that the person at the screen is that natural person, and it does not determine whether they really had authority. Ticking a consent declaration does not create authority out of nothing; what it leaves behind is their explicit statement about their own authority at that moment.

If you shut down one day, where do I get the document?

What you can put on the table

Not from us. The moment signing completed, the documents were already sitting as attachments in both parties' mailboxes.

Mechanism and limits

If you shut down one day, where do I get the document?

Once the signing transaction commits, the system sends the completion notice in the background. The contract PDF and the evidence report PDF are real MIME attachments, not download links — a copy lands in each party's own mailbox and does not depend on this platform continuing to exist. The initiator and the signer each get their own. The message prints the SHA-256 of contract.pdf and of evidence-report.pdf, plus the finalized content fingerprint, and notes that the three do not cover the same thing: the first two are byte hashes of the attachments, and only the last is what the timestamp was issued over.

What this does not prove: Attachments are bounded by the mail provider's 10MB per-message limit; above it the message degrades and the delivery status states truthfully which document was “not attached”. If PDF rendering fails, the message is not sent at all — we do not send a message that claims to carry a document it does not carry.

The copy you sent me and the copy you kept were never going to be identical.

What you can put on the table

They are. Neither side's contract PDF is printed by their own browser; both are the same bytes, rendered by the same server.

Mechanism and limits

The copy you sent me and the copy you kept were never going to be identical.

Contract PDFs are always rendered server-side by headless Chromium, pinned to Chrome for Testing 152.0.7977.54: colour profile pinned to sRGB, font hinting and LCD subpixel smoothing off, timezone pinned to Asia/Taipei, viewport and device scale factor fixed. After output, the only two values in the PDF that vary run to run — /CreationDate and /ModDate — are normalised to fixed values. If an /ID appears in the trailer, rendering fails outright rather than quietly producing a file that will not reconcile later. A finalized contract's content no longer changes, so every render of the same contract yields the same bytes.

What this does not prove: This guarantee covers the contract PDF only. The evidence report keeps growing as events accumulate — one more delivery record for every successful send — so two evidence report PDFs are not necessarily byte-identical. We do not claim a PDF file is archived in the system: what is kept is the contract content and its fingerprint, and the PDF is re-rendered on demand.

One of the middle pages was pulled out and replaced. Would you even notice?

What you can put on the table

Not from the same seal stamped on every page. Slice the seal, one slice per page, and a mismatch is visible.

Mechanism and limits

One of the middle pages was pulled out and replaced. Would you even notice?

The straddle seal cuts the company seal into N equal-width slices and prints one down the right edge of each page at a fixed vertical position. The seal is only whole when the pages are in order; pull one out, swap one in, or reorder them, and the slices no longer line up. It requires the company seal to be uploaded under Settings → Organisation, applies only to documents of 2 pages or more, can be switched per document or set as the default for new contracts, and locks on finalization.

What this does not prove: This is visual recognition on paper, not cryptographic protection: a seal image can be copied, and reprinting the whole document realigns it. The straddle seal setting is also outside what the finalization fingerprint covers — tamper resistance comes from the content hash, the RFC 3161 timestamp and the audit hash chain, not from this seal.

Proving mine is in your records — doesn't that expose every signature you hold?

What you can put on the table

No. One root goes out, yours is still provable from it, and what anyone else signed, or how much, is not visible.

Mechanism and limits

Proving mine is in your records — doesn't that expose every signature you hold?

The daily aggregate gathers every signature completed that day into a Merkle tree, and the only thing published is the root (where it goes is described in “you picked the timestamping company” above). The evidence report prints your leaf's record verbatim, the leaf hash, its position in the day (slice N of M), and every step of the inclusion proof: the sibling hash in full, with the direction labelled “left (before)” or “right (after)”. A leaf is SHA-256(0x00 || record) and an internal node is SHA-256(0x01 || sibling || running value), with domain separation between the two, so you can recompute the root yourself. The proof is recomputed live rather than stored, so a stored proof can never drift from the actual data.

What this does not prove: Aggregation by itself does not prove we did not rebuild the whole tree; what carries weight is still the third parties the root was sent to. The day's tree is only built after that business day closes, so a signature completed today first shows as not yet included.

Hovering pauses it; a click stops it so you can read.

These limits are written into the product, not just onto this page: the evidence report marks an unanchored stretch as unanchored, and an assurance level we do not offer as not offered.

The chain of legal weight

One contract, four different things proved

A template tool helps you type the words. What is added here is what comes after. Scroll down, and the panel on the right changes to the screen that each link actually produces.

  1. 01 · Finalize

    Content fingerprint (SHA-256)

    Proves: The content has not been changed

    At finalization, SHA-256 is computed over the content itself. The full hash can be copied in one click and is printed in the “certified digital fingerprint” block on the last page of the A4 document. Anyone holding the same content and using standard tools arrives at exactly the same value.

  2. 02 · Sign

    External signing evidence

    Proves: The other side did express agreement

    The other side does not register; they open a link and sign. By default they must first enter a six-digit code sent to the mailbox you specified before they can read the contract. The system records the signer's name and title, the version signed and its content hash, the source IP, the browser User-Agent, the drawn signature image, and a full-text snapshot of the consent declaration as it stood at that moment.

  3. 03 · Timestamp

    Trusted timestamp (RFC 3161)

    Proves: The content already existed at that point in time

    The finalization fingerprint is submitted to an independent third-party timestamping authority. Once the .tsr is downloaded, the other side or their lawyer can verify it with openssl — without an account here, and without trusting us.

  4. 04 · Report

    Audit trail and evidence report

    Proves: The whole history is accounted for

    Creation, every saved version with that version's hash, status transitions, approvals, online signing and timestamping are strung into an append-only timeline that prints as a contract audit evidence report. The report also carries the audit hash chain and the daily aggregate, labelling each stretch anchored or unanchored and flagging automatically whether the hashes match.

Download the .tsr and verify it yourself with standard tools (illustrative)
$ openssl ts -verify \
    -in contract.tsr -data contract.txt \
    -CAfile tsa-chain.pem
Verification: OK

Or drop the whole evidence .zip into the open-source verifier — every check is recomputed in your browser, and it works with the network unplugged. Open the verifier

Scope, stated up front

  • External signing is designed around the concept of a general electronic signature under Taiwan's Electronic Signatures Act, building a chain of evidence from the declaration of intent, e-mail verification, the document fingerprint and the audit trail. It is not a certificate-based digital signature.
  • Trusted timestamps are issued by a third-party authority and prove the content existed at that point in time. They are not notarization, and the feature must be enabled by a system administrator.

Screens captured from the sign-up-free demo. The contracts shown are samples, not any real customer's data.

Signing and identity

Not just that it was signed — who signed it

Everything that happens on the signing page is recorded. When the other side says “I didn't sign that” or “I had no authority”, you have what happened at the time.

E-mail verification proves that, at the moment of signing, the other side could receive mail at the address you specified. It does not prove the natural-person identity of whoever was at the keyboard: a mailbox may be shared, forwarded, or read by an assistant. It is not equivalent to a personal certificate or to notarization.

What the AI does

The AI drafts and compares. You decide.

Every AI output is shown to you first, and you choose whether to take it. Nothing writes itself into the contract. Hover a card — or tap it — for the detail.

Screens captured from the sign-up-free demo. The contracts shown are samples, not any real customer's data. AI-generated content must be reviewed by counsel. It is a starting point for a draft, not a document you can sign as it stands. The demo answers AI calls from a local stub, so what is shown above is the interface and the input, not model output.

The life of a contract

What each stage leaves behind decides what you can produce later

From drafting to archiving, a contract goes through five stages. What each one gives you, and what kind of evidence each one deposits, laid out.

  1. 01

    Drafting

    Clauses, variables and the A4 layout sit on one screen. Amounts, dates and company names are entered once and flow through the whole text, and article numbers renumber themselves.

    What it leaves behind: Every saved version records the time, the author and a version note, and SHA-256 is computed over that version's content.

  2. 02

    Review

    Named reviewers approve one by one and comments attach to individual clauses. Any two versions compare line by line: additions in green, deletions in red.

    What it leaves behind: Who approved, when, and with what comment all enter the audit trail. Without approval, the contract cannot be finalized.

  3. 03

    Finalization

    The content locks. Changing it means un-finalizing first — and un-finalizing is itself a record. The contract PDF is rendered by the server, so both sides hold the same bytes.

    What it leaves behind: The SHA-256 fingerprint computed over that version at finalization, printed in the evidence report and on the last page of the A4 document. The same fingerprint goes to a third-party timestamping authority and comes back as an RFC 3161 token.

  4. 04

    External signing

    Send the invitation link. The other side passes the code sent to the mailbox you specified, then ticks the consent declaration and signs. On completion each party receives a notification with the PDFs attached.

    What it leaves behind: Invitation sent, verification passed, first opened, consent ticked and signature completed each leave a time, a source IP and a User-Agent, plus a verbatim snapshot of the consent declaration.

  5. 05

    Archiving

    The whole timeline prints as an evidence report and downloads as an evidence package. That day's signatures are then aggregated into a Merkle tree whose root goes to a public log and to Bitcoin.

    What it leaves behind: An append-only hash chain, an RFC 3161 timestamp, the daily Merkle root, and the publication records for Rekor and OpenTimestamps — with the report marking, stretch by stretch, what is anchored and what is not.

Drafting speed

Layout, numbering and repeated details are the system's job

What actually eats the time is rarely the wording. It is renumbering articles, reconciling amounts and swapping company names. All of that is automated away.

Articles number themselves

Insert a new article in the middle and everything after it shifts up on its own. No more editing “Article 7” and “Article 8” by hand.

Reordering warns about broken cross-references

Reorder by dragging, by keyboard, or by saying “move to article N”. Before it applies, the system lists which “see Article 8” references this reorder would repoint — numbers recompute themselves, but text written into a clause does not, and that is where the silent errors live.

Company seal and each handler's own seal

The company seal is set on the organisation and stamped in the entity field; a personal seal is set by each member and stamped in the handler field, coming along automatically when that member is assigned. What is stored in the document is the snapshot at that moment, so a member later changing their seal or leaving does not affect contracts already sent out.

Six variable types

Text, date, number, amount, list and image. Amount variables take an ISO 4217 currency and a tax rule (percentage or fixed, added on or included), and changing the value in one place updates the whole document.

Three scopes for variables

Contract variables › organisation variables › built-in own-party details, with the contract's own value winning on a name collision — one set for the whole company, overridden in place when a particular contract needs an exception.

Template library

Save a contract you have tuned as a template in one click. Next time, fill in the variable values you already know and get an editable new contract straight away.

Quotations and attachments

Subtotals and totals compute live, frequently used items are saved to a catalogue for reuse, the AI can generate line items from a scope of work, and the whole thing attaches to the contract as “Attachment 1”.

True A4 pagination preview

The “page 2 of 3” you see in the preview is what comes out of the printer, with the company letterhead repeated on every page — no discovering at print time that the signature block was cut in half.

Tax calculation on amount variables is a documentation aid only. For an actual tax determination, consult your accountant.

Versions and collaboration

Every change leaves a trace

Versions, approvals and comments are all part of the audit record, and they go into the evidence report's timeline together.

Versions do not overwrite each other

Every press of “save version” leaves a version behind, and once saved it cannot be edited or deleted. The version note is what lets you recognise, six months later, what that version changed.

Any two versions, line by line

Added lines on green, deleted lines on red, and unchanged stretches folded to “… 12 lines unchanged …”. Which few words the other side quietly altered is visible at a glance.

Every reviewer must approve before finalization

Name the reviewers when sending for approval. While anyone has not approved, the “finalize” button stays grey; any one of them pressing “request changes” returns it to draft immediately.

Comments at the clause level

Discussion attaches to the contract or to an individual clause and can be marked resolved but not deleted. Comments never appear on the printed document and are never seen by the external signer.

Attachments lock with the contract

The moment a contract is finalized, the quotation attached to it refuses edits and deletion, and the “save” button disappears entirely. That is what keeps the content covered by the signature evidence from changing afterwards. To adjust it, return the contract to draft and the attachment unlocks immediately.

Two-factor login (personal opt-in)

The account holds the whole company's contracts, so account security is part of what makes the records credible. Each member can enable two-factor login for themselves: after the password, a second step — a one-time code mailed to the account address, or an OAuth sign-in to the Google/Microsoft account matching it (your choice, with the mailed code always available as the way back). Turning it on, off, or switching methods all require re-entering the password — whoever finds a logged-in screen cannot switch it off.

See what it actually looks like first

The demo comes with five sample contracts in different states — including an NDA that is finalized, signed online and timestamped, whose audit trail and evidence report you can open straight away.

Sign in / Register

Sample data lives in the browser tab and is never saved to our servers. Close the tab and it is gone.