Overview

• over 60,000 tps

• $0.00025 transaction fees

• 800 ms blocktime

Sets of validators called clusters work together to validate client transactions. Different clusters may coexist and are identified by their genesis block. Two clusters that share the same genesis block will attempt to merge, otherwise they will ignore each other.

Differs from traditional blockchains in that actions across nodes can be synchronized using proof of history (PoH).

• leader creates cryptographic proof with entries that some duration has passed since the last proof

• leader shares new entries with validator nodes which verify those proofs

• verifiable timestamps allow entries to arrive at validators in any order since the validators can reconstruct their order

• "blocks" are a set of entries that have been confirmed together.

• validator nodes optimistically process transactions in entries and roll back changes in the event that consensus wasn't achieved.

Miscellaneous

• end users can create atomic transactions to multiple programs. On Ethereum this is only possible through a smart contract router.

• account model was designed to be easily parallelized

  • programs are completely immutable accounts that store executable byte code. Programs store their state in non-executable accounts.

  • Accounts can specify an owner which is the only program allowed to make modifications to the account

  • to parallelize transactions, transactions specify all the accounts they will read from or write to so that validators know ahead of time which transactions can be parallelized and which conflict. Enabling programs to store data in different accounts allows devs to optimize for parallelization so that as many transactions can be parallelized as possible.

• transaction signatures

  • an array of signatures is passed to solana transactions so if on chain programs are looking for more than one signature (say for a multisig wallet), all the signatures can efficiently be verified by a GPU instead of within a program

• recentBlockhash vs nonce

  • solana transactions sign a recent blockhash and old transactions cannot be verified. This solves the same problem as an Ethereum nonce while also ensuring old transactions can't be run

• sol transfers

  • there's a solana program, the system program, which allows users to transfer sol

• transactions roughly have a fixed cost and there is a limit to the compute cost a transaction can use

• solana instructions (think Ethereum tx data) are commands for on chain programs. Transactions can include multiple instructions (executed atomically). The encoded size of a transaction is 1232 bytes so instructions cannot become too large.

• solana has special programs for deploying programs and transferring sol.

• account ownership

  • all accounts have an owner. By default their owner is the system program. When a program owns an account it is able to change its data. When an program does not own an account, it can merely read the account's data

Terminology

• Account: record on the ledger that holds data or is an executable program

• Bank State: state of all programs on the ledger at a given tick height

• entry: an entry on the ledger which is either a tick or a transaction entry. Blocks consist of entries which are smaller smaller batches of transactions.

• tick: an entry that estimates wallclock duration (timestamp)

Usage Notes

• super fast, feels basically instant

Smart Contract Development + Developer Tools

• programs compiled via LLVM compiler infrastructure to Executable and Linkable Format (standard binary file format for Unix) containing Berkeley Packet Filter (BPF) bytecode

• smart contracts can be written in any language that can be compiled down to solana's backend. Rust is popular.

Deposits/Withdrawals

• FTX

• Coinbase

Login/Wallets

• magic.link

• phantom

Existing Smart Contract Infrastructure

Conditional Token Contracts

AMMs

• Token Swap Program

Order Book

• Serum

Gas Station Network

• we'd have to create our own custom solution

Proxy Wallets

• Solana uses a proxy-wallet like architecture by default for their tokens because user token data is stored in an Account that is controlled by the program

Oracles

• https://solana.com/ecosystem/bandprotocol

• https://solana.com/ecosystem/chainlink

Blockchain Indexers

• https://aleph.im/#/

Cross Chain Communication with Ethereum

• https://wormholenetwork.com/en/ whose docs can be found here.

  • wormhole allows for generic message passing between solana and ethereum

  • network of (currently 19) guardians watches wormhole contracts. When enough guardians sign an observation, the message is then posted on the destination chain

Resources:

• https://docs.solana.com/

• https://2501babe.github.io/posts/solana101.html

• https://solana.wiki/zh-cn/docs/ethereum-comparison/

• https://dev.to/cogoo/solana-teardown-walkthrough-of-the-example-helloworld-program-18m4

• https://github.com/solana-labs/solana-program-library

• https://docs.solana.com/developing/on-chain-programs/developing-rust

Dev Notes

SPL Token

State

Separate accounts for

• Mint info

  • defines total supply, decimals, who can optionally mint, and who can optionally freeze

