Centrifuge Integration

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 deRWA share token, which is transferable between non-frozen accounts.

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 examples use five live PassthroughVault deployments across two independent chains. Each chain has its own RPC endpoint, gas token, and USDC contract.

Base (Chain ID 8453, Gas in ETH)

Product	Deposit mode	Vault address	Accepted asset	Asset address	deRWA token
JSPX (formerly 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)

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`

The share token at 0x9c5C... was renamed onchain from deSPXA to JSPX on August 17, 2026. The address and 18-decimal precision did not change.

For protocol-level contracts and newly supported networks, see the Centrifuge deployments reference. Confirm product-specific passthrough vault addresses with Centrifuge before adding another deployment.

How It Works

Across the listed deployments, deposits are synchronous for deJAAA, deHYB, and deJTRSY, and asynchronous for JSPX. Redemptions are asynchronous (ERC-7540 style): 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 configured per passthrough vault, not per chain or product. Read asyncDeposit() from the vault instead of assuming a mode from its name. Three things to know before writing any code:

There is no claim() function. Claiming a fulfilled deposit is done by calling deposit(...), and claiming a fulfilled redemption by calling redeem(...).
Requests are self-directed. The controller and owner parameters in the request functions must be your own address.
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 for project tooling.
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 browser-exposed mainnet RPC URL for Base or X Layer.
The selected chain’s gas token: ETH on Base or OKB on X Layer.
USDC on the selected chain for deposits.
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: {
      jspx: {
        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.jspx

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

JSPX 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 passthrough 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 JSPX shares (18 decimals) are now in your wallet:

const jspxBalance = 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.jspx to redeem JSPX. On X Layer, select deJAAA, deHYB, or deJTRSY from selectedNetwork.products.

Conclusions

These passthrough vaults use the same transaction interface across Base and X Layer. Synchronous deposits complete atomically, while JSPX deposits and every listed product’s redemptions use a request-and-claim lifecycle. Selecting another listed deployment changes the chain, RPC URL, USDC address, vault address, and share-token address without changing Para’s authentication or signing flow.

Overview

DeFi & Money Movement

Real World Assets (RWA)

Smart Accounts

Chains & Privacy

Para Templates

Agents

Centrifuge Integration

Overview

Reference Deployments

Base (Chain ID 8453, Gas in ETH)

X Layer (Chain ID 196, Gas in OKB)

How It Works

What You Need

Install Dependencies

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

Setup

Case 1: Sync Deposit

Case 2: Async Deposit

Step 1: Approve USDC

Step 2: Submit the Request

Step 3: Wait for Fulfillment

Step 4: Claim Your Shares

Case 3: Async Redemption

Step 1: Approve Shares

Step 2: Submit the Request

Step 3: Wait for Fulfillment

Step 4: Claim Your USDC

Conclusions

​Overview

​Reference Deployments

​Base (Chain ID 8453, Gas in ETH)

​X Layer (Chain ID 196, Gas in OKB)

​How It Works

​What You Need

​Install Dependencies

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

​Setup

​Case 1: Sync Deposit

​Case 2: Async Deposit

​Step 1: Approve USDC

​Step 2: Submit the Request

​Step 3: Wait for Fulfillment

​Step 4: Claim Your Shares

​Case 3: Async Redemption

​Step 1: Approve Shares

​Step 2: Submit the Request

​Step 3: Wait for Fulfillment

​Step 4: Claim Your USDC

​Conclusions

Overview

Reference Deployments

Base (Chain ID 8453, Gas in ETH)

X Layer (Chain ID 196, Gas in OKB)

How It Works

What You Need

Install Dependencies

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

Setup

Case 1: Sync Deposit

Case 2: Async Deposit

Step 1: Approve USDC

Step 2: Submit the Request

Step 3: Wait for Fulfillment

Step 4: Claim Your Shares

Case 3: Async Redemption

Step 1: Approve Shares

Step 2: Submit the Request

Step 3: Wait for Fulfillment

Step 4: Claim Your USDC

Conclusions