Web3edge Originals

Hello World!

The last few weeks the news cycle has been dominated with the collapse of the FTX exchange, FTX US exchange and Alameda Research. Sam Bankman-Fried (SBF) filed for Chapter 11 Bankruptcy in the United States and stepped down from his role as CEO. The full list of companies included in this filing can be found directly from the  bankruptcy filing  itself.

To get caught up on the latest news, you can read below news stories:

•  FTX Crisis Shifts Into New Phase as Contagion Spreads – The Defiant
•  At least $1 billion of client funds missing at failed crypto firm FTX – Reuters
•  SBF on the Run? – The Milk Road

With the collapse of these major crypto financial institutions, users also reportedly lost access to their funds. According to multiple news sources withdrawals were deactivated for FTX, FTX US, BlockFi and other platforms which Alameda Research and FTX were invested in.

Now, FTX has applied for Chapter 11 Bankruptcy in the United States. Chapter 11 Bankruptcy requires the company to reorganize in order to continue operations and pay back creditors over time. While this gives a glimmer of hope to users that they may be able to get access back to (some of) their funds, this process can take months to years. And if the reorganization plan is unsuccessful, firms can move on to Chapter 7 bankruptcy, which would see their assets become subject to liquidation.

Centralized Exchanges vs. Decentralized Ambitions

The challenge with centralized exchanges (CEXs) is that their operations are not transparent. While blockchain networks add a level of transparency, CEXs connect the off-chain financial world with the on-chain blockchain world: this means that a large portion of operations, specifically the off-chain portion, are still not transparent to users. Users trust the CEX is operating in good faith and has sufficient measures in place to protect customer funds and protect themselves from insolvency.

Bitcoin was founded with the purpose of being:

“an electronic payment system based on cryptographic proof instead of trust” – Satoshi Nakamoto (2008), Bitcoin: A Peer-to-Peer Electronic Cash System (Bitoin Whitepaper)

This is also the ethos on which the entire decentralization movement is based on: do not trust people, trust the (cryptographic) math.

There are many ways a CEX can handle private/public keys and their internal ledger. Generally speaking, when you create an account with a CEX, the CEX will create a private-public keypair (and address) for every network you wish to use. In asymmetric cryptography, the private key (also known as secret key) is what allows a user to spend tokens or sign messages. It is essentially a password that provides master-access to all funds within an address. If this private key is leaked, all tokens on that address are compromised. The public key acts as an address visible to the public, and can be used be other people to verify that the private key holder did indeed sign a message (such as a transaction).

Let’s take a slight detour to take a high-level look at how private keys and public keys are created and how they work. This will help you to better understand the importance of keeping private keys secret.

Note: readers who are not interested in the cryptographic underpinnings of private and public keys can skip the entire Asymmetric Cryptography section and go straight to the Private Keys & Custody section!

Asymmetric Cryptography

Generally speaking, a private key is first generated using a pseudo-random approach. A popular approach is to use a seed phrase – a collection of random words from a specified word list – that are converted into numbers and then hashed using a specific algorithm to create a private key (see BIP0039 for more details). The private key is then used to generate the public key and address. In blockchain networks, the public key and address act as pseudonymous usernames that do not reveal the identity of the user. The below illustration shows how addresses are generated in Ethereum using a seed phrase:

Private/public keypairs in asymmetric cryptography are also referred to as one-way cryptography. This means that with the private key it’s easy to generate the public key, but with the public key it’s computationally extremely difficult to generate the private key (up to the point where it’s essentially impossible for any practical purposes). This is due to mathematical properties of the encryption algorithm used.

To illustrate these mathematical properties in an oversimplified manner: arbitrarily select two numbers (e.g., 5 and 16) and multiply them with each other (5*16 = 80). The two selected numbers (5 and 16) are akin to the private key, and the result (80) is akin to the public key. If an attacker wants to find out what the private key is that relates to the public key, they would have to brute force every single combination that results in the public key (8*10 = 80; 5*16 = 80; 4*20 = 80; 2*40 =80; 1*80 = 80), until they find the combination initially selected. If the arbitrarily selected numbers are large enough and the right algorithms are used, brute-forcing all combinations could take 300 trillion years. This is the concept behind one-way cryptography: if you know the inputs, getting the outputs is easy. If you only have the outputs, guessing the correct inputs is very difficult.

For readers interested in the mathematics behind these cryptography concepts, I direct you to read more about the RSA and ElGamal encryption algorithms and the Digital Signature Algorithm (DSA) – note: math involved!

Once the private/public keypair and address has been generated, users can use these to interact with blockchains and smart contracts. Generally speaking, private/public keypairs are used for two primary purposes:

• Sharing secret (encrypted) messages with another party
• Signing a message to verify that a specific private key did indeed send a message

Let’s take a look at how messaging and signing work with private/public keypairs.

Sharing secret (encrypted) messages with another party

Let’s assume two users Alice and Bob want to communicate with each other without a third party knowing what contents of their messages are about. If each of them have a private/public keypair, they can communicate by encrypting a message using the recipients public key, and the recipient can decrypt the message using their own private key. A third party would only be able to see the encrypted message (also referred to as ciphertext) being shared among each other.

This is extremely helpful in the situation that both users are not able to meet in advance to share an encryption key that can be used for encryption/decryption.

Signing a message to verify that a specific private key did indeed send a message

Let’s assume two users Alice and Bob again. Alice wants to send Bob a message, but Bob needs to be sure that the message received is indeed from Alice. This is achieved through digital signatures. Alice signs the message with her private key, and sends the message and the signature to Bob. Using a signature verification algorithm and Alice’s public key, the message and her signature as inputs, Bob can verify that the message did indeed come from Alice.

That message sent by Alice could also be a command sent to an ERC20 smart contract telling the smart contract to transfer tokens from her address to another address, or could otherwise interact with smart contracts. With the command and the signature, the smart contract would thus know to execute the transaction, as the signature proves to the smart contract that the user initiating the transaction is the owner of the private key.

Private Keys & Custody

The private key allows for a user to send encrypted messages to another, and allows users to sign messages, which on blockchains are used to authorize certain commands to the network. The latter is critical, as it means the private key can be used to authorize any action on the account, including moving funds or interacting with smart contracts.

That is why storing the private key and/or the seed phrase that helped generate a private key is of crucial importance. As mentioned above, CEXs hold private keys for users and when users log in to the CEX, they use the private keys of addresses associated to their CEX account to execute transactions. In this entire process, the user of the CEX does not get access to the private key – and they most likely never will.

A CEX acts as a custodian for users funds, or more specifically, a users private keys that provide access to their funds. A custodian is “a financial institution that holds customers’ securities for safekeeping to prevent them from being stolen or lost”. This gave rise to the phrase:

Not your keys, not your coins.

This is also why a lot of people use self-custody wallets. While CEXs are responsible to keep your private keys safe, with self-custody the user is responsible of keeping their keys safe. An analogy to traditional finance is that when you keep cash in your pocket or at home under your bed, your are the custodian of your cash. When you deposit your cash into your bank account, the bank is the custodian of your deposit.

What happens when your custodian goes bankrupt or is hacked?

I’d like to remind readers: this is not financial advice and investors are urged to do their own due diligence and consult their financial advisors.

While laws and regulations differ between countries and jurisdictions, in the US deposits to traditional savings accounts with banks or credit unions are both insured up to US$250,000 by the Federal Deposit Insurance Corporation (FDIC) and the National Credit Union Share Insurance (NCUSI) respectively. In a fact sheet issued by the FDIC, they clarify that the FDIC does not insure assets issued by non-bank entities, such as crypto companies. That means users have to trust CEXs even more than banks when it comes to their custodial duties, as there is no legally-mandated insurance that protects users from institutional failure. If a CEX fails, users could lose all tokens they kept in the CEX. Because users do not have access to their private keys, they cannot remove any funds from the CEX once withdrawals are halted. Withdrawals were halted on FTX US, but also other custodians such as Voyager and Celsius halted withdrawals in the past.

Self-Custody and Wallets

When setting up your own private key and taking care of the custody of your assets on your own, the onus for ensuring nobody can access your private keys or your seed phrase is on you. Different wallets will take different precautions for security to ensure the private key is not leaked, but generally speaking hardware wallets are usually considered the most secure. Hardware wallets are “cold wallets”, meaning they are not connected to the internet. Ledger and Trezor are examples of companies that produce hardware wallets.

On the other end of the spectrum we have software-based wallets, often referred to as “hot wallets” due to them being always ready to be used in an instant on an accessible computer. The most popular one is probably Metamask. Metamask is an EVM-compatible self-custody wallet, meaning it supports EVM-based networks including Ethereum, Ethereum-based Layer2s and Binance Smart Chain.

A crucial point about self-custody wallets is: the private keys are stored on your personal device. There are no backups stored somewhere. If a user loses access to their private key and/or seed phrase, they will PERMANENTLY LOSE ACCESS TO THEIR FUNDS.

What to understand before embarking on the self-custody journey

Below is a non-exhaustive list of what’s important for users to understand if they decide to take custody of their assets into their own hands:

