RP1 supports Solidity through a native EVM module and supports Wasm-oriented workflows through Velocity and typed adapters. The safest design is to use the chain module that already owns the invariant instead of rebuilding it inside a contract.
Native EVM
The EVM module manages accounts, nonces, code, storage, gas, logs, native token integration, block-level state roots, and an Ethereum-compatible JSON-RPC server. It also has a versioned precompile boundary for selected RP1-native capabilities.
The current application wiring registers the following callable precompile:
| Address suffix | Capability |
|---|---|
0x0803 |
Velocity Script and supported Wasm/bridge workflows |
The 0x0800–0x0802 address constants are reserved for possible Oracle, Privacy, and InstaWrap adapters, but they are not callable precompiles in the current application wiring. Use native module messages and queries for those capabilities. Always use the typed Solidity interfaces in the chain and contracts repositories, and never assume an address, method, or gas behavior on a different network without querying the target configuration.
Wasm and Velocity
Velocity provides a module-backed intent state machine and an EVM-facing facade for supported runtimes. Synchronous Wasm flows and asynchronous Bitcoin/Solana-style flows have different lifecycle and recovery requirements. Payload-size, timeout, runtime-allowlist, executor-authorization, and replay controls are part of the boundary.
Safety checklist
- Bind contract calls to the target chain ID and gas denom.
- Bound dynamic calldata and validate offsets and lengths before decoding.
- Treat bridge and intent status as asynchronous state, not a synchronous return value.
- Use module queries and receipts to reconcile logs and state.
- Do not give a contract arbitrary custody or connect Vaults V1 directly to leverage, DEX, lending, or cross-chain flows.
Continue with EVM integration, programmable workflows, and Velocity.