Circle Research releases an open-source prototype for adding encrypted messages to ERC-20 transactions.
TLDR:
Almost all payment transactions require messaging alongside transfers to reconcile payments and meet regulatory requirements. Blockchain payments using ERC-20 tokens have no place for memo lines and encrypted messaging. Recibo is a smart contract that lets payers insert encrypted messages into transaction calldata when performing ERC-20 payments. Structured metadata makes it easy to use with arbitrary message formats and encryption algorithms.
- Circle Research releases Recibo: an open-source smart contract for adding encrypted messages to standard ERC-20 token transfers.
- Works with any ERC-20, as well as extra hooks for ERC-2612 permit and ERC-3009 transferWithAuthorization functions.
Overview
It’s hard to imagine commerce without invoices and receipts. Billing, accounting, tax payments, and regulatory compliance all begin with documenting the reason for money transfers. Yet the most widespread blockchain payment standard ERC-20 does not include a message line. Merchants and payment processors have to build their own offchain workarounds.
Introducing Recibo, a model smart contract that lets payers add encrypted messages to transactions. It works with standard ERC-20 tokens and also supports gasless transactions using ERC-2612 and ERC-3009. Payers route transactions through Recibo to record their messages as function calldata.
Basic accounting reconciliation and regulatory compliance requires transmitting information along with financial transactions. Adding encrypted messaging capabilities to blockchain transfers unlocks many important use cases:
- Merchants can attach digital receipts when they accept payment via a transferFrom transaction. They can also send encrypted credentials for the customer to claim digital goods.
- Users can attach the payment invoice or shopping cart ID when they send funds via transfer transactions.
- Financial institutions can include the standard ISO200022 payment messages, enabling functionalities that are similar to the SWIFT messaging network.
- Money transmitters can transmit required Travel Rule data within the transaction.
We designed Recibo to support arbitrary encryption and encoding formats.
Functions
Recibo has four functions to route transactions to the target token:
- transferFromWithMsg: Transfers tokens from msg.sender to receiver with an attached message. Requires prior approval for Recibo to transfer funds.
- permitWithMsg: Approves token spending using EIP-2612 permit with an attached message.
- permitAndTransferFromWithMsg: Performs EIP-2612 permit and transfer with an attached message.
- transferWithAuthorizationWithMsg: Transfers tokens using EIP-3009 authorization with an attached message.
Using Recibo adds about 10,000 gas overhead to a standard token transaction. Every 100 bytes of the message uses an additional 560 gas. To reduce the cost of sending large messages, users can encrypt revokable access tokens instead of the message itself.
Message Format
We structured Recibo calldata to support diverse use-cases:
struct ReciboInfo {
address messageFrom;
address messageTo;
string metadata;
bytes message;
}
Custodial wallet support. Custodial wallets make it difficult to discern the designated beneficiary of an ERC-20 transaction. A payment between two individuals can appear on the blockchain as a transfer between two large exchange wallets. The ReciboInfo messageFrom and messageTo identify the actual sender and receiver of the encrypted message. These can be mapped to offchain encryption keys.
Cryptographic agility. The metadata is a string that identifies the specific protocol used to encrypt the message. For users that have multiple public keys or rotate keys, the metadata can identify the version or hash of the key.
Encrypted message. The encrypted message itself is encoded as bytes for maximum efficiency.
Approve/TransferFrom
The approve/transferFrom pattern replaces a single transfer call. Payers who plan to use Recibo for multiple transactions can pre-approve Recibo for a larger allowance. Recibo only lets the token owner transfer funds using this pattern.
The approve/transferFrom pattern works with all ERC-20 tokens. The account holder approves the Recibo smart contract to transfer funds on its behalf. Moving forward, it can call the Recibo transferFromWithMsg function to transfer funds to others. For security, Recibo only transfers funds from the msg.sender. As a result, this solution would not work if the account holder tries to interact with Recibo via an intermediary smart contract.
PermitAndTransferFrom with ERC-2612
Tokens that support gasless approvals via the permit function can replace the approve/transferFrom pattern with a single transaction.
Tokens that implement permit from ERC-2612 can streamline transfers into a single blockchain transaction. The account holder signs a permit for the Recibo smart contract to transfer funds on its behalf. Then the account holder executes permitAndTransferFromWithMsg on the Recibo smart contract, which executes both permit and the transfer on the caller's behalf. For security, Recibo only transfers funds from the msg.sender - otherwise, an intercepted signed permit would allow any user to call Recibo to transfer funds on the account holder's behalf. Similarly to the approve/transferFrom pattern, this solution would not work if the account holder tries to interact with Recibo via an intermediary smart contract.
Permit then TransferFrom with ERC-2612
DeFi smart contracts like to call transferFrom on the ERC-20 themselves to simplify their documentation. The permit then transferFrom pattern integrates with this approach. It also allows gasless transferFrom on the receiver’s behalf.
Tokens that implement permit from ERC-2612 can also use the standard approve and transferFrom pattern preferred by swap contracts: the account holder approves the swap contract and then the swap contract calls transferFrom. In this case, the account holder (or a proxy) calls permitWithMsg on the Recibo smart contract with a signed permit. Then the swap contract can call transferFrom on the ERC-20 to obtain the approved funds. Unlike permitAndTransferFrom where Recibo performs the transfer, this pattern allows proxies to act on behalf of both the account owner and the receiver.
TransferWithAuthorization with ERC-3009
Smart contracts like USDC that implement gasless transferWithAuthorization let proxies perform a single gasless transfer with encrypted messages in a single transaction on the user’s behalf.
Tokens that implement transferWithAuthorization from ERC-3009 can perform gasless transfers by delegating to a 3rd-party EOA or smart contract. The account holder signs an authorization to transfer funds from himself to another party. Any account can then call transferWithAuthorizationWithMsg on the Recibo smart contract, which executes transferWithAuthorization on the ERC-20.
Caveats
Recibo has not been audited, has no security guarantees, and is released under Apache 2.0 license for educational purposes only.
You should NEVER store sensitive data on a public blockchain, even in encrypted form, in case of key leakage. It is better to store the data offchain, and include a URL + revokable token into the encrypted message. This approach will also reduce gas cost for large messages.
Ethereum nodes do not store function calldata long term on the blockchain, and most nodes delete old transactions. It is important to promptly retrieve messages and store them offchain.
Getting Started
We invite you to visit github.com/circlefin/recibo to view our open-source Recibo implementation. As always, Circle Research welcomes your input and feedback as we strive to accelerate crypto and blockchain innovation.
Subscribe to receive our latest updates or reach out to collaborate on new research.
Note: This article describes technology developed by Circle Research, a division of Circle committed to public good and open-source contributions to push the boundaries of technology used in crypto and blockchain. These projects do not represent completed and released software or services. Unless otherwise stated, content published by Circle Research is open-source and is available for anyone to consume, use, and build upon. Due to their experimental and emergent nature, Circle Research innovations are provided to be tested and evaluated at a developer’s or company’s discretion.
