Introducing Etherspot

The Pillar Project
Apr 7 · 8 min read

The team behind the Pillar wallet have created Etherspot, a blockchain development framework to make decentralized apps multichain. This allows dapps to simplify user onboarding across blockchains, and use direct state channel bridges to provide a seamless user experience across EVM-compatible chains.

Overview

Users can be onboarded to a side-chain with ease, with a single deposit, using an address that is consistent across chains. Etherspot provides a full API to generate transactions and read transactions/balances using counterfactually deployed smart wallets and multi-EVM payment channels.

In a typical onboarding workflow, the user is only asked to sign a message authorizing Etherspot, then to confirm a request to transfer mainnet assets to the sidechain.

The user can then begin using the application without having to understand anything about the network or sidechain.

Etherspot can be used in a variety of ways across chains and apps. It batches transactions and leverages state channels to reduce transaction costs and transaction settlement speed. Transactions are processed on-chain when only necessary.

History

Pillar is a smart contract-based wallet and we’ve been integrating and designing interfaces for blockchain projects since 2018. Our aim was always to create the “super app” for crypto, with numerous services integrated to offer users what we envisioned to be a “dashboard for one’s digital life”.

Our products are built with user-friendliness in mind, and with an intent to create an ecosystem around our platform — letting people use the Pillar interface natively in an integrated manner to build better and more efficient dapps, setting the new standard compared to what we know from Web2.

In 2019 we built the Pillar Payment Network, our own state channel implementation, and throughout this process we’ve been facing the UX challenges that everyone building in this space has to face.

We believe that those can be solved, and that’s why we’re introducing Etherspot.

Problem

Onboarding users to a gas efficient Layer2 solution is convoluted and unfriendly for less tech savvy users.

Let’s analyze Kickback’s case

Kickback.events is a project created to deliver higher event participation rate by asking registrants to pledge ETH/DAI. Registrants who do not show up to the event risk losing their pledge, which can be donated or distributed to the registrants that did come to the event.

Unfortunately, running it on Ethereum mainnet made this project rather impractical due to the recent spike of gas prices — as every time you make a transaction on Ethereum, you’re going to pay for the computing and for accessing the storage — and this costs real money. For applications that are not financially able, it can become extremely difficult to continue offering their services in times of high gas fees.

One of the workarounds for this is to move into a sidechain or another layer of EVM Layer1 that essentially allows for cheaper transactions. In Kickback’s case, they chose xDai,

Let’s go over the user experience here…

While developers can understand what this all means, we can’t really expect a non-techie or new user to go through this. It’s a very high barrier to entry for a lay end-user, and sometimes even for a sophisticated blockchain user.

For argument’s sake, let’s assume you did all that and instructed the user on how to do that.

So the user goes…

This is still a long and convoluted way before they can use the app, and it puts many gates in front of them. This is where a high attrition rate comes from — if you put a login or a wallet barrier, you will lose users.

Solution

Our idea is to change how this works and bring down the barriers of adoption by building better interfaces powered by Etherspot and Pillar.

Before proceeding, let’s break down a typical dApp to its base components:

  • Users can sign transactions, broadcast transactions, and subscribe to events.
  • Users are reading and writing from the blockchain and making subscriptions from the blockchain.
  • This feeds into your local front-end state and this is the starting point.

Signing

The first thing we propose with Etherspot is breaking the signing component. It’s having a clear separation of purpose between the component that signs transactions and the one that broadcasts transactions.

This comes from a strict interpretation of the meta transaction patternsigner and broadcaster are not the same and we make this very explicit.

This means if you’re using, for example, a web3-injected wallet like MetaMask, you’re going to only use it for signatures, and you never broadcast from it.

This provides us the first benefit, which means MetaMask doesn’t actually need to know the RPC endpoints where we are going to. This level of interaction allows us to write an application that’s targeting xDai, Binance Smart Chain, and any other EMV-compatible chain.

Regarding the signer — be it a WalletConnect connected wallet or an injected web3 dApp — you actually don’t know where these transactions are going because it’s not relevant. It’s only relevant that they sign the transactions using this single account process. As long as the chain supports the EVM and supports the same address space, this works.

We always broadcast to use meta transactions — you can broadcast directly, but now that there is a separation of concerns, the signer and the broadcaster are different components. This first layer of interaction means the user never sees requests to make a transaction, they always see requests to sign a message and this is a small UX barrier.

This is a bit of a trade-off — wallets have nice UIs to do transactions, but they don’t tend to have nice UIs to deal with messages. We hope to cooperate and change that for wallets, starting with our own, Pillar, with which we can provide a best-in-class experience. This is why it makes sense for us to go into infrastructure as a wallet provider — it ultimately helps us with adoption.

