Porting to Robinhood Chain

Choose a strategy before choosing a model

The catalogue distinguishes EVM adaptation, non-EVM ports and off-chain integrations. That distinction determines what the agent can reasonably change and how a reviewer can verify the result.

A repository being open source does not make it deployable on every chain. Treat the target runtime, external services and financial assumptions as explicit inputs to the brief.

Adapting an EVM project

• Identify hard-coded chain IDs, deployment addresses, tokens, fee settings and external contracts.
• Review supported compiler versions, EVM opcodes, RPC behavior and transaction assumptions.
• Replace oracle, router, bridge, keeper and indexing dependencies with verified target-chain integrations.
• Revisit upgrade authority, access control, signature domains and replay protection.
• Test deployment scripts and contract interactions against the actual target configuration.

Porting a different execution model

A Solana, Move, CosmWasm or native Rust project generally needs a redesign of its execution boundary rather than a replacement RPC URL. Map the original account model, instruction flow, storage, authorization and asset custody into the EVM design.

For a financial engine such as Percolator, identify the numerical and solvency invariants before changing implementation language. Integer widths, rounding, overflow handling, liquidation ordering and failed-call rollback can change outcomes even when the interface looks similar.

Adapting tools and services

An indexer, SDK, wallet component or development tool may remain an off-chain service. Define its RPC, event decoding, chain configuration and hosting requirements separately from any contracts it uses.

A working frontend without a configured indexer or oracle is not a functioning protocol. Record each external service, its failure behavior and the operator responsible for keeping it available.

Define evidence that can reveal a wrong port

• Create reference input/output vectors from the pinned upstream revision.
• Compare outputs and state transitions across normal, boundary and failing inputs.
• Check unauthorized calls, rounding boundaries, resource exhaustion and failed external calls.
• Test interactions between custody, accounting, pricing and liquidation instead of only isolated helper functions.
• Record command exit codes and the exact code revision covered by the results.

Use bounded builds for bounded work

The current runner has a ten-minute sandbox lifetime and a capped reservation per job. A complex protocol port can require many reviewed iterations and work beyond this runner’s supported scope. A model returning a patch does not establish completion.

Write the remaining migration work into the review artifact. Release only the functionality supported by the implemented code and independently checked evidence.