• users are responsible for their own private keys: loss of private keys means permanent loss of assets
• users will have to create accounts (a private/public keypair and associated address) for each network their assets are on
• users will have to understand that trading assets will become far more complex, as bridges are needed to access other networks
• users will have to understand that liquidity will not be as concentrated as on most CEXs

CEXs do a good job of taking away the complexity of the entire Web3 and blockchain world. With self-custody, users need to understand their assets beyond the candle charts and price movements on CEXs. Users need to understand which network their assets are on, and which networks their wallets support and which assets can be received by which wallets.

What to look out for when sending tokens from CEX to a self-custody wallet

When withdrawing assets from a CEX to a self-custody wallet, users need to:

• understand what networks their tokens belong to (e.g. Bitcoin network, Ethereum network, Polkadot network)
• understand the asset type (e.g., Bitcoin, Ethereum-based ERC20 asset, Polkadot-based PSP22 asset)
• find a wallet that supports that network and asset (see Bitcoin web wallet finder, Ethereum Wallet Finder, Polkadot Wiki Wallet Page)

Modern hardware wallets often allow users to create accounts for a wide range of networks and asset types. For example, you could create an account for Ethereum-based assets, for Bitcoins and for other networks on a single Ledger hardware wallet device.

For hot wallets, the situation is often a little different: while an Ethereum-based hot wallet can hold Ethereum assets, such as ERC20 tokens, Ethereum-based wallets cannot natively accept tokens from other networks. This is because different networks use different math to create the private/public keypairs which make them incompatible with each other – one network will quite literally not understand inputs form another network. Bitcoins from the Bitcoin network, DOT tokens from the Polkadot network and AR token from the Arweave network are all not compatible with Ethereum-based wallets such as Metamask. Instead, to withdraw Bitcoins from a CEX, a user will need a Bitcoin wallet, to withdraw DOT tokens users will need a Polkadot-based wallet, and to withdraw AR tokens they will need an Arweave wallet.

In a CEX’s withdrawal screen it will usually advise which asset type and network they are using. This is crucial to take note of, because some projects issue tokens on multiple networks and different exchanges may have integrated different networks to allow for trading the tokens. For example, the Crust Network token CRU exists as a Crust Network native token named (Crust Network is it’s own Layer1 network), as an Ethereum-based ERC-20 token called and also as an Elrond-based ESDT token. If a CEX integrated the Crust Network native token, users can only withdraw the token to a Crust-compatible wallet. It is not possible to withdraw a Crust Network native CRU token to a Metamask wallet and receive an ERC20-based CRU token.

While it is often advised to send a small denomination of tokens to your address first to ensure assets are sent properly and can be received before sending larger quantities, users are urged to always double and triple check the recipient address. Some wallets on UTXO-based blockchains, such as Bitcoin and Cardano, will generate a new address whenever new funds are received to protect users privacy. While old addresses should still be valid, if a wallet built custom enhancements to the well-accepted standards, loss of assets could occur.

Self-custody, yay or nay?

Ultimately, users need to decide for themselves if self-custody is suitable for them. Self-custody means engaging deeply with Web3 ecosystems and understanding how they work in order to take full advantage of them. This is a whole new level of complexity that some may not be willing to learn. Personally, I find it fascinating, and I believe that the benefits of self-custody – having full control and responsibility over my own assets – outweigh the learning curve, because ultimately “not your keys, not your coins”.

Knowledge Hub

Additional content to grow your edge

Technology

•  Web3 Credentials → A Primer – @coolnothankyou
•  Value Flows in the MEV Ecosystem – Shayon Sengupta (Multicoin Capital)
•  Crypto Opsec Guide Collection – @tony_intern

Financial

•  Introduction to on-chain leverage utilizing DefiLlama leveraged lending and optimizooooor dashboard – @llamaintern
•  Token Value Accrual – @VaderResearch

Design Thinking

•  The Revenue-Evil Curve: a different way to think about prioritizing public goods funding – Vitalik Buterin
•  How to Design web3 Platform Governance – Porter Smith and Andrew Hall (a16z crypto)
•  Paying People to Participate in Governance – Ethan Bueno de Mesquita and Andrew Hall (a16z crypto)
•  All You Need to Know about Soulbound NFTs – Global Coin Research
•  The Types of Value Graphs – Mason Nystrom

____________

Today’s newsletter was written by @0xPhillan for Web3edge.io. Follow @Web3edge_io on Twitter!

This newsletter is not financial advice, I am not a financial advisor. The information provided by Web3edge is for general informational and educational purposes only. Do your own research before investing. See Disclaimers for more information.

Was this email forwarded to you? Sign up here.