• Account for each address with a token balance

  • defines the owner, mint, and amount held by the account among other things

• Multisig

  • struct enables many diff

Life Cycle

• create an account for the new token's Mint storage. This includes creating a new key pair or passing in an existing key pair for the new account. This key pair will be one of signers of the transaction. The address of the spl token will be the owner of the account. Importantly, there is one piece of code that manages how many different tokens operate.

  • creating the account includes transferring the minimum balance the account needs for 2 years of rent exemption

  • client specifies a fixed storage size preallocated to the account

• initialize_mint to define the account that can mint new tokens

• initialize the user's account

  • use create_associated_token_account to deterministically create an account for the user's token data

  • initialize the account. Write the initial data to the account.

• mint tokens to the users account

  • update Mint account with the updated supply

  • update Account account with it's updated token amount

• transfer tokens

  • if the recipient account isn't created, create an associated token account for the recipient

    • use create_associated_token_account to create the account

  • process the transfer

    • ensure the Mint account of both Accounts is the same (i.e. it is the same token) and a bunch of other checks

    • update the balances in both accounts

• approve an account to spend your tokens

There’s a large learning curve to learning blockchain development because it’s so different than web2 programming paradigms. Instead of writing code that runs on one computer, you’re writing and interacting with code that runs on a distributed network

To deeply understand blockchain development, we’ll want to look at the virtual machine (VM) that’s used. There’s a couple different virtual machines that different blockchain’s use including Sealevel (Solana), CosmWasm (Cosmos), Wasm (Polkadot), Move VM (created by Facebook for Diem and will be used by Sui and Aptos).

The most popular virtual machine, though, is the Ethereum Virtual Machine or EVM. It has the largest number of applications and support from some of the largest blockchains including Ethereum, Polygon, Avalanche, Near, Optimism, and Arbitrum to name a few.

This guide is designed to get you up to speed on advanced concepts extremely quickly. It should take about 10 hours of deeply focused work to get through but you’ll come out of it with a great knowledge of the EVM.

1. The Basics

Some of the basics to understand on Ethereum

For a deeper dive into most of these topics you can go to https://ethereum.org/en/developers/docs/intro-to-ethereum/

• Public Key Cryptography: Blockchains rely on public key cryptography to prove ownership of assets and to create transactions. Public key cryptography uses a key pair which consists of a public key and a private key. The private key is kept secret and is used to digital signatures and can derive the public key.

• Hash Function: a cryptographic function which creates a unique digital identifier (hash) for a piece of data.

• ether (ETH): The native token on Ethereum which is required to pay for transaction fees.

  • wei: the smallest denomination of ETH. 1 ETH = 10e18 wei

  • gwei. 1 ETH = 10e9 gwei.

• Ethereum Account: An entity that can send transactions. Accounts are either external owned (EOA) and controlled by a private key or they have code associated with them (i.e. it is a smart contract)

• Ethereum Address: The public identifier of an ethereum account is it's address. The address is the keccak256 hash of an account

• Wallet: a wallet is a piece of software that controls a user's private key. More advance wallets like MetaMask provide an easy way to connect to dapps and send transactions.

• Transaction: A signed instruction from an account

• Block: A batch of transactions that includes a hash of the previous block in the chain.

• Gas: a unit of measure for how computationally intensive an operation is on Ethereum. The amount of gas a transaction requires is used to calculate the transaction fee a user must pay to execute a transaction.

• Gas Price: The amount of ETH a user pays per unit of gas to execute a transaction. Gas Price is typically measured in gwei.

• Ethereum Node: a computer running the software for the Ethereum protocol

• Json-RPC: A lightweight remote procedure protocol (RPC). Ethereum nodes an expose their json rpc api so that clients can query the state of the blockchain.

Token Decimals: https://docs.openzeppelin.com/contracts/2.x/erc20#a-note-on-decimals

2. Your First Smart Contract

We’re going to use Foundry to create your first smart contract. Foundry is a rust-based smart contract development toolchain created by Georgios Konstantopoulos that’s new but very well liked. There’s other smart contract development environments which I’ll split into 2 categories:

1. Pure Solidity: Tests are written in Solidity

   1. Foundry

   2. DappTools

2. Javascript Based: Tests are written in JS/TS

   1. Hardhat

   2. Truffle

