Skip to content

DEVELOPERS

nOPAL Integration

nOPAL is the Nest BlackOpal LiquidStone II Vault. This page is organized around the recommended Actions API path first, then the direct contract path for advanced EVM integrations, plus the Solana transaction-builder flow.

FieldValue
VaultNest BlackOpal LiquidStone II Vault
SymbolnOPAL
Slugnest-opal-vault
EVM share token0x119dd7daff816f29d7ee47596ae5e4bdc4299165
Share decimals6
EVM Actions API base URLhttps://api.nest.credit/v1/actions
Solana API base URLhttps://api.nest.credit/v1/solana
Solana share mintGArhnnDj3GYhmQeApKVXaRv4TQFwhPcs3SNF6FXsTeXq
Solana USDC mintEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
ChainDeposit or redemption assetnOPAL NestVaultDecimals
Plume98866USDC0x2223…a7af0xd258…05c06
Plume98866pUSD0xdddd…6f3f0xfbfe…9a486
Ethereum1USDC0xa0b8…eb480xd258…05c06
Ethereum1USDT0xdac1…1ec70x5e94…7a2c6
FieldValue
nOPAL SPL mintGArhnn…TeXq
OFT program IDChEfPd…j1th
OFT config keyFmeHf1…7XLq
Solana USDC mintEPjFWd…Dt1v
Plume NestVaultComposer for nOPAL0x9053…62c9

Use the EVM Actions API when your app wants Nest to handle quote construction, vault selection, Predicate compliance checks, calldata encoding, and transaction simulation for nOPAL. The API returns transactions that your app signs and sends with the user’s EVM wallet.

This section covers:

The base URL is:

https://api.nest.credit/v1/actions

All amounts are raw base-unit integer strings. Do not send decimal UI amounts.

Use the quote route before building transactions. This returns the expected raw share amount, decimals, fee fields, rate fields, and a preview of the transaction steps.

Terminal window
curl -X POST https://api.nest.credit/v1/actions/vaults/nest-opal-vault/mint/quote \
-H 'content-type: application/json' \
-d '{
"depositAsset": "0x222365ef19f7947e5484218551b56bb3965aa7af",
"depositAmount": "1000000",
"chainId": 98866
}'

Example response shape:

{
"data": {
"slug": "nest-opal-vault",
"shareTokenAddress": "0x119dd7daff816f29d7ee47596ae5e4bdc4299165",
"depositAsset": "0x222365ef19f7947e5484218551b56bb3965aa7af",
"depositAmount": "1000000",
"depositDecimals": 6,
"shareAmount": "...",
"shareDecimals": 6,
"rate": "...",
"rateDecimals": 6,
"feeAmount": "0",
"fees": {
"ratePpm": 0,
"flatAmount": "0",
"maxRatePpm": 0,
"maxFlatAmount": "0"
},
"steps": [
{ "label": "approve", "description": "Approve PredicateProxy to spend the deposit asset" },
{ "label": "deposit", "description": "Deposit through NestVaultPredicateProxy" }
]
}
}

steps is a preview. The actual build-tx response may omit approve if the wallet already has sufficient allowance.

Use build-tx when the user is ready to deposit. The recipient is the EVM address that signs as depositor and receives the minted nOPAL shares.

Terminal window
curl -X POST https://api.nest.credit/v1/actions/vaults/nest-opal-vault/mint/build-tx \
-H 'content-type: application/json' \
-d '{
"depositAsset": "0x222365ef19f7947e5484218551b56bb3965aa7af",
"depositAmount": "1000000",
"chainId": 98866,
"recipient": "0x00000000000000000000000000000000000000ab"
}'

Submit the returned transactions in order. Every returned transaction uses the chain ID from the request. By default, the API simulates the transaction bundle before returning it. User-facing apps should generally keep simulation enabled.

Use the redeem quote route before submitting a redemption. This quotes the redemption asset amount and validates the selected asset for this vault.

Terminal window
curl -X POST https://api.nest.credit/v1/actions/vaults/nest-opal-vault/redeem/quote \
-H 'content-type: application/json' \
-d '{
"redemptionAsset": "0x222365ef19f7947e5484218551b56bb3965aa7af",
"shareAmount": "1000000",
"chainId": 98866
}'

For this guide, treat the NestVault redemption flow as the supported redemption path. If an integration receives an unsupported route value, surface it as an integration error instead of trying to fall back to a different contract flow.

