How it works

A liquidation network with no coordinator and no single key.

Stellar DeFi relies on single-operator bots for critical automation. Nectar distributes keeper responsibility across competing operators, funded by one shared vault.

The loop

From deposit to liquidation, end to end

01
Deposit
LPs deposit USDC into the shared vault and receive appreciating LP shares.
02
Monitor
Every keeper independently polls Blend pool positions for health factor < 1.0.
03
Race
On an underwater position, all keepers create & submit fill transactions at once.
04
Settle
First confirmed tx wins. Losers catch ErrAlreadyFilled and log it — no wasted gas spiral.
05
Return
Winner returns 90% of profit to the vault; retains 10%. Share price ticks up.

ARCHITECTURE

SOROBAN TESTNETKeeperRegistryregister(stake)mark_draw / clear_drawrecord_execution()slash(keeper)NectarVaultdeposit / withdrawdraw / return_proceedscap · cooldownshare_price()mark / clearBlend Poolnew_liquidation_auction()submit() — fillget_positions()Dutch · 0–400 ledgersMock Oracleset_price(asset, price)pricesUSDC (SAC)transfer · balancestakeOFF-CHAINKeeper #1 (keeper-alpha)monitor → draw → fill → returnstaked operator · slashableKeeper #2 (keeper-beta)monitor → draw → fill → returnstaked operator · slashable
KeeperRegistry — staking & slashing
Operators register by staking USDC; the registry tracks executions, success rate, and outstanding draws. Slashing transfers a configurable share of the stake to the vault when a draw isn't returned within the timeout.
NectarVault — pooled liquidation capital
Depositors mint shares against pooled USDC. Deposit caps and per-account withdrawal cooldowns protect against capacity attacks; share price reflects accumulated profit. draw() / return_proceeds() cross-call the registry to mark and clear the operator's outstanding draw.
Blend Pool — Dutch auctions
Liquidations run as two-phase Dutch auctions: lot scales 0→100 % over the first 200 ledgers, bid scales 100→0 % over the next 200. Keepers evaluate profitability live and submit a fill when lot/bid crosses their threshold.
Multi-operator race
Both keepers can simulate and submit fills concurrently. One wins; the other receives an AlreadyFilled error, returns the drawn capital to the vault, and logs the loss.

Graceful contention

Two keepers fill. One wins. Nothing breaks.

When a position goes underwater, multiple keepers submit fill transactions simultaneously. The first confirmed transaction wins the auction. The others receive ErrAlreadyFilled and handle it gracefully — logging the miss, returning any drawn capital, and moving on. Redundancy without a coordinator, and without a single point of failure.

auction contention — replay
[keeper-alpha] pos GD7F9…2K1R hf=0.946 — LIQUIDATABLE
[keeper-beta] pos GD7F9…2K1R hf=0.946 — LIQUIDATABLE
[keeper-alpha] creating auction · submitting fill
[keeper-beta] creating auction · submitting fill
[keeper-alpha] filled auction: GD7F9…2K1R
[keeper-beta] already filled by another keeper
[keeper-alpha] returned drawn capital + profit to vault

Vault economics

Profit becomes share price

See it live →
90 / 10 split

Every liquidation returns 90% of realized profit to the vault. The winning keeper keeps 10% as its execution incentive.

One rising price

Profit accrues to a single share price — total_usdc ÷ total_shares. No reward tokens, no emissions, no lockups.

Staked operators

Keepers register on-chain and bond stake. Misbehavior is slashable; the leaderboard ranks by realized profit.

Ready to deposit?

Open the vaultLive dashboard →