@0xkkonrad

TLDR: Identity is hard. It’s going to get much worse in a multichain world of altchains and L2s. Currently, token transfers rely on chats where Alice and Bob exchange onchain identity information, along with chain and token preferences. This is offchain and interactive. One solution relies on storing these preferences in a keystore contract. We propose an alternative solution that relies on offchain communication through links. Links make payments non-interactive: Alice pushes funds to Bob on the communication channel they already have (e.g. WhatsApp, email, meeting in meatspace). Our solution sidesteps the identity problem by using links.

There is an intrinsic tension between the elegance engineers seek and the organic order that humans flourish in. The problem statement for the engineer is “give access rights to the right person”. The ideal system would be one that has a root identifier that is unique, easily readable, and impossible to spoof.

Yet, the engineer’s problem statement is tension with a little human quirk: society. Humans have the annoying tendency to take on different roles. We present ourselves differently at a bank than at a best friend’s bachelor party, we speak differently depending on our roles and the roles of our interlocutors.. How we appear on LinkedIn is different from our Twitter which is different to our Instagram.

“Give access rights to the right person” seems to be difficult as there is so little in common between these profiles. Luckily, you only need one unique identifier. Anything that is uniquely assigned to the user is enough to establish that it is them, no matter how different their tweets are from their wholesome family vacation pictures. Passport numbers, phone numbers and email addresses seem to be perfect. Just one more step — a handshake — and you are good to go. To make sure no one else uses your address, a one-time password will validate the ownership. Receiving messages is the primary function for email addresses and phone numbers, so they are the perfect match. They are used frequently, everyone has them, they fit in the normal communication flows we have. This is why web2 has passed the buck to phone and email providers in terms of identity. You see how this could be an issue with web3.

The worse news is that crypto complicates everything. Transactions are public by default. Most of crypto is finance, which mixes poorly with social identities. It’s also highly technical and geared towards specific use cases. The explosion of scaling solutions create a fragmented multichain world which also fragments identity across chains.

The fact that transactions are public makes a social identity impossible. While naming services like ENS are a nice add-on to show your presence, it makes no sense to consolidate all activity under them. After all, I don’t want the whole world to know how much money I have, where I spend it and how much I made from my previous employer. It simply makes no sense to have one kkonrad.eth. There is nothing to gain other than showing off trades or net crypto worth, while what’s at risk includes regulatory scrutiny, targeted phishing and hacker attacks, and the attention of sales people — the worst from this list.

Crypto is mostly geared towards finance and the aspect that are not pure finance like NFTs, gamefi or social media, are heavily financialised. Finance, in general, does not mix well with social identity. In many cultures, talking about money is frowned upon. Of course, there will always be groups like collectors who will talk a lot about the monetary value of Pokemon Cards or photos by Elsa von Freytag-Loringhoven. However, rarely is money a central focus. Current solutions like ENS do not work. They would require users to juggle multiple identities for different roles. “It ties too many things to your name” as Vitalik put it.

What’s worse, the boom in rollups and altchains lead to a fragmented multichain reality. With the increased complexity coming from the rise of stealth addresses, different L2s, etc. a simple payment interaction (the thing crypto is for!) could require a long list of instructions. Smart contract wallets are becoming popular and the addresses can be different across chains. It’s a nightmare that social identity is fragmented. Add multichain fragmentation, which runs tangentially to the fragmentation of social identity, and you’ve got a terrifyingly tormenting ordeal of splintered dependencies and infrastructural misfits.

Even the most simple use case, like paying for green tea, becomes a nightmare. Vitalik’s problem statement is:

I have coins on Scroll, and I want to pay [you] for coffee … you are only set up to receive coins on Taiko. Wat do?

This creates a complete clusterfuck. Vitalik summarises the following options:

1. Keystore contracts

2. Links

Keystore contracts contain pointers that prove ownership of the L2s addresses and list them. In essence, they are a long list of your different identities on the different chains. You could also expand that concept to altchains. In terms of UX, these complexities could be abstracted on the recipient’s or sender’s side. For sending, the funds could be routed to the preferred L2. For receiving, one could list all the accepted chains in the keystone contract and wallets could auto-consolidate funds later.