Use this route to submit a redemption request on the same EVM chain.

Terminal window
curl -X POST https://api.nest.credit/v1/actions/vaults/nest-opal-vault/redeem/build-tx \
-H 'content-type: application/json' \
-d '{
"redemptionAsset": "0x222365ef19f7947e5484218551b56bb3965aa7af",
"shareAmount": "1000000",
"chainId": 98866,
"user": "0x00000000000000000000000000000000000000ab"
}'

NestVault redemptions return:

  • approve, if the selected NestVault does not already have sufficient share-token allowance.
  • requestRedeem, to submit the asynchronous redemption request.

After the request becomes claimable, use the claim routes below.

For NestVault-backed redemptions:

Terminal window
curl -X POST https://api.nest.credit/v1/actions/vaults/nest-opal-vault/claim/pending \
-H 'content-type: application/json' \
-d '{
"redemptionAsset": "0x222365ef19f7947e5484218551b56bb3965aa7af",
"chainId": 98866,
"user": "0x00000000000000000000000000000000000000ab"
}'
Terminal window
curl -X POST https://api.nest.credit/v1/actions/vaults/nest-opal-vault/claim/build-tx \
-H 'content-type: application/json' \
-d '{
"redemptionAsset": "0x222365ef19f7947e5484218551b56bb3965aa7af",
"chainId": 98866,
"user": "0x00000000000000000000000000000000000000ab"
}'

claim/build-tx builds a transaction to claim all currently claimable shares for the selected NestVault and user.

The update routes are for reducing an existing pending redemption:

POST /vaults/nest-opal-vault/update-redeem/pending
POST /vaults/nest-opal-vault/update-redeem/build-tx

newShareAmount is the final pending share amount, not the delta to remove.

When instant liquidity is available for the selected asset, use:

POST /vaults/nest-opal-vault/instant-redeem/quote
POST /vaults/nest-opal-vault/instant-redeem/liquidity
POST /vaults/nest-opal-vault/instant-redeem/build-tx

The instant-redeem request body uses redemptionAsset, shareAmount, chainId, and user. receiver is optional and defaults to user.

Use direct contracts only when your integration needs lower-level control than the Actions API provides. This path requires you to handle the full flow yourself:

This section covers:

For a direct integration, you handle:

  • Validate the selected chain, vault slug, and asset.
  • Check Predicate compliance and obtain a valid Predicate message.
  • Read the correct NestVault for the asset.
  • Quote shares or redemption assets.
  • Apply any app-level slippage or UX checks.
  • Submit ERC-20 approvals.
  • Submit deposit, redeem, update, instant-redeem, or claim calls.
  • Track asynchronous redemption state.
ContractAddress
nOPAL share token0x119d…9165
NestVaultPredicateProxy0xfc0c…9035
USDC NestVault (Plume, Ethereum)0xd258…05c0
pUSD NestVault (Plume)0xfbfe…9a48
USDT NestVault (Ethereum)0x5e94…7a2c

For accountants, roles, and other shared protocol contracts, use the Smart Contracts page as the source of truth.

For nOPAL minting, the direct flow is:

  1. Read the NestVault for the selected deposit asset and chain.
  2. Call previewDeposit(depositAmount) on that NestVault to estimate shares after fees.
  3. Get a Predicate message for the user and chain.
  4. Approve NestVaultPredicateProxy to spend the deposit asset.
  5. Call NestVaultPredicateProxy.deposit(depositAsset, depositAmount, recipient, nestVault, predicateMessage).

Minimal TypeScript outline:

import { encodeFunctionData, parseUnits } from "viem";
const chainId = 98866;
const recipient = "0x00000000000000000000000000000000000000ab";
const depositAsset = "0x222365ef19f7947e5484218551b56bb3965aa7af";
const depositAmount = parseUnits("1", 6);
const nestVault = "0xd258029cf5a177e3306e09fbea63424543a505c0";
const predicateProxy = "0xfc0c4222b3a0c9b060c0b959dec62442036b9035";
// 1. previewDeposit on nestVault
// 2. get Predicate message for recipient
// 3. approve depositAsset -> predicateProxy
// 4. encode PredicateProxy deposit call
const data = encodeFunctionData({
abi: NestVaultPredicateProxyAbi,
functionName: "deposit",
args: [depositAsset, depositAmount, recipient, nestVault, predicateMessage],
});

The Actions API’s mint/build-tx route performs these steps for app integrations and is the preferred reference for expected calldata shape.

