Centrifuge Integration

Use a Para-powered wallet to deposit into and redeem from Centrifuge vaults on Base and X Layer.

This walkthrough explains how to integrate Centrifuge vaults on Base and X Layer with a Para-powered EVM wallet. It is a step-by-step guide for depositing into and redeeming from Centrifuge vaults in a TypeScript web application.

The vault sits in front of the Centrifuge protocol so integrators don’t have to deal with its complexity: you deposit USDC into the vault and receive the freely transferable deRWA token.

The examples below use five live vaults across two different chains, Base and X Layer. They are worked examples rather than an exhaustive list. The same contract interface applies to every Centrifuge vault, so an integration written against one of these works against the others by changing the chain and the addresses. More products and chains are live already, and new ones are added regularly. The current list is published at docs.centrifuge.io.

Overview

The vaults in this guide provide a small contract interface for investing in tokenized real-world asset products. Users deposit an accepted asset, such as USDC, and receive product shares. Depending on the vault configuration, a deposit either completes immediately or enters a settlement queue.

Redemptions are always asynchronous. The user submits a redemption request, waits for settlement, and then claims the resulting asset.

The integration must therefore distinguish between:

• Synchronous deposit: one transaction deposits the asset and returns deRWA tokens.
• Asynchronous deposit: one transaction creates the request and a later transaction claims deRWA tokens.
• Asynchronous redemption: one transaction creates the request and a later transaction claims the asset.

Reference Deployments

The code in this guide uses the vaults below. Base and X Layer are two independent chains, each with its own RPC endpoint, gas token, and USDC contract, so a deployment on one is unrelated to a deployment on the other even when the product is the same.

Base (Chain ID 8453, Gas in ETH)

Product	Deposit mode	Vault address	Accepted asset	Asset address	deRWA token
deSPXA (18 decimals)	Fully asynchronous	0x86faaBE66124Fe9027BEC5d920AdF7aF0590cECC	USDC (6 decimals)	0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913	0x9c5C365e764829876243d0b289733B9D2b729685
deJAAA (18 decimals)	Synchronous deposit, asynchronous redemption	0x3f24925123deAcec58CD122BFD329907B8038712	USDC (6 decimals)	0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913	0xAAA0008C8CF3A7Dca931adaF04336A5D808C82Cc

X Layer (Chain ID 196, Gas in OKB)

The three X Layer vaults accept the same USDC contract and all use synchronous deposits with asynchronous redemption, the same mode as deJAAA on Base.

Product	Deposit mode	Vault address	Accepted asset	Asset address	deRWA token
deJAAA (18 decimals)	Synchronous deposit, asynchronous redemption	0xddD4E1F19DA8CAF2702840784D8D930d661d51c4	USDC (6 decimals)	0xB6CEceAB302E2E4948951eE7843FC24E92933061	0x5F8a1C74C112865BD05dbe4752C7608332719062
deHYB (18 decimals)	Synchronous deposit, asynchronous redemption	0xD55716089C722e8086A53AF180D528207AC0E753	USDC (6 decimals)	0xB6CEceAB302E2E4948951eE7843FC24E92933061	0xc5A9F6EdB48160eD9d9FB156A23c39d7140457eE
deJTRSY (18 decimals)	Synchronous deposit, asynchronous redemption	0x61506f58f12ff371b0ea88764cc09fe7d86af1d6	USDC (6 decimals)	0xB6CEceAB302E2E4948951eE7843FC24E92933061	0x8DE0F3295B9e42b29E7617BAdA7C603277420451

Other products and chains are live beyond these five vaults, and the set keeps growing. Look up the current addresses in the Centrifuge deployments reference rather than hardcoding this table into a long-lived integration.

How It Works

Across these deployments, deposits are synchronous for deJAAA, deHYB and deJTRSY, and asynchronous for deSPXA. Redemptions are asynchronous (ERC-7540 style) everywhere: you submit a request, the issuer fulfills it during their settlement cycle (this can take hours or days), and then you claim the result.

Deposit mode is a property of the vault, not of the chain or product. Read asyncDeposit() from the vault instead of assuming the mode from its name.