For your first smart contract, we’re going to create an ERC20 token which is the standard interface for fungible tokens on EVM blockchains. You won’t be expected to understand a lot of what’s happening under the hood, which is fine because we’re just trying to quickly expose you to a bunch of different concepts in EVM development.

Pre Requisites

Go to the Foundry installation page and follow its directions to install Foundry. If you’re successful you should be able to run the following command.

$ forge --version
# Output should be something like
# -> forge 0.2.0 (60b1919 2022-07-24T00:08:10.658215Z)

forge and cast are the two binaries that foundryup installs and running forge version only returns the version of forge if forge is successfully installed.

Setting up the Project

Create the Project

Follow the instructions in the Foundry docs to set up your first project.

Install Dependencies

We’re going to use transmissions11’s Solmate repo as a dependency. Solmate is a collection of common smart contracts that are helpful for using as building blocks. Solmate is gas-optimized (a.k.a. it’s written so people spend as little as possible on transaction fees) and already audited which reduces the surface area for a vulnerability and the cost of an audit for your project.

$ forge install transmissions11/solmate

Create the Token

Rename src/Counter.sol to src/FirstToken.sol. Open up src/FirstToken.sol in your editor and copy in:

// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.8.13;

import { ERC20 } from "solmate/tokens/ERC20.sol";

contract FirstToken is ERC20 {
    constructor(uint256 totalSupply) ERC20("First Token", "FT", 18) {
        _mint(msg.sender, totalSupply);
    }
}

Let’s quickly go over what is happening in the contract.

• Line 2: The pragma statement specifies which version of the Solidity compiler we need to use. In this case we’ll only accept the compiler version 0.8.13

• Line 4: We import the Solmate ERC20 token contract. This contract is what’s doing all the work under the hood. Refer to that contract if you’re interested in how the token is implemented.

• Line 6: We define our contract FirstToken and that it inherits from the Solmate ERC20 contract. Contracts in Solidity are similar to classes in object-oriented languages and can inherit from one another.

• Line 7: We define the constructor of the contract and call the constructor of the ERC20 contract.

  • Solidity is unique in that a contract can extend multiple other contracts, and thus the atypical syntax of calling the ERC20 constructor in the constructor definition, not in a super call.

  • Our constructor accepts 1 argument totalSupply. The ERC20 constructor accepts 3 arguments: name, symbol and decimals. name and symbol are straightforward. decimals is the number of decimals to use in the numbers representation. Ethereum and all other blockchains I know of have no concept of floating point numbers so for more granular accuracy they just stick a bunch of zeros behind each number and refer to those as decimal points. ETH and most ERC20 tokens have 18 decimals. USDC and USDT both have 6 decimals (because fiat?) and Wrapped Bitcoin (WBTC) has 8 decimals because Bitcoin has 8 decimals.

• Line 8: We mint the totalSupply of tokens to the msg.sender, which is the account that is sending the message to create the contract.

Deploy the Smart Contract

Now that we’ve created the smart contract, we need to deploy it.

Wallet Creation

Before we can deploy the smart contract, we’ll have to create a wallet that we can deploy the contract from.

The simple way to create a wallet with foundry is running:

cast wallet new

But if you want to get creative you can run:

cast wallet vanity --starts-with <prefix>

This command will search for a private key that matches an address that starts with <prefix>. Not that <prefix> must be valid hex (i.e. valid characters include 0-9 and a-f only). Note that the longer the prefix is, the more attempts it will take the script to find a valid address that fulfills your vanity requirements. From my experience, anything under 4 characters will return instantly, 5 characters will take about 20-40s and each successive character will take an order of magnitude longer (it’s 16x harder to be exact). The exact times you’ll see will depend on the specs of the machine you run this on.

💡 Keep your private key safe. Anyone with access to this private key can access any funds in your wallet. It’s recommended to not keep a lot of funds in a hot wallet like this.

Fund the Wallet

We’ll need to fund the wallet before we can send a transaction to it. To accomplish this, we’ll use a “faucet” which see send us testnet tokens. Go to https://faucet.paradigm.xyz/ and claim tokens from the faucet to the wallet you created in the previous step.

Check the wallet is funded