For nOPAL redemptions, use the selected NestVault for the redemption asset:

  1. Approve the NestVault to spend nOPAL shares, if allowance is insufficient.
  2. Call NestVault.requestRedeem(shareAmount, user, user).
  3. Wait until shares become claimable.
  4. Call NestVault.redeem(claimableShares, user, user) to claim the redemption asset.

If you need to reduce a pending redemption before it is claimable, call NestVault.updateRedeem(newShareAmount, user, user).

Use the Solana transaction-builder endpoints or the browser SDK. The API returns a base64-encoded Solana VersionedTransaction; the user’s wallet signs and broadcasts it.

At a high level, Solana integrations are transaction-builder flows. Call a build-tx endpoint to get the transaction for a mint or redemption, have the user wallet sign it, and broadcast it on Solana.

Mints settle asynchronously: after the mint transaction is submitted, the Nest token is minted to the receiver’s Solana wallet, typically in about one minute at default priority. Standard redemptions are also asynchronous and settle according to the vault asset’s redemption policy and cadence. After the user submits the Solana redemption request, Nest keeper automation handles the follow-up redeem and auto-claim steps once liquidity is ready. USDC is returned to the user’s Solana wallet automatically; the user does not build or sign a later finish, claim, or finalize transaction. If instant liquidity is available, the Solana redeem endpoint can build an instant-redemption transaction for a fee.

This section covers:

The base URL is:

https://api.nest.credit/v1/solana

Solana transaction builders support both user-paid and sponsored fee-payer transactions. If feePayer is omitted, behavior is unchanged: the user wallet pays Solana transaction fees. If feePayer is provided, it must be a base58 Solana public key and becomes static account key 0, the transaction fee payer.

The user wallet remains the token owner or authority and must still sign. In sponsored mode, the user wallet should pay 0 SOL; the sponsor or relayer signs the fee-payer slot and broadcasts the transaction.

FlowAmount fieldType
MintrawAmountUsdcnumber
Standard redemption (async) requestrawAmountNestTokenstring
Standard redemption (async) update/cancelnewRawAmountNestTokenstring
Instant redeemrawAmountNestTokennumber
Terminal window
curl -X POST https://api.nest.credit/v1/solana/nest/mint/build-tx \
-H 'content-type: application/json' \
-d '{
"rawAmountUsdc": 1000000,
"finality": "standard",
"nestVaultSlug": "nest-opal-vault",
"receiver": "CFagSTMBFiMaD4YKHr7mMcKTzpi35DqiBKbDA35BvZgr"
}'

Response shape:

{
"data": {
"txBase64": "..."
}
}

The returned transaction:

  • Deposits Solana USDC through CCTP.
  • Routes to Plume for the nOPAL mint.
  • Delivers nOPAL back to the receiver as an SPL token through LayerZero OFT.
  • Is pre-signed where needed by Nest keeper infrastructure.
  • Still requires the receiver wallet signature before broadcast.

finality can be standard or fast. fast uses the 1 bp CCTP fast-finality fee and is expected to settle faster.

Sponsored mint request body:

{
"nestVaultSlug": "nest-opal-vault",
"rawAmountUsdc": 1000000,
"receiver": "<USER_SOLANA_PUBKEY>",
"feePayer": "<RELAY_SOLANA_PUBKEY>",
"finality": "fast"
}

Build Solana standard redemption (async) transactions

Section titled “Build Solana standard redemption (async) transactions”

Use standard redemption (async) when a Solana user wants to request a redemption, then later update or cancel the pending request before it is processed. The user’s only required Solana action is to sign and broadcast the request or update transaction. After liquidity is ready, Nest keeper automation completes the redeem and auto-claim flow, and USDC is returned automatically. The user does not submit a separate finish, claim, or finalize transaction.

Sponsored standard redemption (async) request body:

{
"nestVaultSlug": "nest-opal-vault",
"rawAmountNestToken": "1000000",
"owner": "<USER_SOLANA_PUBKEY>",
"feePayer": "<RELAY_SOLANA_PUBKEY>"
}

Submit that body to POST https://api.nest.credit/v1/solana/nest/async-redeem/request/build-tx.

Sponsored standard redemption (async) cancel/update-to-zero request body:

{
"nestVaultSlug": "nest-opal-vault",
"newRawAmountNestToken": "0",
"owner": "<USER_SOLANA_PUBKEY>",
"feePayer": "<RELAY_SOLANA_PUBKEY>"
}

