by Konrad Urban (kkonrad), Hugo Montenegro (hugo0)
The motivation is to gather knowledge and build a shared understanding of the problem and potential solutions space around addresses, chains, and payments.
Crypto account addresses are bad for peer-to-payments. They are not human-readable, they are a vector for attacks (address poisoning, clipboard hijacking, etc.), they're public. There are no guarantees for smart contract wallet addresses being the same across L2s. They usually require an interactive communication process about preferred chain, token and recipient wallet address.
There are two broad categories to address these issues: unified onchain identity and transfer abstraction. The core premise of unified identity is to keep all necessary information in one place. The core premise of offchain delegations is to sidestep onchain identity altogether.
The unified identity space is complex and rich. The main characteristics are keeping everything onchain and bringing together fragmented identities under one central contract. There are three main ideas in unified identity space: naming services, keystore contracts, and Account Abstraction mechanisms that rely on web2 identities.
Naming services simply create a human-readable name for the 0x address (ENS and UD, which map 0x addresses to names they sell). They can also map the accounts to web2 identities (e.g. Idriss) or use Account Abstraction mechanisms where authorisation is granted by web2 identities or where accounts are created counterfactually, based on web2 identities (e.g. Patchwallet). However, they do not fully guarantee counterfactual addresses on L2s. One solution could be keystore contracts which are counterfactual-friendly but would require significant changes on the middleware and app layers.
Unified identity projects have a key disadvantage: blockchains are public and people do not like to co-mingle their identities. Even those who have ENS names, usually also have other non-public accounts.
Links are a powerful way to abstract away multiple complexities. These complexities around token transfers 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. Let us call this transfer abstraction.
Transfer abstraction can be implemented in primitives that function as an escrow or a delegation 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. This new crypto primitive is an escrow-like smart contract, with composable release conditions.
There is an alternative, less explored, approach that completely sidesteps the onchain identity problem: offchain messages. Offchain messages can communicate all necessary information about the identity of sender and receiver without any additional onchain infrastructure. Offchain messages are address-agnostic, which means the sender does not have to know anything about the recipients onchain identity, thereby “invert[ing] the asset sending relationship” . All that is needed is a communication channel like a web2 messenger or even meatspace. This channel establishes sender and receiver identity for the transfer.
Links can be used for payments like so: the sender Alice can send tokens to Bob via messenger, e.g. by sending a link that Bob can claim Alice’s tokens from. We just went from an interactive communication protocol where Bob has to state preferences about how to receive funds, to a non-interactive one.
Compare the standard interactive protocol (or pull model):
Alice: Hey Bob, where can I send you the $100 I owe you?
Bob: Can you send them to bob.eth?
Alice: Sure, but gas is high, what’s your preferred chain?
Bob: Optimism is fine!
Alice: Is USDC ok?
Bob: I prefer USDT but if you don’t have any, that’s OK, you can send me USDC.
Alice: Ok! Here is your optimistic.etherscan.io receipt
To the non-interactive protocol (or push model):
Alice: Hey Bob! Here is your $100 payment.link/claim?...
Bob: Thanks!
This has important UX and security benefits. Links dramatically shorten the usual back-and-forth of figuring out preferred addresses and chains, and then sending an etherscan receipt. It does not require the sender to know anything about the onchain identity of the recipient. It also avoids some of the pitfalls of clipboard hijacking, ENS mimicry etc. It can have additional logic such as routing for cross-chain swaps or through privacy protocols..
In principle, this offchain message can have any format, e.g. a JSON object, but URLs are a particularly powerful way of transmitting these messages. A URL can be resolved directly by wallets or dapps (e.g. Peanut Protocol App), such that the user does not have to connect and click “claim” but simply receive a notification. Before these get implemented, a frontend can be used already.
This is because URLs provide a graceful fallback in case they cannot be resolved directly by a wallet or dapp. In fact, they do not require any integration, unlike name service resolvers or keystore contracts. They are also better than a custom URI because custom URIs have a history of low adoption as they require browser-level changes (e.g. bitcoin:// or ipfs://).
Claim links are great for onboarding new users. Links are compatible with a web2 audience, the frontend can guide a crypto newbie through the onboarding process, In the future, with ramp integrations, Bob could even withdraw the funds to fiat directly, and Alice could deposit fiat directly.
Links are already a well-established way of requesting payments. Claim links reverse the well-established payment request. All consumer wallets have it in the form of payment requests, a simple QR code that contains wallet addresses. Also SaaS companies like Request Finance allow for easy payment requests. They are also a well-established standard in the Bitcoin ecosystem.
There are two kinds of claim links. The first type, the lazy claim links, are the pure delegator model. They are lazy because they do not move funds until needed. The second type uses an escrow delegator model: funds are moved to an escrow from which the recipient claims the funds. Both have advantages and disadvantages.
Lazy claim links, or delegatable links, have been proposed by Dan Finlay and Rick Dudley in the delegatable.org docs and first in the Ethereum object capabilities. To avoid confusion with delegation as a concept. The name “delegations” is shared across a few distinct concepts. It has nothing to do with the Solidity delegatecall or Delegate.xyz (ironically, an identity project), or delegating votes (although delegating votes can be achieved with offchain delegations). The core idea of offchain delegations is that a signed message can grant the right to control assets or other rights.
Delegations can be written as human-readable code by using EIP712. This allows for clearly expressing intent, with a good understanding for all parties involved on what the code means. Most importantly, offchain delegations are not about just sending funds from Alice to Bob. They can have more complex logic. This additional logic is called caveats. Caveats are specific claim conditions. These are a necessary part of delegations as without caveats, the third party would have full permissions. These caveats can be logic such as claiming in a given timestamp range, specific ERC-20 allowances, transaction limits, but also more flexible logic such as oracle data. Caveats are a powerful mechanism because they can be composed of external complex permissions systems.
These caveats can be built in directly. If they get complex, they can also be managed by using a base delegatable contract that follows a diamond contract structure (ERC-2535). They are not limited to EOAs as smart contract accounts can sign these delegations by using EIP-1271.
Lazy claim links are:
More gas efficient (the transaction only happens when needed). In comparison, escrow claim links require two transactions: sending the funds to the escrow and then to the recipient.
Lazy claims are easily reversible. This means that a sender can always withdraw the funds before they are claimed.
Lazy claim links can achieve splitting and forwarding with simpler and more gas efficient logic. For example, the following results in only four onchain transactions Alice can send a lazy claim link delegating $50 to Bob. Bob can take $20 of those and forward Alice’s delegation $30 to Charlie, who can take $10 forward and $20 of Alice’s funds to Dan.
Another category relies on escrow contracts. 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.
With multi-factor authentication escrowed links are more useful because they are non-reversible. For example, Alice is making a very large transfer to Bob and wants to make sure the person she is talking to is not a phisher. An escrowed claim link can be constructed such that it is only claimable once Bob’s Github, e-mail and ENS ownerships are verified, and cannot be reversed or cancelled by Alice. Some additional logic is also not possible without escrowing the funds, such as routing any kind of routing, e.g. through a privacy protocol, a swap or a bridge.
Furthermore, escrowed links have in-wallet UX that is akin to a normal transaction. The sender who owns $50 sends $10 and the remaining funds in the wallet are clearly stated as $40. In the case of lazy links, it functions more like a traditional bank check, where it would continue showing the original $50. Only when the delegation is checked in, the sender’s wallet would update to $40. Alternatively, wallets could keep track of lazy claim links spending and subtract that from the balance shown in the UI, or otherwise keep track of the lazy link liabilities.
Furthermore, escrowed claim links can handle more asset types: native coins, ERC-721 tokens, ERC-1155 tokens, non-EVM tokens. Lazy claim links rely on the allowance mechanisms present in ERC-20 contracts.
Escrowed claim links can be cross-ecosystem links. For example, Peanut Protocol has an experimental Ethereum-to-Cosmos claim link feature. Links should follow CAIP-2.
There is a growing number of projects that are using claim links to make token transfer UX better. Here is a list of examples that use offchain links or delegations:
Centralised and Escrow Claim Links
Peanut Protocol (2022) - Escrow
Beam Wallet (2023) - Escrow (uses Peanut)
Silk (launch in 2024, uses Peanut)
Daimo (2023) - Escrow
Tiplink (2022) - Escrow (Solana only)
Linkdrop (2019) P2P Escrow (similar to Peanut)
Sling (2023)
Requesting funds via link:
Request (2017) - Accounting SaaS
Almost all wallets as early as Bitcoin-Qt (2012)
The growing number of projects using links as a medium for offchain delegations creates worries about interoperability. Currently, the usage of claim links in the ecosystem is still small. It would be good to start a discussion on how to remain interoperable without forcing breaking changes later on. We should avoid a scenario where several wallets create their own schema and each one requires a separate resolving mechanism.
As claim links will grow in adoption, we will see auto-claim UX, where links are automatically and natively resolved. The standard should be such that no breaking changes are required, yet set unambiguous and easy ways for resolving claim links.
Here is a list of initial suggestions to start off the conversation about a common standard. These are in no way recommendations. They are merely meant as a starting point for a discussion on these standards.
One suggestion has been using a custom URI, such as web3. However, we have seen that even commonly used protocols like IPFS are not natively resolved in major browsers such as Chrome or Firefox. Bitcoin request links, despite being accepted as a BIP as early as 2012 (see BIP-0021) have failed to be widely adopted. Most importantly however, a custom URI does not provide the graceful fallback.
Using HTTPS links has several major advantages:
graceful fallback
perfect for onboarding new users
can handle more complex flows by having additional frontend logic
Most importantly, claim links can be domain-agnostic. For example, Peanut Protocol has implemented domain agnostic links where any integrator can simply have claim links direct to their domain. However, for others to resolve these links, this would require a well-known file that contains the domains to be resolved automatically through iOS and Android universal linking. There should be a default, trusted, fallback domain for links of domains that could not be resolved otherwise.
All current escrow and delegation mechanisms are slightly different. Yet, for most, there is a common element of a secret or private key, and then optional additional parameters.
For example, Daimo uses: https://daimo.com/link/note///<depositPublicKey#
the privKey is at the end
additional parameters are username, amount, deposit public key (which serves as tx id)
Similarly, Peanut Protocol uses the following schema: https://peanut.to/claim?#c=&i=&v=&p=, where:
p is the privkey
c, v and i are additional parameters chain id, version, index (which serves as tx id)
Notably, in both, there is the privKey and there are parameters, which are different in both use cases. Whilst the params might differ between implementations and use cases, the privKey will always be one per transaction.
We propose the following minima standard schema for claimLinks:
https://?<idx?>#
Type: similar to Ethereum transaction types, denotes the type of link
Chain: CAIP-2 chain Identifier
ContractAddress: onchain Address of the link contract
Idx: optional param if necessary (e.g. peanut protocol V4 links)
Key: either full private key, if it starts with 0x, or seed if not
There are many optional parameters that could be useful, examples include:
Additional information about the transaction
A message (optional)
Signed Caveats(obligatory for delegations)
Sender information (optional)
Checksum (optional)
Multilinks (optional, example)
And more
The design goal of a good standard for links should take shortness into account for better UX.. We expect a growth in parameters with more logic being moved to offchain messages, we can bundle the parameters under one JSON file which is linked in the link.
To shorten the links, we can bundle the parameters under one encrypted JSON file which is linked in the link. Since these parameters might contain secret information, they can be encrypted with the privKey. The resulting schema would be:
/#
Alternatively, if not many, the public parameters can be listed directly in the link instead of linking to an external file. In such a case:
/#
The privkey can be reused as an encryption key such that the parameters on IPFS remain private. Using base62 wecan further condense the key, drastically reducing the number of characters.
These can be stored on a centralized service (since no trust is required) or on IPFS/Arweave.
Implementations and links should be multichain. For example, one wallet might be used in multiple ecosystems (e.g. Ethereum and Solana) and resolve claim links natively. Furthermore, links can also have cross-chain logic (see Peanut Protocol’s experimental cross-chain links) built in. This necessitates a clear naming schema that makes the links ecosystem and chain agnostic. To that end, it’s best to rely on CASA and CAIP-2, which has a clear standard for chain addresses: chain_id: namespace + ":" + reference.
The objective of this overview and proposal is to have a shared understanding of the problem and solutions space. We’ve given a broad overview of the two approaches to fixing serious problems to the crypto payments UX: unified identity and offchain delegations. We’ve discussed the problems of unified identity, and then explored the different ways offchain delegations can be used. We’ve discussed lazy claim links and escrowed claim links.