Security

Documentation Index

Fetch the complete documentation index at: https://docs.blend.money/llms.txt

Use this file to discover all available pages before exploring further.

Your users’ money stays in their own Gnosis Safe. Automation can only call whitelisted functions through approved modules. Every transaction passes through pre- and post-execution checks. Blend does not rely on a single security layer. It stacks five independent layers so that each one catches what the others miss.

​

Defense in depth

1. Safe isolation. Every user gets their own Gnosis Safe. No pooled funds. No shared risk. If one Safe is affected, no other user is impacted.
2. Access control. Only a single authorized executor can trigger operations. All vault actions run via delegatecall inside the Safe’s own context. There are no admin keys that can move user funds.
3. Transaction guards. RolesGuard validates every transaction before it executes. It checks pause state, permissions, and whitelisted targets. Slippage protection uses oracle-based price validation with governance-set limits.
4. Rate limiting. Each Safe-vault pair has a cooldown between operations. Even if an attacker compromised the executor, they could only act slowly. Slippage guards revert any transaction that exceeds acceptable price impact.
5. Emergency controls. The system can pause all non-owner transactions across every chain instantly. Safe owners keep full control during a pause and can always withdraw directly.

​

Real-world risk scenarios

Security claims are easy to make. Structural proof is harder. Here are five real failure modes from other platforms and how Blend’s architecture prevents each one.

​

Custodial collapse (Celsius, BlockFi)

What happened. Centralized custodians took opaque, off-chain bets with user funds. When those bets failed, platforms froze withdrawals. Users became unsecured creditors in bankruptcy. Why this cannot happen in Blend.

• Blend never takes custody. User assets stay in the user’s own Safe.
• All positions are on-chain and verifiable. No opaque off-chain bets.
• No single counterparty holds user assets. There is nothing to freeze.
• Users can withdraw directly from their Safe at any time, even if Blend goes offline.

​

Vault exploit (smart contract hack)

What happened. A DeFi protocol’s vault contract is exploited. Funds inside the vault are drained. Why Blend limits this damage.

• User capital is spread across multiple vaults. Only the portion in the affected vault is at risk.
• Each vault in the catalog is scored by Philidor across asset quality, platform security, and governance controls.
• The neobank controls which vaults their users are exposed to. Conservative products can use only Prime-tier vaults.
• Automated derisking moves funds out of positions when risk indicators spike.

​

Bridge exploit (cross-chain failure)

What happened. A cross-chain bridge is exploited or halted. Funds in transit are lost or frozen. Why Blend limits this damage.

• User funds stay in the user’s own Safe on each chain. They are never locked inside a bridge contract.
• If a bridge fails, users can still access and withdraw assets on each chain directly.
• Bridge transfers are confined to the user’s own Safe fleet. Funds bridged from a Safe on one chain can only arrive at that user’s Safe on another chain.
• There is no co-mingling across users. The exact assets on each chain are always known and verifiable.

​

Oracle manipulation (price feed attack)

What happened. An attacker manipulates a price oracle to borrow against inflated collateral or trigger liquidations at wrong prices. Why Blend mitigates this.

• Three layers of slippage protection: governance-set maximum, per-swap limits, and oracle-verified minimum output.
• Swap adapters verify zero-balance invariants before and after every swap. No tokens can be left behind.
• Rate limiting per Safe-vault pair prevents rapid exploitation even if an oracle is stale.

​

Protocol exploit (underlying lending market drained)

What happened. A lending market that the system builds on is exploited and drained of funds. Why Blend limits this damage.

• User capital is never fully exposed to a single protocol. Only the portion allocated to that specific vault is impacted.
• Vaults go through Philidor scoring before entering the catalog. Unaudited or high-risk contracts are filtered out.
• Your neobank controls allocation percentages. You can cap exposure to any single protocol.
• Automated monitoring detects adverse conditions and triggers derisking before losses grow.

These are not policy choices. They are structural properties of the protocol.

​

What you can verify

Everything happens on-chain. You can verify it yourself.

• Every Safe is a real Gnosis Safe contract. Look it up on any block explorer.
• All positions, balances, and transactions are visible on-chain.
• Contract code is immutable and verified on Etherscan.
• Vault configurations and executor addresses are public state on the RolesReceiver contract.

​

Audits

Blend’s contracts have been audited by independent security firms. See the full list of audit reports with links to the findings.