AggSandbox

AggSandbox is a Rust CLI and Docker-based development environment for running local, forked, and multi-L2 Polygon zkEVM bridge workflows.

Cross-chain systems are difficult to test because local environments need multiple networks, bridge contracts, services, transaction scripts, and clear inspection points.

At Nethermind, I authored 49 merged pull requests across the Rust CLI, Docker and Anvil environments, contract deployment, AggKit integration, bridge and claim commands, multi-L2 mode, tests, and documentation. The broader project provides the Polygon zkEVM bridge contracts and services that the CLI orchestrates.

• The Rust CLI starts and inspects Docker Compose environments containing an Anvil L1, one or more Anvil L2 chains, AggKit services, and deployed bridge contracts.
• Local mode simulates the full stack, fork mode starts from real network state, and multi-L2 mode exercises bridging between multiple destination chains.
• Bridge commands submit asset or message operations; status, events, bridges, and claims commands expose the intermediate state needed to diagnose the asynchronous lifecycle.

aggsandbox start --detach
aggsandbox bridge asset --network-id 0 --destination-network-id 1 --amount 0.1 --token-address 0x0000000000000000000000000000000000000000
aggsandbox show claims --network-id 1

• Docker Compose pins a repeatable service topology while the CLI provides one command surface for local, forked, and multi-L2 variants.
• Operational inspection remains explicit through status, events, bridges, and claims instead of hiding bridge state behind a single success message.
• The repository includes unit, integration, benchmark, and bridge-flow work so CLI behavior and infrastructure changes can be exercised together.

• Multi-chain startup has to coordinate ports, network IDs, contract addresses, service health, and deployment ordering across several containers.
• A bridge operation spans source submission, AggKit processing, proof or claim availability, and destination execution, so failures need to preserve enough identifiers for follow-up commands.
• Fork and multi-L2 modes change the surrounding network assumptions while the CLI still needs stable command semantics and deterministic tests.

• The Docker stack improves reproducibility but requires Docker, Rust, Make, multiple ports, and enough local resources for several chains and services.
• Local simulations help reproduce bridge workflows but do not reproduce every timing, availability, or finality condition of public networks.
• The CLI reduces setup steps without removing the need to understand network IDs, token addresses, transaction hashes, and claim state.

The public Nethermind repository's latest tagged release is v0.3.0, published July 6, 2025. I authored 49 merged pull requests; main includes changes after that release.

• GitHub repository
• 49 merged pull requests
• v0.3.0 release

• Architecture overview
• Bridge operations guide
• CLI reference

August 9, 2026