[ Docs ](https://sendnda.com/docs) [ Evidence ](https://sendnda.com/docs/evidence) The signing record ================== The chained log of every step, and what each entry holds. 03 Evidence -------- Article 1 of 3 Every NDA on Send NDA carries its own log. Each step, from the moment the agreement is saved to the moment its PDF is sealed, is written as an event. So is every delivery report on its emails, even one that arrives after the seal. Nothing in the log is edited later: a new fact is a new event at the end. The events are chained. Each one's hash covers the event before it, so taking an event out, changing one, or putting them in another order breaks every hash after it. That's what lets anyone check the record later instead of taking our word for it. What gets recorded ------------------ These are the events an NDA can collect, in the order they usually happen: | Event | When | What it holds | |---|---|---| | `created` | The NDA is saved | Both names and email addresses, who discloses, the AI tools level, the purpose, the four optional clauses, and both durations. | | `sent` | The signing emails go out | The template version and the SHA-256 of the agreement as it went out. | | `resent` | The sender resends the recipient's link | Nothing beyond the time. | | `viewed` | The recipient first opens the NDA | The IP address, `credential` and `link_id`. | | `redlined` | The sender is shown what the recipient's own details changed in the agreement | The SHA-256 of the text they were shown, and a code for each adjustment the recipient's own law made. Written once per text, so a second look adds nothing. | | `notified` | A party is shown what their own country's law asks of them, and goes on to sign | Which party, a code for each thing they were told, and the wording they were shown with its sources, under the same template version, SHA-256, consent, `credential`, `link_id` and user agent their signature carries. Some statutes turn on whether a party knew, so the record holds what they were told rather than only that something was shown. | | `approved` | A party approves the clauses that weigh on them, where the governing law asks for that | Which party, the headings of the clauses they approved, and the same template version, SHA-256, consent, `credential`, `link_id` and user agent their signature carries. | | `signed` | A party signs | Which party, the signature (the party's name as entered on the NDA, and the SHA-256 of the signature they drew where they drew one), the IP address, `credential` and `link_id`, the browser's user agent, that consent was given, the template version, and the SHA-256 of the agreement as that party saw it. | | `completed` | The second signature lands | Nothing beyond the time. | | `frozen` | The sealed PDF is stored | The template version and the SHA-256 of both the PDF and the HTML it was printed from. | | `certified` | The signing certificate is stored | The SHA-256 of the certificate. | | `anchored` | A Bitcoin block confirms the seal's OpenTimestamps stamp | The SHA-256 of the stamped manifest and of the proof, the block's number, its merkle root and its time. | `credential` says how the party signed in: `magic_link` for a link from an email, `passkey`, `session`, `api_token` for an API token, or `oauth_token` for a connected app. `link_id` is a hash that identifies that credential without being it, and is `null` for a session. Two more kinds of event can appear. `amended` records a change either party made before anyone signed: the sender's to the terms, or the recipient's to their own details. It holds which party, which fields, the values before and after, whether the recipient's email address changed, which withdraws their unused links, and the party's `credential` and `link_id`. It also holds the template version, the SHA-256 of the amended agreement and the SHA-256 of the text it superseded, which is what the redline reads back to show what moved. Where the recipient's answer to the consumer question changed, the question goes in too, in the words they were asked. And the email provider reports back when an email about the NDA was delivered or bounced, as `resend.email.delivered` and `resend.email.bounced`, with the provider's own message id and timestamp. These reports can arrive after `certified`. How the chain works ------------------- Every event is first written out as one fixed piece of text, the canonical payload. It has a version line, the NDA's id, the event's sequence number, its type, the time in UTC, and then every field sorted by name. Each field carries its length in bytes, so a value that contains a line break can't pass itself off as a second field. The event's hash is the SHA-256 of the previous event's hash, a line break, and that canonical payload. The first event has no previous hash. Sequence numbers start at 1 and have no gaps, and the database refuses two events with the same number for one NDA. ``` hash = sha256(previous_hash + "\n" + canonical_payload) ``` The canonical payload is stored exactly as it was hashed, next to the fields it came from. A check hashes the stored text, and also rebuilds it from the stored fields to see that the two still agree. How it's checked ---------------- A check walks the events in order and stops at the first one that fails. An event passes when: - its sequence number is the next one, with no gap; - it points at the hash of the event before it; - its stored canonical payload is what its stored fields produce, so changing a field alone is caught; - its hash is what the previous hash and its canonical payload produce. This check runs every time someone verifies a PDF. A PDF only counts as a match when its NDA's chain passes. See [Verify a copy](https://sendnda.com/docs/evidence/verify-a-copy). Who sees what ------------- Both parties get the result in the sealed PDF: each signature with its date, time in UTC and IP address. The signing certificate that comes with it prints every event up to the seal, with its hash. Both of you see the steps on the NDA's page, with the time of each: sent, viewed, signed and completed. Once it's completed, the page's **Signing record** lists when the recipient viewed it and when each of you signed, each with its time in UTC and IP address. The full chain stays on Send NDA's side, and the [Privacy Policy](https://sendnda.com/legal/privacy) says how long it's kept. Checked against the code on 18 October 2026. [ The sealed PDF ](https://sendnda.com/docs/evidence/the-sealed-pdf)