Skip to main content
An end user’s account under one platform Account Type. Maps 1:1 to a Gnosis Safe context on-chain. In the frontend SDK, accounts are resolved during SIWE sign-in. In the server SDK, accounts are looked up by EOA address via sdk.lookupAccount().
A product offering created by a platform (e.g., “Savings”, “Growth”, “BTC+”). Each Account Type defines vault allocations for all accounts under that type. Gets its own publishable key for SDK integration.
A set of HTTP endpoints exposed by Blend for authentication, account data, transaction intents, yield data, and Safe operations. See the API reference for the interactive playground.
A server-side secret key (sk_live_) for authenticating server SDK requests. Scoped to an organization. Managed from the admin portal Credentials page. Never expose in client code, logs, or version control.
The system that manages all DeFi asset metadata in Blend. Platforms request assets from the Philidor-scored catalog. Each asset goes through a review pipeline: PENDING, APPROVED, REJECTED, or ARCHIVED.
The per-account log of every action. Exportable by the platform from the portal. On-chain activity is independently verifiable on any block explorer. See Compliance Controls.
A vault allocation template containing asset addresses, chain IDs, and target percentages. Maps to one or more vault deployments on-chain. Platforms set manual allocations on their Account Types.
The portal marketplace where platforms browse and request vaults for their Account Types. Vaults are scored by Philidor (DeFi risk ratings), Credora (credit ratings), and RWA.xyz (tokenized real-world assets).
A strategy that aims for near-zero exposure to price movements of an underlying asset. Blend uses flash loans to create leveraged delta-neutral positions that capture yield spreads.
A standard for tokenized vaults that represent shares of a single underlying ERC-20 asset, providing a unified API for token vaults.
An uncollateralized loan that is taken out and paid back within the same blockchain transaction. Used in strategies to create leveraged positions safely - the entire transaction reverts if any step fails.
A transaction session for a deposit or withdrawal. In the SDK flow, intents move through OPEN, LOCKED, SUBMITTED, and terminal settlement states.
The core automation component of Blend that orchestrates capital deployment and rebalancing based on user intents and market conditions.
A smart contract or algorithm that determines the interest rates for borrowing and lending in a DeFi protocol, typically based on utilization.
A token that represents a user’s staked assets in a proof-of-stake network (e.g., stETH). It allows users to gain liquidity on their staked funds.
The ratio of a loan to the value of the collateral securing it.
The permission set a user grants up front: their account, plus the venue whitelist. Within it, Blend routes capital without per-transaction signatures. Outside it, Blend cannot act. See Accounts & Custody.
A DeFi protocol that enhances interest rates on other lending protocols like Aave or Compound. Blend integrates with Morpho for its delta-neutral strategies.
A type of platform. See Platform.
Blend cannot move user assets outside the mandate. Not “does not.” Cannot. Contracts are immutable, with no admin keys. Users keep full control of their assets through their own Safe.
A machine-readable specification used to document Blend’s REST API and power the interactive playground in the docs.
A user with administrative access to a platform organization. Roles: Admin (full control), Operator (manage account types and flow plans), Developer (read + API keys), Viewer (read-only).
The DeFi risk scoring system that evaluates vaults in Blend’s catalog. Each vault receives a composite score (0-10) across three dimensions: asset quality (40%), platform security (40%), and governance controls (20%). Vaults are classified as Prime (8-10), Core (5-7.9), or Edge (0-4.9).
A smart contract that pays for transaction gas fees on behalf of users, abstracting away the need for users to hold the native network token.
A client-safe key (pk_live_) for a Blend Account Type. The frontend SDK sends it as X-Publishable-Key to identify the organization and account type. It is not a secret; user authorization comes from the SIWE session. The server-side counterpart is the API key (sk_live_).
The process of transferring an asset from one blockchain (like Bitcoin) to a sidechain or layer-2 network (like Botanix).
A company that offers Blend-powered products to its users: a neobank, wallet, or fintech app. Platforms create Account Types, approve flow plans, and run their own KYC and AML programs. Integrates via frontend or server SDK.
A point-in-time record of how far each position has drifted from its target allocation. Included in every flow plan so the platform can see the deviation before approving.
Created when a user’s positions drift from the target allocations defined by their Account Type. Platforms review and approve flow plans, or set auto-approve. States: PENDING_APPROVAL, QUEUED, SOLVING, EXECUTING, SETTLED, FAILED, CANCELLED. See Flow Plans.
A Gnosis Safe smart contract account that holds a user’s funds. In Blend, each user gets their own personal Safe where they are the sole signer. This is the foundation of Blend’s SMA (Separately Managed Account) model.
A deterministic account-type value used to derive unique, predictable Safe addresses. In the SDK flow, the backend resolves this from the publishable key. It enables multi-account support where the same user can have separate Safes for different products.
Automated checks of every account address against OFAC and global sanctions lists. Runs before account creation, on deposit flows, and on an ongoing basis. A flag blocks Blend-routed operations until a person reviews it. Flags never clear automatically. See Compliance Controls.
A wallet authentication standard where the user signs a human-readable message to prove control of an EOA. Blend uses SIWE to issue frontend SDK sessions. Server-side integrations use API keys instead of SIWE.
Blend’s architecture where each user has their own isolated position (Gnosis Safe) rather than sharing a pooled vault. Enables individualized strategies, precise risk/return profiles, and per-user risk isolation. Isolation is also what lets compliance controls attach to each account: you can screen and audit an account, not a slice of a pool.
A transaction intent for a deposit or withdrawal. Sessions follow a state machine: OPEN (created/quoted), LOCKED (signer acquired), SUBMITTED (tx hashes sent), then SETTLED, FAILED, or CANCELLED. One active session per account. See SDK Transactions.
An individual asset movement within a flow plan. Contains source chain, destination chain, token address, and amount. A single flow plan can have multiple transfer nodes.
The total dollar value of assets deposited across strategies or integrations. Available via vault/tvl API endpoints.
Market conditions driven by MEV or manipulation that increase the risk of adverse selection, unstable borrow curves, or outsized price impact.
The amount of digital currency remaining after a cryptocurrency transaction completes. Blend’s indexer monitors for these on the Bitcoin network.
The on-chain deployment configuration for an Account Type’s vault infrastructure. Moves through states: PENDING, PROVISIONING, READY, ACTIVE, CANCELLED. Composition changes require provisioning + 24h timelock. Weight-only changes skip to READY.
The on-chain smart contract wrapper that Blend deploys to manage assets for an Account Type. Some Vault V2s wrap a single asset (standalone positions); others wrap multiple assets for gas efficiency (composite positions).
Blend’s flagship product. Capital routes from each user’s own Safe across curated venues like Morpho and Aave, never as a pooled position. Runs within the mandate each user grants up front. See Yield on Blend.
A Gnosis Safe module that enables fine-grained, role-based permissioning for what actions a delegated address (like Blend’s automation) can perform.
Last modified on July 3, 2026