logo
Crypto means ownership. Owning means two things: controlling, and transferring ownership. Wallets are responsible for the former. Account abstraction makes wallets more drastically more useful and user-friendly. The second condition is the ability to transfer ownership.
Token transfers are complex because they are transfers of value. Value transfers are inherently tied to conditions, events, and identities. Value transfers are multi-step multi-party processes that have to resolve the identities of sender and recipient. Often, they function cross-chain, parties will often maximise privacy or require arbitration should a dispute arise. Yet, all of these complexities currently require many steps from the end users.
These complexities can be expressed as transfer intents. They can be communicated via a simple set of parameters sent through, for example, links (URLs or QRs). The complexities of choosing the correct parties for a swap or abtration, ensuring privacy, or additional multi-factor authentication can be done in the background.
We introduce a new crypto primitive that functions as an escrow that can read the parameters and determine whether their conditions have been met. The sender can predefine parameters or leave setting them to the recipient. In other words, this new crypto primitive is an escrow-like smart contract, with composable release conditions.
The simplest implementation of this is an asymmetric encryption key pair for each transaction, where the private key unlocking the funds is sent off-chain. This means that the protocol is non-custodial, trustless and permissionless. In practice, this allows for sending anyone tokens by just simply sending them a link (URL or QR). Links are useful because they are compatible with everything: everyone with internet access can receive them.
The scenario is that Alice wants to pay Bob. They communicate via a messenger about the payment. Alice goes to a frontend like peanut.to and generates a private-public key pair on the frontend (her device alone). She deposits funds into the the Peanut Protocol smart contract, alongside the public key. The Smart Contract returns a transaction ID (e.g. 001). Alice creates a package that contains the ID and adds a private-public keypair on her device and offchain (frontend). For instance, the package can be send as URL parameters (e.g. id=001&p=secret123) embedded on the link or QR code, and sent via the messenger. Bob then sends a message using the keypair and the smart contract will release the funds in case the message matches the public key.
The scenario is that Alice wants to pay Bob. They communicate via a messenger about the payment. Alice goes to a frontend like peanut.to and generates a private-public key pair on the frontend (her device alone). She deposits funds into the the Peanut Protocol smart contract, alongside the public key. The Smart Contract returns a transaction ID (e.g. 001). Alice creates a package that contains the ID and adds a private-public keypair on her device and offchain (frontend). For instance, the package can be send as URL parameters (e.g. id=001&p=secret123) embedded on the link or QR code, and sent via the messenger. Bob then sends a message using the keypair and the smart contract will release the funds in case the message matches the public key.
Image without caption
πŸ’‘
Try the Peanut PayLink dapp to see a single-chain implementation of transfer abstraction in action.
Share