Protocol control structure

Fuel Credit separates administrative authority, price signing, and permissionless protocol actions. No single role can rewrite loan terms or bypass contract accounting.

V10 replaces V9's immediate owner transfer with owner proposal, exact-nominee acceptance, and owner cancellation. Proposal grants no authority. V10 also preserves borrower-claimable pro-rata collateral as a liability after partial-loan finalization; neither owner nor manager may withdraw or deploy it. V9 retains its deployed legacy rules.

Control map

Capability	Who can act	Contract guard
Add FUEL or USDC liquidity	Any wallet	Only configured assets and positive amounts are accepted
Open a loan	Any borrower	Valid current price attestation, supported term, exact FUEL payment, and sufficient USDC liquidity
Repay a loan	Its borrower	Active loan, USDC payment, and strictly before maturity; collateral remains locked
Claim collateral	Its borrower	At/after maturity: full V10 share after repayment or finalized pro-rata share; not previously claimed
Finalize a matured loan	Any wallet or bot	Active loan and timestamp at or after maturity; no grace/cure period
Withdraw idle pool funds	Current owner	Cannot withdraw locked borrower collateral or unavailable balances
Propose/cancel V10 ownership transfer	Current owner	Nominee must be nonzero and different; proposal grants no authority
Accept V10 ownership	Exact pending nominee	Pending proposal must exist
Replace the price oracle	Current owner	New address must be nonzero and different
Sign FUEL prices	Current price oracle	Attestation is domain-, chain-, contract-, price-, and timestamp-bound

Owner

INITIAL_OWNER sets the owner at deployment. Thereafter, owner() is authoritative.

The current V10 owner can:

• withdraw only idle supported assets;
• propose or cancel ownership transfer with propose_ownership(new_owner) and cancel_ownership_transfer();
• replace the validated rolling oracle with set_oracle(new_oracle); and
• manage manager proposals and the strategy allowlist.

Only the pending nominee can complete ownership transfer with accept_ownership(). Deployed V9 retains its immediate transfer_ownership(new_owner) behavior.

The owner cannot:

• modify existing loan terms;
• withdraw locked borrower collateral;
• repay a borrower's loan, claim a borrower's fully repaid collateral, or seize an active loan early;
• mark a loan delinquent before maturity;
• bypass asset, balance, status, or accounting checks.

A V10 ownership proposal does not change authority. Transfer takes effect only when the exact nominee accepts; the former owner then loses all owner authority immediately. V9 transfer remains immediate.

Owner administration page

The unlinked /admin route reads authoritative contract balances, pool statistics, immutable asset IDs, owner, oracle signer, and chain ID on testnet or mainnet. It also checks the selected network's oracle service.

Administrative controls appear according to authoritative V10 owner(), pending_owner(), and manager() reads. Wallet-confirmed actions can fund assets, withdraw only contract-reported available liquidity, rotate the oracle, propose/cancel ownership, or let the exact nominee accept. The contract remains the security boundary: hiding the route is convenience, not authorization. Confirmed transactions trigger a fresh onchain read.

The page never receives deployment or oracle private keys. Rotating the onchain signer does not configure the corresponding Worker.

Price oracle

INITIAL_PRICE_ORACLE sets the first signer. Thereafter, price_oracle() is authoritative.

The oracle signs only a current FUEL price and timestamp. It does not choose the borrower, collateral amount, term, LTV, principal, fee, maturity, or repayment rules; the contract computes and enforces those values.

The oracle key does not need transaction funds because signing occurs offchain. If the key is lost or compromised, the current owner can replace it. Old-key signatures stop verifying immediately after rotation, including otherwise-unexpired attestations.

/v1/health exposes bounded monitoring state: selected source, market and signature age, last attempt, consecutive failures, and a sanitized failure category. Refreshes emit structured success/failure logs. Three consecutive failures make health return 503. The mainnet monitoring Worker uses a secret TELEGRAM_BOT_TOKEN and non-secret numeric TELEGRAM_CHAT_ID configuration to send sanitized failure alerts at three failures and every tenth failure thereafter, plus a combined testnet/mainnet health report every twelve hours. Reports contain no keys, addresses, raw errors, or transaction data. Refresh and reporting execute independently, and health includes bounded report configuration, attempt, delivery-age, and failure-category state.

Permissionless actions

Pool funding and matured-loan finalization do not require a privileged wallet. This allows independent liquidity providers and automation bots to participate without receiving administrative authority. All callers pass the same contract checks.

Recovery boundaries

Loss scenario	Recovery path
Oracle key lost or compromised	Owner rotates to a new oracle address
Owner key lost	No onchain recovery unless ownership was transferred beforehand
Both keys lost	No privileged recovery path
Indexer or application unavailable	Contract state and direct contract calls remain authoritative

Owner and oracle keys must remain separate, with encrypted offline recovery backups. A production owner should use custody appropriate for its withdrawal and rotation authority.

Deployment and verification

Deployment tooling records the initial owner and oracle. Because both can change, deployment files are historical configuration—not proof of current authority. Verify live control with:

owner()
price_oracle()

The release build is deployed on testnet; owner() and price_oracle() were verified after deployment. Valueless testnet pools have been funded for lifecycle validation and mainnet remains gated by the prerequisites listed in Deployments.