# Roadmap: WhatsABI

## Background

[WhatsABI](https://github.com/shazow/whatsabi) is a tool for extracting the ABI (and other metadata) from EVM bytecode, even without the original source code.

**Goal:** Improve decentralization, transparency, and user safety by reducing our dependence on proprietary frontends to EVM contracts.

WhatsABI works by using static analysis techniques, but it's specifically constrained in ways that other static analysis tools are not:
- Built in Typescript with minimal dependencies, so that it is **runnable in the browser and embeddable in wallets.**
- Algorithms used are limited to `O(instructions)` with a small constant factor, so that **complex contracts don't cause it to time out or use unbounded memory.**
- Does not rely on source code, so it **works with unverified contracts.**
- Does not assume the source language, so it can work for source languages other than Solidity (Vyper, or even hand-written assembly).
- Permissive open source (MIT-licensed), so that anyone can use it.

WhatsABI is perfect for building [better contract explorers](https://github.com/shazow/shazow.net/issues/46) (a better Etherscan), transaction builders (Safe Wallet), smarter wallets (MetaMask, Zapper), and for doing security research.

**Already used by**: [gnosis/zodiac-pilot](https://github.com/gnosis/zodiac-pilot), [ondora.xyz](https://www.ondora.xyz/), [monobase.xyz](https://monobase.xyz), ethcmd.com, [notar-cli](https://github.com/peetzweg/notar), [abi.w1nt3r.xyz](https://abi.w1nt3r.xyz/), ...

Many of the products in our ecosystem need WhatsABI. They just don't know it yet.

## Roadmap & Milestones

Each track is composed of sequential dependencies (can't skip the preceding step). Tracks themselves can be tackled independently.

### Track 1: Coverage of analysis and reliability

1. R&D a bounded-complexity abstract stack tracing approach for static analysis.
[Issue #26](https://github.com/shazow/whatsabi/issues/26)
(High risk, high impact, 3-8 weeks of work.)
- **Challenge:** Mainstream static analysis approaches have unbounded computation required, as they try to traverse every possible call path. This is easier to implement, but causes tools to time out or explode in resource usage. WhatsABI aims to constrain its approach to a constant number of instruction passes, so that it continues to be useful and reliable for client-side embedding.

2. Utilize abstract stack tracing to implement:
(Low risk, high impact, 1-3 weeks of work.)
- Dynamic jump tracing, to cover the call flow tracing more completely.
[Issue #24](https://github.com/shazow/whatsabi/issues/24)
- Improve reliability of detecting function modifiers (state mutability, payable, etc).
[Issue #27](https://github.com/shazow/whatsabi/issues/27)

3. Bonus: Guess more precise input types and return types.
(High risk, low impact, 1-3 weeks of work)

### Track 2: Building better procedural frontends

1. Detect common interfaces and mixins (useful for building interface-specific widgets)
[Issue #21](https://github.com/shazow/whatsabi/issues/21)
(Low risk, medium impact, 1-2 weeks of work)
2. Detect proxies and helper for resolving proxies automatically.
[Issue #11](https://github.com/shazow/whatsabi/issues/11)
(Low risk, medium impact, 1-2 weeks of work)

### Track 3: Security Research and bytecode explorer

1. Interactive web visualizer for WhatsABI's disassembler and call flow.
(Low risk, medium impact, 1-3 weeks of work)
- WhatsABI already has an internal command-line tool for exploring bytecode call flows, but it would be much more accessible if it was implemented as an interactive web app that can be used with any contract.