System Architecture

This page describes the technical architecture of appeX: how the onchain and offchain layers interact, what each smart contract does, and how capital flows through the system.

Architecture Overview

appeX operates as a two-layer system. The onchain layer is permissionless and handles capital. The offchain layer is permissioned and handles credit decisions. This separation lets each layer do what it does best: smart contracts manage money with verifiable logic, while the offchain layer handles business relationships that require human judgment.

LPs interact only with the onchain layer. Borrowers interact with both. The diagram above shows where each participant connects and how the two layers communicate.

Layer A: Onchain Permissionless

The onchain vault is the liquidity engine interfacing with capital providers. All operations are executed by smart contracts onchain.

Onchain operations include:

• LP deposits and redemptions with continuous NAV pricing
• LP token minting and burning
• NAV calculations with fine-grained accrual (granularity can be daily, hourly, or per-second depending on implementation)
• $APPEX staking with cap enforcement and duration multipliers
• DEX integration for $APPEX purchases during payout distribution and fee conversion
• DeFi deployment of unborrowed capital to Aave and Compound for continuous yield

Every onchain operation is verifiable. LPs can inspect vault state, NAV calculations, and fee distributions directly onchain.

Layer B: Offchain Permissioned

The offchain layer manages everything the blockchain should not: business relationships, credit underwriting, and fiat operations.

This layer is where trust is required. The appeX team evaluates borrower creditworthiness, sets borrowing limits, and monitors repayment performance. These are human judgments that cannot be reduced to smart contract logic. The offchain layer represents the primary centralization point in the protocol, and users should understand this boundary. See Risk Framework for a complete analysis.

Separation of Concerns

This separation is deliberate and protects both sides.

• LPs face only the vault. Deposit USDC, receive LP tokens, redeem shares for USDC. No exposure to individual receivables or borrower operations. No need to evaluate downstream counterparties.
• The vault faces the borrowers. Each borrower is responsible for repaying principal plus fees regardless of downstream outcomes. If a borrower's customer defaults on an invoice, the borrower still owes the vault. This insulates LPs from individual receivable risk.

Capital Flow

Capital moves through the vault in three distinct operations: deposits from LPs, advances to borrowers, and repayments back to the vault. Each flow is detailed below.

Deposit Flow

1. LP connects wallet and specifies USDC amount
2. Vault executes internal NAV refresh to ensure current pricing
3. Share price calculated as NAV / Total Shares Outstanding
4. LP tokens minted at current share price (Shares = Deposit / Share Price)
5. USDC enters the vault and is deployed to DeFi lending protocols until needed for borrower advances

Advance Flow

1. Approved borrower requests capital draw within their approved limit
2. Offchain verification confirms that underlying value has been delivered (impressions served, goods shipped, services completed)
3. USDC released from vault to borrower
4. Borrower deploys capital according to their business needs (instant payouts, supplier payments, growth capital)
5. Advance is recorded with principal, LP yield fee, expected repayment date, and associated protocol fee

Repayment Flow

1. Borrower's customer pays on original terms (Net-30 to Net-180)
2. Borrower repays vault: principal + LP yield fee in USDC
3. Borrower pays protocol fee in USDC or $APPEX (25% discount for $APPEX)
4. LP yield fee is realized in vault NAV (it was already accruing incrementally during the term)
5. Protocol fee splits 50/50. Treasury receives one half. The other half purchases $APPEX on a DEX (or receives $APPEX directly if paid in tokens) and distributes to stakers.
6. Repaid capital becomes available for new advances. The cycle repeats.

DeFi Capital Deployment

There is no idle capital in the vault. All USDC not locked in active borrower advances is deployed to established DeFi lending protocols:

• Aave - Variable-rate lending
• Compound - Algorithmic money market

Capital exists in exactly two states: active advances (locked until the borrower repays) or DeFi-deployed (liquid, withdrawable instantly). LP redemptions are funded by withdrawing from DeFi positions. The only constraint on redemption capacity is capital locked in active advances. Only established, audited protocols with deep liquidity and multi-year track records are approved for deployment.

NAV Calculation

The vault's Net Asset Value determines LP token price and is the single source of truth for vault economics.

NAV = USDC_DeFi + USDC_lent + Accrued_Fees + DeFi_Yield_Accrued - Bad_Debt_Reserve

Accrual Mechanics

Yield is not recognized only when cash arrives. Instead, fees accrue incrementally over the contractual term of each advance. This is a critical design choice for fair LP treatment.

For a $100 advance with a $10 fee over 30 days:

This prevents a known vulnerability: late-entering LPs capturing yield they did not earn. By Day 20, $6.67 of the fee is already reflected in NAV. A new LP depositing on Day 20 buys shares at the higher price and only benefits from the remaining $3.33.

The vault uses aggregate fee-rate math to keep NAV updates computationally efficient. Accrued fees are calculated based on the total fee rate across all active advances multiplied by elapsed time since the last refresh. This approach enables per-interaction NAV accuracy without significant overhead.

NAV Update Triggers

NAV is effectively continuous but only materialized when needed:

• Deposits and Redemptions - NAV is refreshed before pricing shares. Users always transact against current state, not stale data.
• Permissionless Refresh - NAV can be refreshed at any time to support secondary market price discovery and UI accuracy.

Warning: NAV reflects accrued yield, not guaranteed yield. If a borrower defaults, the affected portion of accrued yield may be reversed. See Risk Framework for default handling procedures.