How TrustChain records a signature

The creator signs in to a TrustChain account and fills in the agreement: the title, what is being done, the amount, the dates and the other person's email address.

TrustChain's server saves the record, not the creator's browser: no browser or app can create an agreement record directly. The record holds the creator's account ID, the email address entered for each side, the title, the amount and currency, the agreement text and its other fields, the status (waiting for signatures), both signatures marked as not signed yet, and the time it was created.

On agreements made with the current form, the server writes the agreement text itself from the fields it has just saved, so the text people read, sign and anchor matches those fields.

The server also gives the agreement an 8-character Record ID. The public record link (trustchain.biz/verify/ followed by the Record ID) and the certificate use it. TrustChain also keeps a longer internal record ID for each agreement.

The agreement's History gets its first entry: the creator created the agreement, with the time. No IP address is recorded for this step.

The creator invites the other person by email, as the person who signs. The creator can also invite other people as viewers, who can read the agreement but can't sign it.

For each invitation, TrustChain's server makes a new random link. It keeps only a one-way hash of the link's secret part, never the link itself, and emails the link from TrustChain's address through Resend, an email delivery service. The creator's page also shows the link, so the creator can copy it and send it another way.

How long a link works: 7 days. While new identity checks are paused, a new link works for 14 days instead, so it doesn't run out while the person waits for checks to come back. Right now a new link works for 14 days. A link already sent keeps the expiry it was sent with.

A link opens the agreement as often as needed until it expires, the creator cancels the invitation, or the creator sends a new link. Pressing "Send a new link" makes the old link stop working. Inviting the same address again creates a second invitation, and both links work until each one expires or is cancelled.

The History records the invitation being created and sent, with the time, the creator and the invited address. Both entries are written before the email is handed to the delivery service, so on their own they don't show that the email arrived. If delivery fails, the invitation is marked as undelivered and the creator is asked to send a new link. Changing the invited address, cancelling an invitation and sending a new link each add their own entry.

The address of the person who signs can be edited only until their link is opened, anyone signs, or the invitation is linked to their TrustChain account. After that, until the invited person signs, the creator can only cancel the invitation, which removes that address's access and is recorded in the History, and invite someone else.

If a link expires before it is used, the invited person can ask for a new one from the expired link's page. TrustChain tells the creator, at most once a day, and only the creator can send a new link. The request adds an entry to the History.

When someone opens the link, TrustChain's server finds the invitation from the link and checks that it hasn't expired and wasn't cancelled. It records the first opening of that link and each viewing of the agreement in the History, and starts a guest session for that one invitation, so the person can read the agreement without making an account.

The IP address of each opening and viewing is kept in that History entry (section 8).

If the person is already signed in to a TrustChain account whose confirmed email is the invited address, they sign from that account instead of a guest session.

A guest session started from a link keeps working after the link expires or is replaced. Cancelling the invitation ends it.

Signed in to a TrustChain account

The creator always signs this way. The invited person can too, when their account's confirmed email is the invited address.

Signed with the invite link

The invited person signs in the guest session their invite link started.

Each signature records which of the two was used. TrustChain's server works out who is signing, and on which side, from the account or the invitation the person is signed in with, never from anything the browser says. A viewer's invitation can't sign, and each invite link can sign only once.

Everyone who signs on TrustChain passes an identity check first. The check is required: TrustChain's server refuses a signature unless its record for the signing account says the check passed. There is no way to sign without it.

Sumsub, an identity verification company, runs the check in its own window on TrustChain's page, with a photo ID and a selfie. The documents go to Sumsub. To learn the result, TrustChain's server asks Sumsub for the check's record. Sumsub's reply can include details read from the ID, such as the name, and TrustChain keeps only the result. No browser or app can write that result. A TrustChain account passes the check once; a guest session from an invite link has a check of its own.

New identity checks are paused right now. Someone who passed the check before can still sign. Anyone else can sign once checks are back. Writing an agreement, inviting and sharing it work meanwhile. The check stays a required step the whole time.

