Liquid banking Architecture

Liquid Banking is built as a modular, permissionless, fully on-chain financial stack. Instead of a monolithic app with tightly coupled logic, the system is designed as a set of isolated smart-contract modules that compose like building blocks. These modules recreate the full spectrum of banking: accounts, payments, credit, savings, trading, and ramps - entirely on-chain, without requiring a bank, broker, custodian, or centralized exchange.

This modularity is what makes “banking on-chain” possible, we call it Liquid Banking.

Core Philosophy: Non-Custodial by Design

Unlike traditional crypto cards where you deposit funds into a centralized wallet, Hyperbeat utilizes a ManagementAccount architecture.

• You hold the keys: You are the Owner of your smart contract.

• You control the assets: Assets sit in your contract or your personal DeFi positions (e.g., Aave, Morpho).

• Permissioned Settlement: The Hyperbeat backend (Operator) is only authorized to settle card transactions up to a limit you define. The Operator cannot arbitrarily seize funds or withdraw assets to unauthorized addresses.

2. Architecture Overview

The system is built on a modular architecture to ensure security, upgradeability, and risk management.

Key Components

Component	Description
ManagementAccount	The core user wallet. It holds assets, manages permissions, and executes DeFi interactions. Deployed as a UUPS upgradeable proxy.
ManagementAccountFactory	The central factory that deploys user accounts and enforces global parameters (e.g., protocol fees, timelocks).
ServiceRegistry	A whitelist of approved DeFi adapters (e.g., Morpho, Aave) that users can interact with safely.
TokenWhitelistRegistry	A central registry of approved tokens to prevent interaction with

2.1 Liquid Bank account: ManagementAccount

At the core is the ManagementAccount, a non-custodial smart contract wallet deployed via the ManagementAccountFactory.

• Role: It acts as the user's on-chain identity and asset vault.

• Modularity: It does not contain hardcoded logic for specific DeFi protocols. Instead, it relies on a standardized IService interface to interact with external modules.

• Upgradeability: Built on the UUPS (Universal Upgradeable Proxy Standard) pattern, allowing the contract logic to be improved or patched without forcing users to migrate funds or change their address.

2.2 Services: ServiceRegistry

To enable "banking" features like savings or credit, the account connects to the ServiceRegistry. This registry acts as an on-chain "App Store" of verified adapters.

• Function: It maintains a whitelist of approved protocol adapters (e.g., MorphoService for lending/borrowing).

• Security: Users must explicitly approveService before a module can interact with their funds. This prevents a new, unvetted protocol from draining user assets.

• Extensibility: New financial products (e.g., a new yield source or a prediction market) can be added simply by deploying a new Service Adapter and registering it. The core wallet does not need to be upgraded.

2.3 The Asset Layer: TokenWhitelistRegistry

To protect the banking loop from malicious assets (e.g., spam tokens or "dust" attacks), the system utilizes a TokenWhitelistRegistry.

• Function: It defines which assets are valid for deposits, collateral, and settlement.

• Settlement Token: It enforces the validity of the specific stablecoin (e.g., beatUSD or USDC) used for card settlements.

3. Operating Modes

The ManagementAccount adapts to your financial strategy via two distinct operating modes.

💳 CASH Mode

In this mode, you hold the settlement token directly in your ManagementAccount.

• Mechanism: Direct cash.

• Flow: When you swipe your card, the Operator calls settle() to deduct the specific amount from your account balance.

• Safety: You set a Spending Limit. The Operator cannot withdraw more than this allowance.

• Withdrawal Rules: Withdrawing the settlement token requires a cooldown and operator approval (to ensure no pending card swipes are unpaid). All other tokens can be withdrawn instantly.

🏦 CREDIT Mode

In this mode, you deposit assets into DeFi protocols (like Aave or Morpho) via your account.

• Mechanism: Collateralized Borrowing.

• Flow: When you swipe your card, the Operator is authorized to borrow the settlement token from the DeFi protocol on your behalf.

• Debt Management: You are responsible for managing your health factor and repaying the debt.

• Safety: The Operator acts as a delegate borrower only.

