> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voltr.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Adaptor Creation Guide

> Build custom adaptors to bridge Voltr vaults with external DeFi protocols

An adaptor is a Solana program that bridges a Voltr vault with your DeFi protocol. The vault program calls your adaptor via CPI, and your adaptor routes those calls to your protocol.

<Tip>
  Building with a coding agent? The [Voltr Agent Skill](/explore/agent-skill) ships an `adaptor-creation.md` reference and a complete minimal Anchor adaptor in `examples/adaptor/` to scaffold this for you.
</Tip>

## How It Works

When a vault manager allocates or deallocates funds, the vault program:

1. Transfers tokens to/from the `vault_strategy_auth` PDA
2. Calls your adaptor's `deposit` or `withdraw` instruction via CPI
3. Reads the returned `u64` (via Solana's `get_return_data`) to track the strategy's position value

Your adaptor translates these calls into whatever your protocol needs — initializing markets, minting receipt tokens, managing exchange rates, etc.

## Core Requirements

Every adaptor must implement at minimum these three instructions:

| Instruction  | Called When                           | Must Return                                                        |
| ------------ | ------------------------------------- | ------------------------------------------------------------------ |
| `initialize` | Strategy is first created             | `Result<()>`                                                       |
| `deposit`    | Vault allocates funds to strategy     | `Result<u64>` — current position value in underlying token terms   |
| `withdraw`   | Vault deallocates funds from strategy | `Result<u64>` — remaining position value in underlying token terms |

Adaptors can define additional instructions beyond these three for protocol-specific workflows — such as multi-step withdrawals (request → withdraw), reward harvesting, or rebalancing. These extra instructions are invoked by the vault manager via `remaining_accounts` or separate transactions, not by the vault program itself.

## Key Concept: Strategy = Your Protocol's State

The vault passes a `strategy` account to your adaptor. This account maps to your protocol's own state — a market PDA, a reserve, a lending pool, etc. Your adaptor validates this mapping:

```rust theme={null}
// Example: strategy must be the ctoken market account
#[account(constraint = strategy.key() == market.key())]
pub strategy: AccountInfo<'info>,
```

Each vault strategy is a 1:1 mapping to a specific instance of your protocol.

## Accounts Passed by the Vault

The vault program always passes these accounts in a fixed order when calling your adaptor:

**Initialize:** `payer`, `vault_strategy_auth` (signer), `strategy`, `system_program`, + remaining accounts

**Deposit / Withdraw:** `vault_strategy_auth` (signer), `strategy`, `vault_asset_mint`, `vault_strategy_asset_ata`, `asset_token_program`, + remaining accounts

Any additional protocol-specific accounts are appended via `remaining_accounts`.

## Getting Started

<CardGroup cols={2}>
  <Card title="Core Components" icon="cubes" href="/protocols/adaptor-creation/core-components">
    Required instructions and account structures
  </Card>

  <Card title="Security Considerations" icon="shield" href="/protocols/adaptor-creation/security">
    Security best practices for adaptor development
  </Card>
</CardGroup>