What the stamp shows. Each signature made after a passed check carries a stamp: ID checked by Sumsub. It shows that, when the signature was saved, TrustChain's record for the signing account said Sumsub's check had passed with a positive result.

What it doesn't show. TrustChain doesn't keep the ID document or the selfie, and doesn't keep the name Sumsub checked. It doesn't compare that name with any name in the agreement or with the email address. For a signature made with an invite link, the check belongs to that invitation's guest session, not to a TrustChain account. The details of a check are held by Sumsub. Signatures made before TrustChain added the stamp don't have one, and TrustChain never adds one afterwards.

Both places where a person signs, the agreement page for an account and the invite link's page, show the agreement first: the title, the other person, the amount, the completion date and the full text (on older agreements, also standard clauses built from other fields).

Under it is a box to tick, labelled "I want to sign this agreement", with this line: "I've read all the terms above. I understand my signature will be recorded with the date and time and tied to my verified identity." The signature isn't sent until the box is ticked. TrustChain's server doesn't record the tick itself.

Right above the sign button, as plain text and not behind a link, is this sentence:

A signature doesn't store which version of this sentence its page showed. TrustChain can't see a person's screen, so its records don't show that the person read the sentence.

When the person presses the button, TrustChain's server checks their sign-in, works out which side they sign for, and checks that the agreement is still open for signing, that they haven't signed already and that their identity check passed. Then it saves everything below in one step: either all of it is saved, or none of it is.

Time

The moment the signature was saved, set by TrustChain's database from Google's server clock, not by the signer's phone or computer. The certificate shows it in UTC.

Method

Signed in to a TrustChain account, or signed with the invite link.

Who

The account ID or the invitation ID, the email address from the sign-in or from the invitation, the side (creator or invited person), and whether it was a guest session. For the creator, the address is the one on their account, which TrustChain doesn't require them to have confirmed.

Identity check stamp

ID checked by Sumsub (section 5).

Signing IP address

The IP address TrustChain recorded for the signing request. TrustChain takes it from the address its web framework reported for the request, which on some requests can be one the caller sent. It is kept in the signature's History entry, which both people on the agreement, and anyone invited to view it, are allowed to read, as the sentence above the button says. The agreement page doesn't display it today. A person on the agreement can ask TrustChain for it (section 14).

An IP address can belong to a mobile carrier, an employer, a VPN or a shared network. It doesn't identify a person or a precise place, and TrustChain doesn't look up locations.

When the second person signs, the status becomes signed by both, the same time is saved as the time both had signed, and the History gets a signed by both entry. TrustChain then emails both people: the creator at their account's confirmed address, if it has one, and the invited person at the address their signature was recorded under.

TrustChain also records the IP address for these steps: opening an invite link, viewing the agreement from it, asking for a new link, and confirming the work is done. It takes each one from the address its web framework reported for the request, which on some requests can be one the caller sent.

Each address is kept in that step's History entry, which both people on the agreement, and anyone invited to view it, are allowed to read.

Creating an agreement, sending, changing or cancelling an invitation, and anchoring record no IP address.

Every step above adds an entry to the agreement's History, each with its time from TrustChain's server: created, invitation sent, address changed, invitation cancelled, new link sent, invitation opened, agreement viewed, new link asked for, signed, signed by both, confirmed done, completed and anchored.

Only TrustChain's servers write History entries. No browser or app can add, change or delete one, and none can change the agreement text, the signatures, the status or their times on the record. Both people on the agreement, and anyone invited whose invitation still stands, can read the History.

Two entries, created and anchored, are written just after their step rather than in the same step. If one of those writes failed, the entry is missing, and the record's own times still show when the step happened.

These rules bind browsers and apps. They don't bind TrustChain's own servers, or a person with administrative access to TrustChain's database, who could change a record. That is one reason anchoring exists: an anchored fingerprint is on Polygon, outside TrustChain's control. The rules have also changed over time, so for an older record TrustChain can say which rules applied when it was made.

After both have signed, each person can press a button saying everything agreed has been done. The creator does it from the agreement page, and the invited person from their account or their own invite link. A viewer can't.

