Overview
The Ether Deck, further known as the “deck”, is an opinionated, optimized, extensible, multi-signature smart contract wallet. It is written in Huff and tested extensively using a Foundry-based fuzz and unit testing suite. There are four built-in functions for handling authentication, signature count threshold, shard management, and a generalized executor. The main interface to any functionality on the deck is through a signed syscall. Shards may extend the core functionality by assigning selectors to contract addresses in local storage. Encoding data to send to the deck is atypical and uses a packed calldata encoding scheme, making it a suitable choice for layer 1 Ethereum as well as layer 2 rollups that commit calldata to l1 storage.
Core
The core of the deck is the syscall. This takes a target address, call value, payload, and a list of signatures. The deck loads the required signature count threshold, or number of signatures required to execute, then checks each signature. All signatures must come from authorized accounts and too few signatures will fail. Once the signatures are validated, the target address is called with the respective value and payload.
Setters for authorized accounts, threshold, and shards exist on the deck but must be accessed via a syscall where the target is the deck itself. This prevents unauthorized state modification.
Signature verification uses a tight encoding and makes specific assumptions that allow for computational efficiency gains without breaking invariants. More on this in the documentation.
Shards
Shards are extensions to the deck. These can be assigned via a mapping of selectors to addresses where the address is the target and the selector prefixes the payload. A few example shards are provided in the repository enabling bundled multi-calls, token standard compliance, and public storage readers. However, any smart contract can be delegated as a shard. There are a few security considerations that should be reviewed in the documentation's shard security section before delegating to just any contract.
Since shards require extreme caution when using, a tool to screen shards for potentially dangerous opcodes is included in the scripts directory of the repository. This does not guarantee security, nor does a potentially dangerous opcodes guarantee a vulnerability. This scanner simply reports what opcodes are involved and what they can potentially do. Shards can be categorized as stateless, read-only, and stateful.
Stateless shards do not read from the local contract's storage. An example of this is the ERC721Receiver and ERC1155Receiver compliance shard called “recv”. Recv simply returns the selector give to it, indicating the deck is capable of receiving ERC721 and ERC1155 tokens.
Read-only shards may read from the local contract's storage or make external read-only calls to other contracts. No state changes are possible with a read-only shard. An example would be the public storage reader, or “pubstore” shard. Pubstore takes a storage key as an argument, loads the value from storage, then returns it to the caller. This is useful for reading the deck's storage.
Stateful shards have full control over the deck. They may make external calls, read and write local storage, append transaction logs, and even self destruct. Extreme caution must be taken when setting stateful shards. However, they can be useful. The multicaller shard is capable of bundling external calls into a single transaction and executing them atomically.
Testing and Security
Full security implications are documented in full in the documentation including assumptions, invariants, and other considerations. It is important to note that while testing is extensive, at the time of writing, it is not audited. A bug bounty program will be released shortly and if external interest is sufficient, an audit will be scheduled.
Next Steps
While there are basic tools for interfacing with the deck, it is incompatible with existing client tooling by design. It is optimized for on-chain computation, not compatibility. More tooling is under development for interfacing with the deck in a more intuitive way. However, it is important to note this is not targeting general users, this is built for users that have deep experience and knowledge of smart contract wallets and the EVM more broadly.
Conclusion
The Ether Deck makes highly opinionated choices in favor of on-chain gas optimization and instead offloads the user experience to the client tooling that interfaces with it, allowing for incredibly cheap transaction execution. Shards may extend the functionality of the deck and make its own decisions on transaction execution and encoding.
If you enjoy this article and relevant work consider subscribing, as more work on the deck and other interesting projects are in progress. Until next time, good hacking.