Submit that body to POST https://api.nest.credit/v1/solana/nest/async-redeem/update/build-tx. Both standard redemption builders return the same txBase64 response shape as mint and instant redeem.

After broadcasting the user’s Solana redemption transaction, track the flow with the original Solana transaction signature:

Terminal window
curl https://api.nest.credit/v1/solana/redeem-status/<SOLANA_REDEEM_TX_SIGNATURE>

The status response includes the cross-chain stages:

  • solanaBurn: the user’s Solana request transaction.
  • plumeProcessing: delivery and processing on Plume.
  • cctpAttestation: USDC return path attestation.
  • solanaClaim: keeper-driven auto-claim delivery back to the user’s Solana wallet.

solanaClaim is a lifecycle stage, not a user action. Apps should show it as automatic settlement progress instead of asking the user to build or sign a separate claim transaction.

Terminal window
curl -X POST https://api.nest.credit/v1/solana/nest/redeem/build-tx \
-H 'content-type: application/json' \
-d '{
"rawAmountNestToken": 1000000,
"nestVaultSlug": "nest-opal-vault",
"owner": "CFagSTMBFiMaD4YKHr7mMcKTzpi35DqiBKbDA35BvZgr"
}'

Response shape:

{
"data": {
"txBase64": "..."
}
}

The Solana redeem builder sends nOPAL SPL shares through the OFT path to the nOPAL composer on Plume. The Plume-side flow processes redemption and returns USDC through CCTP.

From the user’s perspective, this is the only Solana transaction required for instant redemption. After the signed transaction is broadcast, Nest’s cross-chain infrastructure processes the redeem and returns USDC through CCTP; the user does not submit a separate claim or finalize transaction.

dstEid is deprecated for the Solana redeem endpoint. The destination is Plume mainnet.

Sponsored instant redeem request body:

{
"nestVaultSlug": "nest-opal-vault",
"rawAmountNestToken": 1000000,
"owner": "<USER_SOLANA_PUBKEY>",
"feePayer": "<RELAY_SOLANA_PUBKEY>"
}

After receiving txBase64, decode the Solana VersionedTransaction. If feePayer was provided, assert that transaction.message.staticAccountKeys[0] equals the fee payer public key. The user signs as the owner or receiver, then the relay signs as fee payer and broadcasts.

For sponsored instant redeem and standard redemption (async) flows, the expected required signers are [feePayer, owner]. For sponsored mint, the receiver remains the USDC owner and Nest share receiver, while the sponsor pays fees. For first-time sponsored mint receivers, the receiver’s Nest share ATA must already exist; the sponsor can create it separately with an idempotent ATA transaction.

The direct Solana API uses rawAmountUsdc. This browser SDK version forwards an amountUsdc field to the API, so pass the raw 6-decimal base-unit amount when using this wrapper.

import { Connection } from "@solana/web3.js";
import { createNestBrowserClient } from "nest-sdk";
const connection = new Connection("https://api.mainnet-beta.solana.com", "confirmed");
const client = createNestBrowserClient({
connection,
wallet,
config: {
nestApiBaseUrl: "https://api.nest.credit",
},
});
await client.mintNestToSolana({
nestVaultSlug: "nest-opal-vault",
amountUsdc: 1000000,
finality: "standard",
});

The SDK delegates transaction construction to the API, asks the user’s wallet to sign, and sends the signed transaction on Solana.

ConditionExpected behavior
Unsupported vault slugAPI returns 400.
Unsupported chain IDEVM Actions API returns 400.
Unsupported asset for the selected chainAPI returns 400.
Non-compliant walletEVM mint build returns 400; Solana mint build returns 403.
Deposit too small to mint sharesEVM quote/build returns 400.
Failed transaction simulationEVM build-tx returns 400 unless skipSimulation is true.
RPC, indexer, or Predicate service issueAPI returns 500.
Existing allowance is sufficientapprove may be omitted from returned transactions.
  • Treat every API amount as a raw integer amount.
  • Use the API’s returned depositDecimals, shareDecimals, and redemptionDecimals when rendering UI values.
  • Execute returned EVM transactions in order.
  • Never assume approve is present. Render and execute the returned transactions[].
  • Do not reuse quotes indefinitely. Re-quote close to the time the user signs.
  • For direct contract integrations, prefer the registry and Smart Contracts page over copying addresses from old integration examples.