DIVE grew out of recurring difficulties deploying blockchain nodes, smart contracts, and bridges for development and testing. These environments require ordered setup, shared configuration, and deployment outputs that remain available to subsequent steps.
I designed DIVE to make that setup repeatable, using Kurtosis as the orchestration foundation. Idempotency was a central design goal: a repeated operation should account for existing infrastructure and reuse it where appropriate.
I started the project around those deployment problems and worked with the team to turn the setup sequences into executable workflows. My implementation work connected the command interface to node startup, contract deployment, and bridge configuration.
Separate the command from the environment plan
The CLI implementation provides a Go command layer around the infrastructure workflows. Starlark packages describe the services and setup operations that run through Kurtosis.
This separates the developer-facing command interface from chain-specific infrastructure plans. Each environment defines the services to start, their dependencies, and the outputs consumed by subsequent operations.
The separation also has a cost: configuration and results have to cross the Go, Starlark, and service boundaries correctly. Those interfaces are part of the architecture, even when the individual steps are straightforward.
Make repeated setup aware of existing services
My BTP orchestration change connected sequential node startup with bridge setup. It included paths for starting the required nodes and for setting up the bridge against nodes already running.
The workflow passes deployment information into later steps: contract addresses, network identifiers, and block information are collected before relayer setup. The ordering is consequential. A command that starts processes without connecting their outputs would still leave the developer to assemble the environment manually.
That existing-node path is a concrete part of the idempotency goal. Setup has to distinguish between infrastructure that needs to be created and infrastructure whose details should be reused. Using Kurtosis provides a foundation for that work; the deployment logic still has to handle each operation appropriately.
Extend the workflow across chains
The Cosmos Starlark package added another chain environment. The later ICON–Cosmos integration added setup and startup flows for an IBC relay between ICON and Archway.
These changes make the progression visible: individual chain services, then the configuration connecting them, then the relay that uses that configuration. Each layer carries information the next one needs.
What shipped
The merged work includes CLI commands, node and contract setup workflows, sequential BTP setup, a Cosmos service package, and ICON–Cosmos relay integration.
The concrete result is an executable path through development environment setup. Developers can invoke the implemented workflows instead of reconstructing those steps from separate commands and deployment outputs, including a BTP setup path that reuses already-running nodes.
The architecture makes setup order, deployment state, and service reuse explicit. Those are the concerns that originally made manual deployment difficult, and they remain the basis for evaluating the tool’s behavior.
Explore my DIVE repository · Upstream implementation · Back to projects