RP1 gives builders more than one programmable surface. Native EVM supports Solidity contracts and Ethereum-compatible JSON-RPC methods; Wasm and Velocity provide a separate workflow boundary for supported contract and bridge operations.
Choose the right layer
- Use native EVM when the application is Solidity-first and needs Ethereum tooling, contract storage, logs, and EVM JSON-RPC.
- Use Wasm/Velocity when the workflow needs the RP1 script/intention surface or a typed adapter into supported cross-chain operations.
- Use native modules when the chain already owns the accounting invariant: DEX, stables, privacy, UTA, lending, MPP, Vaults, or enterprise.
- Use IBC or InstaWrap when value must cross a chain boundary; do not rebuild custody inside an arbitrary contract.
Precompile boundary
The current application wiring exposes the Velocity Script precompile for supported Wasm and bridge workflows. Oracle, Privacy, and InstaWrap precompile address constants are reserved but not callable in the current wiring; use those modules’ native message and query surfaces. A precompile is an adapter into a validated chain surface, not permission to bypass that module’s authorization, gas, pause, proof, or accounting checks.
Deployment checklist
- Query the EVM chain ID and native gas denom from the target endpoint.
- Deploy a minimal contract and verify the receipt and logs.
- Bound dynamic calldata and apply explicit gas limits.
- Use typed precompile interfaces and validate every returned status.
- Keep asynchronous cross-chain intents idempotent and observable.
Start with EVM integration, smart contracts, and Velocity.