• Withdrawal Rules: Withdrawing collateral requires operator approval (to ensure the withdrawal won't cause liquidation or unpaid settlements).

4. Security Model

Liquid Banking is engineered around a dual-control, non-custodial security model that ensures user funds remain safe, unfreezable, and verifiable at all times. Unlike centralized banking systems where trust is placed in off-chain intermediaries, Liquid Banking enforces cryptographic guarantees around spending, borrowing, withdrawals, and mode changes each of which is governed by explicit on-chain rules.

4.1 Separation of roles

The core security innovation is the strict separation of powers between the Owner (You) and the Operator (Hyperbeat). The Operator is treated as a service provider, not a custodian.

• Restricted Authority: The Operator holds a restricted role (OPERATOR_ROLE). It cannot upgrade contracts, change global registries, or seize assets arbitrarily.

• Settlement Allowance: The Operator is "firewalled" by a spending limit you define. If you set a limit of $1,000, the Operator’s request to settle $1,001 will revert on-chain. This ensures that even if the Operator key were compromised, the attacker could not drain your entire wallet.

• Debt Isolation: In Credit Mode, the Operator acts only as a delegate borrower. It cannot withdraw your collateral to an external address; it can only execute specific borrow actions to pay a merchant.

4.2 Timelocks & Anti-Race Conditions

Blockchain transactions and real-world card swipes happen at different speeds. To prevent "race conditions" (where a user might try to withdraw funds immediately after swiping a card but before the settlement processes), we enforce mandatory delays for critical actions.

• Settlement Token Withdrawals: In Spending Mode, withdrawing the settlement token requires a 2-step process with a cooldown (default: 1 day). This gives the Operator time to verify that all card transactions have settled before releasing the funds.

• Mode Switching: Switching from Credit to Spending mode also enforces a timelock. This ensures a user cannot swipe a card using credit and then immediately switch modes to evade settlement.

• Collateral Safety: Withdrawals of collateral in Credit Mode require Operator approval to confirm that the withdrawal will not result in bad debt or unpaid card transactions.

4.3 Registry-Based Safety (Whitelists)

To protect users from "dust attacks," spam tokens, or malicious protocol interactions, the system utilizes centralized, audited registries.

• Token Whitelisting: The TokenWhitelistRegistry ensures that the account can only interact with verified assets. You cannot accidentally interact with a malicious token contract that might try to exploit your wallet.

• Service Vetting: The ServiceRegistry acts as a gatekeeper. Users can only connect their accounts to DeFi protocols (like Aave or Morpho) that have been audited and explicitly added to the registry by the protocol admin.

4.4 Access Control & Upgrades

The system is built to evolve without breaking security invariants.

• UUPS Upgradeability: We use the Universal Upgradeable Proxy Standard (UUPS). This allows us to patch vulnerabilities or add features to the logic contract without moving your funds. However, upgrades are strictly gated by the UPGRADER_ROLE and limited to implementations whitelisted by the factory.

• Role-Based Access Control (RBAC): Every function is protected by specific roles (OWNER, OPERATOR, SERVICE_ADMIN, TOKEN_ADMIN). This granularity ensures that a compromise in one part of the system (e.g., the service registry) does not automatically grant access to user funds

5. Key management

Liquid Banking uses Turnkey to provide secure, non-custodial key management without seed phrases, browser extensions, or custodial wallets. Turnkey generates and protects each user's on-chain signing key, which becomes the Owner of their ManagementAccount. This means users, not Hyperbeat, control the smart contract that holds all assets.

Turnkey never has custody of funds. It enforces policy-based signing, which requires every user signature to follow strict rules. Examples include allowing a key to interact only with the user’s ManagementAccount or preventing token transfers without explicit approval. These policies protect users even if a device or session token is compromised.

For convenience, Turnkey issues session keys. These are short-lived, limited-permission keys that allow users to trade, view balances, or interact with approved services without exposing their main private key. Session keys cannot move assets or change account permissions.

Turnkey also supports secure, non-custodial recovery through passkeys, hardware keys, and social recovery. Users can regain access to their account without involving Hyperbeat or any third party.

In simple terms: Turnkey protects the keys, the ManagementAccount protects the assets, and the Operator can only perform actions that the user has explicitly authorized.

6. Audits

The Liquid bank has undergone multiple audits by leading auditing firms:

• Zellic

• Nethermind