We are confident it’s a much smaller barrier than the one that currently exists for sidechain apps, who are asking users to add new networks and be aware of what a network is.

We use counterfactually generated addresses for smart contact wallets. By using CREATE2 addresses end up being the same across all EVM-compatible chains that share the same address space. This means that the user has one address per chain — they’ll sign messages and get all the benefits of smart contact wallets across different chains.

Now the user really doesn’t have to know anything about how to set up their wallet to connect a different chain, and the user doesn’t have to care where the chain lives.

Smart contract overhead

Contemporary Smart wallets with neat features such as spending limits come with a high cost of deployment due to their size.

Etherspot’s design approach can be framed as the “Volkswagen Beetle project”, because of our admiration for machines that are mechanically simple and run forever.

We deploy an account registry contract where all wallets, with only proxy contract deployments, designate everything to. This makes our wallet deployment significantly smaller, hence cheaper.

Batched transactions

Another feature we have is the ability to execute a series of batched calls — series of transactions. Because we’re using the meta transaction pattern, our first check-in to our relayer backend is to check if a user is using an account that’s been deployed. If the contract is not deployed yet, it will be deployed automatically in the registry. This is handled by the registry itself -we don’t even need to track if an account is deployed.

If the user deploys and sends the transaction, two transactions are executed. We could do the deployment and batch it, or execute the transaction the user is actually going to make, and let them pay for deployment on the first use.

This is going to bring a series of benefits — there are very low deployment costs and users don’t need to have ETH in their accounts to actually pay for it. Because we’re batching a series of transactions, it’s possible to batch, for example, a transaction that takes a flash loan, deploy a transaction, deploy a wallet, get some money received out of Layer 2 and pay back the flash loan. This essentially means I can receive an account on Layer 2 and pay for it.

We are not completely eliminating the deployment aspect of the smart wallet, but we provide freedom on how you want to fund the user.

Layer 2

This is where Etherspot shines the most. If you’ve been following Pillar, you know we’ve been playing around with state channels for a long time. In 2019 we built a solution called the Pillar Payment Network, a state channel implementation. With Etherspot, we’ve generalized this.

Because we have the same contract wallet address in every chain — whenever you pass a message on the smart wallet or on Layer 2, you’re passing a chain ID. This means we’re going to route this to the correct relayer.

Imagine a scenario where a user has liquidity on mainnet and on xDai — the user signs a message pointing to mainnet, and secures a message on xDai showing the availability of liquidity on both sides. This ensures that the user has enough liquidity to pay for her debt on whatever chain she executes on.

Etherspot allows that to enhance this experience — by asking users to submit liquidity, for example, for the xDai or to deposit into Etherspot some amount of your xDai to then allow users to top up into mainnet state channels.

That way, we’re allowing them to execute on any EVM that we have liquidity on and we can settle it back for the user — taking it out of their mainnet accounts so we can pay the liquidity provider. Simultaneously, we allow total flexibility of the user as to where they want to execute this.

Summing it up

Going back to our original flow with Kickback and xDai, you have a user with MetaMask, xDai, and ETH. Etherspot generates a contact wallet for them on xDai and mainnet — that’s all CREATE2, meaning there’s actually no transaction at this point. We would ask them to sign one transaction topping up this account — with still no transaction submitted to the chain yet — then we ask them to sign another transaction to execute the payment on xDai using the bridge and finally — here’s the beauty of it — because we’re batching these transactions we’re going to do this in essentially only two steps that will also be visible for the user once.

All we need to do is to ask the user to tap, sign twice and it gets sent to the mainnet. You’ll send a transaction to deploy the user’s wallet and a transaction to make the deposit from their external account. To put this on Layer 2, which is natively supported by the smart contract, my relayer and my guardian of the p2p payment system knows that he can execute liquidity and I can execute the third transaction — and make a payment on xDai. That way, the user doesn’t need to know that Kickback lives on xDai or any other network, and he does not need to know what the network is.

One final benefit to the end user is they will be paying way less every time they use it, with the exception of a bit of overhead on the first transaction. Compared to previous barriers to entry, they have been all significantly lowered, and that’s why we’ve built Etherspot — removing all the steps that lead to and hang in front of the app.

Reduced cost, increased speed, simpler user experience — that’s Etherspot.

Github: https://github.com/etherspot/
Website: https://etherspot.io/
Audited by Consensys Diligence
Playground: https://try.etherspot.dev/