MarginFi and Perena

Manifest-based integration path for protocols that are not yet wrapped by dedicated SDK adapters.

MarginFi and Perena

MarginFi and Perena currently use a manifest-based integration strategy.

This keeps the solver and Ranger generic while allowing you to add real execution bundles later.

How the manifest path works

The implementation lives in services/adapters/src/manifest-adapter.ts.

Behavior:

• if a manifest path is configured, the adapter loads real instructionEnvelopes
• if no manifest exists, the adapter falls back to a static deterministic placeholder

Environment variables

Variable	Purpose
STRATEGY_MARGINFI_CANARY_MANIFEST_PATH	Path to the MarginFi manifest file
STRATEGY_PERENA_EXOTIC_MANIFEST_PATH	Path to the Perena manifest file

Sample files

• config/strategy-manifests/marginfi-canary.sample.json
• config/strategy-manifests/perena-exotic.sample.json

What a manifest should contain

Each manifest can define operations for:

• deposit
• request_withdraw
• finalize_withdraw

Each operation can include:

• notes
• cpiProgramId
• instructionLabels
• instructionEnvelopes

When to move from static to manifest mode

Use manifest mode when:

• you already know the correct transaction bundle
• you want Ranger to execute real instructions before writing a custom adapter
• you want to validate an integration incrementally without changing solver logic

Remaining gap

These strategies are not fully first-class until they either:

• get dedicated SDK-backed adapters, or
• consistently use production-quality manifests maintained by the operator team