💧 SLP Token

What SLP is

SLP (Sivo Liquidity Provider) is the token you receive when you deposit stablecoins into the Sivo protocol. It is a plain, upgradeable ERC-20 on Ethereum with 6 decimals (matching USDC and USDT), ERC-2612 permit support, and no rebasing or on-chain accrual. Each SLP represents a proportional claim on the dollar-equivalent value of the SLP Pool, and its value is expressed by a single number: the SLP/USD net asset value (NAV) published on-chain through a Chainlink price feed.

SLP is a P&L-backed token, similar in design to Hyperliquid's HLP: its NAV reflects the aggregate performance of the pool's activities, net of expenses and any realized losses. It is not a fixed-rate instrument and it is not a stablecoin.

Contract addresses for Sepolia and the full Solidity interface are on the Smart Contracts reference page.

---

What backs SLP

Sivo finances receivables: contractual payment obligations that have already been earned but not yet paid. Sivo purchases these receivables from originators on a true-sale basis (a purchase and assignment, not a loan), so the associated principal, interest, fees, and other contractual cash flows are transferred to Sivo and form the underlying cash flows of the protocol.

The SLP Pool holds:

• Sivo Receivables — short-duration payment rights issued by a Sivo entity (the "Issuer"), each backed by a portfolio of Underlying Receivables purchased from a specific originator or facility. Underlying receivables include gig and creator payouts, payment-processor settlements, marketplace and eCommerce receivables, invoices, subscription receivables, rental payouts, interest and loan payments, settlement receivables, and similar contractual cash flows. Because the underlying receivables are short-dated, they repay and are replaced on a rolling basis, so SLP tracks a constantly refreshing portfolio rather than any specific asset.
• Stablecoin liquidity — USDC and USDT from deposits and collections that has not yet been deployed, held in the protocol contracts or in Sivo's operating accounts, and used to fund redemptions.

Credit protection on the underlying facilities typically includes originator loss reserves that absorb losses ahead of the pool, parent-level guarantees and security packages over the originator's assets, receivable substitution and cure obligations, concentration limits, and — for qualifying facilities — credit insurance. Sivo follows a low-and-grow deployment strategy: exposure to a new originator starts small and grows only as repayment performance is demonstrated. The whitepaper describes the underwriting, monitoring, and protection structure in detail.

SLP holders hold a claim on value, not on specific assets. SLP does not entitle a holder to any specific Sivo Receivable or Underlying Receivable, and it does not create a security interest in, or segregation of, any particular asset. Funds placed into the protocol are not insured by any governmental authority.

Who issues SLP

The Sivo platform, the SLP Pool, and SLP tokens are operated and issued by Sivo Yield Administrator, LLC ("Sivo"), under the Sivo Receivables Purchase and Platform Terms of Service. Sivo operates as part of a group of affiliated entities with distinct functions: one or more affiliates act as the Issuer of Sivo Receivables and purchase the Underlying Receivables from originators, while the SLP Pool acquires Sivo Receivables from the Issuer (or in the secondary market) and does not extend capital to originators directly. The portfolio and liquidity balances backing SLP are independently verified by Accountable.

---

How NAV is computed and published

Computation

The NAV of SLP is the net asset value of the SLP Pool divided by the SLP tokens outstanding:

SLP NAV = (Sivo Receivables at accrued value + stablecoin and other liquid assets − liabilities and accrued expenses) / SLP outstanding

The pool's assets are valued at their accrued value: a Sivo Receivable is carried at cost plus the discount or interest earned to date, and written down for any realized or expected loss. As collections arrive from the underlying obligors and are reinvested into new receivables, NAV increases; expenses and realized losses reduce it. Because SLP tracks the pool's overall P&L, returns are variable, not fixed. Portfolio balances, collections, and NAV inputs are reported to Accountable, which independently verifies them; the verified data is published at transparency.sivo.xyz.

SLP has no on-chain accrual logic and never rebases. All value appreciation is expressed solely through the published NAV, so the number of SLP in your wallet stays constant while the value of each SLP changes.

Publishing to the on-chain feed

NAV is published on Ethereum through the Chainlink SLP/USD Data Feed (AggregatorV3Interface, 8 decimals, description SLP / USD Exchange Rate) at 0x0e095dD47bdE0d7cdb57a72bB98B6419dfBB505b. Any contract or indexer that already consumes Chainlink feeds can read it with latestRoundData(); historical rounds remain queryable via getRoundData(roundId).

