Overview
Credit Account V3 is a minimal contract that serves as a proxy for user interactions with external protocols. Each credit account represents a single leveraged position owned by a user. The account can hold multiple tokens as collateral and execute calls to whitelisted protocols through adapters. Contract Location:contracts/credit/CreditAccountV3.sol
Interface: ICreditAccountV3.sol
Key Features
- Lightweight proxy for leveraged positions
- Token transfer functionality (restricted to credit manager)
- External contract execution (restricted to credit manager)
- Emergency rescue functionality (restricted to account factory)
- Immutable connection to credit manager and account factory
State Variables
Immutable Variables
Contract version (always returns
3_10)Contract type identifier (always returns
"CREDIT_ACCOUNT")Account factory that deployed this credit account
Credit manager this account is connected to
Functions
safeTransfer
Token to transfer
Transfer recipient
Amount to transfer
execute
Contract to call
Calldata to pass to the target contract
Returns the result of the function call
This function is used by adapters to interact with external protocols on behalf of the credit account.
rescue
Contract to call
Calldata to pass to the target contract
Access Control
The credit account implements strict access control through modifiers:creditManagerOnly
Ensures the function caller is the connected credit manager.- Applied to:
safeTransfer(),execute() - Reverts with:
CallerNotCreditManagerException
factoryOnly
Ensures the function caller is the account factory.- Applied to:
rescue() - Reverts with:
CallerNotAccountFactoryException
Architecture
Credit accounts follow a minimal proxy pattern:- Deployment: Created by the account factory when a user opens a position
- Ownership: Tracked in the credit manager, not stored in the account itself
- Lifecycle: Returned to the factory pool when closed, can be reused for new positions
- Execution: All actions are initiated through the credit manager and credit facade
Constructor
Credit manager to connect this account to
The constructor sets both the credit manager and factory (from
msg.sender) as immutable variables.Security Considerations
Key Security Features:
- Immutable Connections: Credit manager and factory addresses cannot be changed
- Restricted Access: Only credit manager can transfer tokens and execute calls
- No Direct User Access: Users cannot call credit account functions directly
- Emergency Recovery: Factory can rescue accidentally left tokens
Example Usage
Credit accounts are not called directly by users. Here’s how they’re used internally:Token Transfer (Internal)
Protocol Execution (Internal)
Emergency Rescue (Internal)
Gas Optimization
Credit Account V3 is designed for minimal gas usage:- No Storage: Only immutable variables (stored in bytecode)
- Simple Logic: Minimal validation, relies on credit manager for checks
- Reusable: Accounts are recycled via the factory to save deployment costs
- Efficient ABI: Uses
abicoder v1for smaller bytecode
Related Contracts
- Credit Manager V3: Controls all credit account operations
- Credit Facade V3: User interface for account management
- Account Factory: Deploys and recycles credit accounts
- Adapters: Enable interactions with external protocols
Implementation Notes
Credit Account V3 uses OpenZeppelin’s
SafeERC20 library and Address.functionCall for safe external interactions.