Skip to main content
Blend is built for neobanks, wallets, and fintech products that want user-isolated Safe accounts with DeFi yield. You create the strategy, build the product, and deploy accounts. Blend handles the infrastructure.

​
Your setup workflow

Here’s the end-to-end path from zero to live product:
1

Submit assets

Add the DeFi positions you want in your strategy. Each asset goes through Blend’s review pipeline. See Assets.
2

Create a Basket

Build a strategy template from your approved assets. Set target allocation percentages. See Baskets.
3

Create an Account Type

Create a product offering (e.g., “Savings”, “Growth”) and link it to your Basket. See Account Types.
4

Deploy user accounts

Use the SDK to create accounts and deploy Safes for your users. See User Accounts.
5

Manage flow plans

When positions drift from target allocations, approve or cancel flow plans to rebalance. See Flow Plans.
You can also use a Basket from an external Risk Architect instead of building your own.

​
The operating model

EntityWhat it representsManaged by
AssetA DeFi position (Morpho vault, Euler market, Pendle PT, etc.)You submit, Blend reviews
BasketYour strategy template with target allocationsYou
Account TypeYour product configuration for end usersYou
AccountA single end-user account under one Account TypeCreated per user
SafeThe deterministic Gnosis Safe tied to that accountBlend + on-chain deployment

​
No omnibus structures

This section is for informational purposes only and does not constitute legal or financial advice. Consult qualified legal counsel for guidance on regulatory compliance.
Blend’s SMA model means you don’t pool user funds into a shared contract. Each user gets their own Safe. You pick a Basket, and Blend maps it to every user’s individual Safe. No co-mingling, no omnibus. See Regulatory Alignment for how this maps to US, EU, and global regulations.

​
What your application owns

Your application is responsible for:
  • creating and managing the user experience
  • collecting the user’s EOA address
  • calling Blend with your API key, neobankId, and accountTypeId
  • persisting any product-specific mappings between your internal user IDs and Blend accountIds
  • executing deposit quote payloads and withdrawal calldata payloads in your wallet or relay layer
Blend is responsible for:
  • account creation and account-scoped API reads
  • deterministic Safe addressing
  • Safe deployment requests and validation
  • deposit quote generation
  • withdrawal calldata generation
  • flow plan generation when positions drift
In the current public SDK, the normal lifecycle is:
  1. Instantiate one BlendClient per neobank plus account type
  2. Call client.safe.account(userEoa) to get the user’s accountId and Safe address
  3. Use account.accountId for balances, positions, returns, and deposit quotes
  4. Use client.withdraw.getCalldata(...) when the user wants to exit funds
const account = await client.safe.account(userEoa);
const balance = await client.balance.get(account.accountId);
const quote = await client.deposit.getQuote({
  chainId: 8453,
  inputAssetAddress: usdcAddress,
  eoa: userEoa,
  accountId: account.accountId,
  amount: "1000000",
});

​
Safe lifecycle

The Safe-related endpoints are intentionally split:
  • safe.account(address): returns the Blend account record and deterministic Safe address
  • safe.resolve(accountId, chainId): checks whether the Safe is already deployed on a specific chain
  • safe.request(accountId, chainId): requests Safe deployment on a specific chain
Use safe.account() as your default first call. Only reach for safe.resolve() or safe.request() when you need chain-specific deployment behavior.

​
HTTP vs RPC: what requires what

This is the most important architectural distinction in the SDK. Getting this wrong is the most common integration mistake.

​
Group 1 - Pure backend HTTP calls: no wallet, no RPC, no user signature needed

Every method in this group makes an Axios HTTP request to the Blend backend. They work from a Node.js server, a Next.js API route, or a browser. The user does not need to connect their wallet for any of these.
SDK methodWhat it does
client.safe.account(eoa)Gets or creates the account record. Returns accountId, safeAddress, chainsDeployed.
client.safe.resolve(accountId, chainId)Checks Safe deployment status on a specific chain.
client.safe.request(accountId, chainId)Requests Safe deployment on a new chain.
client.balance.get(accountId)Per-chain balances and total USD.
client.balance.getHistory(accountId, params?)Historical balance snapshots.
client.positions.get(accountId)All deposit, withdraw, and rebalance events.
client.returns.get(accountId)Cumulative return metrics.
client.yield.get()Current yield breakdown for the account type. No accountId needed.
client.deposit.getChains()Supported EVM chains for deposits. Cached server-side.
client.deposit.getTokens(chainId, eoa?)Token catalog. With eoa, returns wallet holdings with balances. No RPC needed.
client.deposit.getQuote(params)Relay-backed deposit route quote. Returns a quote payload for your bridge execution UI.
client.withdraw.getCalldata(params)Pre-built, ABI-encoded withdrawal calldata across chains. Returns calldata only, does not execute it.

​
Group 2 - On-chain execution: requires Viem transports and a paymaster

The transports and paymasterTransport fields in BlendClientConfig exist solely for on-chain execution. They are not used by any of the read or quote methods above.
ScenarioWhat you need
Submitting calldata from withdraw.getCalldata() via a relay or TransactionHandlerpaymasterTransport (e.g. Pimlico)
Enabling a Safe module via TransactionHandler.submitEnableModuleTransaction()Viem WalletClient, PublicClient, and paymasterTransport
Executing action plans via TransactionHandler.submitActionPlan()Viem WalletClient, PublicClient, and paymasterTransport
transports is keyed by chain ID and points to your RPC provider (e.g. Alchemy). paymasterTransport points to your ERC-4337 bundler (e.g. Pimlico). Both are required in BlendClientConfig even if you only use read methods, because they are part of the config shape. They are only exercised when executing on-chain transactions.

​
Summary

Use these namespaces for reads, quotes, and calldata generation. No wallet connection needed:
  • client.safe
  • client.balance
  • client.positions
  • client.returns
  • client.yield
  • client.deposit
  • client.withdraw (returns calldata only)
Use TransactionHandler and SafeMultisendManager when you need to submit UserOperations on-chain. You execute the deposit quote from client.deposit.getQuote() via your Relay integration, not the SDK. There is no public client-built deposit() action in the current @blend-money/sdk surface. Deposits use quote APIs and withdrawals use server-built calldata payloads.

​
Integration risks to design around

  • accountId is required for client.deposit.getQuote() because Blend resolves the destination Safe from account context
  • client.deposit.getTokens(chainId, eoa?) returns a flat DepositToken[] array. With eoa, tokens include balance and amountUsd fields
  • client.safe.request() returns { message }, not a status wrapper inside data
  • client.withdraw.getCalldata() returns payloads with a steps array. Each step has a kind discriminator
  • For max withdrawals, bridge steps may be omitted because the final amount is not known until settlement

​
Next steps

API Reference

Interactive API reference for all integration endpoints.

Blend SDK

Learn the current public SDK surface.

Cross-chain Deposits

Implement asset discovery and deposit quote flows.

Deposit & Withdraw

See the recommended end-to-end flow split for deposits and withdrawals.

Onboarding

Apply to become an integration partner.
Last modified on March 20, 2026