We’re going to deploy the contract on Ethereum’s Goerli testnet so go to https://goerli.etherscan.io/ and search for the wallet address you previously created. After claiming tokens from the faucet you should see that it has an Ether balance.

You should also run:

cast balance --rpc-url https://goerli.infura.io/v3/9aa3d95b3bc440fa88ea12eaa4456161 \
    <your_address>

You should notice that there are a lot more 0s behind your ETH balance when running this CLI command.

Deploy

Now let’s deploy the contract. Run the following command:

forge create --rpc-url <your_rpc_url> --private-key <your_private_key> \ 
    src/FirstToken.sol:FirstToken \
  --constructor-args 1000000000000000000000000

Replace <your_rpc_url> with https://goerli.infura.io/v3/9aa3d95b3bc440fa88ea12eaa4456161 and with the private key you previously created. This will create a token with a total supply of 100,000 (assuming I counted correctly). If you go to the etherscan link for your account that deployed the contract, you’ll notice your balance is shown under the “Erc20 Token Txns” Tabs (e.g. https://goerli.etherscan.io/address/0x8404a542298827022bf4441afef0a96766be7201#tokentxns for account 0x8404A542298827022bf4441Afef0a96766Be7201 on Goerli) Peeking Under the Hood Let’s take a look at what’s happening under the hood. Go back to Goerli etherscan and look up the transaction you just sent. Find the parameter on the transaction called “Input Data” (often just called “data” or “input”). You may have to expand more properties on the transaction to see it. Now open up the out/FirstToken.sol/FirstToken.json file in your repo. The “Input Data” on the transaction should look similar to the bytecode.object field in the file. Next, look up the address of the contract you just created. Click on the “Contract” tab and you should see the deployed bytecode of the contract. This value should look similar to the deployedBytecode.object property within the FirstToken.json file. Interacting with your Contract Now that you’ve deployed your first contract, let’s interact with it. Checking Your Balance First we need to get the calldata to check your balance cast calldata "balanceOf(address)" <your_eoa_address> If you look closely at the calldata, you’ll notice that there’s 8 digits after the “0x” prefix at the start of it and the last 40 characters are from your address. Now that we have the calldata run: cast call --rpc-url https://goerli.infura.io/v3/9aa3d95b3bc440fa88ea12eaa4456161 \ <your_contract_address> <call_data> The output of the previous command is a bunch of hex jargon so let’s make it a little easier to read: cast --to-dec <hex_output> You should see the same number you passed into the constructor when creating the contract. Transferring the Token Let’s now transfer some of your token to another address. Run the following command: cast send --rpc-url https://goerli.infura.io/v3/9aa3d95b3bc440fa88ea12eaa4456161 \ --private-key <your_private_key> \ <your_contract_address> \ "transfer(address,uint)" 0x6666664c7d32A5577070EB846f7dFa5f962e5e6a 1000000000000000 This will transfer tokens to my address 0x6666664c7d32A5577070EB846f7dFa5f962e5e6a. Replace this address with an address you control if you want to keep all the tokens for yourself. 3. Read Up on EVM Read the Ethereum Yellow Paper. The Ethereum Yellow Paper is the technical specification for Ethereum and is probably the quickest way to understand how the EVM works at a granular level. The yellow paper is super dense but understanding sections 4-7 are super useful to understand. Feel free to skim/skip all the proofs. 4. Analyzing ERC20 Contracts Lastly, we’ll analyze 2 different implementations of the ERC20 standard. The first is the Solmate contract that we used in part 2. The second is a contract written entirely in Yul, which is a low-level EVM language. Yul is often used for highly optimized contracts in terms of gas efficiency. Analyzing the contract will help us understand what’s happening under the hood when looking at a Solidity contract. Solmate: https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC20.sol ERC20 in Yul: https://docs.soliditylang.org/en/v0.8.15/yul.html#complete-erc20-example

Account abstraction (AA) has been hot recently because it’s an order of magnitude improvement over plain-old EOAs. Yet, even with all its hype, it is often misunderstood. AA is often referred to synonymously with smart contract wallets and gasless transactions which has been a great marketing play although a little misleading. Let’s dive into what AA and smart contract wallets are and then explore the benefits and challenges of each.

What’s What

Before we can understand AA, we’ll need to go over the two types of accounts on EVM blockchains. First, there are EOAs which include the wallets of most existing crypto users. When users sign up for a wallet like MetaMask or Phantom, they’ll write down a seed phrase which is used to derive their private keys. Those private keys can sign transactions, which the wallet submits to a blockchain.

