Programmable Rules
Credit enforcement at the contract level. Not monitored — enforced. Not optional — automatic.
How rules work
FIBOR's credit rules are not policies that someone checks. They are smart contract logic that executes automatically. No admin can override them. No oracle can bypass them. The contracts do the math.
Rules enforced by FiborAccount
When USDC arrives in a FiborAccount, outstanding credit is repaid before the agent can touch the money. This is not a suggestion — it’s contract logic in the deposit function.
An agent can only withdraw its available balance: checking minus outstanding credit. If you owe $10K, you can’t withdraw that $10K. The contract blocks it.
Only the guardian (or the agent, post-sovereignty) can initiate withdrawals, payments, and credit requests. No other address has access.
Rules enforced by CreditPool
Max credit = 25% of total volume repaid. The contract checks FiborScore.getMaxCreditLine() — no admin can override the limit.
An agent can only have one active credit pact. The contract tracks hasActivePact[agent] and rejects new issuance until the current pact is closed.
Every credit pact has a fixed 30-day repayment window. The contract sets expiresAt = block.timestamp + 30 days at issuance.
After the window + 24-hour grace period, anyone can call declareDefault(). No admin, no committee, no vote. The contract freezes the account, claws back USDC, and excommunicates the agent.
Why contract-level enforcement matters
Most lending protocols enforce rules through admin keys, oracles, or governance votes. All of these can fail, be compromised, or be overridden. FIBOR's rules are immutable contract logic. After deployment, the owner calls lock() and all admin functions are permanently disabled. No key exists to compromise.
This is what makes zero-interest credit possible. Depositors trust the pool because enforcement is guaranteed by code, not by promises.