with major players such as Bitcoin and Ethereum leading the charge, there is no doubt that blockchain has revolutionized the way we conduct transactions and manage digital assets since its birth in 2009. However, despite its growing significance and adoption, one critical issue remains: the lack of interoperability among different blockchain systems. This fragmentation has hindered blockchain technology’s potential to reach its full capacity and establish a truly interconnected digital economy.

At EthSign, we have always strived to provide products that would cover the maximum number of networks and thus reach as many users as possible. After multiple product iterations of attempting different approaches, we believe we have finally formulated a viable solution that ties together the fragmented ecosystem without compromising decentralization. Here is our journey — our past flaws, present aspirations, and future visions.

Early Lessons

Inthe 3.0 release, we tried to cover all our bases by deploying the smart contract onto more than 5 EVM chains as well as integrating Web3Auth, a wallet solution that allows Web 2 users to be easily onboarded through email or social logins. It sounds great on the surface until you realize we haven’t exactly covered all our bases and everything is still very much segregated.

To start, users must be on the intended network. If a user is on the wrong network, then the wrong data would be displayed. Any action performed on the wrong network, such as creating a document, results in none of the signers having anything show up on their dashboard. If Alice is on Ethereum and Bob is on Polygon, there is no way for them to sign documents with one another unless one of them moves over to the other network. This all makes sense technically but is incredibly counterintuitive in terms of UX. There were no shortage of panicking users reaching out asking why their documents disappeared, only to realize their wallet was on a different network.

In addition to the lack of interoperability, there are simply too many obstacles for users to overcome before they can do anything. Remember how we deployed the smart contract on more than 5 EVM chains? The question now becomes, which chain should the user use? This is a trivial question for blockchain veterans but a daunting question for newcomers who genuinely have no idea which chain to use. “Ether is the easiest to obtain but it costs more to transact on the Ethereum main network. Matic is more difficult to obtain, not to mention the fact that two versions of Matic exists (ERC20 vs. native), but gas fees are way cheaper on Polygon. Oh also, Ethereum main network is probably more secure than Polygon. By the way, we only covered two networks. There’s also Binance Chain, Avalanche, and Fantom, each with their own pros and cons.” With so much of an information dump, it’s incredibly easy to drive users away through analysis paralysis — when being presented with so many choices, users end up not choosing because they don’t know what to choose. This was especially problematic for Web 2 users who wanted to try our product through Web3Auth.

Mitigating the Problem

During our 3.0 postmortem, we decided to build 4.0 from scratch and adjust our strategy. Instead of supporting a variety of networks, we decided to stick with Polygon exclusively. On top of that, we would make use of meta transactions (thanks Biconomy :)) to pay gas fees for our users, eliminating the need to possess cryptocurrency entirely. This proved to be a great leap forward and skyrocketed our usage, gathering more than 180k signatures at the time of writing.

As our user base grew, familiar questions began to bubble up: What about other networks? What if I’m not on an EVM blockchain? What if I only have a Bitcoin wallet? Interoperability remains a major pain point, which we attempted to mitigate by forcing everyone to be on the same network and sponsoring all transaction costs — a rather hasty fix that fails to address anything fundamental. A more radical solution is needed to break the chain barrier and reach more users.

What’s Next?

After much consideration back on the drawing board, we decided to go big or go home. We set our sights on not only all EVM chains but also other blockchain networks such as Bitcoin, Solana, TON, and more. To achieve such a wide range of coverage across blockchains of massively varying degrees of programmability, we had to make some of the biggest changes to how our signing product worked on a foundational level. Up to this point, the core layer of EthSign operated in a rather simple manner:

When performing a write action (e.g. signing a PDF contract):

• Front-end parses user input and asks the user to sign it
• Front-end uploads parsed input and user’s digital signature to a decentralized storage platform (IPFS in 3.0, Arweave in 4.0) and retrieves the associated content identifier
• Front-end calls the appropriate smart contract function
• State is updated after the smart contract cryptographically verifies input parameters

When performing a read query (e.g. loading a signed PDF contract):

• Smart contract events are queried from The Graph
• Relevant state is reconstructed from queried data on the front-end
• State is rendered to the user

As you can observe, the current approach heavily relies on the smart contract to verify data integrity before permanently writing to state. Unfortunately, as crucial as the smart contract is, it’s also the single most significant roadblock to our vision. The fact is, smart contracts simply cannot cross from one chain to the next, plain and simple. We must deprecate its use to properly move forward. Here is what we propose:

When performing a write action (e.g. signing a PDF contract):

• Front-end parses user input and asks the user to sign it
• Front-end uploads parsed input and user’s digital signature to a decentralized storage platform
• State is updated

When performing a read query (e.g. loading a signed PDF contract):

• Storage payloads are queried from Arweave using tags
• Relevant state is reconstructed from queried data on the front-end
• State is cryptographically verified by the front-end
• State is rendered to the user if verification succeeds

You may notice there are much fewer steps when writing to state in the proposed approach compared to the current approach. Since we no longer use smart contracts, verification-related work is offloaded to the front-end when reading from state. This frees us from being tied to any single blockchain network and allows us to integrate any identity provider that supports arbitrary message signing and independent verification. The scope is now broader than ever since the concept of signing and verifying messages isn’t exclusive to Web 3. By shifting data verification computation to clients, we are able to support signing sessions that are cross-chain or even one that includes participants from both Web 2 and Web 3. This is an incredible advancement for us, a total paradigm shift in the way data is stored and processed. Instead of calling it 5.0, a brand new codename was born.

We are incredibly excited to announce the next step in the evolution of our signing product: EthSign Next.

A Unified Web

thSign Next brings a host of new features with the most impactful and immediate being true cross-network support where users from completely different blockchain networks are able to collaborate with each other.

Here is the initial roster of networks we intend to support:

• Bitcoin
• Ethereum (EVM)
• Solana
• Aptos
• Telegram Open Network (TON)

Theoretically we can add support for any network, Web 3 and Web 2, as long as an identity system that supports private/public key based message signing and verification is available. An example of Web 3 and Web 2 interoperability on our platform would be a Bitcoin user initiating a signing session and inviting signers from Ethereum, TON, and Proton Mail (as it makes use of PGP keys).

Aside from the interoperability upgrade, we have also planned a complete UI facelift and a series of QoL improvements available in a future release later this year.

Roadmap

EthSign Next is currently under development and will be launching a closed beta soon. Eligibility is rolled out in tiers with SignPass holders having the highest priority, then Galxe NFT holders from our previous events, and eventually transitioning into an open beta. In addition, SignPass holders will have a direct line to the development and product team to help shape the future of this product.

Finally, I’d like to personally express my appreciation to our community and investors. We wouldn’t have made it this far without your unwavering support through all the ups and downs over the years. On behalf of the entire EthSign team, thank you.

Access EthSign Here
Twitter | Gitbook | Discord | YouTube