The other type of account is a contract account, an account with associated code. Examples of contract accounts include NFTs and DeFi protocols, which are often composed of multiple contract accounts.

Both EOAs and contract accounts have limitations. EOAs cannot have code associated with them and contract accounts cannot initiate transactions. Account Abstraction, in its pure form, will remove the limitations of each. EOAs will have code and contract accounts will be able to submit transactions, hence the name “account abstraction.”

Account abstraction is often referred to synonymously with smart contract wallets and gasless transactions due to EIP4337, but as previously mentioned, it is sometimes misleading. Let’s define each:

• Smart Contract Wallet: A contract account that is used as a wallet. The code in the associated account will define the wallet’s policy for sending transactions which often requires a signed message from a user.

• Gasless transaction: The technical term here is meta-transaction which is a signed instruction from a user that is executed on-chain by another account. The transaction still includes gas, but from the user’s perspective it is gasless because the user is not the one dealing with gas.

Smart contract wallets and gasless transactions have been around for years and are yet to have widespread adoption. We’ll cover gasless transactions further in the next article, but let’s go over the benefits of drawbacks of smart contract wallets before looking at how AA can improve upon plain old smart contract wallets.

Smart Contract Wallet Scorecard

Benefits

Gasless transactions

Most smart contract wallets support gasless transactions where a user can sign a message authorizing a transaction and then another entity can submit that transaction for the user.

Batch transactions

Send multiple transactions at once. For instance, instead of sending an approval transaction, waiting, and then finally submitting a swap, you can send both transactions at once.

Social Recovery

A decentralized "forgot your password" flow. If you lose access to a private key, a few trusted friends, family or institutions can help you recover your account. Most people will likely opt for a trusted institution similar to how people use iCloud and Dropbox to back up their data, or how people use LastPass and 1Password to back up their passwords.

Session Keys

Traditionally you need to sign every transaction sent from a wallet like MetaMask. Session keys allow a user to authorize an entire session of transactions with one single click. Instead of signing a message for every transaction, you’ll authorize X amount of a token to be spent by a temporary private key living on the user’s device within a specified timeframe.

Upgrading Key Management

Users can upgrade their key management when they are ready. A user may start with a wallet controlled by 1 key that lives on their device. Then, when they are ready, they may upgrade to MPC or a hardware wallet.

Drawbacks

High onboarding cost

It costs about 250k gas to deploy most smart contract wallets* on EVM blockchains. At the time of writing (gas cost is 42 gwei/gas), that’s $20 on Ethereum mainnet to onboard a user which is prohibitive for everyday users.

Onboarding costs are feasible on layer 2s and sidechains, though. It only costs about $0.02 to create a smart contract wallet on Polygon for instance.

*Technical note: This figure is based on the deployment cost of a minimal upgradeable proxy like the SafeProxy contract which is one of the smallest contracts you can deploy to create a new smart contract wallet.

Signing

Smart contract wallets do not have associated private keys to sign messages which makes smart contract wallets incompatible with applications that require user signatures like many on-chain order books. EIP1271 was created as standard for compatibility with signature-verifying protocols, but EIP1271 is not yet well supported.

Inability to sign messages also adds complexity for applications that use off-chain signatures for web2 authentication flows like Sign-In with Ethereum.

These problems will go away over time as smart contract wallets gain adoption and smart contract wallet compatibility becomes a requirement. In the meantime, though, these problems do add friction to smart contract wallet adoption.

Different Wallets on Different Chains

Users will expect their wallet to be the same on every chain but wallet addresses and implementations may differ between different chains. Due to nuances between different EVM implementations (e.g. support for both EIP-155 transactions and pre-EIP-155 transactions), smart contract wallets may have different addresses on different chains if developers do not set them up correctly*.

Furthermore, smart contract wallet logic may differ across different chains. Most smart contract wallets can be upgraded (e.g. upgrading key management, upgrading the code of the contract) which will need to be kept consistent across different chains.

I suspect this problem will be solved off-chain. A potentially clean, decentralized solution for this would be to track upgrades to wallets on Arweave, a permanent storage ledger, and then upgrade wallet logic on specific chains as needed. All wallets would stay up to date without users paying for upgrades on dormant wallets.