• Data flow — Sivo and its connected financial data sources report portfolio balances, collections, and liquidity to Accountable, which independently verifies them before the NAV is published on-chain through Chainlink's oracle infrastructure. The on-chain value is therefore independently checked rather than self-reported by Sivo, and Sivo's own keys do not sign the price. The same verified data is visible at transparency.sivo.xyz.
• Cadence — the NAV is a daily value; the feed updates on Chainlink's schedule for this feed, so consecutive rounds normally reflect one NAV per day.
• Fail-closed consumption — the deposit and withdrawal contract enforces a maximum staleness of 90,000 seconds (25 hours) and a sanity band on the NAV (currently 0.90–1.50 USD per SLP), and rejects incomplete rounds. If the feed is not updated within the window, or the answer falls outside the band, deposits and withdrawal fills halt rather than clearing at a stale or implausible price. The band is ratcheted upward around the drifting NAV by the MANAGER multisig via setOracle.
• Legacy feed (deprecated) — the initial mainnet release was priced by SlpOracle (0xd346…6B26), an operator-published Chainlink-compatible feed. With the Chainlink feed live, the protocol was re-pointed atomically via setOracle; SlpOracle is no longer read by the protocol and is abandoned in place, with its past rounds still queryable for history. Integrators should read the live feed address from UniswapHook.oracle() rather than hard-coding either address.

---

Deposits

Deposits are instant and always clear at the exact published NAV — there is no bonding curve, no slippage, and no spread. There are two equivalent paths:

1. Uniswap v4 swap — swap USDC or USDT for SLP through any Uniswap router or aggregator. The SLP/USDC and SLP/USDT pools are ordinary Uniswap v4 pools, but they hold zero curve liquidity: Sivo's hook absorbs every swap in beforeSwap and mints fresh SLP at the oracle NAV. Exact-input and exact-output swaps are both supported. Only the stablecoin → SLP direction is a swap; SLP → stablecoin reverts and must use the withdrawal queue.
2. Direct deposit(asset, assets, receiver) on the UniswapHook — economically identical to the swap: approve the stablecoin, call deposit, receive SLP at the same oracle read. This is the path the sivo.xyz app uses.

Rounding always favors the pool (SLP out rounds down, stablecoin in rounds up). Deposits are blocked while the protocol is paused, while the NAV feed is stale or out of band, or while the deposited stablecoin's own Chainlink USD feed is outside its peg band of 0.995–1.005. maxDeposit(asset) returns 0 whenever deposits for that asset are currently blocked, so integrators can check before routing.

Deposited stablecoin accumulates in the hook and is swept by Sivo operators into receivables deployment, except for the portion reserved for filled-but-unclaimed withdrawals, which can never be swept.

---

Withdrawals

Exits use an asynchronous FIFO queue, one per stablecoin, that mirrors the ERC-7540 request → claimable → claim lifecycle:

1. Request — call requestWithdraw(asset, shares). Your SLP is pulled into the hook and a queue entry is appended. Minimum request: 1 SLP (minRequestShares = 1,000,000 in 6-decimal units). No price is locked at request time.
2. Fill — requests are filled strictly in order from the hook's free stablecoin at the NAV current at fill time. The filled SLP is burned and the stablecoin is moved into a claim reserve that can never be swept. Partial fills are supported and each filled portion locks its price. Fills happen three ways:
   • automatically inside every deposit — each deposit fills up to 5 queue entries from the inbound stablecoin, so while deposits are flowing the queue drains permissionlessly;
   • operator fill — Sivo operators fill from stablecoin already held by the hook;
   • operator replenish — Sivo operators return stablecoin from receivables collections and fill the queue with it.
3. Claim — call claimWithdraw(asset, receiver) to receive your full claimable balance. Claims are deliberately not gated on oracle health: the redemption price was fixed when the request was filled.

You can cancel any unfilled request at any time with cancelWithdraw (newest-first, so older requests keep their FIFO priority) or cancelWithdrawByIds, and you can delegate cancels and claims to another address with setOperator. Your position is visible on-chain via pendingWithdraw(asset, you) and claimableWithdraw(asset, you); the queue depth is totalPendingShares(asset).

Expected settlement time

