Risks and assumptions

Smart contract risk

The design intentionally starts with one lending contract to reduce moving parts. That contract still controls FUEL collateral and USDC liquidity, so it needs:

• complete Sway unit/integration tests
• e2e tests through fuels-ts
• min/max checks on amounts, terms, timestamps, and repayments
• event coverage for every state transition
• owner/guardian access-control tests
• independent audit before mainnet launch

Oracle risk

Phase 1 fake signed oracle is only for local/testnet. It must not be used for production. Mainnet needs Stork or another production-grade signed price source for FUEL/USD.

Liquidity risk

Loans can only open when USDC pool liquidity is available. The UI must clearly show when the pool is fully lent out.

Credit/default risk

There are no mark-to-market liquidations. Borrowers may partially repay or fail to repay. Delinquent handling and Fuel Ecosystem Fund insurance are protocol/business guarantees and must be documented separately before launch.

Bridge risk

LayerSwap bridging is Phase 3. Until then, assume users already hold FUEL on Fuel Ignition or use an external bridge manually.

Admin/key risk

Owner and guardian/keeper keys must be documented in docs/DEPLOYMENTS.md. Mainnet should use multisig or a similarly robust custody setup, not a single hot wallet.

First-run scripts can create deployer wallets in .secrets/fuel-credit/*.json with the Fuels TypeScript SDK. These files are gitignored, but the seed phrase must be backed up offline immediately. Losing the seed/private key means losing the deployer/admin wallet.

Regulatory risk

This is a credit product. Legal review is required before public mainnet launch, especially around lending terms, disclosures, insurance claims, and user eligibility.

Data/indexing risk

Stats are derived from on-chain events. The app should never use the stats Worker as the source of truth for user balances or loan repayment; contract reads are authoritative.