*Technical note: contracts can be deployed on the same address on different chains using the create2 opcode which deploys contracts to a deterministic address based on the sender’s address, a salt (i.e. arbitrary data), and the to-be-deployed contract’s bytecode. If the sender’s address or bytecode are different on different chains, then the smart contract wallet will have a different address.

Typically contract deployments use a singleton factory to deterministically deploy contracts, which must be deployed at the same address on every chain to keep the sender address consistent. Some singleton factories use pre-EIP-155 transactions so that a single signed transaction can be submitted on any chain, but some EVM implementations do not support pre-EIP-155 transactions. The downside of the first mentioned singleton factory is that projects must trust the Safe team to properly safeguard their private key used to deploy it.

Why AA

Pure AA, allowing EOAs to upgrade into contract accounts, has the potential to solve the two main drawbacks of smart contract wallets: onboarding costs and signing. Users will be able to create a wallet without the friction of an expensive contract deployment and then upgrade to a smart contract wallet when they are ready.

Regarding signing, if a smart contract wallet has a private key associated with its public address, that private key can be used. There are potential issues in this case if a user transitions control of their wallet to another key, but it would still lead to compatibility with more protocols while EIP1271 gains adoption.

Lastly, pure AA solves the potential issue with different addresses on different chains because the public address on different chains would be derived from the original private key.

The Current State of Smart Contract Wallets

Smart contract wallets have been around for a while. They have traditionally been used as MultiSig wallets where the wallet is controlled by multiple private keys and transactions are authorized in distinct steps. Signing transactions in distinct steps makes sense when the private keys are controlled by different individuals which is the case when the MultiSig is used to hold the funds of an organization, but it’s a clunky experience for advanced users that want improved security.

Safe has historically been the most popular MultiSig. Smart contract wallets need to be trusted and Safe’s long history of safety and security makes it the best option. There is some risk to using an early smart contract wallet given that some have been hacked in the past (*cough cough* Parity MultiSig hack). New smart contract wallets will need to prove themselves over a long time period before they can reach wide adoption.

Argent and Authereum were two of the earliest attempts to bring smart contract wallets mainstream but both teams have since pivoted because the deployment costs on Ethereum mainnet were (and still are) prohibitive for everyday users. Argent pivoted to focusing their wallet on Layer 2s, specifically Starknet and zkSync, while the Authereum team is now behind the Hop bridge.

Recently wallets like Waymont and Sequence have created much cleaner user-experiences around MultiSigs. The former is targeted at high net worth individuals and the latter is targeted for everydays users. Polymarket also uses smart contract wallets under the hood to offer their users gasless and batched transactions.

EIP4337

An article on smart contract wallets and account abstraction wouldn’t be complete without discussing EIP4337. EIP4337 is a standard for smart contract wallets and a design for a decentralized relayer (“bundler” in EIP4337 jargon) network.

Creating a standard for smart contract wallets is great, but I’ve long been critical of EIP4337 for creating a decentralized bundler network, making the standard more complicated without an immediate benefit to users or developers. With that said, EIP4337 will help Ethereum transition to native AA. If it gains enough adoption, blockchain validators will become bundlers and vice versa.

There are a number of companies building smart contract wallets on top of EIP4337 including Fun, ZeroDev, and Biconomy.

Looking Forward

I expect smart contract wallets to gain significant adoption in the next couple years due to their benefits and eventually become the status quo for wallets when account abstraction is adopted in the protocol. There is an opportunity now for wallets like Metamask, Phantom, Rainbow, etc. to offer users a more secure and seamless experience by being early consumer smart contract wallets for users able to pay for their own onboarding costs.

Legacy Solutions

A handful of private key management solutions have been around for years including Magic Link, Web3Auth, Venly and Bitski. They allow users to sign in with email or OAuth (i.e. Sign in with Google) and manage private keys for users under the hood. These legacy private key management solutions offer a slick user experience and have helped onboard millions of web3 users.

These offerings do come with tail risk, though. The aforementioned services take advantage of legal gray areas to argue they are non-custodial while being able to access or lose users’ private keys. Legacy private key management services generally work by using a user’s web2 login methods to back up their private key so that on subsequent logins a user can retrieve their backed-up private key. If these services disappear or turn out to be malicious, users will lose all their assets. Yet, they can claim to be non-custodial using the guideline that users can access their private key.