Each press adds a confirmed entry to the History, with its time from TrustChain's server clock and the IP address of the request (section 8). When both have pressed it, the status becomes complete, that time is saved on the record, and the History gets a completed entry.

This records only that each person pressed the button. TrustChain doesn't check the work or any payment.

Anchoring is optional and never automatic. After both have signed, a person on the agreement who has a TrustChain account can choose to anchor it. It is part of the paid plans, or a one-off purchase on the Free plan (Pricing).

TrustChain's server computes the record's fingerprint: a Keccak-256 hash over TrustChain's internal record ID, the title, the agreement text, the amount, the creator's account ID and the invited person's account ID (left empty when the record holds none for them, as when they signed with the invite link without a TrustChain account). It sends that to TrustChain's registry contract on Polygon in a transaction that TrustChain's own wallet sends and pays for. The people on the agreement don't sign it and don't need a wallet.

Exactly what goes on-chain:

• the fingerprint;
• TrustChain's internal record ID for the agreement, as plain text (not the 8-character Record ID);
• two wallet address slots, left empty;
• the time of the block the transaction is in, as the Polygon network records it, and the address of TrustChain's anchoring wallet, which sent it.

No agreement text, names, email addresses, amounts, signatures, IP addresses or identity check results are written to Polygon.

TrustChain waits for one confirmation, then saves the network, the contract address, the transaction hash, the block number, the fingerprint and the time, and adds an anchored entry to the History.

What it shows. The fingerprint was written to Polygon at that block's time, and the contract has no function to change or delete an entry. A later change to any field the fingerprint covers would no longer match it, so an anchored record is tamper-evident. What it doesn't show. It doesn't cover the signatures, their times, the identity checks or any PDF, and it doesn't show who signed.

The contract address and the anchoring wallet are listed on Security. Has a signed contract been changed? explains how a record is checked against Polygon.

TrustChain keeps:

• the agreement record: the text, the title, the amount, the email address entered for each side, the account IDs, the statuses and their times;
• the History;
• each signature, with everything listed in section 7;
• each invitation, with only a one-way hash of its link;
• the IP addresses described in section 8, in their History entries;
• for each account or guest session that took the identity check: Sumsub's result, when it last changed, and Sumsub's reference for that check.

TrustChain doesn't keep:

• ID documents, ID photos or selfies. Sumsub handles them.
• Legal names. TrustChain doesn't ask for or check a legal name. An account may show a display name from a sign-in provider, such as a Google account name, which nobody checks.
• The invite links themselves.
• Copies of the PDFs people download.
• The chat between the two people in readable form. It is end-to-end encrypted, and only the people in the chat can read it.

What the records don't show: who physically pressed a button (they show which account or invitation made each request, and what TrustChain's checks found at that moment); who used an invite link, since the creator can also copy it and send it on; whether the work was done or anyone paid; what was on a person's screen beyond what this page describes; or anything that happened outside TrustChain.

Either person can download the agreement PDF, from the agreement page or the invite link's page: the parties, the full text and the History. It is the main record.

The certificate is a one-page summary: the Record ID, the status, when each person signed, the completion date and, if the record was anchored, the anchor details. It doesn't show the agreement text. A person's own copy shows each email address partly hidden; the copy anyone can download from the public record page shows none.

Both are made in the browser of the person who downloads them, from the record at that moment. TrustChain doesn't keep a copy, and a PDF can be changed after download, so check it against the live record at trustchain.biz/verify/ followed by the Record ID.

A person on an agreement who needs TrustChain's records of it, for example for a tribunal or a court, can write to founder@trustchain.biz with the Record ID. TrustChain keeps the records this page describes for every agreement, and can export them for that one: the record, its History, the invitations without their link hashes, and the identity check result. The identity documents themselves are with Sumsub, not TrustChain.

This page is versioned. When the procedure changes, the version and date at the top change and the list of changes says what moved, so a record can be read against the procedure that applied when it was made. TrustChain keeps every earlier version of this page and can provide it on request.