Dymension RollApps support configurable execution within approved mainnet standards

Dymension RollApps use the RollApp Development Kit (RDK) to run application-specific chains that settle through the Dymension Hub. Designing one involves choosing an execution runtime, arranging sequencer operation and providing data availability. EVM and CosmWasm support different contract environments. Mainnet deployment also requires approved Dymension RollApp Standards (DRS) binaries, which limit changes to security-sensitive chain logic. Start with the application behavior that you need, then account for the software and infrastructure that support it.

Key takeaway: A production RollApp needs an approved execution standard, a funded sequencer and functioning data availability, even when local application tests succeed.

Choose the contract environment

The execution runtime determines which contracts a RollApp runs and which interfaces clients use, making existing application compatibility the starting point for choosing its chain software.

Application interfaces

EVM contract execution

EVM RollApps execute Ethereum Virtual Machine contracts and expose Ethereum-style JSON-RPC for compatible clients. The EVM template combines its contract environment with RDK modules and Dymint sequencing. Existing EVM applications therefore have familiar interfaces, while chain-specific dependencies still need attention. A contract that expects particular deployed addresses needs suitable addresses on its destination chain. Wallet connectivity and contract compatibility are separate requirements; a successful account connection alone does not establish that the application can execute correctly.

CosmWasm contract execution

CosmWasm runs WebAssembly smart contracts with its own execution and query interfaces. Its contracts need a compatible host environment and the capabilities that their compiled code requires. A WebAssembly file also needs CosmWasm’s required contract interfaces; the file format alone does not make every program a deployable contract. Choosing this runtime therefore affects contract code and client integration, even though the chain still uses Dymension settlement. Both runtime choices need application tests that match their execution rules.

Keep chain customization inside DRS boundaries

The RDK builds on the Cosmos SDK and supplies reusable modules, so developers can use existing account and token functionality when designing application-specific chains. Application contracts add behavior through the chosen runtime. Changes to the underlying chain binary raise a separate mainnet compatibility question, because production RollApps must follow the network’s approved standards.

Open full-size image

Mainnet RollApps must use approved Dymension RollApp Standards binaries. DRS limits access to components that could compromise chain security. A developer who needs a new execution environment or changes outside an approved standard can propose an extension for governance approval. This boundary belongs in the initial design: a locally modified binary does not automatically qualify as an approved mainnet implementation.

Deployment settings and their security boundaries

A RollApp configuration connects its execution runtime to sequencing, data publication and settlement, with each component carrying a different responsibility for a functioning deployment. The runtime must match its approved standard. The selected data availability (DA) integration must also work with the deployed software, so provider support is a software compatibility requirement.

Deployment settings and their security boundaries

A RollApp configuration connects its execution runtime to sequencing, data publication and settlement, with each component carrying a different responsibility for a functioning deployment. The runtime must match its approved standard. The selected data availability (DA) integration must also work with the deployed software, so provider support is a software compatibility requirement.

• Supported setting (Design parameter) Execution runtime: EVM or CosmWasm Sequencing engine: Dymint Data availability: A supported external DA integration Settlement mode: Dymension Hub, or mock settlement for local testing
• Security boundary (Design parameter) Execution runtime: Mainnet requires the matching approved DRS binary. Sequencing engine: The Hub determines eligible active sequencers. Data availability: Verification needs access to the published data. Settlement mode: Mock settlement does not establish live Hub settlement.

Economic settings add another design layer. A creator defines token allocations and inflation settings when preparing the chain. RollApp governance can update designated parameters, including minimum inflation and revenue distribution. Those choices affect the application economy and operator incentives.

Open full-size image

Economic settings add another design layer. A creator defines token allocations and inflation settings when preparing the chain. RollApp governance can update designated parameters, including minimum inflation and revenue distribution. Those choices affect the application economy and operator incentives.

Operating costs follow the workload

Dymint’s on-demand block production reduces unnecessary idle work, while hosting, data publication and Hub transactions remain separate operating responsibilities that need funding and reliable services. Block production and batch submission have their own configuration. Execution latency and settlement timing reflect different parts of this architecture. The sequencer publishes batches to its DA network before submitting their state updates to the Hub. Publication costs follow the selected network’s terms and the data that the sequencer submits.

Batching groups publication work, while application activity determines execution load. Size both components against the intended workload; an idle test cannot establish capacity under sustained demand.

Sequencer bonding commits DYM to operator eligibility. DYM staking supports the Hub’s validator security; the sequencer bond serves a different operational role.

Bonded capital and running expenses need separate budgets. The bond participates in operator selection and security incentives, while transaction fees and service costs fund continuing operation. The applicable minimum bond comes from Hub parameters, so a figure copied from another deployment can misstate the requirement.

What does shared settlement leave the application responsible for?

The Hub handles settlement bookkeeping between Dymension and RollApps, while application contracts still need correct execution logic and available transaction data to support independent verification. Approved chain software constrains security-sensitive modifications. Application developers still need to examine contract permissions and behavior. Shared settlement does not repair a flaw in an application contract.

Verification data

Full nodes verify the state transitions that the sequencer produces. Their ability to reconstruct execution depends on access to the relevant data. Data availability networks may prune transaction data after publication. Archival nodes must retain data for later retrieval. An application that needs historical indexing should plan retention explicitly, rather than treating data availability as a permanent archive.

Runtime-specific dispute protection

The EVM fraud-proof test implementation demonstrates dispute verification in a local environment. Production fraud-proof availability needs confirmation for the exact runtime and protocol version. A local demonstration does not establish automatic protection across live EVM and CosmWasm deployments.

Local execution and public deployment

Roller’s mock mode runs a local RollApp for development and testing without requiring live Hub settlement, so you can examine application behavior before adding external deployment dependencies. The quick-start setup demonstrates an EVM RollApp and also supports WASM RollApps. Mock dependencies provide a controlled development environment, without exercising the live settlement connection. Public operation needs the appropriate registered RollApp, an eligible sequencer and functioning settlement and DA services. Client access needs suitable public endpoints too. Keep the deployed runtime and DRS version consistent across participating nodes. Distinguish application faults from failures in those supporting services.

A dedicated chain versus contracts on an existing chain

A dedicated RollApp fits an application that needs its own execution environment and economic configuration enough to justify ongoing sequencing, data publication and supporting node infrastructure. The RDK supplies the chain framework, while the chosen standard sets the permitted production customization. Neither component removes the need to maintain the application itself.

Contracts on an existing chain can supply application logic without adding responsibility for a separate chain deployment. A RollApp adds control over its own chain configuration alongside operating obligations and DRS constraints. Compare both choices against the same application requirements. If a suitable existing runtime already provides the required behavior, maintaining another chain introduces work that the application may not need.

Open full-size image