Three things to know before writing any code:

1. There is no claim() function. Claiming a fulfilled deposit is done by calling deposit(...), and claiming a fulfilled redemption by calling redeem(...).
2. Requests are self-directed. The controller and owner parameters in the request functions must be your own address.
3. mint() and withdraw() don’t exist. Only deposit() and redeem() are supported, so don’t point generic ERC-4626/7540 tooling at this vault.

These deployments allow anyone to claim a controller’s entire settled balance on their behalf, but the receiver must be that same controller. Partial third-party claims are not supported.

What You Need

• Node.js 18 or later.
• A package manager such as npm, pnpm, or yarn.
• A Para API key, a completed Para authentication flow, and an EVM wallet for the authenticated user.
• The Para Web SDK, Para’s viem integration, and viem.
• A mainnet RPC endpoint for the chain you target, Base or X Layer in this guide.
• The gas token of that chain in the signing wallet, ETH on Base or OKB on X Layer.
• USDC on that same chain for deposits. The USDC contract is different on each chain.
• The authoritative vault ABI and a standard ERC-20 ABI.
• A user interface that represents pending and claimable states separately.
• Para handles signing without exposing or storing the user’s private key in your application.

Install Dependencies

npm install @getpara/web-sdk @getpara/viem-v2-integration viem

---

Step-by-Step Integration (TypeScript + Para + viem)

All the code in this guide lives in a single file and uses Para’s Web SDK, Para’s viem integration, and viem.

Setup

Start with the Para and viem imports:

import Para from '@getpara/web-sdk'
import {
  createParaViemAccount,
  createParaViemClient,
} from '@getpara/viem-v2-integration'
import {
  createPublicClient,
  http,
  parseAbi,
  parseUnits,
  maxUint256,
} from 'viem'
import { base, xLayer } from 'viem/chains'

Define the supported deployments in one place. This walkthrough selects Base by default; change selectedNetwork to deployments.xLayer to use an X Layer sync-deposit or redemption flow.

const deployments = {
  base: {
    chain: base,
    rpcUrl: 'YOUR_BASE_RPC_URL',
    usdc: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
    products: {
      deSPXA: {
        vault: '0x86faaBE66124Fe9027BEC5d920AdF7aF0590cECC',
        share: '0x9c5C365e764829876243d0b289733B9D2b729685',
      },
      deJAAA: {
        vault: '0x3f24925123deAcec58CD122BFD329907B8038712',
        share: '0xAAA0008C8CF3A7Dca931adaF04336A5D808C82Cc',
      },
    },
  },
  xLayer: {
    chain: xLayer,
    rpcUrl: 'YOUR_X_LAYER_RPC_URL',
    usdc: '0xB6CEceAB302E2E4948951eE7843FC24E92933061',
    products: {
      deJAAA: {
        vault: '0xddD4E1F19DA8CAF2702840784D8D930d661d51c4',
        share: '0x5F8a1C74C112865BD05dbe4752C7608332719062',
      },
      deHYB: {
        vault: '0xD55716089C722e8086A53AF180D528207AC0E753',
        share: '0xc5A9F6EdB48160eD9d9FB156A23c39d7140457eE',
      },
      deJTRSY: {
        vault: '0x61506f58f12ff371b0ea88764cc09fe7d86af1d6',
        share: '0x8DE0F3295B9e42b29E7617BAdA7C603277420451',
      },
    },
  },
} as const

const selectedNetwork = deployments.base
const syncProduct = selectedNetwork.products.deJAAA
const redemptionProduct = selectedNetwork.products.deJAAA
const asyncProduct = deployments.base.products.deSPXA

We only need approve and balanceOf from the ERC-20s:

const erc20Abi = parseAbi([
  'function approve(address spender, uint256 amount) returns (bool)',
  'function balanceOf(address owner) view returns (uint256)',
])

And from the vault, the request/claim functions plus the two views that track a request’s lifecycle in each direction:

const vaultAbi = parseAbi([
  'function asyncDeposit() view returns (bool)',
  // deposit flow
  'function requestDeposit(uint256 assets, address controller, address owner) returns (uint256)',
  'function deposit(uint256 assets, address receiver) returns (uint256 shares)',
  'function deposit(uint256 assets, address receiver, address controller) returns (uint256 shares)',
  'function pendingDepositRequest(uint256, address controller) view returns (uint256)',
  'function claimableDepositRequest(uint256, address controller) view returns (uint256)',
  // redeem flow
  'function requestRedeem(uint256 shares, address controller, address owner) returns (uint256)',
  'function redeem(uint256 shares, address receiver, address controller) returns (uint256 assets)',
  'function pendingRedeemRequest(uint256, address controller) view returns (uint256)',
  'function claimableRedeemRequest(uint256, address controller) view returns (uint256)',
])

Complete Para authentication before creating the account and clients. createParaViemAccount selects the first available EVM wallet unless you pass a specific address or walletId.

const para = new Para('YOUR_PARA_API_KEY')

if (!(await para.isFullyLoggedIn())) {
  throw new Error('Authenticate with Para before signing transactions')
}

const account = createParaViemAccount({ para })

const publicClient = createPublicClient({
  chain: selectedNetwork.chain,
  transport: http(selectedNetwork.rpcUrl),
})

const walletClient = createParaViemClient({
  para,
  walletClientConfig: {
    account,
    chain: selectedNetwork.chain,
    transport: http(selectedNetwork.rpcUrl),
  },
})

Finally, a small helper so every write waits for inclusion and fails loudly on revert:

async function sendAndWait(txPromise: Promise<`0x${string}`>) {
  const hash = await txPromise
  const receipt = await publicClient.waitForTransactionReceipt({ hash })
  if (receipt.status !== 'success') throw new Error(`Tx reverted: ${hash}`)
  return receipt
}

That’s all the setup. Everything below uses these constants, clients, and the helper directly.

Case 1: Sync Deposit

In sync mode there is no request and no claim: approve USDC, call deposit, and the shares arrive in the same transaction.

async function syncDeposit(usdcAmount: string) {
  const assets = parseUnits(usdcAmount, 6)

  await sendAndWait(walletClient.writeContract({
    address: selectedNetwork.usdc, abi: erc20Abi, functionName: 'approve',
    args: [syncProduct.vault, assets],
  }))

  await sendAndWait(walletClient.writeContract({
    address: syncProduct.vault, abi: vaultAbi, functionName: 'deposit',
    args: [assets, account.address],
  }))
}

Case 2: Async Deposit

deSPXA on Base is the only asynchronous-deposit product in this guide. This case requires selectedNetwork = deployments.base and uses asyncProduct from that deployment.

Step 1: Approve USDC

The vault pulls your USDC when you submit the request, so it needs an allowance first. USDC uses 6 decimals:

const assets = parseUnits('1000', 6) // 1,000 USDC

await sendAndWait(walletClient.writeContract({
  address: selectedNetwork.usdc, abi: erc20Abi, functionName: 'approve',
  args: [asyncProduct.vault, assets],
}))

Step 2: Submit the Request

requestDeposit takes the amount plus a controller and an owner. Both must be your own address (the caller). Your USDC is transferred immediately and the request enters the queue:

await sendAndWait(walletClient.writeContract({
  address: asyncProduct.vault, abi: vaultAbi, functionName: 'requestDeposit',
  args: [assets, account.address, account.address],
}))

Step 3: Wait for Fulfillment

The issuer settles requests in epochs, so fulfillment is not instant. Two views, both denominated in USDC, tell you where your request stands: pending is what’s still queued and claimable is what’s already settled and ready.

async function getDepositStatus(controller = account.address) {
  const [pending, claimable] = await Promise.all([
    publicClient.readContract({
      address: asyncProduct.vault, abi: vaultAbi,
      functionName: 'pendingDepositRequest', args: [0n, controller],
    }),
    publicClient.readContract({
      address: asyncProduct.vault, abi: vaultAbi,
      functionName: 'claimableDepositRequest', args: [0n, controller],
    }),
  ])
  return { pending, claimable }
}