A common-sense, more restrictive guideline is whether someone else has access to the user's private key. Magic Link, Bitski and Venly are all custodial under this classification–there's folks at their companies with the ability to access users’ keys. Depending on how decentralized the Torus network is, which Web3Auth uses under the hood, there may be folks able to recreate Web3Auth keys as well.

An even better guideline to determine whether a service is custodial or non-custodial is whether someone else can lose the user’s private key. All four key management solutions are custodial with this guideline. For example, if Magic Link, Venly, or Bitski lost access to their AWS account (assuming they all use AWS as their cloud provider), all their users would lose access to their private keys, assuming they did not back them up prior (unlikely). As for Web3Auth, if enough Torus nodes go down, all Web3 auth users would lose their private keys (again assuming that users did not back them up prior).

State-by-state money transmission guidelines in the United States are generally created to protect consumers. When regulators look at private key management closely, they may consider the aforementioned solutions to be custodial. There’s a risk that companies providing these private key management solutions will be required to be money services businesses in the future and need to implement burdensome know your customer (KYC) processes when onboarding users.

Given risks associated with legacy private key management solutions, they are unlikely to be adopted by crypto-natives who are serious about security and censorship resistance.

New Solutions

There are newer solutions for private key management that look more promising. These solutions are using a combination of multi-party computation (MPC) signature schemes and secure enclaves like Intel SGX or AWS Nitro to create solutions that improve user experience and security for everyday users and cryptonatives alike. Let’s break down MPC and secure enclaves to better understand how they help.

With MPC, private keys are essentially split into multiple shares and then a predefined threshold of shares must sign a message for the signature to be valid. Imagine a 2-of-3 MPC scheme where:

• 1 share is on the user’s device,

• 1 backup share is emailed to the user in case they ever need to recover their key, and

• 1 share is kept with a trusted third party who can help provide a slick user experience.

With such a scheme, users get a slick user experience and no third party is capable of accessing or losing a user’s keys; the trusted third party only has 1 share which they can’t do anything with on their own.

Secure enclaves are isolated compute environments designed to process highly sensitive data like private keys (or private key shares). They support remote attestations which is a fancy way of saying that people can verify that the enclave is running the software they expect it to. (Remote attestations do require trusting that the server is running a secure enclave in the first place.)

Secure enclaves reduce trust assumptions. Imagine in the MPC scheme we discussed that the trusted third party is using secure enclaves. Even if an attacker was able to access 1 of a user’s shares, it’d be nearly impossible for them to hack the trusted third party.

In short, MPC removes the central point of failure that exists with legacy key management solutions (i.e. someone else can access or destroy a private key) and secure enclaves help reduce trust assumptions. Some key management solutions to look out for include Turnkey, Capsule, Portal, Utila, and Coinbase's WaaS. As these solutions are proven out, existing wallets will incorporate their tech to increase their security and user experience.

Conclusion

Key management options that are more secure with a great user experience are nearby. In many cases these solutions will be paired with smart contract wallets which we’ll discuss in the next post.

Technical Appendix

Private Keys

Private keys are random codes that can prove ownership over a public key. In most use cases, a computer generates a random private key and then uses the 3 algorithms provided by a digital signature scheme to use it.

1. Get the public key for a given private key. The public key is sometimes the user’s blockchain address.

2. Sign a piece of data with a private key

3. Get the public key that signed a piece of data

Multi-party Computation

Multiparty computation (MPC) is a branch of cryptography for doing computation among untrusted parties. The term MPC is often used synonymously in web3 which threshold signature schemes, which are schemes to split up private keys among untrusted parties as we discussed above.

Thank you to Shekar Ramaswamy for the feedback on this post.

Crypto On-ramps

Credit card on-ramps like Moonpay, Transak, Ramp and Wyre solve onboarding for some users but have low approval rates. These can be very lucrative businesses, but many issuing banks will deny all card transactions to purchase crypto because of high historical fraud.

Local payment rails like ACH in the United States can help solve the low approval rates with card transactions. Local payment rails won't automatically deny crypto purchases, but each comes with its own nuances and development teams would need to individually integrate local fiat rails in every region they want to support. Sardine and Ratio, who have launched ACH on-ramps in the last year, can be great options to onboard users within the United States.  