The problem with the multichain explosion is that Bob has to provide much more information than their ENS. From a simple process where Bob provides a simple string (the address) and Alice uses that to make a transfer on mainnet, in a multichain world, Bob has to provide a whole array, ideally, with a preferred order (e.g. Scroll is preferred to Polygon which is preferred to Optimism). This information can be stored in a keystore contract.

The process looks something like this:

Alice: I want to send you $1

Bob: Here is my keystore contract Bob.eth (contains the equivalent of: Please send funds to 0xA… if on Arbitrum, to 0xB… if on Polygon, to 0xC… if on Mainnet, and my order of preference is Arbitrum, Polygon, Mainnet.) Also, I prefer USDC on Polygon but USDT on Arbitrum but don’t worry if you can’t.

Alice: OK, sorry, I only have USDC on Arbitrum, so here your arbi-scan receipt.

Bob: OK, thanks! I’ll consolidate my funds later.

Yet, keystore contracts inherit all the problems about onchain identity: they are not private and they tie all your activity to one identity. An alternative to the keystore contract relies on links, which skip identity problem entirely.

The second option are links. Or in Vitalik’s words:

In other words, Alice deposits funds and sends a URL or QR that lets Bob withdraw the funds. The frontend ensures that Bob is connected to the right chain when withdrawing funds. Bob can also choose which chain and token to claim on, and the funds are bridged in the background (on the roadmap of Peanut Protocol). Here is what this would look like:

Alice: I am sending you $1 https://peanut.to/claim?c=3&v=v3&i=1278&p=nwkGQOqa0ItZd9xL

Bob: Ok, thanks! 🐿️

We just went from an interactive communication protocol where Bob has to state preferences about how to receive funds, to a non-interactive one. All Alice has to do is click “generate link” and paste it to her chat where she is discussing a payment to Bob.

So how does it work? The link is simply a user-friendly way of sending an off-chain message. All it is an array of parameters: For instance this Peanut link https://peanut.to/claim?c=3&v=v3&i=1251&p=twLDK7YWL9tOZi9A is actually just a medium for the following information:

{
  "chain-id": 3,
  "version": "v3",
  "transfer-id": 1251,
  "secret": "twLDK7YWL9tOZi9A"
}

The claim function on the frontend then ensures that that this array is relayed to an RPC.

If it’s just an array of data, why use links? Because links will have a frontend that will deliver the JSON to the right place. Without such a frontend, each app would have to integrate a receive and send functionality within their app (if you work for a wallet or know someone, please get in touch). Rebuilding the entire middleware and dapp layer would be necessary for implementing keystore contracts.

URLs are already compatible with all devices, dapps, messengers and wallets without requiring any integration. This is unlike the keystore contract, which will require all dapps and wallets to integrate it with huge effort, changing fundamental backend flows. Even better, Peanut Protocol is perfectly compatible with keystore contracts. Bob could have their keystore contract and a frontend that implements Peanut Protocol could easily read that contract, and auto-suggest the preferred chains for claiming.

The crazy thing is: everyone with internet access can already use this cutting-edge decentralised protocol called HTTPS, without any onboarding. This means links are compatible with a web2 audience too. In such a case, the frontend can guide a crypto newbie through the onboarding process, which with account abstraction will be a few clicks. In the future, with ramp integrations, Bob could even withdraw the funds to fiat directly, and Alice could deposit fiat directly.

Peanut Protocol lets Alice send tokens to Bob without any new information about Bob. She does not need to know whether Bob is a crypto native or what chain Bob prefers. In other words, Peanut Protocol lets users send tokens without any assumptions about Alice’s or Bob’s crypto identities. No wallet addresses, no ENS, no keystore contracts, no lists of preferred tokens. Just a link or QR code.

Put more abstractly, in any offchain conversation, a handshake has already been made. Alice is already talking to Bob, whether that’s through WhatsApp, pidgeon post or just by standing near Bob in meatspace. Remember when we talked about identity and the engineer being tasked with “give access rights to the right person”? We realised that whilst social identity was extremely complex, the engineer was lucky: you only need one unique identifier. Engineers often opt for email or phone numbers, because they enable handshakes. The handshake makes sure that both parties know who’s who and prevents someone random from using Alice’s credentials. In fact, in crypto, we manually emulate handshakes by doing test transactions, which prevents human errors.