Fulfillment can also be partial: requests settle in order across all investors, so claimable may cover only part of your request for a while. You can claim partial amounts as they become available.

In a real service, poll these views from a background job or cron. Fulfillment can take hours or days depending on the product’s settlement cycle.

Do not use pending === 0 as the only terminal signal. Rounding dust can leave a small pending amount that is not claimable, and these vaults do not expose request cancellation.

Step 4: Claim Your Shares

Once claimable > 0, claim by calling deposit. Passing maxUint256 as the amount claims everything that’s ready, so you don’t have to compute it first:

async function claimDeposit() {
  const { claimable } = await getDepositStatus()
  if (claimable === 0n) throw new Error('Nothing claimable yet')

  await sendAndWait(walletClient.writeContract({
    address: asyncProduct.vault, abi: vaultAbi, functionName: 'deposit',
    args: [maxUint256, account.address],
  }))
}

The deSPXA shares (18 decimals) are now in your wallet:

const deSpxaBalance = await publicClient.readContract({
  address: asyncProduct.share, abi: erc20Abi, functionName: 'balanceOf',
  args: [account.address],
})

One nice property: if you submit a new requestDeposit while you still have a claimable balance from a previous one, the vault auto-claims the old one to you first. You’ll never strand settled funds by re-requesting.

Case 3: Async Redemption

The redemption flow mirrors the asynchronous deposit flow: request, wait, and claim, but moving shares in and USDC out. The selected redemptionProduct can be any of the five products listed above as long as it belongs to selectedNetwork.

Step 1: Approve Shares

requestRedeem pulls the selected product’s shares via transferFrom, so approve the vault first. All share tokens listed in this guide use 18 decimals:

const sharesToRedeem = parseUnits('500', 18)

await sendAndWait(walletClient.writeContract({
  address: redemptionProduct.share, abi: erc20Abi, functionName: 'approve',
  args: [redemptionProduct.vault, sharesToRedeem],
}))

Step 2: Submit the Request

Same rule as deposits: controller and owner must be your own address.

await sendAndWait(walletClient.writeContract({
  address: redemptionProduct.vault, abi: vaultAbi, functionName: 'requestRedeem',
  args: [sharesToRedeem, account.address, account.address],
}))

Step 3: Wait for Fulfillment

Same pattern as deposits, with the redeem-side views. Note these are denominated in shares, not USDC:

async function getRedeemStatus(controller = account.address) {
  const [pending, claimable] = await Promise.all([
    publicClient.readContract({
      address: redemptionProduct.vault, abi: vaultAbi,
      functionName: 'pendingRedeemRequest', args: [0n, controller],
    }),
    publicClient.readContract({
      address: redemptionProduct.vault, abi: vaultAbi,
      functionName: 'claimableRedeemRequest', args: [0n, controller],
    }),
  ])
  return { pending, claimable }
}

Step 4: Claim Your USDC

Claim by calling redeem. Again, maxUint256 claims everything that’s settled:

async function claimRedeem() {
  const { claimable } = await getRedeemStatus()
  if (claimable === 0n) throw new Error('Nothing claimable yet')

  await sendAndWait(walletClient.writeContract({
    address: redemptionProduct.vault, abi: vaultAbi, functionName: 'redeem',
    args: [maxUint256, account.address, account.address],
  }))
}

The example selects deJAAA. On Base, set redemptionProduct to selectedNetwork.products.deSPXA to redeem deSPXA. On X Layer, select deJAAA, deHYB, or deJTRSY from selectedNetwork.products.

Conclusions

These vaults require direct contract integration for deposits and redemptions, giving enough flexibility to be integrated into many different applications. Synchronous deposits complete atomically, while deSPXA deposits use a request-and-claim lifecycle. Redemptions are asynchronous for every listed product. Para supplies the authenticated viem account and wallet client used to sign each transaction.

The five vaults covered here, two on Base and three on X Layer, are examples of the pattern rather than the full catalogue. Once these deposit and redemption flows are implemented, supporting another product or another chain is a matter of pointing the same code at different addresses. The Centrifuge deployments reference is the place to check as new ones ship.