FAQ

On a concentrated liquidity venue only the bin holding the current price earns anything. Every other bin you funded holds real capital that earns nothing until the price arrives. Juncta lends that capital into a money market that shares the same pool and the same ledger, so one deposit earns trading fees while its bin is active and lending interest while it is not.

No. Reclassifying a bin between trading and lending is a change of accounting rather than a transfer. Nothing is wrapped, no receipt token is issued, and no outside contract sits in the path.

A bin near the current price is likely to be needed for a trade soon, so little of it is lent and whoever borrows it pays the most. A bin far away is unlikely to be reached, so most of it is lent at the base rate. Deployment rises with distance and the premium falls, because the two price opposite sides of the same fact.

Less than all of it, by construction. The bins nearest the price are never lent, and even the furthest tier keeps a fifth back as instant reserve. A realistic position lands well short of the ceiling, and the comparison that matters is against a conventional venue, where only the active bin earns at all.

No, and this is the most important thing to understand before depositing rather than after. Because provided liquidity is the lending supply, withdrawal is gated by utilization. Below eighty percent it is immediate from the instant reserve. Between eighty and ninety it tapers, part immediate and part queued. Above ninety it queues until the specific bins backing it are repaid. A queued position keeps earning while it waits.

Not necessarily. Supply and utilization are genuinely shared across every pool holding an asset, but recall is cleared against the specific bins your withdrawal draws on. Two providers in identical circumstances can wait different lengths of time. We say so rather than presenting a queue position, because under bin-scoped clearing there is no single queue to hold a position in.

Liquidation proceeds in five levels. Each closes only the minimum needed to restore a target health factor, at a cost that rises with severity, with recovery windows in between so a borrower can add collateral or repay. It is a trim and a chance to recover rather than a single close-out.

It can only be pledged for the part that was never lent. That restriction is what keeps each dollar backing exactly one claim, and it means anything a liquidator is entitled to seize is already sitting in the pool rather than outstanding with a borrower. The cost is borrowing capacity on a heavily deployed pool, and a provider who wants more of it can move part of their position out of deployment.

The protocol runs on Solana devnet. Mainnet follows the audit.

Not yet. Nothing on this site should be read as implying otherwise, and the figures shown in terminal screenshots are sample data rather than a live balance sheet.

Solana. The design assumes one execution environment, and the sharding that keeps pools from serializing behind a single account is a response to that specific concurrency model, so a second deployment would be a separate instance rather than a port.

The whitepaper carries the mechanism, the solvency result and its proof, and the liquidation schedule. The documentation carries parameters and interfaces.