XOXNO Lending is a collateralized lending protocol on Stellar Soroban. Suppliers earn interest on borrowed liquidity, and borrowers hold debt against supplied collateral. Each lending account is tokenized as a position NFT, markets are grouped into isolated hubs with per-spoke risk configuration, and a controller enforces account health while a central pool custodies all tokens and tracks market accounting.
PoC Required
KYC required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Permanent freezing of funds
Protocol insolvency
Theft of unclaimed yield
Permanent freezing of unclaimed yield
Temporary freezing of funds
Smart contract unable to operate due to lack of token funds
Out of scope
This program covers the XOXNO Lending smart contracts on Stellar Soroban mainnet. A valid report shows a concrete deviation from a protocol invariant, an authorization boundary, an accounting rule, a price guarantee or a liveness property. A report that restates a documented design choice is closed without a reward.
Out of scope
- Bugs in the Stellar network, the Soroban host, the Rust toolchain, upstream crates, or third-party providers (Reflector, RedStone, DeFindex, Blend, swap venues, listed token contracts). Report those to their maintainers. How XOXNO Lending validates a response from one of them is in scope.
- Any scenario that requires a compromised governance key, role key, oracle signer key or keeper key, unless the report shows that the protocol makes the consequences of that compromise materially worse.
- Impact reachable only through the documented administration path: typed proposals, the configured execution delay, guardian pause, oracle sanity-band tightening or hot-role revocation.
- Loss caused by the behaviour of a listed token itself, including sender surcharges, fee-on-transfer, rebases, false balances, clawbacks, freezes, admin mint or post-listing upgrades. Admitting a token is a governance decision.
- Swap route quality, slippage, price impact, MEV and router fee outcomes. The controller checks positive measured output and final account health, not route optimality.
- Oracle prices that pass the configured sanity bands, source count and staleness limits. Manipulation of an external feed within those bands is a trust assumption of that provider.
- An operation that fails closed, or that is blocked by global pause, a listing flag, a cash shortage, storage archival or TTL expiry, or a Soroban CPU, memory or footprint budget.
- Deployments other than Stellar mainnet, and repository paths that are not deployable contracts: mock/, tests/, certora/, vendor/, scripts/, services/ and docs/. An issue there qualifies only when it reaches a production build.
- Web and application surfaces: the xoxno.com frontend, the REST API, the TypeScript SDK, the keeper and exporter services, and hosting, DNS, email or cloud infrastructure. This program is smart contract only.
- Governance parameter values as such, including listings, loan-to-value weights, liquidation thresholds, bonuses, caps, fees and feed selection. Logic that lets a parameter violate an invariant is in scope.
- Centralisation observations with no exploitable path. An owner or address gate is a source boundary, not a claim of multisig custody or a timelock.
- Scanner output, lint findings, missing events, fee optimisation, code style and documentation defects with no security consequence.
Known design choices. Do not report these
The behaviours below are deliberate, documented and covered by tests. Each one is recorded as a decision record in docs/explanation/decisions.md. A report that describes one of them as a vulnerability is closed as a non-issue unless it demonstrates a concrete invariant violation that the record does not already accept.
- Directed rounding (ADR-0003). Supply mints floor shares, withdrawal burns ceiling shares, borrowing mints ceiling debt and partial repayment burns floor debt. Single-unit rounding always favours the protocol. Only accumulated drift that breaks a stated accounting invariant is a finding.
- Supplier-index loss allocation (ADR-0012). Eligible bad debt is written down by reducing the affected market's supply index above a nonzero floor, so suppliers in that market bear the loss. A supplier who exits before the write-down avoids it, and a displayed claim is not a guarantee that the amount can be withdrawn.
- Gross-debt cleanup accounting (ADR-0021). Cleanup converts remaining account supply to protocol revenue and then socializes gross debt, without first netting supply against debt in the same market.
- Immutable spoke binding (ADR-0009). An account keeps its spoke for its whole lifetime. Governance can change listings and refresh applicable stored risk values, but cannot rebind an account to another risk regime.
- Central custody with separate market books (ADR-0002). One pool holds every token. The same token listed in several hubs keeps separate books while sharing one physical balance and one set of token risks.
- Credit measured receipts (ADR-0013). Credited amounts are the amounts actually received, not the amounts requested, and under-delivered liquidation repayment reduces the associated seizure. Direct donations do not rewrite market books.
- Fail-closed valuation (ADR-0005) and dual-source agreement (ADR-0004). A required price that is missing, stale, out of band or in disagreement aborts the operation. Where two sources are configured, one usable source never substitutes for a failed source.
- Liquidation share credit (ADR-0019). Liquidation may credit an authorized receiver in the same spoke instead of paying collateral out. The supply entry gate is deliberately bypassed for credited positions because value is moved rather than created, and the protocol fee is reclassified rather than minted.
- Zero-fee flash position (ADR-0020). flash_position creates debt with no origination fee, unlike multiply. It is an authorized borrowing strategy, not a free flash round trip, and returned debt is never automatically repaid.
- Literal asset-unit caps (ADR-0015). Caps are asset units converted at the applicable index. Exits do not release headroom, and same-spoke liquidation credit does not require new supply-cap headroom.
- Millisecond rates and chunked accrual (ADR-0016). Rates are RAY per millisecond and accrual is divided into bounded chunks, each using the preceding chunk's market state. Cadence dependence and bounded rounding error are expected consequences.
- Independent halt flags (ADR-0008) and the emergency ratchet (ADR-0007). Global pause preserves designated exit and recovery entrypoints, listing flags separately control entry, exit and seizure, and a sanity band may only be tightened.
- is_collateralizable is an entry gate only. Clearing the flag blocks new supply of that asset but deliberately does not strip collateral value from existing or credited positions, which is a soft wind-down. To remove borrowing power, governance sets the loan-to-value weight to zero.
- Account authority is the position NFT. The account id equals the NFT token id and the NFT owner controls the whole account. A registered delegate has complete economic control, including borrowing and withdrawing to an arbitrary address. This is the documented authority model.
- Full-close liquidation fallback. Once collateral is worth less than debt, no liquidation can raise the health factor, so the protocol falls back to a full close at the base bonus. The absence of a post-liquidation health-factor improvement guard is deliberate: such a guard would block liquidation of unrecoverable positions and let debt compound.
- Solvency and liquidity are separate. A healthy account that cannot borrow or withdraw because its market holds no available cash is behaving as designed.
Smart Contract specific
- Incorrect data supplied by third party oracles
- Not to exclude oracle manipulation/flash loan attacks
- Impacts requiring basic economic and governance attacks (e.g. 51% attack)
- Lack of liquidity impacts
- Impacts from Sybil attacks
- Impacts involving centralization risks
All categories
- Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed
- Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
- Best practice recommendations
- Feature requests
- Impacts on test files and configuration files unless stated otherwise in the bug bounty program
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers


