Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Upload your unsigned document or select from our contract template library.
Click the "Create New Contract" button on your dashboard and select a file, or drag and drop your unsigned PDF into the upload field. EthSign currently only supports PDF files up to 5MB.
You can also choose a contract from our template library, which cover a wide range of categories, including intellectual property, business operations and transactions, and employment.
Chain agnostic, Web2-compatible authentication.
Go to the EthSign app here to login
We accept and support signatures made from the following list of blockchain wallets.
EVM: MetaMask, OKX, or any standard EVM wallet
Aptos: Petra
Bitcoin: Hiro
Solana: Phantom
TON: TON Connect, TON Space
We also accept and support signatures made from wallets associated with your Google and Twitter accounts, powered by Particle Network.
Configure encryption and expiry date before sending your contract.
Review, and if needed edit, your recipients. Optionally, configure an expiry date for your contract after which signatures cannot be made. Set your encryption method and send your contract!
To review EthSign's data encryption methods, and learn about upcoming encryption options see Data Encryption.
Capture consent with your Web3 identity.
If you designated yourself as a Signer, sign and fill in the date and text fields. EthSign supports custom signature styles. You can draw, type, or upload your signature.
Recipient Signers can input the contract's password, review the contract with ease, and then fill in the required fields. Enable email and Telegram notifications in Settings to be alerted when you have a document to review.
Bringing trust to trustless networks
EthSign is bringing trust to trustless networks by connecting real-world legal agreements and decentralized identities. We provide the same functionality, user experience, and legal validity as Web 2.0 e-signing platforms while leveraging the power of public blockchains to enhance transparency and security. Users can upload documents, create signing fields, customize annotation objects like text fields and checkboxes, invite co-signers, track signing status, download documents, and view events of the entire agreement lifecycle.
Digital signatures on EthSign are generated with EIP-712 or equivalent standards and written into the documents.
Industry-leading keyless encryption means you never have to remember any document passwords again, even applying retroactively to past documents once the user has enabled advanced encryption for their address.
EthSign complies with mainstream nations’ digital signature laws and signatures can be verified publicly at zero cost.
From its inception, one of the most substantial problems facing the Web3 industry has been the fragmentation and siloing of different blockchain systems. Even for veteran users, switching between blockchains is an annoying process, not to mention blockchains built on different virtual machines require different wallets to access. On top of that, universal data interoperability is nonexistent between blockchains.
Therefore, to break the chain barrier, we must end the reliance on smart contracts. This is not to say things are any less decentralized – we keep decentralization by flipping the data verification workflow though lazy verification, meaning data integrity is validated by the user's browser indepedently when it's loaded instead of when it's stored. As a result of this paradigm shift, we now support multiple wallets from multiple blockchains interacting with each other on EthSign. Signing a cross-chain agreement between Bitcoin, EVM, TON, and Solana users is becoming a reality.
We have added optional email and Telegram notifications to EthSign. Worry not, we never store any user information or telemetry unless it is necessary for the application to function properly. Email addresses and Telegram handles, for example, do not persist server-side and are automatically discarded once the notifications are sent out. Your document and signing data never leave your browser unencrypted unless you explicitly consent to bypass our industry-standard AES-256-GCM and ECIES encryption. We take privacy and data security extremely seriously – our business model does not and will never involve selling any raw or derived user data.
One of the major complaints of previous versions of EthSign was the speed (or lack thereof) of the interactions and the fact that random errors caused by faulty RPCs would stop users from completing their tasks. This is not only frustrating for the users but for us as well, since these errors are caused by factors outside our control. By embracing the aforementioned verification model, we have moved away from smart contracts and replaced them with an open-source backend on AWS, resulting in the total elimination of any wallet errors and extra wait time. Taking complete technical ownership and control of the entire workflow also eliminates our inability to fix certain errors. Combined with front-end optimizations, CDNs, and edge servers, this is our most performant version of EthSign to date.
Inarguably, two of the most important questions in the industry are “wen token” and “how centralized is this product”. With our previous talk regarding the use of AWS, it is only reasonable to raise some questions about our engineering practices in EthSign. Have we finally taken the red pill and gone down the rabbit hole of centralization since some think ordinary users don’t know any better or actually care? For the longest time, we have struggled with striking the right balance between decentralization and usability. A product cannot be so decentralized that we become a hostage to the various tech stacks we utilize that are completely out of our control, but it also cannot be so centralized that if the platform unexpectedly terminates service, all historical user data is lost or obfuscated.
In EthSign, we decided to adopt the practice of decentralized settlement. Any documents still being signed are stored centrally to improve user experience while those that have completed the signing process (settled contracts) are automatically submitted to Arweave at no cost to the user. Of course, regardless of the storage location, we fully respect and enforce the encryption rules set by the user. If the document is encrypted, nobody outside the intended group of recipients can decrypt the document, not even us.
We also took steps to make sure our users can still access their signed documents and cryptographic proof-of-consent even if we are gone. Once your documents have been permanently stored on Arweave, you no longer need us to access them and their respective metadata. You can easily index, decrypt, parse, and verify all your completed documents via an open-source tool that we will release later this year. Don’t trust us – trust the code.
Add recipients by inputting their emails and wallets or generating a signing link.
There are two ways to add a recipients to a contract: individually input recipients' email and wallet addresses or generate a signing link.
You may individually add signers and viewers by inputting their emails and wallet addresses. Signers will be asked to e-sign the contract. Viewers will receive the contract but will have read-only access.
Click the "Add New Recipients" button to add others to your signing session. You can also add yourself to the contract.
Optionally, enter the recipient's name and/or Telegram handle; if they have enabled notifications on EthSign, they will receive a message.
You can generate a signing link to distribute a contract to a large number of signers, making it ideal for agreements such as NDAs, Terms of Service, payment authorizations, DAO member agreements, and more. This approach allows you to share the link directly with recipients without the need to invite them via email or wallet address.
For generating signing links, you can select between two contract types:
Each signer signs their own contract:
Add a signature field to the contract.
Each signer receives an individual copy to sign.
All signatures on one contract:
All signers' signatures are appended to the bottom of a single, shared contract.
Cryptographic signatures are used to prove identity and sign documents.
Cryptographic signatures are at the core of EthSign, representing everything from data integrity to digital consent. We utilize your cryptographic signature to prove your identity and sign documents.
With the cross-chain nature of EthSign, we accept and support signatures made from the following list of blockchain wallets:
Enter the recipient's email, their wallet address (see ), and wallet network.
EVM: Coinbase, MetaMask, OKX, or any standard EVM wallet
Aptos: Petra
Bitcoin: Hiro
Solana: Phantom
TON: TON Connect, TON Space
Independently verify the validity of a digital signature from EthSign.
The ability to independently verify the validity of a digital signature is just as important as the act of signing, and this is exactly what EthSign Signatures offers. To verify your downloaded PDF file online, head here.
All documents that have completed signing are settled on Arweave. Since our document data structure is public and Arweave is an open network, technically anyone can upload data and have it considered "valid" as long as they conform to our data structure. This is not something we condemn — in fact, our game plan is to build a protocol and we love it when others build on top of our standard.
However, sometimes it is still necessary to distinguish an official implementation from a third-party implementation. This is the idea behind the "EthSign Certified" stamp - all documents created and signed on the official EthSign platform are digitally signed by a private key that EthSign controls and can be independently verified offline.
We also attest all document signing actions and completions on Sign Protocol.
EthSign Certified signing address (attest.ethsign.eth): 0x91f0ff8089A78A135E11123D84c07F9D93883E79
Users can verify the integrity of the original contents of their completed and downloaded PDF against the Arweave copy and the digital signatures within said downloaded PDF on our verification page.
Visit the Digital Signature Verification and Contract Audit tool here.
Verify the integrity of the contents and cryptographic signatures of any contract signed on EthSign. Note, the contract must be signed by all invited signers to be verified.
Upload the signed PDF to check its contents against the copy of the contract stored on Arweave. View the signers' addresses, creation date, signing dates, document key, and document storage CID.
All documents created and signed on EthSign Signatures are digitally signed by a private key that EthSign controls and can be independently verified offline.
EthSign Certified Signing Address: 0x0xCB9a3AA2eBa735f4d09Ad5b710989646aBE66e12
To review EthSign's data encryption methods, and learn about upcoming encryption options, see Signature Verification.
Configure signature styles, notifications, and contacts.
Click the "Add Styles" button to customize the visual style of your signature. You can type, draw, or upload a signature. Save multiple custom signature styles for future use.
Enable email and Telegram notifications to be alerted when you have a document to sign or review.
Save the contact information of your collaborators so you can invite them by name to future contracts. Click the "Saved Contacts" tab and add a contact by inputting their name, wallet information, and email address or Telegram handle.
EthSign uses a hybrid storage architecture to strike a balance between usability and decentralization. As a document is uploaded and a signing session is created, all data is temporarily stored in our servers to optimize performance. Once all parties have finished signing, the document is sealed and uploaded to Arweave for permanent, decentralized storage.
EthSign offers three different tiers of encryption.
At EthSign, we take data privacy extremely seriously. If document encryption is enabled, none of the encrypted data leaves the browser unencrypted. In other words, if our users choose to encrypt their data, nobody aside from the intended recipients can decrypt it, not even us.
EthSign offers three different tiers of encryption:
Unencrypted
AES-256-GCM: Symmetric password; Advanced Encryption Standard with Galois Counter Mode
AES-256-GCM + ECIES: Asymmetric passwordless; Advanced Encryption Standard with Galois Counter Mode + Elliptic Curve Integrated Encryption Scheme
The encryption method used throughout a signing session is dictated by the initiator.
Note: "Signing Session" refers to the process during which users send and sign a specific document.
All data is viewable by anyone else. It is extremely important to keep in mind that unencrypted data can be seen by everyone and once submitted to Arweave, it will become permanently visible to the entire world. There are cases where transparency is needed, but to avoid users disabling encryption by accident, we display a stern warning if the user attempts to submit data unencrypted.
AES-256-GCM is a symmetric encryption algorithm. It's been widely used and battle-tested over many years. When making use of this encryption method, all recipients must possess a copy of the passphrase that generates the AES key. This key must be kept secret and EthSign does not natively facilitate the key exchange.
Elliptic Curve Integrated Encryption Scheme is an asymmetric encryption algorithm, meaning the information needed to perform encryption is different from the information needed to perform decryption. In this case, a public key is used to encrypt data while the corresponding private key is needed to decrypt data. In the context of EthSign, using ECIES means nobody needs to memorize any passwords of any kind since the data is locked to every recipient's public encryption key.
This is a sequence diagram showcasing the encryption workflow. The word gibberish simply means the data is encrypted and thus opaque to us and everyone aside from the intended recipients.
This is somewhat similar to which made use of MetaMask's API. However, this API is now deprecated, and although a has been submitted, it is still in the draft stage. In addition, we had to make encryption universal across different blockchains (secp256k1 + curve25519), so we decided to establish our own encryption system, branded as EthSign Password Manager.
To learn how EthSign Password Manager works in detail, refer to .
Discord
Medium
GitHub
A curated collection of useful legal contract templates for the Web3 industry.
Visit the EthSign Contract Library here.
With the EthSign Contract Library, individuals and organizations can kickstart their projects with legally enforceable contracts and drive compliance from day one. Currently, available templates include:
Employment agreements for hiring employees, inviting advisors, or offering token grant
Fundraising agreements such as Simple Agreement for Future Token (SAFT) or Simple Agreement for Future Equity (SAFE)
Business transaction agreements such as Event Sponsorship or Terms of Use
IP protection agreements such as One-way or Mutual Non-Disclosure Agreement (NDA)
And more!
All templates have been written by prominent law firms and renowned legal professionals in the Web3 space, and are provided to EthSign users free of charge.
Please use this form to submit contract templates to EthSign Contract Library! Your submissions will be reviewed promptly and added to the library upon approval.
Secure password storage and sharing using asymmetric end-to-end encryption.
At EthSign, data privacy is one of our top priorities.
Users are advised to encrypt their EthSign contract data for enhanced security every time contract data is committed to decentralized storage. Due to the multi-chain nature of EthSign, users must generate their own passwords.
EthSign Password Manager enables secure and wallet-based password storage and sharing, so users never have to worry about remembering contract passwords.
Random bytes are locally generated as the decryption private key.
A random message is locally generated and signed by the user. The resulting digital signature is hashed to 256 bits and used as the ECIES private key. For incompatible wallets, a master password is used in place of a digital signature.
A public encryption key is then derived, signed, and sent to EthSign to enable password sharing capabilities. The random message is also sent to EthSign so users can regenerate their ECIES private key when they switch devices.
Possession of the random message alone does not compromise the security of this system and EthSign keeps a copy of this random message to prevent users from losing access to their encrypted data forever.
When sensitive data needs to be shared, it is encrypted to the recipient’s public encryption key which is stored with EthSign. When encrypted data needs to be decrypted, the user retrieves the random message from EthSign, signs it, and derives the private key locally to decrypt.
For more information, see How EthSign Handles Your Secrets.
A Legal Overview of E-signatures and EthSign’s Compliance
As large swaths of the business world recognize and embrace the convenience and flexibility of electronic signatures, one critical problem to consider is the legality and validity of e-signatures across different jurisdictions and in specific scenarios.
Broadly speaking, e-signature laws in different countries can be divided into two categories: technology-neutral laws and tiered-model laws.
Technology-neutral laws are also known as minimalist or permissive laws, which tend to adopt a broad definition of electronic signatures and do not stipulate specific technical requirements (e.g. security technologies like PKI-based digital certificates, cryptographic protocols) that e-signatures must meet in order to be legally binding and enforceable.
Jurisdictions that adopt technology-neutral e-signature laws include the United States, Canada, China, Australia, New Zealand, the Cayman Islands, and BVI. Subject to certain exceptions, which we will discuss later in this article, e-signatures in these jurisdictions carry the same (or similar) legal weight as handwritten signatures as long as they satisfy the general requirements of the specific country’s law.
In the U.S, for instance, the E-Sign Act and the Uniform Electronic Transactions Acts (UETA) define “electronic signature” as “an electronic sound, symbol, or process, attached to or logically associated with a contract or record and executed or adopted by a person with the intent to sign the record.” Therefore, for electronic signatures to be qualified under U.S. law, signers have to demonstrate their intent to sign the document, and the signature must be electronically connected to the corresponding document signed and cannot be transmitted to anyone else or onto any other document.
Tiered-model laws, on the other hand, set stricter requirements for e-signatures to be legally recognized. Jurisdictions adopting tiered model laws typically provide stronger legal presumptions to signers who use approved authentication or security technologies, which generate a more secure type of e-signatures, known as digital signatures*. Some jurisdictions may also require digital signatures to be verified by a Certificate Authority (CA)/Trust Service Provider (TSP). Nevertheless, tiered-model laws typically leave signers free to agree on the type of e-signatures they use when doing business, and rarely would courts deny the validity of e-signatures solely because they are not digital signatures or backed up by digital certificates.
*Note: “digital signatures” is not a legal term, but rather a specific technology implementation of electronic signatures that use algorithms to protect the integrity and authenticity of the signature and the signed document.
Tiered model laws are enacted by the European Union and many Asian jurisdictions including Singapore and Hong Kong. As an example, the European Union adopted the Electronic IDentification Authentication and Trust Services (eIDAS) regulation in 2016. An EU-wide legal framework, the eIDAS divides e-signatures into three tiers: simple electronic signatures (SES), advanced electronic signatures (AES), and qualified electronic signatures (QES). Among the 3, QES must be backed by a qualified certificate, issued by approved trusted service providers, and is considered the legal equivalent of handwritten signatures.
Notably, e-signatures are not legally admissible for certain kinds of use cases. In the U.S., these exceptions include court orders, power of attorney, wills, and family law documents such as adoption and divorce agreements. Bank deposits, mortgages, and some other promissory notes also require handwritten signatures from the parties and are excluded from the coverage of the E-Sign Act. Exceptions in other countries and jurisdictions are varied and should be considered on a case-by-case basis.
Under technology-neutral laws:
EthSign easily satisfies and exceeds the general requirements of simple or standard e-signatures under virtually all technology-neutral laws.
Using U.S. law as an example:
EthSign helps users show intent by having them either add a signature or click to sign the agreement;
Users show consent by having signers accept a standard or customized agreement before opening and signing the document;
Furthermore, EthSign’s cryptographically secure workflow can ensure that a signature is logically associated with the electronic record (i.e., the signed document). This is because when using EthSign, users are essentially signing a hash that combines the storage content ID of the document, that of any overlaid annotations, and the index of the document’s signing fields. Any mismatch of the above three will lead to an error detected by our algorithm, so the e-signature cannot be transmitted to anyone other than the signer.
Lastly, the electronic records are permanently stored in IPFS and Arweave, satisfying the record retention requirement.
It is worth pointing out that under U.S. law, there is no specific requirement regarding signer identification or association of the signature with the signer, which is an important and necessary requirement that many tiered-model laws specify.
Under tiered-model laws :
As a decentralized signing platform, EthSign does not collaborate with any third-party trust service provider or government agencies to verify the signer’s identity or issue certificates. This means our e-signatures would not qualify as qualified electronic signatures (QES) under the EU’s eIDAS framework or QES equivalent in other jurisdictions.
However, EthSign does comply with advanced electronic signature (AES) requirements under eIDAS. For e-signatures to qualify as AES, eIDAS requires unique signer identification and asks that signatures be linked to the data signed in a way that any subsequent data change is detectable.
The legal language here is formulated in a technology-neutral way and therefore does not necessarily require identity verification via government-issued credentials. As the world is migrating to the Web 3.0 stage, all forms of online identity can be used to verify one’s identity, including emails, phone numbers, and even public and private keys, thus enabling EthSign to satisfy the identification requirement without collecting or storing critical user information such as name, facial ID and government ID.
Furthermore, EthSign deploys the elliptic curve digital signing algorithm (ECDSA), which can easily verify and detect subsequent data changes made after signage: when given the data hash used for signing, ECDSA will return a public key that matches with the public key of the signer. If, however, changes are made to the data after signing, the return address from ECDSA will also change unpredictably, leading to a mismatch with the signer’s public key. Since the 256-bit hash of a piece of data is entirely unpredictable, EthSign essentially relies on the backbone of all modern cryptography to ensure our signature is tamper-proof.
Factors to consider when using E-signatures
Moving on from here, we have several suggestions to EthSign users concerning compliance and legality.
Choose the governing law: It is preferable to choose those jurisdictions adopting technology-neutral laws as they are more likely to embrace newly developed technologies and recognize blockchain-based e-signatures as legally binding and enforceable. Notably, many states in the U.S. (including Arizona, Vermont, and North Carolina) have passed amendments recognizing blockchain-backed e-signatures; e-signatures and electronic records are also widely recognized in China, where the Supreme People’s Court has recently approved the use of electronic records stored on the blockchain as court-admissible evidence.
Gain consent to use e-signatures: Parties should include explicit language in contracts and terms of agreements to agree on the use of e-signatures as the legal equivalent of handwritten signatures.
Determine whether the subject matter of the contract is appropriate for e-signatures: Take note of important exceptions such as mortgages and promissory notes where using e-signatures to sign those documents will not be legally recognized. For these use cases, EthSign can leverage blockchain technologies to give users greater flexibility: EthSign gives businesses easy access to smart contract-based innovations and is actively integrating with other DeFi protocols, allowing our users to make deals on-chain securely and potentially avoid certain statutory restrictions of e-signature laws.
Heather Zhou (EthSign’s Legal Researcher) is a Juris Doctor Candidate at Harvard Law School
Your input about our product is valuable to us, provide feedback here
[Twitter] [Discord] [Youtube] [Gitbook]
References:
[1] Mark Tibberts (Baker&McKenzie), How to Execute Contracts Electronically While Working From Home (30 March 2020)
[2] U.S. Congress, Electronic Signatures in Global and National Commerce Act
https://www.govinfo.gov/content/pkg/PLAW-106publ229/html/PLAW-106publ229.htm
[3] European Commission eIDAS Regulation
https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
[4] Carey Olsen, The legal validity of electronic signatures in Bermuda, the British Virgin Islands and the Cayman Islands
[5]Singapore Status, Electronic Transactions Act
https://sso.agc.gov.sg/Act/ETA2010
[6] Zegal, Global E-signing Handbook https://ts5mapnq9e48izo12znjei1n-wpengine.netdna-ssl.com/wp-content/themes/FoundationPress/ebooks/e-signatures/Zegal%20Global%20E-signing%20Handbook%20-%20Country%20by%20country%20guide.pdf
[7] National People’s Congress of China, China’s Electronic Signature Law (中华人民共和国电子签名法)
http://www.npc.gov.cn/wxzl/wxzl/2004-10/20/content_334609.htm
[8] Adobe, Brexit briefing: What is the impact on electronic signature laws in the UK?
[9] Ascertia, Basics of Digital Signatures & PKI
https://www.signinghub.com/wp-content/uploads/2017/05/Basics-of-Digital-Signatures-and-PKI-s.pdf
[10] Supreme People’s Court of China, Rules for Online Litigation in People’s Court (人民法院在线诉讼规则)
http://www.court.gov.cn/fabu-xiangqing-309551.html