Currently, there are only two types of canonical outputs: vouchers and notices.
Vouchers trigger CALL instructions in the EVM, which cover a myriad of use cases, such as:
Transferring Ether to addresses
Transferring tokens to addresses (*)
Minting tokens to addresses
(*) ERC-20 token transfers aren't 100% safe with standard vouchers, because they don't check whether transfer returns true. For the majority of ERC-20 token contracts, this isn't a problem, because they either return true or revert, and vouchers aren't marked as executed if the underlying call reverts.
Some use cases, however, are not covered by CALL instructions alone, such as:
Transferring Ether to ENS names
Transferring tokens to ENS names
Transferring ERC-20 tokens safely (by checking whether transfer returns true)
Minting tokens to ENS names
ENS name resolution brings several benefits to users, such as the ability to sell L2 accounts by selling L1 ENS names. See this post by @pedroargento for extra motivation.
✔️ Solution
We could implement a new output type for every use case, but then the application contract code would grow with every new case. Instead, we can add one output type that covers all of these use cases, thanks to the EVM instruction known as DELEGATECALL.
With DELEGATECALL vouchers, extra functionality would be implemented in the form of Solidity libraries, which are completely decoupled from the application contract. That means that application developers can implement new types of voucher through libraries. Such libraries can do virtually anything in the context of the application contract, so extra care must be taken.
📚 Context
Currently, there are only two types of canonical outputs: vouchers and notices. Vouchers trigger
CALLinstructions in the EVM, which cover a myriad of use cases, such as:(*) ERC-20 token transfers aren't 100% safe with standard vouchers, because they don't check whether
transferreturnstrue. For the majority of ERC-20 token contracts, this isn't a problem, because they either returntrueor revert, and vouchers aren't marked as executed if the underlying call reverts.Some use cases, however, are not covered by
CALLinstructions alone, such as:transferreturnstrue)ENS name resolution brings several benefits to users, such as the ability to sell L2 accounts by selling L1 ENS names. See this post by @pedroargento for extra motivation.
✔️ Solution
We could implement a new output type for every use case, but then the application contract code would grow with every new case. Instead, we can add one output type that covers all of these use cases, thanks to the EVM instruction known as
DELEGATECALL.With
DELEGATECALLvouchers, extra functionality would be implemented in the form of Solidity libraries, which are completely decoupled from the application contract. That means that application developers can implement new types of voucher through libraries. Such libraries can do virtually anything in the context of the application contract, so extra care must be taken.