Dynamic Safe Resolution
Safe addresses are computed deterministically from three inputs:| Input | Source | Example |
|---|---|---|
| neobankId | Your neobank identifier | "brookwell" |
| accountTypeId | The Account Type slug | "savings" |
| userAddress | End user’s wallet address | 0xABC... |
Multi-account support
Because the salt nonce includes the Account Type ID, the same user can have multiple Safes within your platform:Cross-chain consistency
The salt nonce does not include chain ID, which means a user’s Safe address is the same on every supported chain. This simplifies cross-chain operations: you can reference the same address regardless of which chain the user is interacting with.Deploying User Accounts
When a user creates an account:Resolve the Safe address
Use the API to compute the deterministic Safe address for this user + Account Type combination.
Deploy the Safe
If the Safe has not been deployed yet, trigger deployment. Blend handles the on-chain transaction.
Your neobank pays a per-account deployment fee that covers gas costs and Safe setup. See Integration Fees for details.
Account Lifecycle
| State | Description |
|---|---|
| Resolved | Safe address computed but not yet deployed on-chain |
| Deployed | Safe contract deployed. Ready for deposits. |
| Active | Has a non-zero balance and is actively earning yield |
| Inactive | Zero balance. Safe still exists on-chain but no active positions |
Security Model
- Non-custodial: The user is the sole signer of their Safe. Neither you nor Blend can access their funds.
- Isolated: Each Safe is independent. One user’s Safe cannot be affected by another user’s activity.
- Transparent: Users can view and interact with their Safe directly on safe.global at any time.
End users do not need admin portal access. They interact exclusively through your consumer app. The admin portal is for your team to manage Account Types and monitor accounts.