On-ramps can also leverage decentralized exchanges and cross chain bridges to scale to more chains and more tokens. Currently, most on-ramps use companies like ZeroHash or Prime Trust under the hood for their exchange infrastructure and as their liquidity provider so on-ramps themselves are limited by the tokens and chains their underlying exchange supports. Using decentralized exchanges and cross chain bridges can allow on-ramps to scale to new tokens and new chains quicker, giving on-ramps that do so a competitive advantage.

NFT Checkout

High card decline rates for crypto on-ramps created an opportunity for NFT Checkout products, allowing people to purchase NFTs with a credit card. Card companies classify NFTs under a different merchant category code so when an issuing bank needs to approve the transaction, they see a digital good purchase, not a cryptocurrency purchase. NFT Checkout products have acceptable approval rates as a result, but they are limited to only NFTs. NFT Checkout products include Paper, Crossmint, Wert and Winter.

Fraud

Fraud is a major challenge for on-ramps and NFT checkout products. If a fraudster has someone's card information or banking details, the best opportunity for them is to cash out in an irreversible, highly liquid financial system. Due to consumer protections, the on-ramp or NFT checkout provider will be left holding the bag, making it a risky business.

Fraud is a cat-and-mouse game where fraudsters will find a new loophole and then on-ramps will need to find and patch it. It's a tough business but the companies that can successfully manage fraud will end up big winners. Helping other companies manage fraud is a great business in itself, and the best companies at managing fraud will be able to build great on-ramps.

** **

Allowing applications to easily onboard users from their credit card or bank account remains one of the toughest challenges for user experience in crypto. There isn’t a path anytime soon for a completely seamless experience going from fiat to crypto and vice versa, but the businesses that make this experience marginally better will continue to thrive.

Thank you to Jack Jia for his feedback on this post.

Having spent significant time working on web3 user experience at Slide, a company I co-founded backed by top web3 investors, and at Polymarket, where I led their gas-less transaction infrastructure, I have a deep understanding of this frontier and will be sharing my thoughts in an upcoming series of posts.

There are many exciting products and solutions emerging to improve the user experience of crypto. I'll explore these efforts across five key areas:

1. Fiat to Crypto

2. Private Key Management

3. Smart Contract Wallets (Account Abstraction)

4. Gasless Transactions

5. Transaction Simulation and Security

At a high level, user experience in crypto comes down mainly to wallets. Standalone wallets will slowly incorporate new tech in these areas, and consumer-focused applications will incorporate embedded wallets and drive new crypto users to them. Embedded wallets can be broken into two categories: end-to-end embedded wallets and application-specific wallets. 

End-to-end embedded wallets are out of the box replacements for standalone, browser wallets like MetaMask and come with a UI. They are great for getting an easy to use wallet integration off the ground quickly or for an existing application to better support new web3 users without needing to build and maintain an application-specific wallet. They can also be used across different web3 applications, giving a successful end-to-end embedded wallet a powerful network effect. End-to-end embedded wallets included Sequence, Magic Connect, Peaze and Ramper.

Application-specific wallets are wallets siloed to a specific web3 application. They provide a familiar, integrated experience for users that will boost an application's onboarding rates. Many web apps will also enjoy the control over the user experience from building their own wallet. Application-specific wallets can’t be used across many different applications like you can with MetaMask, but that’s not a benefit when onboarding new crypto users. Application specific wallets include Reddit’s wallet and Polymarket’s login-with-email wallet.

With both of these embedded wallet options, users will log in using their email or OAuth, and a private key is generated and managed for them behind the scenes. As these wallets become more popular, mobile and browser wallets will develop ways for users to transition from embedded wallets to standalone mobile or browser wallets.

In the long term, we can expect wallets to be built into devices like mobile phones and laptops by default. Although large tech companies are beginning to explore crypto, they will probably wait for startups to prove the technology and demand before experimenting with wallets themselves. Startups have the opportunity now to build a moat before the big tech corporations jump in.

The future of web3 depends on creating a seamless and user-friendly onboarding experience. In the next post I’ll explore fiat-to-crypto in depth. Follow me on twitter to stay up to date.

** **Thank you to Shekar Ramaswamy and Pavel Asparouhov for the feedback on this post.