However, in any human conversation, the handshake has already happened. Alice is already talking to Bob! Whether it’s a chat about the recent freelance gig, last night’s pizza or pooling funds for a drone donation. Clearly, Alice already has a communication channel with Bob that establishes their respective identities. They could be standing next to each other, writing emails, using pigeon post. There is no need to parallelise the offchain handshake with the onchain handshake.

In fact, piggy-backing on the offchain handshake has UX and security benefits. From an end-user perspective, links are strictly superior. As already mentioned, it is a one-step process, where Alice sends the funds and receipt in one go, without having to wait for Bob stating his preferences. Equally importantly, the payment happens within the conversation that is already about the payment. There is no need to go back-and-forth between talking about the payment on telegram, copypasting details into metamask, and identifying the right transaction on etherscan. This reduced complexity also increases security from several common attacks and errors. First, since no wallet addresses or chain identifiers are needed, there is no room for Clipboard Hijacking or mistaking chains. Phishing is also made more difficult because you are likely to have a chat history.

Overall, payment links sidestep the entire identity problem and its many pitfalls. Instead, the offchain handshake already identifies Alice and Bob, and can be used for token transfers. So, at least for token transfers, we can easily abstract complexities away from end-users, without adding layers of complexity.

We’re now building cross-chain functionality where Alice can deposit USDC on Polygon, and Bob can choose to claim aEth on Arbitrum. This completely sidesteps the need for keystore contracts for most payments. We will build this on top of the infra built by our friends at Squid.

As a middleware, we help apps and wallets. Imagine if, as an end user, you could simply click “pay with link” rather than ask for preferred chains, tokens, wallet addresses or make test transactions. Links are a worry-free and newbie-friendly alternative to this error-prone process that could cost you your funds. Imagine just receiving funds to your email and being able to choose the wallet, chain and token of your preference. That’s Peanut Protocol. The SDKs let you have these buttons within your own app very easily. Links are also extremely useful for acquiring and onboarding new users. After all, they don’t need a wallet address yet and can be hand-held through some onboarding process.

Join us in this effort. We highly value all feedback, pointers towards people who might find this useful, and we are always open to talk about joining our core team :) So join our discord and be part of this massive sidestep!

@0xkkonrad

TLDR: Identity is hard. It’s going to get much worse in a multichain world of altchains and L2s. Currently, token transfers rely on chats where Alice and Bob exchange onchain identity information, along with chain and token preferences. This is offchain and interactive. One solution relies on storing these preferences in a keystore contract. We propose an alternative solution that relies on offchain communication through links. Links make payments non-interactive: Alice pushes funds to Bob on the communication channel they already have (e.g. WhatsApp, email, meeting in meatspace). Our solution sidesteps the identity problem by using links.

There is an intrinsic tension between the elegance engineers seek and the organic order that humans flourish in. The problem statement for the engineer is “give access rights to the right person”. The ideal system would be one that has a root identifier that is unique, easily readable, and impossible to spoof.

Yet, the engineer’s problem statement is tension with a little human quirk: society. Humans have the annoying tendency to take on different roles. We present ourselves differently at a bank than at a best friend’s bachelor party, we speak differently depending on our roles and the roles of our interlocutors.. How we appear on LinkedIn is different from our Twitter which is different to our Instagram.

“Give access rights to the right person” seems to be difficult as there is so little in common between these profiles. Luckily, you only need one unique identifier. Anything that is uniquely assigned to the user is enough to establish that it is them, no matter how different their tweets are from their wholesome family vacation pictures. Passport numbers, phone numbers and email addresses seem to be perfect. Just one more step — a handshake — and you are good to go. To make sure no one else uses your address, a one-time password will validate the ownership. Receiving messages is the primary function for email addresses and phone numbers, so they are the perfect match. They are used frequently, everyone has them, they fit in the normal communication flows we have. This is why web2 has passed the buck to phone and email providers in terms of identity. You see how this could be an issue with web3.

The worse news is that crypto complicates everything. Transactions are public by default. Most of crypto is finance, which mixes poorly with social identities. It’s also highly technical and geared towards specific use cases. The explosion of scaling solutions create a fragmented multichain world which also fragments identity across chains.

