eSign

Document settlements on Aetrna

This feature conducts the on-chain settlements / agreements between multiple parties. Allows to sign documents and check the integrity / authenticity of the certified docs by verifying the signatures.

The process is the following:

File preparation and initial signing:

(user A is the initiator, user B is the co-signer)

1. User A prepares a PDF document

2. User A selects encryption type in the app (the internal PDF encryption should be disabled)

3. User A sets the co-signer's Ethereum address

4. User A draws his visual signature

5. The browser assembles the manifest that is going to include original_hash of the file User A has prepared, the list of co-signers (User A and User B), timestamp and the joint statement that both parties are agreeing upon.

6. User A signs the manifest (that is going to be in the final document) and uploads the file

Example of manifest

{ "aetrna_certification_version": "Alpha", "designated_co_signer_addresses": [ "0x...User_B_Ethereum_Address" ], "hash_algorithm": "keccak256", "original_hash": "0x123...", "pdf_filename": "document.pdf", "statement": "I attest to the authenticity and integrity of this document.", "timestamp": 1750836306, "uploader_address": "User_A_Ethereum_Address" }

Co-signing:

1. User B opens his Library page on Aetrna app

2. User B sees the document awating for co-signing on his Library page

3. User B clicks on "Co-sign" button and is able to see what document he is about to co-sign

4. User B puts the visual signature in the placeholder set by User A

5. User B signs manifest extracted from the PDF he is signing

6. User B makes a delta file that he formed (with his visual signature and ECDSA signatures)

7. User B calls the contract with his signature on the manifest and the delta

Then, whenever the document is downloaded, the PDF file itself will have both visual signatures of user A and B, along with a table in the last stamp page.

---

Legal paper trail

TLDR: To connect blockchain trail to email trail, both parties (initiator and cosigner) must send to each other an email with some sort of confirmation that they have signed the document. In most cases, exchanging the wallet addresses is enough, but for maximum confidence the users should exchange the wallets, a message and a signature over that message.

We can not and will not enforce it, but it is in user's mutual interests if email trail is necessary. To simplify the process, we provide a tool to quickly assemble such confimation emails — you can use the "email trail" feature right after the signing (both for Initiator and Co-signer) and also you can assemble such an email in Library at any time.

In-depth explaination:

To enable the legal binding with emails, we must connect 2 worlds — blockchain and email. Therefore, both parties should be able to make sure that the counterparty has full access to the inbox.

There are several solutions to this, however, due to the principles of Aetrna, we:

• do NOT provide an intermediary (third party) that will distribute the one-time-passwords that will confirm the possession of the email account of the users (because the intermediary can be hacked and the email addresses along with timestamps will get leaked, therefore anyone would be able to narrow down the emails to wallet addresses which is something we want to avoid at all costs).

• do NOT store nor see any sensitive user data such as emails, names, files etc. Therefore even if our backend will get compromised, the worse that they will see is the public addresses and timestamps that are already available to anyone to read from the blockchain.

• can NOT legally store the emails with DKIM signatures and other headers inside the blockchain

Therefore, the only way that will preserve the privacy, security and decentralization of the process is to pass this part of the flow onto the users to exchange the emails between themselves with some evidence about on-chain signing process.

Both parties (initiator and co-signers) must be interested in this email exchange if they take their on-chain agreement seriously and legal-binding. Without this exchange (from user A to user B, and from user B to user A), both parties are risking to have a huge disadvantage in case if legal proces is invoked.

If user A (initiator) and user B (co-signer) set a contract with emails, without confirmation exchange, here is what could happen:

1. Initiator can make a new wallet, fund it via shielded transactions, and sign a contract with co-signer without even letting them know about it, effectively signing a contract with themself.

2. Co-signer, on the other hand, can absolutely dispute the validity of the contract even if he did actually sign the contract. He can accuse Initiator of signing it with himself (1)

This is why both parties must exchange the messages via emails that confirm their participation in the signing process.

1. If Initiator didnt send the confirmation to co-signer, the co-signer will have no legal basis in believing that the owner of user A's email is the Initiator.

2. If co-signer would not send the confirmation email back to Initiator party, the Initiator party will have a disadvantage in case of legal process, since the co-signer party could claim that they did not sign and the wallet is not in their possession.

The legacy apps are solving this problem by storing the user data (emails, logs, names, etc) and which then could be provided in legal case scenario. But this also puts the users in the risk of data leaks or hacks and undercuts their privacy, which we specifically aiming to solve.

---

Verification

1. Anyone can download and open (if unencrypted) the document

2. After co-signing, the document can be verified in the dedicated feature Verify that will check the document's original_hash and signatures over the manifest from the PDF file.

Which essentially proves that:

1. The document was not altered after signing, otherwise the original_hash will not match to the one in manifest

2. Both initiator (User A) and co-signer (User B) were the ones who signed that manifest and visual drawings inside the file with its original hash and the statement.

A successfull verification looks like this:

Successfull verification