Redemptions are funded first from the pool's available stablecoin liquidity, which comes from new deposits and from collections on the underlying receivables. While available liquidity covers the queue, requests are typically filled within the same transaction as the next deposit or on the operator's next routine fill, and are claimable as soon as the fill transaction confirms. Available liquidity is not fixed; it varies with deposit and redemption flows, collections, and deployment activity.

If redemption demand exceeds available liquidity, Sivo replenishes the queue as the short-duration underlying receivables collect and, where needed, by selling Sivo Receivables through Sivo's marketplace. In that case fills take longer while those collections and sales settle. Sivo does not guarantee redemption within any specific timeframe; see Terms of Service §9.

---

Fees

• No protocol fee on deposits, swaps, or withdrawals. Both Uniswap v4 pools are configured with a 0 fee tier, and the hook charges nothing on deposit, requestWithdraw, fill, or claimWithdraw. You receive SLP at exactly the published NAV and redeem at exactly the NAV at fill time (subject to protocol-favoring rounding at the last decimal).
• Gas — you pay Ethereum network fees for your own transactions. Fills performed inside someone else's deposit or by Sivo operators cost you nothing.
• Pool-level economics — the NAV is reported net of the pool's operating expenses and any realized losses; there is no separate management or performance fee deducted from your balance. Sivo may introduce fees prospectively and will disclose them on the platform or in the applicable documentation before you incur them (Terms §12).
• Third-party venues — vaults, aggregators, and lending markets that wrap or route to SLP set their own fees, which Sivo does not control.

---

Risk disclosures

Participation involves risk and losses may occur. Key risks include:

• Credit and originator risk. SLP's value ultimately depends on originators and obligors meeting their payment obligations. Financial distress, operational failure, fraud, or deterioration in portfolio performance can produce losses that reduce NAV. Loss reserves, guarantees, and insurance reduce but do not eliminate this risk; insurance is subject to policy limits, exclusions, and insurer performance.
• Liquidity and redemption-timing risk. Withdrawals are queued, not instant. Fills depend on available stablecoin liquidity, receivable collections, and operator replenishment; during stress they may take materially longer, and Sivo does not guarantee redemption within any timeframe. Secondary-market liquidity for SLP, where it exists, may be thin and trade below NAV.
• Oracle risk. Every deposit and fill clears at the published NAV. The NAV is published through a Chainlink feed from data independently verified by Accountable, but the inputs originate from Sivo's books and off-chain systems; an incorrect, delayed, or manipulated NAV would misprice deposits or redemptions. The protocol mitigates this with staleness and sanity-band gates that halt activity rather than clear at a bad price.
• Stablecoin risk. Deposits and fills value USDC and USDT at par and halt if either stablecoin's own Chainlink feed leaves its 0.995–1.005 peg band. A depeg outside the band blocks activity in that asset; movement inside the band is borne by the pool.
• Smart contract and upgrade risk. The SLP token and hook are UUPS-upgradeable proxies. Upgrades, oracle configuration, and pausing are controlled by Safe 2-of-3 multisigs, with on-chain timelocks being rolled out in phases (see Access control). The contracts were audited by CredShields (August 2026, no critical or high findings; all medium and low findings remediated), but bugs may remain.
• Centralization and counterparty risk. Deposited stablecoin is swept by Sivo into off-chain receivables deployment; SLP is a claim on the value of the SLP Pool, operated by Sivo Yield Administrator, LLC, not on segregated on-chain collateral. Holders rely on Sivo's operations, record-keeping, and solvency. Funds are not bank deposits and are not insured by any governmental authority.
• Leverage risk. Third-party protocols may allow SLP to be used as loan collateral ("looping"). Leverage amplifies both gains and losses and can lead to liquidation under the third party's parameters, which Sivo does not control.
• Regulatory risk. The platform is not available in sanctioned or restricted jurisdictions and is subject to evolving regulation that could affect the protocol or holders' ability to use it.

Past performance, collection history, reserve levels, or historical returns do not guarantee future results. The full risk statement is in the Terms of Service §13. For the underwriting framework, protection layers, and Key Risks in detail, read the whitepaper.

---

Further reading

• Smart Contracts reference — full interface, events, access roles, and Sepolia addresses
• holasivo/slp-evm — contract source, deployment parameters, and audits
• Whitepaper · Terms of Service · Transparency dashboard
• Questions: Discord · X · [email protected]