The fact that transactions are public makes a social identity impossible. While naming services like ENS are a nice add-on to show your presence, it makes no sense to consolidate all activity under them. After all, I don’t want the whole world to know how much money I have, where I spend it and how much I made from my previous employer. It simply makes no sense to have one kkonrad.eth. There is nothing to gain other than showing off trades or net crypto worth, while what’s at risk includes regulatory scrutiny, targeted phishing and hacker attacks, and the attention of sales people — the worst from this list.

Crypto is mostly geared towards finance and the aspect that are not pure finance like NFTs, gamefi or social media, are heavily financialised. Finance, in general, does not mix well with social identity. In many cultures, talking about money is frowned upon. Of course, there will always be groups like collectors who will talk a lot about the monetary value of Pokemon Cards or photos by Elsa von Freytag-Loringhoven. However, rarely is money a central focus. Current solutions like ENS do not work. They would require users to juggle multiple identities for different roles. “It ties too many things to your name” as Vitalik put it.

What’s worse, the boom in rollups and altchains lead to a fragmented multichain reality. With the increased complexity coming from the rise of stealth addresses, different L2s, etc. a simple payment interaction (the thing crypto is for!) could require a long list of instructions. Smart contract wallets are becoming popular and the addresses can be different across chains. It’s a nightmare that social identity is fragmented. Add multichain fragmentation, which runs tangentially to the fragmentation of social identity, and you’ve got a terrifyingly tormenting ordeal of splintered dependencies and infrastructural misfits.

Even the most simple use case, like paying for green tea, becomes a nightmare. Vitalik’s problem statement is:

I have coins on Scroll, and I want to pay [you] for coffee … you are only set up to receive coins on Taiko. Wat do?

This creates a complete clusterfuck. Vitalik summarises the following options:

1. Keystore contracts

2. Links

Keystore contracts contain pointers that prove ownership of the L2s addresses and list them. In essence, they are a long list of your different identities on the different chains. You could also expand that concept to altchains. In terms of UX, these complexities could be abstracted on the recipient’s or sender’s side. For sending, the funds could be routed to the preferred L2. For receiving, one could list all the accepted chains in the keystone contract and wallets could auto-consolidate funds later.

The problem with the multichain explosion is that Bob has to provide much more information than their ENS. From a simple process where Bob provides a simple string (the address) and Alice uses that to make a transfer on mainnet, in a multichain world, Bob has to provide a whole array, ideally, with a preferred order (e.g. Scroll is preferred to Polygon which is preferred to Optimism). This information can be stored in a keystore contract.

The process looks something like this:

Alice: I want to send you $1

Bob: Here is my keystore contract Bob.eth (contains the equivalent of: Please send funds to 0xA… if on Arbitrum, to 0xB… if on Polygon, to 0xC… if on Mainnet, and my order of preference is Arbitrum, Polygon, Mainnet.) Also, I prefer USDC on Polygon but USDT on Arbitrum but don’t worry if you can’t.

Alice: OK, sorry, I only have USDC on Arbitrum, so here your arbi-scan receipt.

Bob: OK, thanks! I’ll consolidate my funds later.

Yet, keystore contracts inherit all the problems about onchain identity: they are not private and they tie all your activity to one identity. An alternative to the keystore contract relies on links, which skip identity problem entirely.

The second option are links. Or in Vitalik’s words:

In other words, Alice deposits funds and sends a URL or QR that lets Bob withdraw the funds. The frontend ensures that Bob is connected to the right chain when withdrawing funds. Bob can also choose which chain and token to claim on, and the funds are bridged in the background (on the roadmap of Peanut Protocol). Here is what this would look like:

Alice: I am sending you $1 https://peanut.to/claim?c=3&v=v3&i=1278&p=nwkGQOqa0ItZd9xL

Bob: Ok, thanks! 🐿️

We just went from an interactive communication protocol where Bob has to state preferences about how to receive funds, to a non-interactive one. All Alice has to do is click “generate link” and paste it to her chat where she is discussing a payment to Bob.

So how does it work? The link is simply a user-friendly way of sending an off-chain message. All it is an array of parameters: For instance this Peanut link https://peanut.to/claim?c=3&v=v3&i=1251&p=twLDK7YWL9tOZi9A is actually just a medium for the following information:

{
  "chain-id": 3,
  "version": "v3",
  "transfer-id": 1251,
  "secret": "twLDK7YWL9tOZi9A"
}

