PaperAuth - decentralized eSignatures

Demo

About

The problem it solves As of now, many industries still rely on pen and paper to sign documents, which is a total waste of time, especially when popular solutions like DocuSign offer GDPR-compliant options to sign legally binding documents. However, these regulations won't protect your personal information from hacks. Thus, the issue of trust remains. PaperAuth is the first software to use blockchain technology as a means of safety for eSignatures and your digital identity. Softwares such as HelloSign, DocuSign, and PandaDoc have already reached the masses, but they all store your eSignature on their servers. In other words, your eSignature is theirs and is exposed in every document you send. When you start thinking about it, storing eSignatures as on-chain SVGs, or perhaps even as NFTs, and audit trails as transactions is just the natural evolution.s The use cases for eSignatures are quite clear in the B2B and B2C realms. While enterprises are mostly willing to adopt decentralized technologies, adoption becomes a different issue when it comes to our everyday lives. Despite this, I believe that eSignatures could still thrive in personal contexts, such as with digital IDs or autographs. The challenge lies in the fact that blockchain technology is not always user-friendly and can be intimidating to some. That's why I decided to combine Flow with the "Reddit" method, which aims to reduce friction by using simple language and avoiding blockchain jargon. For example, instead of asking users to create a "wallet," PaperAuth uses the phrase "create a safe" to ensure the security of their information. For instance, to convey a sense of security while keeping it easy to understand, PaperAuth will use the phrase "create a safe" instead of "create a wallet" when prompting users to store their information securely. The word "wallet" might not make sense to some, especially in the context of storing your eSignature.

How it's made

Challenges we ran into As a typical web developer, I had high praise for Flow, such as "it's easy to get into," "it's user-friendly," and "Cadence is similar to TypeScript," and I must say these aren't false statements. However, when you only have one week to learn how to use the Flow CLI, the FCL, and to code using Cadence, things get tricky. That said, it's a fun learning curve. The most challenging part for me was integrating a seamless wallet creation process. I had to figure out a way to ensure that the user's eSignature would be safe and owned by itself only, while the documents would remain available even if the user's safe, or "wallet," got lost. This issue brought up many questions. When do you create the wallet? Do you tell the user about the blockchain side of things? Do you store the user's wallet in case they lose it? In the end, I opted for a different method than what you might see in a traditional Web3 dApp and tried to get as close as possible to the Web2 flow without compromising the layer of security that the blockchain adds. Here's what I did and how I did it: 1. The user creates a typical Web2 account using an email/password. The goal was to make it seem like a traditional SaaS, as I don't think people are entirely ready to move into Web3. 2. The user is prompted with an onboarding flow. This is where the "safe" comes in. The wallet is then associated with the user's account without exposing the eSignature. 3. In this final step, the user draws and links their eSignature with the newly created wallet. With all that, the user is aware that the eSignature is in their own hands, that the app can only recover their documents, and that their eSignature can't be easily stolen since it is not directly exposed in the sending process.