Liquidium

Rejected venues wait the longest for re-review; a rejection has to earn another look before the scheduled date.

Liquidium is a cross-chain lending protocol built on Internet Computer canisters. Users may enter and exit through native Bitcoin or Ethereum addresses, but the lending orchestrator, pooled share and debt accounting, health checks, ckAsset pools, liquidation coordination and asynchronous withdrawal log execute on ICP. The 2026-08-15 endpoint reported about $3.81M and attributes the protocol to ICP. That settlement and control dependency makes the v1 rejected-chain disposition more fundamental than size.

Kill criteria: the events that revoke this verdict
• Deploys an independently underwritable lending control and accounting plane on a chain the registry approves
• The ICP chain verdict changes

The research file

Mechanism and chain applicability

Liquidium describes a pooled cross-chain lending system built on Internet Computer. A lending canister tracks supply shares, debt shares, health factors, interest and liquidations, while BTC, ERC and ICP pool canisters custody chain-key assets and execute deposits, borrows, repayments and withdrawals. Native-chain UX does not move the protocol accounting or control plane off ICP.

Current observation and perimeter

The DefiLlama protocol API read on 2026-08-15 classified Liquidium as Lending, reported approximately $3.81M and listed ICP. Current technical documentation says Liquidium is built on IC and that all supported routes feed common canister pools. BTC, ETH and stablecoin transfers use their native chains at the edges, but ckAsset minting, canister accounting and the single health factor remain ICP dependencies.

Control, loss and exit applicability

The lending canister validates caps, prices and health, coordinates liquidations and schedules asynchronous pool operations. Withdrawals burn supply shares, then rely on a write-ahead log, pool canister and chain-key minter or ICP ledger; insufficient liquidity causes retries. A native-chain transaction can therefore be confirmed while Liquidium finalization remains pending, making ICP availability and canister correctness inseparable from ordinary exit.

Why the shared dossier decides

The v1 rejected-chain disposition controls because the investable lending state is orchestrated on ICP even when a user supplies or receives a native external-chain asset. This does not allege that chain-key cryptography or Liquidium contracts are defective. Reopen if ICP passes the chain framework or Liquidium establishes an independently underwritable approved-chain control plane; then review each pool, canister roles, oracle, liquidations, audits, bad debt and proposed-size withdrawal.

Sources

The claims above trace to these. Where a number could not be independently verified, the thesis says so.

• Liquidium — protocol overview · primary · accessed 2026-08-15
  Supports: built on Internet Computer, cross-chain lending, suppliers, borrowers, canister contracts
• Liquidium — technical architecture · primary · accessed 2026-08-15
  Supports: IC canisters, lending orchestrator, BTC pool, ERC pool, share accounting
• Liquidium — lending canister · primary · accessed 2026-08-15
  Supports: positions, health factor, interest, liquidation API, pool coordination
• Liquidium — cross-chain flow and ckAssets · primary · accessed 2026-08-15
  Supports: ICP chain key, ckAsset pools, native-chain routes, single health factor, liquidations
• Liquidium — withdrawal execution · primary · accessed 2026-08-15
  Supports: share burn, write-ahead log, insufficient liquidity, retries, native outflow
• DefiLlama — Liquidium survey record · secondary · accessed 2026-08-15
  Supports: current TVL, ICP perimeter, Lending category, survey observation

Inherited controls

The verdict above grades the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The least safe layer sets the position’s grade, and the position table names which one that is.