The claim function on the frontend then ensures that that this array is relayed to an RPC.

If it’s just an array of data, why use links? Because links will have a frontend that will deliver the JSON to the right place. Without such a frontend, each app would have to integrate a receive and send functionality within their app (if you work for a wallet or know someone, please get in touch). Rebuilding the entire middleware and dapp layer would be necessary for implementing keystore contracts.

URLs are already compatible with all devices, dapps, messengers and wallets without requiring any integration. This is unlike the keystore contract, which will require all dapps and wallets to integrate it with huge effort, changing fundamental backend flows. Even better, Peanut Protocol is perfectly compatible with keystore contracts. Bob could have their keystore contract and a frontend that implements Peanut Protocol could easily read that contract, and auto-suggest the preferred chains for claiming.

The crazy thing is: everyone with internet access can already use this cutting-edge decentralised protocol called HTTPS, without any onboarding. This means links are compatible with a web2 audience too. In such a case, the frontend can guide a crypto newbie through the onboarding process, which with account abstraction will be a few clicks. In the future, with ramp integrations, Bob could even withdraw the funds to fiat directly, and Alice could deposit fiat directly.

Peanut Protocol lets Alice send tokens to Bob without any new information about Bob. She does not need to know whether Bob is a crypto native or what chain Bob prefers. In other words, Peanut Protocol lets users send tokens without any assumptions about Alice’s or Bob’s crypto identities. No wallet addresses, no ENS, no keystore contracts, no lists of preferred tokens. Just a link or QR code.

Put more abstractly, in any offchain conversation, a handshake has already been made. Alice is already talking to Bob, whether that’s through WhatsApp, pidgeon post or just by standing near Bob in meatspace. Remember when we talked about identity and the engineer being tasked with “give access rights to the right person”? We realised that whilst social identity was extremely complex, the engineer was lucky: you only need one unique identifier. Engineers often opt for email or phone numbers, because they enable handshakes. The handshake makes sure that both parties know who’s who and prevents someone random from using Alice’s credentials. In fact, in crypto, we manually emulate handshakes by doing test transactions, which prevents human errors.

However, in any human conversation, the handshake has already happened. Alice is already talking to Bob! Whether it’s a chat about the recent freelance gig, last night’s pizza or pooling funds for a drone donation. Clearly, Alice already has a communication channel with Bob that establishes their respective identities. They could be standing next to each other, writing emails, using pigeon post. There is no need to parallelise the offchain handshake with the onchain handshake.

In fact, piggy-backing on the offchain handshake has UX and security benefits. From an end-user perspective, links are strictly superior. As already mentioned, it is a one-step process, where Alice sends the funds and receipt in one go, without having to wait for Bob stating his preferences. Equally importantly, the payment happens within the conversation that is already about the payment. There is no need to go back-and-forth between talking about the payment on telegram, copypasting details into metamask, and identifying the right transaction on etherscan. This reduced complexity also increases security from several common attacks and errors. First, since no wallet addresses or chain identifiers are needed, there is no room for Clipboard Hijacking or mistaking chains. Phishing is also made more difficult because you are likely to have a chat history.

Overall, payment links sidestep the entire identity problem and its many pitfalls. Instead, the offchain handshake already identifies Alice and Bob, and can be used for token transfers. So, at least for token transfers, we can easily abstract complexities away from end-users, without adding layers of complexity.

We’re now building cross-chain functionality where Alice can deposit USDC on Polygon, and Bob can choose to claim aEth on Arbitrum. This completely sidesteps the need for keystore contracts for most payments. We will build this on top of the infra built by our friends at Squid.

As a middleware, we help apps and wallets. Imagine if, as an end user, you could simply click “pay with link” rather than ask for preferred chains, tokens, wallet addresses or make test transactions. Links are a worry-free and newbie-friendly alternative to this error-prone process that could cost you your funds. Imagine just receiving funds to your email and being able to choose the wallet, chain and token of your preference. That’s Peanut Protocol. The SDKs let you have these buttons within your own app very easily. Links are also extremely useful for acquiring and onboarding new users. After all, they don’t need a wallet address yet and can be hand-held through some onboarding process.

Join us in this effort. We highly value all feedback, pointers towards people who might find this useful, and we are always open to talk about joining our core team :) So join our discord and be part of this massive sidestep!