{
let lastTxHash = "";
for (const call of calls) {
const tx = await signer.sendTransaction({
to: call.to,
data: call.data,
value: call.value || "0",
});
const receipt = await tx.wait();
if (!receipt || receipt.status !== 1) throw new Error(`Tx reverted: ${tx.hash}`);
lastTxHash = tx.hash;
}
return lastTxHash;
}
async function optimizeYield(
account: string,
currentPosition: VaultPosition,
signer: any
) {
// 1. Check health factor
const info = await getCreditInfo(account);
const hf = parseFloat(info.data.USDC.healthFactor);
if (hf < MIN_HEALTH_FACTOR) {
console.log(`Health factor ${hf.toFixed(2)} too low to rebalance — skipping`);
return;
}
// 2. Get available strategies from protocol config
const config = await getProtocolConfig();
const strategies = config.strategies ?? [];
// 3. Find the best vault by yield
const bestVault = strategies
.filter((s: any) => s.id !== currentPosition.strategy)
.sort((a: any, b: any) => b.apy - a.apy)[0];
if (!bestVault) {
console.log("No alternative vaults available");
return;
}
const improvement = bestVault.apy - currentPosition.apy;
if (improvement < MIN_YIELD_IMPROVEMENT) {
console.log(
`Best alternative: ${bestVault.apy}% APY (+${improvement.toFixed(2)}%) — below threshold`
);
return;
}
console.log(
`Rebalancing: ${currentPosition.apy}% → ${bestVault.apy}% APY (+${improvement.toFixed(2)}%)`
);
// 4. Unlock from current vault
const unlockCalls = await buildUnlockCalls(
account,
currentPosition.amount,
currentPosition.asset
);
const unlockTx = await executeCalls(unlockCalls, signer);
console.log(`Unlocked from ${currentPosition.strategy}: ${unlockTx}`);
// 5. Lock into new vault with earn param
const lockCalls = await buildLockCalls(
account,
currentPosition.amount,
currentPosition.asset,
bestVault.id
);
const lockTx = await executeCalls(lockCalls, signer);
console.log(`Locked into ${bestVault.id}: ${lockTx}`);
}
// Run the optimizer loop
setInterval(() => {
const currentPosition: VaultPosition = {
strategy: "CURRENT_STRATEGY_ID",
amount: "1000000000000000000",
asset: "0xCOLLATERAL_TOKEN",
apy: 4.2,
};
optimizeYield("0xUSER_ADDRESS", currentPosition, signer).catch(console.error);
}, POLL_INTERVAL_MS);
```
## Configuration
Default: every 1 hour. Vault yields change slowly, so frequent polling isn't necessary. Hourly checks balance responsiveness with API usage.
Default: 1.5. Higher than the health monitor threshold (1.3) because rebalancing temporarily changes collateral composition. The extra buffer prevents accidental liquidation during the unwrap/wrap window.
Default: 0.5% APY. The agent only rebalances if the improvement exceeds this threshold. This prevents excessive on-chain transactions for marginal gains — each rebalance costs gas.
## Supported Vaults
The agent can rebalance between any earn strategies returned by the protocol config:
```bash theme={null}
curl -X GET https://api.sprinter.tech/credit/protocol
```
The `strategies` field in the response contains available earn vaults with their IDs — use these as the `earn` param when calling `/lock`.
See [Risk Management](/sprinter-credit/risk-management) for the full collateral tier table and LTV details per vault type.
## Related
How collateral value and LTVs affect your credit line.
Pair with the health monitor to protect positions during rebalancing.
Earn vault wrap/unwrap endpoints with interactive playground.
# Asset Issuer Integration
Source: https://docs.sprinter.tech/quickstart/asset-issuer
Onboard a T+X asset with Sprinter, then offer instant redemptions and subscriptions on it
## Overview
If you issue an asset that settles on a delay — a tokenized treasury, a bond fund, a yield-bearing stablecoin, a structured vault — Sprinter can front the liquidity so your holders enter and exit instantly, while the underlying settles on your own rail in the background.
Most tokenized assets share the same friction in both directions. A holder who wants out waits for your redemption rail — T+1 for a tokenized treasury, T+4 for a bond fund, T+30 for some structured products — or takes a discount on a thin secondary market. A holder who wants in, especially from another chain, waits for settlement before the position exists. Sprinter closes both gaps.
The credit is repaid by the settlement itself — your redemption or subscription mechanism — not by liquidating the asset. That is why it needs almost no collateral, and why the price is a function of **how long the rail takes**, not of how volatile the asset is.
### Why issuers integrate
* **No idle redemption buffer.** Instead of parking 3–10% of TVL to fund instant exits, outsource that function. Capital that would otherwise sit idle on your balance sheet earns yield in ours.
* **Instant on both sides.** Exits settle immediately in USDC; crosschain deposits credit the position immediately while settlement completes behind it.
* **Works on any settlement path.** Yield-bearing stablecoins, tokenized treasuries and funds, structured and tranched products, RWA-backed tokens. If it has a defined settlement path and a measurable delay, we can front it.
* **Crosschain by default.** Sprinter's solver network services deposits and exits across supported networks, so a holder on one chain can enter or exit a position on another.
* **Optional par experience.** By default Sprinter earns a spread on each fill. Issuers who want a frictionless experience can subsidise that spread so the end user transacts at par — $10 exited returns $10, with no visible fee. The financing cost shifts from the user to you, as a UX and acquisition investment.
Your tokenized asset is onboarded first. Sprinter quotes only assets it has underwritten, allocated liquidity to and configured routes for, so onboarding is step 1 and the runtime calls follow from there.
Two paths. The flow described here draws on **shared liquidity** and gets you live without a commercial agreement. A **dedicated facility** commits capacity to your flow and is agreed commercially — see [Pricing & Credit Facilities](/pricing) for both, and what a fill costs.
The sequence is one onboarding phase, then three runtime steps per redemption:
1. **Onboard the asset** — one time. Underwriting, liquidity allocation, route configuration
2. **Quote** — ask Sprinter what it will pay for the position. Liquidity is reserved against the answer
3. **Open the order** — hand the quote back and get a transaction to send
4. **Settle** — Sprinter fills instantly; you settle the underlying on your rail
***
## Step 1 — Onboard the asset
This is a joint process, not a self-serve API call. Sprinter has to understand the settlement path before it will lend against it, then commit capital and wire up routing. The assessment is about the *settlement path*, not the asset's price.
### What Sprinter underwrites
| | Why Sprinter needs it |
| --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| **Settlement rail** — mechanism, cadence, business-day convention, valuation cut-off, and how variable it is | Sets how long capital is locked, which sets the price |
| **Rail reliability and caps** — historical settlement performance, daily or per-valuation limits on volume, and what happens to requests that breach them | Determines how much can be fronted before hitting your queue |
| **Price source** — NAV stream or oracle, update cadence, acceptable staleness | Sprinter quotes off this; stale prices mean no quote |
| **Issuer reserve adequacy** — whether you maintain your own instant buffer, and how it refreshes | Sizes how much Sprinter needs to front |
| **Secondary market depth** — availability of a fallback exit for positions held during the settlement window | A second exit path lowers the risk premium |
| **Contract addresses** — the token, plus any dedicated mint/redeem or express contracts | Integration and route configuration |
| **Eligibility** — whitelisting on the redemption rail, KYB steps, and any transfer restrictions that apply to Sprinter as counterparty | Sprinter must be able to actually redeem what it holds |
| **Chains** — launch chain priority and planned expansion | Determines which pools and routes are configured |
Underwriting typically takes 1–2 weeks and runs concurrently with onboarding and contract scoping.
### Confirm the asset is live
Before wiring up runtime calls, check that your token is returned by [supported tokens for a chain](/api-reference/sprinter/liquidity/returns-supported-tokens-for-a-chain). If it isn't there, onboarding is not complete and quotes will not return.
Onboarding is per asset and per chain. Adding a second asset, or the same asset on a new chain, needs its own underwriting and route configuration — usually much faster than the first, since the settlement rail is already understood.
***
## Runtime flow
Once the asset is live, this runs per redemption.
```mermaid theme={null}
flowchart TD
A[Holder submits redemption] --> B[GET /lifi-intents/rfq
liquidity reserved for 15s]
B --> C{Quote returned?}
C -->|Yes| D[POST /lifi-intents/transaction
returns open call data]
C -->|No| E[Fall back to native redemption queue]
D --> F[Send the transaction — inputs escrowed on-chain]
F --> G[Sprinter fills instantly in USDC on the holder's chain]
G --> H[Sprinter holds the position and settles on your T+X rail]
H --> I[Settlement repays Sprinter — capital recycles]
F -.->|order expires unfilled| J[You reclaim funds on the escrow contract]
```
### Step 2 — Request a quote
Call [`GET /lifi-intents/rfq`](/api-reference/sprinter/lifi-intents/rfq) with the position, the holder's chain, and where the proceeds should land.
```bash theme={null}
curl --request GET \
--url 'https://api.sprinter.tech/lifi-intents/rfq?srcChain=eip155:8453&dstChain=eip155:8453&amount=100000000&token=0x833589fcd6edb6e08f4c7c32d4f71b54bda02913&srcToken=YOUR_ASSET_ADDRESS&user=HOLDER_ADDRESS' \
--header 'X-Auth-Token: YOUR_API_KEY'
```
The response is a firm price with **liquidity already reserved against it**. Keep the whole quote object — step 3 takes it verbatim.
A quote is valid for **15 seconds**, and the reservation expires with it. Go straight from step 2 to step 3 — do not park a quote behind a user confirmation screen. If the holder needs to confirm, confirm first and quote after.
If no quote returns for an onboarded asset, fall back to your native redemption queue. A `404` means no pool can serve the size right now and is worth one retry after a short backoff; a `400` means the route is not configured and retrying will not help. Sprinter declining a fill should never block a holder from redeeming.
### Step 3 — Open the order
POST the quote back to [`POST /lifi-intents/transaction`](/api-reference/sprinter/lifi-intents/transaction). You get the same object with a `transactionRequest` on it — an unsigned `open` call on the escrow contract.
```bash theme={null}
curl --request POST \
--url 'https://api.sprinter.tech/lifi-intents/transaction' \
--header 'Content-Type: application/json' \
--data @quote.json
```
Send that transaction from the holder's wallet. It escrows the position and publishes the order.
You no longer construct the intent yourself. Sprinter builds it as an exclusive limit order with itself as the filler, priced at the quote, with the deadlines already set — which is what makes the fill deterministic: the holder is quoted a price, and that exact price is what fills.
Include the `quoteId` from step 2 — it is what ties the order to the reserved liquidity. Post a quote without one and you still get valid call data, but nothing is held for it.
With a `quoteId`, this call refreshes the reservation to **60 seconds from the response** — that is the budget for signing and broadcasting, not the 15 seconds the quote had.
### Step 4 — Settle, or reclaim
**If filled:** the holder receives USDC immediately on their chosen chain. Sprinter holds the position and settles it through your native rail. When settlement completes, Sprinter is repaid and the capital recycles into the next fill.
**If the order expires unfilled:** you reclaim the funds on the escrow contract. Nothing is stranded — an unfilled order is a no-op.
## Next steps
What a fill costs, and whether you want shared liquidity or a dedicated facility.
Endpoint reference for both runtime calls, and when to use the Swap API instead.
Facility sizing, pricing, and asset underwriting.
# Card Program Integration
Source: https://docs.sprinter.tech/quickstart/card-program
Add credit-backed card spending to your card program — let cardholders spend against DeFi collateral via the Sprinter Credit API
## Overview
If you run a card program (Rain, Stripe Issuing, Marqeta, etc.), Sprinter Credit lets your cardholders spend against locked DeFi collateral instead of prefunded balances. You keep your existing card stack — KYC, issuance, settlement — and plug in Sprinter as the credit engine.
Your integration is three API calls:
1. **Lock** — cardholder locks collateral, activating a credit line
2. **Draw** — your backend draws USDC to your settlement address when the card is used
3. **Repay** — debt is repaid at end of billing cycle, collateral unlocks
```mermaid theme={null}
flowchart TD
A[Cardholder locks collateral] --> B[Credit line active — card spending enabled]
B --> C[Card swipe → your backend draws USDC via Sprinter]
C --> D[USDC delivered to your settlement address]
D --> E[Repay at end of billing cycle]
E --> F[Collateral unlocked]
```
Every Sprinter endpoint returns `{ calls: ContractCall[] }` — unsigned transaction calldata. No custody handoff, no intermediaries.
## What You Need from Sprinter
| Your card program handles | Sprinter handles |
| --------------------------------------- | ------------------------------------------------- |
| KYC, compliance, card issuance | Collateral locking & credit line activation |
| Card network authorization & settlement | USDC credit draws to your settlement address |
| Cardholder UX, rewards, tiers | Health factor monitoring, LTV enforcement |
| Deposit addresses, funding detection | Earn vaults (collateral earns yield while locked) |
| Billing, statements | Repayment & collateral unlock |
## Before You Start
Card programs that draw credit on behalf of cardholders (e.g. just-in-time at card swipe) need a delegation model. You should decide upfront:
1. **Which account type?** EOA (existing wallet) or Smart Account — this affects onboarding and how delegation is set up. See [Credit Accounts](/sprinter-credit/credit-accounts).
2. **Which operator model?** A [Credit Operator](/sprinter-credit/policy-engine#credit-operators) lets your backend draw credit without cardholder interaction. Most card programs use the `ExclusiveOperator` — see [Delegated Credit Draws](#delegated-credit-draws) below for implementation.
## Integration
When a cardholder wants to activate credit-backed spending, they lock collateral via your app. Optionally wrap into an earn vault so collateral earns yield while locked.
```bash theme={null}
# Lock USDC as collateral on Base
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/lock?amount=1000000000&asset=0x833589fcd6edb6e08f4c7c32d4f71b54bda02913'
# Or lock + earn vault (collateral earns yield)
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/lock?amount=1000000000&asset=0x833589fcd6edb6e08f4c7c32d4f71b54bda02913&earn=STRATEGY_ID'
```
Returns `{ calls: ContractCall[] }` — execute in the cardholder's wallet. Once locked, the credit line is active.
Use `GET /credit/protocol` to fetch available collateral assets and earn strategies.
Query the cardholder's credit position to determine the spending limit for your card program.
```bash theme={null}
curl -X GET https://api.sprinter.tech/credit/accounts/0xUSER/info
```
```json theme={null}
{
"data": {
"USDC": {
"totalCreditCapacity": "900.00",
"remainingCreditCapacity": "900.00",
"totalCollateralValue": "1000.00",
"principal": "0",
"interest": "0",
"healthFactor": "Infinity",
"dueDate": null
}
}
}
```
Map `remainingCreditCapacity` to the card spending limit. Poll periodically to update as collateral values or debt change.
When the card is used, draw USDC from the cardholder's credit line to your settlement address. Two funding models:
Just-in-time draws require a delegation model (Operator or Smart Account). If you haven't set this up yet, see [Before You Start](#before-you-start).
Draw at the moment of each card authorization. Your backend receives the auth webhook, calls Sprinter `/draw`, executes on-chain, and responds — all within \~2 seconds.
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/draw?amount=50000000&receiver=0xYOUR_SETTLEMENT_ADDRESS'
```
This requires a [delegated signer](#delegated-credit-draws) authorized to execute on behalf of the cardholder. See the [Authorization Webhook Handler](/quickstart/credit-draw/authorization-webhook) for a complete TypeScript implementation.
Draw a lump sum to a per-user deposit address before the cardholder spends. Simpler to implement — no real-time on-chain execution needed.
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/draw?amount=500000000&receiver=0xDEPOSIT_ADDRESS'
```
Your card program detects the USDC deposit and credits the card balance.
| Parameter | Description |
| ---------- | -------------------------------------------- |
| `account` | Cardholder's wallet address |
| `amount` | USDC amount (6 decimals — \$50 = `50000000`) |
| `receiver` | Your settlement or deposit address |
Returns `{ calls: ContractCall[] }` — execute on-chain to deliver USDC.
A **0.50% origination fee** is deducted from each draw. See [Fees](/sprinter-credit/credit-engine#fees).
At end of billing cycle, repay the cardholder's outstanding debt. Once debt is cleared, collateral can be unlocked.
```bash theme={null}
# Check outstanding debt
curl -X GET https://api.sprinter.tech/credit/accounts/0xUSER/info
# Repay (anyone can repay on behalf of any account)
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/repay?amount=50000000'
# Unlock collateral
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/unlock?amount=1000000000&asset=0x833589fcd6edb6e08f4c7c32d4f71b54bda02913'
```
Credit runs on a 30-day billing cycle with a 7-day grace period. See [Fees](/sprinter-credit/credit-engine#fees).
## Delegated Credit Draws
Just-in-time card authorizations require drawing credit without cardholder interaction. This requires a [Credit Operator](/sprinter-credit/policy-engine#credit-operators) — a contract that lets your backend act on the user's credit position without custody. See [Credit Accounts](/sprinter-credit/credit-accounts) for choosing between EOA + Operator vs Smart Account. Two approaches:
Deploy an [`ExclusiveOperator`](https://github.com/sprintertech/remote-collateral-contracts/blob/main/contracts/operator/ExclusiveOperator.sol) contract. Your backend address is the authorized caller. Cardholders opt in by setting the operator on their credit position.
**Setup:**
1. Deploy `ExclusiveOperator` with your backend as the `caller`
2. Cardholder calls `setOperator()` on the Credit Hub
3. Cardholder calls `addCreditReceiver()` to whitelist your settlement address
**At swipe time:**
```solidity theme={null}
// Your backend calls directly — no cardholder signature needed
operator.openCreditLine(borrower, settlementAddress, amount);
```
**Safety:** The operator can only draw to whitelisted receivers — never touch collateral. Revocation has a time delay to prevent abuse during active billing cycles.
Cardholders deploy a smart account (ERC-4337) and configure a session key or module that authorizes your backend to call `/draw`. The cardholder retains full custody.
Most trust-minimized option — but requires cardholders to use smart accounts.
See the [Authorization Webhook Handler](/quickstart/credit-draw/authorization-webhook) for a complete implementation with signature validation, credit checks, and the full delegated draw flow.
## Integration Notes
The draw is the trigger — settlement is where value is delivered. When a card is swiped, Sprinter draws USDC to your settlement address, and your card network (Visa, Mastercard) clears the transaction. The cardholder bought coffee, paid for a flight, or shopped online — all funded by credit backed by their DeFi collateral. They never sold an asset, and the merchant received fiat through your normal settlement rails. See [From Credit to Action](/sprinter-credit/credit-engine#from-credit-to-action).
The `receiver` in draw calls is your card program's settlement address — the on-chain address where USDC must land for card network clearing. For pre-funding, this can be a per-user deposit address instead.
Poll `healthFactor` from the info endpoint and adjust card spending limits accordingly. A health factor approaching 1.0 means the position is close to liquidation — reduce or freeze the card limit. See [Risk Management](/sprinter-credit/risk-management).
Use the `earn` parameter when locking to wrap collateral into a yield-bearing vault. This makes credit structurally cheaper — collateral earns while the card is active. Use `GET /credit/protocol` to discover available strategies.
Always decline if the draw cannot be confirmed on-chain. A declined transaction is recoverable; an unauthorized spend is not.
The signing key that executes JIT draws must be secured with HSM or cloud KMS (AWS KMS, GCP Cloud KMS) in production. Never store it in environment variables on shared infrastructure.
## Try It
The **Card Issuer Demo** runs the full credit-backed card lifecycle on Base — collateral locking, credit draw to a settlement address, repay, and unlock — with a mock card issuer that simulates the card program side.
Clone the repo, add a wallet with USDC and ETH on Base, and run `npm run dev`. The mock card issuer handles the card program side — focus on the Sprinter Credit steps.
## API Reference
Every step maps to a single Sprinter endpoint:
| Card Program Flow | Sprinter API |
| --------------------------- | ------------------------------------------------------ |
| Cardholder locks collateral | `GET /credit/accounts/{account}/lock` |
| Lock + earn vault | `GET /credit/accounts/{account}/lock?earn=STRATEGY_ID` |
| Check spending limit | `GET /credit/accounts/{account}/info` |
| Draw USDC to settlement | `GET /credit/accounts/{account}/draw?receiver={addr}` |
| Repay debt | `GET /credit/accounts/{account}/repay` |
| Unlock collateral | `GET /credit/accounts/{account}/unlock` |
| Get protocol config | `GET /credit/protocol` |
Core credit draw lifecycle — lock, draw, repay, unlock.
Health factor, LTVs, and liquidation mechanics.
Full API reference with interactive playground.
# Credit Draw
Source: https://docs.sprinter.tech/quickstart/credit-draw
Draw credit against locked DeFi collateral via the Sprinter Credit API — lock, draw, repay, unlock
## Overview
The Sprinter Credit API lets you draw USDC credit against locked DeFi collateral. This guide walks through the full credit draw lifecycle: lock collateral, check your credit line, draw USDC, repay, and unlock.
```mermaid theme={null}
flowchart TD
A[User locks collateral] --> B[Credit line activated]
B --> C[Draw USDC from credit line]
C --> D[Use USDC — card funding, settlement, etc.]
D --> E[Repay debt at end of billing cycle]
E --> F[Unlock collateral]
```
This example demonstrates the core credit draw flow. For a card program integration, see the [Card Program Integration](/quickstart/card-program) quickstart.
## Before You Start
If your use case requires drawing credit without user interaction (e.g. card authorizations, agent actions, automated strategies), you'll need a delegation model:
1. **Which account type?** EOA (existing wallet) or Smart Account — this affects how delegation is set up. See [Credit Accounts](/sprinter-credit/credit-accounts).
2. **Which operator model?** A [Credit Operator](/sprinter-credit/policy-engine#credit-operators) lets your backend act on the user's credit position without custody. See [Delegated Credit Draws](#delegated-credit-draws) below.
If users sign every transaction themselves, you can skip this and go straight to the integration steps.
## Integration Steps
Lock collateral to activate a credit line. A single `/lock` call handles everything — including optional wrapping into a yield-bearing earn vault.
First, fetch available earn strategies from the protocol config:
```bash theme={null}
curl -X GET https://api.sprinter.tech/credit/protocol
```
This returns the credit configuration including a `strategies` field with available earn vaults and their IDs.
Then lock collateral — add the `earn` param to auto-wrap into a vault in the same transaction:
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/lock?amount=1000000000000000000&asset=0xCOLLATERAL_TOKEN&earn=STRATEGY_ID'
```
The `earn` parameter wraps the asset into a yield-bearing vault before locking — collateral earns while the credit line is active. Use a strategy ID from `/credit/protocol`.
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/lock?amount=1000000000000000000&asset=0xCOLLATERAL_TOKEN'
```
Omit `earn` to lock the raw asset directly without wrapping into a vault.
Returns `{ calls: ContractCall[] }` — execute in the user's wallet. Once locked, the credit line is active.
Display `totalCollateralValue` (spendable credit) and `healthFactor` in your UI.
```bash theme={null}
curl -X GET https://api.sprinter.tech/credit/accounts/0xUSER/info
```
```json theme={null}
{
"data": {
"USDC": {
"totalCollateralValue": "5000.00",
"principal": "0",
"interest": "0",
"healthFactor": "Infinity",
"dueDate": null
}
}
}
```
See [Credit Engine](/sprinter-credit/credit-engine) for how health factor and LTVs work.
With collateral locked, draw USDC from the user's credit line. The `/draw` endpoint is a general-purpose credit draw — the `receiver` can be any address (your settlement address, a card issuer's deposit address, etc.).
If your use case requires server-side draws without user interaction, you'll need a delegation model. See [Before You Start](#before-you-start).
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/draw?amount=50000000&receiver=0xRECEIVER_ADDRESS'
```
| Parameter | Description |
| ---------- | -------------------------------------------------------------------------------------------- |
| `account` | User's wallet address (borrower) |
| `amount` | USDC in lowest denomination (6 decimals — \$50 = `50000000`) |
| `receiver` | Address to receive the USDC (e.g. your settlement address, a card issuer's deposit contract) |
Returns `{ calls: ContractCall[] }` — execute on-chain to deliver USDC to the receiver.
A **0.50% origination fee** is deducted from each draw. See [Fees](/sprinter-credit/credit-engine#fees) for the full fee schedule.
For card programs that need JIT draws inside an authorization webhook, see the webhook handler example:
Complete TypeScript implementation showing how to wire `/draw` into a card authorization flow with signature validation, credit checks, and sub-2-second execution.
Credit runs on a 30-day billing cycle with a 7-day grace period. Repay before the due date to avoid the **15% overdue APR**. See [Fees](/sprinter-credit/credit-engine#fees).
```bash theme={null}
curl -X GET https://api.sprinter.tech/credit/accounts/0xUSER/info
# Returns: principal, interest, dueDate
```
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/repay?amount=50000000'
```
Returns `{ calls: ContractCall[] }`. Anyone can repay on behalf of any account, so you can run an automated repayment service.
When the user has zero outstanding debt:
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/unlock?amount=1000000000000000000&asset=0xCOLLATERAL_TOKEN'
```
Returns `{ calls: ContractCall[] }`. Execute in the user's wallet to return collateral.
## Delegated Credit Draws
Some use cases (like card authorizations) require credit draws without user interaction. This requires a [Credit Operator](/sprinter-credit/policy-engine#credit-operators) — a contract that lets your backend act on the user's credit position without custody. See [Credit Accounts](/sprinter-credit/credit-accounts) for choosing between EOA + Operator vs Smart Account. Two approaches:
Users deploy a smart account (e.g. ERC-4337) that can execute draw transactions autonomously. The user retains full custody — the smart account automates signing based on pre-configured rules.
**How it works:**
1. User deploys or connects a smart account
2. User configures a session key or module that authorizes your backend to call `/draw`
3. At draw time, your backend submits the draw calldata through the smart account
This is the most trust-minimized option — users never grant direct access to their credit line.
Your application deploys an [`ExclusiveOperator`](https://github.com/sprintertech/remote-collateral-contracts/blob/main/contracts/operator/ExclusiveOperator.sol) contract and sets your backend address as the authorized caller. Users opt in by setting this operator on their credit position and whitelisting your receiver address.
**How it works:**
1. Deploy an `ExclusiveOperator` with your backend address as the `caller`
2. Users call `setOperator()` on the Credit Hub to opt in
3. Users call `addCreditReceiver()` to whitelist your receiver address
4. Your backend calls `openCreditLine(borrower, receiver, amount)` directly on-chain
**Safety guarantees:**
* The operator can **only** draw credit to whitelisted receivers — never withdraw collateral
* Users can revoke access, but revocation has a **time delay** to prevent abuse during active billing cycles
* Credit receivers must be explicitly whitelisted per user
See the [Authorization Webhook Handler](/quickstart/credit-draw/authorization-webhook#delegated-credit-draws) for implementation details.
## Integration Notes
Whether using smart accounts or the operator contract, the signing key that executes draws must be secured with HSM or cloud KMS (AWS KMS, GCP Cloud KMS) in production. Never store it in environment variables on shared infrastructure.
The `receiver` in the draw call is the address that receives USDC. This could be your own settlement address, a card issuer's deposit contract, or any other address depending on your use case.
Always decline if the draw cannot be confirmed on-chain. A declined transaction is recoverable; an unauthorized spend is not.
Poll `healthFactor` from the info endpoint and surface alerts in your UI. See [Risk Management](/sprinter-credit/risk-management) for liquidation thresholds and collateral tiers.
## Try It
Want to see the full credit draw lifecycle running end-to-end? The **Credit Draw Demo** executes every step above — lock, credit check, draw, repay, unlock — using real Sprinter API calls on Base. It also supports a dry-run mode for testing without on-chain transactions.
Clone the repo, add a wallet with USDC on Base, and run `npm run ui` to launch the demo dashboard. See the README for full setup instructions.
You can also point an AI coding agent (like Claude) at the [Sprinter Credit API](/api-reference/sprinter/credit/get-credit-protocol-configuration) and your target receiver's API docs to generate a working proof of concept in minutes — the API is simple enough that an agent can wire up the full flow end-to-end.
## Related
Add credit-backed card spending to your card program.
Health factor, LTVs, and liquidation mechanics.
Full API reference with interactive playground.
# Authorization Webhook Handler
Source: https://docs.sprinter.tech/quickstart/credit-draw/authorization-webhook
TypeScript implementation for handling card authorization webhooks with JIT credit draws via the Sprinter Credit API
## Overview
When a cardholder swipes their card, the card network sends an authorization webhook to your backend. You have \~2 seconds to check credit, execute an on-chain draw, and respond.
```
Card swipe → Visa → Card issuer → Your webhook endpoint
├─ Validate signature
├─ Look up wallet from card ID
├─ GET /credit/accounts/{account}/info → check credit
├─ GET /credit/accounts/{account}/draw → build draw calldata
├─ Execute on-chain via delegated signer
└─ Respond: approved / declined
```
This example uses [Rain](https://www.rain.xyz) as the card issuer. Adapt signature validation and response format for your card program.
## Implementation
```typescript theme={null}
import express from "express";
import crypto from "crypto";
import { ethers } from "ethers";
const app = express();
app.use(express.json({ verify: (req: any, _res, buf) => { req.rawBody = buf; } }));
const SPRINTER_API = "https://api.sprinter.tech";
const RAIN_WEBHOOK_SECRET = process.env.RAIN_WEBHOOK_SECRET!;
const SETTLEMENT_ADDRESS = process.env.SETTLEMENT_ADDRESS!;
const RPC_URL = process.env.RPC_URL!;
const SIGNER_PRIVATE_KEY = process.env.SIGNER_PRIVATE_KEY!;
const provider = new ethers.JsonRpcProvider(RPC_URL);
const signer = new ethers.Wallet(SIGNER_PRIVATE_KEY, provider);
```
```typescript theme={null}
interface ContractCall {
to: string;
data: string;
value: string;
}
interface CreditInfo {
data: {
USDC: {
totalCollateralValue: string;
principal: string;
interest: string;
healthFactor: string;
dueDate: string | null;
};
};
}
// Use Redis or a database in production
const processed = new Map();
function validateSignature(rawBody: Buffer, signature: string): boolean {
const expected = crypto
.createHmac("sha256", RAIN_WEBHOOK_SECRET)
.update(rawBody)
.digest("hex");
return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}
async function getWalletForCard(cardId: string): Promise {
// TODO: query your database
throw new Error(`Implement getWalletForCard for cardId: ${cardId}`);
}
async function getCreditInfo(account: string): Promise {
const res = await fetch(`${SPRINTER_API}/credit/accounts/${account}/info`);
if (!res.ok) throw new Error(`Credit info failed: ${res.status}`);
return res.json();
}
async function buildDrawCalls(
account: string,
amountUsdc: string,
receiver: string
): Promise {
const url = new URL(`${SPRINTER_API}/credit/accounts/${account}/draw`);
url.searchParams.set("amount", amountUsdc);
url.searchParams.set("receiver", receiver);
const res = await fetch(url.toString());
if (!res.ok) throw new Error(`Draw calldata failed: ${res.status}`);
const data = await res.json();
return data.calls;
}
async function executeCalls(calls: ContractCall[]): Promise {
let lastTxHash = "";
for (const call of calls) {
const tx = await signer.sendTransaction({
to: call.to,
data: call.data,
value: call.value || "0",
});
const receipt = await tx.wait();
if (!receipt || receipt.status !== 1) {
throw new Error(`Transaction reverted: ${tx.hash}`);
}
lastTxHash = tx.hash;
}
return lastTxHash;
}
/** $1.00 = 100 cents = 1_000_000 USDC units (6 decimals) */
function centsToUsdcUnits(cents: number): string {
return (cents * 10_000).toString();
}
```
```typescript theme={null}
app.post("/webhooks/rain/authorization", async (req, res) => {
try {
// 1. Validate webhook signature
const signature = req.headers["x-rain-signature"] as string;
if (!signature || !validateSignature((req as any).rawBody, signature)) {
return res.status(401).json({ error: "Invalid signature" });
}
const { id, cardId, amount } = req.body;
// 2. Idempotency — return cached result if already processed
const cached = processed.get(id);
if (cached) return res.json(cached);
// 3. Look up user wallet
const wallet = await getWalletForCard(cardId);
if (!wallet) {
processed.set(id, { approved: false });
return res.json({ approved: false, reason: "unknown_card" });
}
// 4. Check available credit and health factor
const info = await getCreditInfo(wallet);
const available = parseFloat(info.data.USDC.totalCollateralValue);
const healthFactor = parseFloat(info.data.USDC.healthFactor);
if (amount / 100 > available) {
processed.set(id, { approved: false });
return res.json({ approved: false, reason: "insufficient_credit" });
}
if (healthFactor < 1.3) {
processed.set(id, { approved: false });
return res.json({ approved: false, reason: "low_health_factor" });
}
// 5. Build and execute the credit draw
const calls = await buildDrawCalls(wallet, centsToUsdcUnits(amount), SETTLEMENT_ADDRESS);
const txHash = await executeCalls(calls);
processed.set(id, { approved: true, txHash });
return res.json({ approved: true, txHash });
} catch (error) {
// Fail closed — always decline on error
console.error("Authorization error:", error);
return res.json({ approved: false, reason: "internal_error" });
}
});
app.listen(3001, () => console.log("Webhook handler running on :3001"));
```
## Delegated Credit Draws
Card authorizations must complete without user interaction. Your backend needs to draw credit on behalf of users. There are two on-chain approaches:
### Option A: Non-Custodial (Smart Accounts)
Users deploy a smart account (ERC-4337) and grant your backend a scoped session key or module that can only call the credit draw function. The user retains full custody.
User grants a scoped session key that can only call the credit draw function. Expires automatically.
User pre-signs EIP-2612 permits for USDC transfers up to a spending limit.
User's smart wallet delegates draw authority to your backend via a custom module.
### Option B: Operator Contract (Server-Side)
Deploy an [`ExclusiveOperator`](https://github.com/sprintertech/remote-collateral-contracts/blob/main/contracts/operator/ExclusiveOperator.sol) contract that lets your backend draw credit on behalf of opted-in users. This is the pattern used by card programs that need server-side control over credit draws.
**Setup (one-time):**
```solidity theme={null}
// Deploy with your backend address as the authorized caller
ExclusiveOperator operator = new ExclusiveOperator(
creditHubAddress, // Sprinter Credit Hub
controllerAddress, // Credit Hub Controller
adminAddress, // Contract admin (your multisig)
callerAddress, // Your backend's signing address
7 days // Revoke delay — users must wait 7 days to revoke
);
```
**User onboarding:**
```solidity theme={null}
// 1. User sets the operator on their credit position
creditHub.setOperator(address(operator));
// 2. User whitelists your settlement address as a credit receiver
operator.addCreditReceiver(settlementAddress);
```
**Drawing credit at swipe time:**
```solidity theme={null}
// Your backend calls this directly — no user signature needed
operator.openCreditLine(
borrowerAddress, // User's wallet
settlementAddress, // Whitelisted receiver
amount // USDC amount in wei
);
```
**Safety guarantees:**
* `withdraw()` is **disabled** — the operator can never touch collateral
* Credit can only go to **whitelisted receivers** the user has explicitly approved
* Revocation has a **time delay** (e.g. 7 days) — prevents users from revoking mid-billing-cycle while the operator still has outstanding credit exposure
* Users can schedule revocation at any time via `revoke()`, then finalize after the delay with `finalizeRevoke()`
The caller address can draw credit from any opted-in user account. Secure the private key with HSM or KMS in production — never store it in environment variables on shared infrastructure.
## Latency Budget
Card networks expect a response within \~2 seconds:
| Step | Target | Notes |
| ------------------------------------- | :-----------: | ----------------------- |
| Signature validation | \< 1ms | Local crypto |
| Database lookup (card → wallet) | \< 10ms | Index on card ID |
| `GET /credit/accounts/{account}/info` | \< 100ms | Sprinter API |
| `GET /credit/accounts/{account}/draw` | \< 100ms | Sprinter API |
| On-chain execution | \< 1000ms | Dedicated Base RPC node |
| **Total** | **\< 1300ms** | \~700ms buffer |
Use a dedicated RPC node on Base. Public endpoints will exceed the time budget under load.
## Production Checklist
* [ ] Replace in-memory idempotency map with Redis or database
* [ ] Use a dedicated Base RPC node (Alchemy, QuickNode, or self-hosted)
* [ ] Store signer key in HSM or cloud KMS (AWS KMS, GCP Cloud KMS)
* [ ] Implement `getWalletForCard()` against your user database
* [ ] Log all authorization decisions for audit trail
* [ ] Load test under expected peak authorization volume
* [ ] Monitor authorization latency (p99 \< 2s)
* [ ] Alert on elevated decline rates
* [ ] Track on-chain execution success rate
## Environment Variables
| Variable | Description |
| --------------------- | ---------------------------------------------------- |
| `RAIN_WEBHOOK_SECRET` | Webhook signing secret from your card issuer |
| `SETTLEMENT_ADDRESS` | Your card program's USDC settlement address on Base |
| `RPC_URL` | Base RPC endpoint (dedicated node recommended) |
| `SIGNER_PRIVATE_KEY` | Delegated signer private key (HSM/KMS in production) |
# Wallet Integration
Source: https://docs.sprinter.tech/quickstart/wallets-integration
Let wallet users borrow against their existing ETH and stETH — no selling, no bridging, just credit
## Overview
If you run a wallet or super app, Sprinter Credit lets your users borrow USDC against their existing holdings — ETH, stETH, wstETH — without selling. Users lock collateral, get a credit line, and spend or transfer USDC while their assets stay productive.
Your wallet already has the signer. Sprinter provides the credit engine — you just execute the calldata it returns.
| Without Sprinter | With Sprinter |
| ------------------------------------------------ | ------------------------------------------------------- |
| User sells ETH to get USDC | User locks ETH, draws USDC — keeps ETH exposure |
| stETH sits in wallet earning yield but illiquid | stETH earns yield **and** backs a spendable credit line |
| User bridges to get stablecoins on another chain | Cross-chain collateral — one credit line, any chain |
| No spending power without selling | Instant USDC credit against existing portfolio |
```mermaid theme={null}
flowchart TD
A[User locks ETH / stETH as collateral] --> B[Credit line activated]
B --> C[User draws USDC from credit line]
C --> D[USDC sent to any address — pay, transfer, swap]
D --> E[User repays when ready]
E --> F[Collateral unlocked — ETH / stETH returned]
```
Every Sprinter endpoint returns `{ calls: ContractCall[] }` — unsigned transaction calldata. Your wallet signs and submits. No custody handoff.
## What You Need from Sprinter
| Your wallet handles | Sprinter handles |
| ----------------------------------- | ------------------------------------------------- |
| Wallet UX, account management | Collateral locking & credit line activation |
| Transaction signing & submission | USDC credit draws to any receiver address |
| Portfolio display, balance tracking | Health factor monitoring, LTV enforcement |
| Network switching, gas estimation | Earn vaults (collateral earns yield while locked) |
| User authentication | Repayment & collateral unlock |
## Supported Collateral
Users can lock assets they already hold. Each asset has its own LTV based on its risk profile:
| Asset | LTV | Collateral Tier | Notes |
| ------ | :-: | ----------------- | -------------------------------------------------- |
| ETH | 80% | Raw volatile | Native ETH — highest liquidity |
| stETH | 75% | Volatile DEX-swap | Lido staked ETH — earns staking yield while locked |
| wstETH | 75% | Volatile DEX-swap | Wrapped stETH — same yield, no rebase |
| USDC | 90% | Raw stablecoin | Stablecoin — highest LTV |
Use `GET /credit/protocol` to fetch the latest supported assets and LTVs. See [Supported Assets](/sprinter-credit/supported-assets) for the full list and collateral tier framework.
## Before You Start
For most wallet integrations, users sign every transaction themselves — no delegation needed. A standard EOA (existing wallet) works out of the box.
If you want to support features like auto-repayment, scheduled draws, or agent-assisted actions, you'll need a delegation model. See [Credit Accounts](/sprinter-credit/credit-accounts) for EOA + Operator vs Smart Account trade-offs, and [Credit Operators](/sprinter-credit/policy-engine#credit-operators) for how delegation works.
## Integration
When a user wants to borrow, they lock collateral from their wallet. The API returns calldata — your wallet signs and submits.
```bash theme={null}
# Lock 1 ETH as collateral on Base
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/lock?amount=1000000000000000000&asset=0xETH_ADDRESS'
```
```bash theme={null}
# Lock stETH as collateral
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/lock?amount=1000000000000000000&asset=0xSTETH_ADDRESS'
```
```bash theme={null}
# Lock collateral and wrap into a yield-bearing vault
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/lock?amount=1000000000000000000&asset=0xCOLLATERAL&earn=STRATEGY_ID'
```
The `earn` parameter wraps the asset into a yield-bearing vault — collateral earns while the credit line is active. Use `GET /credit/protocol` for available strategies.
Returns `{ calls: ContractCall[] }` — present to the user for signing. Once confirmed, the credit line is active.
After locking, display the user's credit position in your wallet UI.
```bash theme={null}
curl -X GET https://api.sprinter.tech/credit/accounts/0xUSER/info
```
```json theme={null}
{
"data": {
"USDC": {
"totalCreditCapacity": "2400.00",
"remainingCreditCapacity": "2400.00",
"totalCollateralValue": "3000.00",
"principal": "0",
"interest": "0",
"healthFactor": "Infinity",
"dueDate": null
}
}
}
```
Key fields to surface in your UI:
| Field | What to show |
| ------------------------- | -------------------------------------------------- |
| `remainingCreditCapacity` | Available to borrow |
| `totalCollateralValue` | Total locked collateral value |
| `principal` + `interest` | Outstanding debt |
| `healthFactor` | Position health (warn below 1.5, danger below 1.2) |
| `dueDate` | Repayment deadline |
When the user wants to borrow, draw USDC to any address — their own wallet, a merchant, a DEX, another wallet.
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/draw?amount=500000000&receiver=0xRECEIVER'
```
| Parameter | Description |
| ---------- | ----------------------------------------------- |
| `account` | User's wallet address (borrower) |
| `amount` | USDC amount (6 decimals — \$500 = `500000000`) |
| `receiver` | Any address — user's wallet, merchant, protocol |
Returns `{ calls: ContractCall[] }` — user signs, USDC is delivered.
A **0.50% origination fee** is deducted from each draw. See [Fees](/sprinter-credit/credit-engine#fees).
Users repay debt to free their collateral. Anyone can repay on behalf of any account.
```bash theme={null}
# Check outstanding debt
curl -X GET https://api.sprinter.tech/credit/accounts/0xUSER/info
# Repay
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/repay?amount=500000000'
# Unlock collateral
curl -X GET 'https://api.sprinter.tech/credit/accounts/0xUSER/unlock?amount=1000000000000000000&asset=0xCOLLATERAL'
```
Credit runs on a 30-day billing cycle with a 7-day grace period. See [Fees](/sprinter-credit/credit-engine#fees).
## UX Patterns
If your wallet supports in-app payments, Sprinter Credit lets users pay with USDC drawn against their ETH/stETH — no selling required.
**Flow:**
1. User initiates a payment within your wallet
2. Your app checks if the user has a Sprinter credit line with sufficient capacity
3. If yes — draw USDC to the merchant/recipient via `/draw`
4. User signs one transaction (the draw), payment is settled
5. User repays later from any source
**What happens after draw:** USDC lands directly in the merchant's or recipient's wallet. The payment is settled on-chain — no intermediary, no delay. The user paid with credit backed by their ETH, and the merchant received real USDC.
This turns every ETH/stETH holder into a USDC spender without any sell pressure.
Display Sprinter Credit as a feature within your wallet's portfolio view.
**UX:**
* Show "Available Credit" alongside token balances
* "Borrow" button next to eligible collateral (ETH, stETH)
* Health factor gauge with color coding (green → yellow → red)
* Repayment reminder before due date
**What happens after draw:** When the user draws, USDC arrives in their wallet instantly — ready to send, swap, or spend. It feels like unlocking liquidity that was always there, just locked up in ETH.
Users treat it like an overdraft — they see available credit and draw when needed.
When a user tries to swap or purchase but lacks stablecoins, offer credit as an alternative to selling.
**Flow:**
1. User wants to buy an NFT / swap for a token but has no USDC
2. Prompt: "Borrow \$X against your ETH instead of selling?"
3. User confirms → lock ETH, draw USDC, complete purchase
4. User repays within 30 days
**What happens after draw:** The USDC goes directly to the seller or protocol — the NFT lands in the user's wallet, the swap executes, the purchase completes. The user got what they wanted without selling a single asset. They repay on their own schedule.
This prevents forced selling and keeps users' long positions intact.
Users can send USDC to friends, family, or other wallets — funded by their credit line instead of their token balance.
**Flow:**
1. User wants to send \$200 to a friend but only holds ETH
2. User draws USDC with the friend's address as the `receiver`
3. USDC arrives in the friend's wallet — one transaction
**What happens after draw:** The friend receives USDC directly — no intermediate step, no swap. The sender's ETH stays locked and earning yield. This makes credit-backed transfers as simple as a regular wallet send.
Let users interact with DeFi protocols using borrowed USDC — provide liquidity, enter yield positions, or fund a DEX trade.
**Flow:**
1. User wants to provide liquidity on a DEX but doesn't want to sell ETH for the USDC side
2. User draws USDC from their credit line
3. USDC is used to enter the LP position alongside their existing tokens
**What happens after draw:** The drawn USDC goes to the user's wallet or directly to a protocol address. The user is now earning LP fees on borrowed USDC while their ETH collateral continues earning staking yield — yield on both sides.
## Integration Notes
Poll `healthFactor` from the info endpoint and surface alerts in your wallet UI. A health factor approaching 1.0 means the position is close to liquidation — prompt the user to add collateral or repay. See [Risk Management](/sprinter-credit/risk-management).
Use the `earn` parameter when locking to wrap collateral into a yield-bearing vault. For stETH users, this means earning staking yield **and** vault yield simultaneously. Use `GET /credit/protocol` to discover available strategies.
Sprinter returns unsigned calldata — the user's wallet signs everything. Sprinter never has access to user funds. This means your wallet integration doesn't change your custody model.
If your users sign every transaction themselves, a standard EOA (existing wallet) is all you need. If you want to enable delegated actions like auto-repayment or scheduled draws, you'll need to choose between an Operator contract or Smart Account. See [Credit Accounts](/sprinter-credit/credit-accounts) for the full comparison.
ETH and stETH prices fluctuate. If collateral value drops, the health factor decreases and the user may face liquidation. Build alerts into your wallet UI — warn at health factor 1.5, strongly warn at 1.2.
Users can lock collateral on any supported chain. Sprinter handles cross-chain accounting — one credit line across all chains. This means users don't need to bridge assets before borrowing.
## API Reference
Every step maps to a single Sprinter endpoint:
| Wallet Flow | Sprinter API |
| --------------------- | ------------------------------------------------------ |
| User locks collateral | `GET /credit/accounts/{account}/lock` |
| Lock + earn vault | `GET /credit/accounts/{account}/lock?earn=STRATEGY_ID` |
| Show credit position | `GET /credit/accounts/{account}/info` |
| Draw USDC | `GET /credit/accounts/{account}/draw?receiver={addr}` |
| Repay debt | `GET /credit/accounts/{account}/repay` |
| Unlock collateral | `GET /credit/accounts/{account}/unlock` |
| Get protocol config | `GET /credit/protocol` |
Core credit draw lifecycle — lock, draw, repay, unlock.
Full collateral list, LTVs, and earn strategies.
Full API reference with interactive playground.
# Sprinter Audits
Source: https://docs.sprinter.tech/resources/audits
Security audits performed on Sprinter protocol smart contracts
## Audits
Our audit partners include [Veridise](https://veridise.com/) and [Spearbit/Cantina](https://cantina.xyz/welcome)
* [Sprinter Hub](https://github.com/sprintertech/sprinter-stash-contracts/blob/main/audits/VAR_Sygma_labs_Sprinter_liquidity_250212-final.pdf) - Veridise
* [Sprinter Liquidity Pools](https://github.com/sprintertech/sprinter-stash-contracts/blob/main/audits/VAR_Sygma_labs_Sprinter_liquidity_pool_250304-final.pdf) - Veridise
* [Sprinter Liquidity](https://cantina.xyz/portfolio/fe3c634c-d06d-47c2-a70a-f19d2f820f58) - Spearbit/Cantina
* [Sprinter Credit](https://cantina.xyz/portfolio/2a4c73be-7566-4d0b-af12-d94a037c4b01) - Spearbit/Cantina
All audit reports are also available on [GitHub](https://github.com/sprintertech/sprinter-stash-contracts/tree/main/audits).
# Sprinter Glossary
Source: https://docs.sprinter.tech/resources/glossary
Key terms and definitions for Sprinter Credit and Sprinter Liquidity
## Terms
### Bridges
Protocols that facilitate asset and data transfer between different blockchain networks. Bridges can be trust-minimized (e.g., ZK-proofs, MPC) or centralized.
### Collateral
Assets deposited by a user to secure a credit line. Sprinter Credit values collateral across all supported chains as a single unified portfolio.
### Credit Account
A guardrailed smart contract that holds issued credit funds and enforces usage constraints defined by the credit policy.
### Credit Configuration
The financial terms governing a credit line: supported collateral assets, LTV ratios, credit asset, interest rate, term length, and fees. A tighter credit policy can unlock a more favourable configuration.
### Credit Hub
The core component of Sprinter Credit. Handles credit line creation, drawdowns, repayments, and liquidations across supported networks.
### Credit Line
A pre-approved borrowing facility issued by Sprinter Credit, allowing users or agents to draw funds up to a defined limit based on their collateral and credit configuration.
### Credit Operator
An entity (user, app, or agent) granted access to a Sprinter Credit line on behalf of its owner, subject to fine-grained policy constraints such as allowed actions, amount caps, and co-sign requirements.
### Drawdown
The act of drawing funds from an open credit line up to the available credit limit.
### Exclusive Fill
An order published so that only one named filler may execute it, for a defined window. Sprinter quotes are exclusive to Sprinter's filler address, which is what makes the quoted price the executed price. After the exclusivity window ends, the order typically opens to any solver before its fill deadline.
### Fill
A fill represents the full lifecycle: detecting a user intent, borrowing liquidity, executing the transaction, repaying liquidity, and realizing solver and protocol profits.
### Health Factor
A single number indicating how close a position is to liquidation, calculated as `(Collateral Value x Maintenance LTV) / Outstanding Debt`. A Health Factor above 1.0 is safe; below 1.0 the position is eligible for liquidation.
### Intent
An order that states the outcome a user wants — this asset out, that asset in, on this chain — without specifying how to achieve it. The user escrows the inputs; a solver competes to deliver the outputs and is repaid from escrow on settlement.
### Intent Systems
A model where users specify desired outcomes, and solvers or order flow networks execute transactions accordingly.
### Interop
The ability of multiple blockchain networks to communicate and share information in a seamless, trust-minimized, and permissionless way. This enables assets, smart contracts, and transactions to interact across chains without requiring users to manage complex bridging processes.
### Liquidation
When a position's Health Factor drops below 1.0, Sprinter Credit liquidates as much collateral as needed to restore a healthy position. Partial liquidations are preferred. Liquidators receive a 5% bonus on the collateral they claim.
### Liquidity Layer
The component that sources and manages the capital required for credit issuance. Liquidity Providers deposit into the Liquidity Hub to earn yield.
### Liquidity Provider
A participant who supplies capital to the Sprinter Liquidity Hub in exchange for yield.
### Loan-to-Value (LTV)
The ratio of a user's credit limit to the value of their collateral. Each supported collateral asset has its own LTV ratio reflecting its risk profile. `Max Credit = Collateral Value x LTV`
### Maintenance LTV
The maximum LTV a position may reach before becoming eligible for liquidation. Set above the initial LTV to provide a safety buffer. `Current LTV = Outstanding Debt / Collateral Value`
### MEV (Maximal Extractable Value)
The value miners, validators, or solvers can extract by reordering transactions, with growing importance in MEV-resistant routing across chains.
### Overcollateralized Credit
A credit line where the value of deposited collateral exceeds the credit issued, reducing lender risk.
### Policy Engine
The Sprinter Credit component that makes credit configurable. Every credit line is governed by a policy defining who can use it, what they can do with it, and under what conditions. Tighter constraints enable more favourable credit terms.
### Productive Collateral
Collateral assets that continue to generate yield while locked in Sprinter Credit, making credit cheaper by design. Sprinter Credit integrates with DeFi strategies from Gauntlet and YO for this purpose.
### Solve RFQ
Sprinter's request-for-quote surface: you describe a trade and Sprinter returns a firm price with the liquidity reserved behind it, plus a transaction that opens the order. Unlike a [borrow quote](#borrow-quote), which is an estimate for solvers, an RFQ quote is a commitment for the life of its validity window. See [Solve RFQ](/solve-rfq).
### Solvers
Automated agents that find and execute the most efficient way to fulfill a user's intent, optimizing for cost, speed, and security.
### Borrow Quote
A borrow quote is the preliminary estimated fee a solver would incur to borrow credit from Sprinter Liquidity. It is returned off-chain via the Sprinter Liquidity API and helps solvers determine if pursuing a fill is profitable. A borrow quote includes expected gas, risk premiums, protocol fees, and capital access costs — but it is not a binding or reserved price.
### Borrow Cost
A borrow cost is the final, authorized borrowing offer issued by Sprinter Liquidity when a solver decides to proceed with a fill. It reserves credit under specific conditions, allowing solvers to confidently execute the crosschain transaction.
### Swaps
Asset exchanges that can occur within a single chain or across multiple chains using interoperability protocols.
### Undercollateralized Credit
A credit line where the issued credit exceeds the value of deposited collateral (or requires no collateral at all). Enabled by tight usage constraints via the Policy Engine.
# Solve RFQ
Source: https://docs.sprinter.tech/solve-rfq
How you get a price out of Sprinter Liquidity — a firm quote with the liquidity already held behind it
Solve RFQ is how you get a price out of Sprinter Liquidity. You describe the trade; Sprinter answers with a price and **holds the liquidity behind that answer** while you decide.
That second half is the part that matters. Most quoting is an estimate: a router prices a path, and what you actually get depends on what the pool looks like when your transaction lands. An RFQ quote from Sprinter is a commitment — the capital to fill it is reserved the moment the quote is issued.
## Why the price can be firm
Three things have to be true at once, and they are the reason this sits on top of Sprinter Liquidity rather than beside it:
| | |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **The capital exists** | Sprinter Liquidity has already underwritten the asset, allocated liquidity to it, and configured the route. Nothing is sourced at quote time |
| **It is reserved** | Issuing a quote takes that liquidity off the shelf for the life of the quote, so a second request cannot spend it |
| **The fill is exclusive** | The resulting order is published as an exclusive limit order to Sprinter's filler, so the price you were quoted is the price that executes |
Take any one away and the quote degrades into an estimate. This is the difference between telling a holder "roughly this" and telling them a number.
A quote is short-lived by design — it is capital held out of use. Quote, then act. The window is measured in seconds, not minutes, and treating a quote as cacheable is the most common integration mistake.
## Two ways to consume it
| | **LI.FI Intents** | **Swap API** |
| ------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------- |
| **Backed by** | Sprinter Liquidity — reserved for your quote | Public on-chain AMM liquidity |
| **Price** | Firm | Indicative, subject to slippage |
| **Use for** | Redemptions, subscriptions, any flow where a user is promised a price | Generic token swaps, and as a fallback when no Sprinter route exists |
| **Requires** | The asset onboarded with Sprinter | Nothing — any supported pair |
Default to LI.FI Intents. Reach for the Swap API when the pair is not onboarded, or as a fallback when a quote does not return.
## What it is not
* **Not a router.** Solve RFQ does not search for the best path across venues. It answers one question: what will Sprinter pay, right now, for this position.
* **Not always available.** Capacity is finite. A request can be declined, and your integration needs a fallback — for an issuer that means your native redemption queue.
* **Not a credit line.** Sprinter Credit is collateralized borrowing against assets you hold. Solve RFQ prices a settlement delay and is repaid by the settlement itself.
## Where to go next
The two runtime calls, end to end, with onboarding.
Endpoints, parameters, auth, and error behaviour.
What a fill costs, and shared liquidity versus a dedicated facility.
The capital layer underneath — where the liquidity comes from.
# Credit Accounts
Source: https://docs.sprinter.tech/sprinter-credit/credit-accounts
EOA vs Smart Account — choosing the right account type for your Sprinter Credit integration
## Overview
Every Sprinter credit position is tied to an on-chain account. Integrators need to decide which account type their users will use. This choice affects how delegation works, what permissions are possible, and how the end-user experience feels.
There are two options: **EOA (Externally Owned Account)** — a regular wallet address, or **Smart Account** — a contract wallet with programmable permissions.
| | EOA + Operator | Smart Account |
| ---------------------- | --------------------------------------------------- | ----------------------------------------------------------------- |
| Setup complexity | Low — user keeps existing wallet | Higher — user deploys or migrates to smart wallet |
| Delegation model | Operator contract draws to whitelisted receivers | Session keys with fine-grained permissions |
| Permission granularity | Receiver whitelist + operator-level constraints | Full control — amount caps, time limits, action types, co-sign |
| Custody model | Non-custodial (operator can't touch collateral) | Fully non-custodial (user owns the contract) |
| Revocation | Time-delayed (prevents mid-settlement abuse) | Instant (session key revoked immediately) |
| Best for | Card programs, simple delegation, most integrations | Advanced use cases, multi-party access, tight on-chain guardrails |
## EOA + Operator
The simplest path. Users keep their existing wallet (MetaMask, Rainbow, Coinbase Wallet, etc.) and interact with Sprinter directly. For delegated actions — where your app needs to act on the user's behalf, like drawing credit at card swipe — you deploy an [Operator contract](/sprinter-credit/policy-engine#credit-operators) that the user opts into.
**How it works:**
1. User locks collateral from their existing wallet
2. User calls `setOperator()` to authorize your Operator contract
3. User calls `addCreditReceiver()` to whitelist your settlement address
4. Your backend calls the Operator to draw credit — no user signature needed at transaction time
## Smart Account
Users deploy a smart contract wallet (ERC-4337) with programmable session keys or modules. Your app is authorized via a session key that defines exactly what it can do — amount caps, time windows, action types.
**How it works:**
1. User deploys a smart account (or your app provisions one during onboarding)
2. User configures a session key authorizing your backend
3. Session key defines permissions: which actions, how much, how often
4. Your backend uses the session key to execute — user retains full custody
## Which Should You Choose?
**Recommended: EOA + Operator**
Card programs typically have a simple delegation model — your backend draws USDC to a settlement address when the card is swiped. The `ExclusiveOperator` contract handles this cleanly. Users don't need to change their wallet setup, and the Operator's receiver whitelist ensures funds can only go to your settlement address.
Use Smart Accounts if you need per-user spending caps enforced on-chain, or if your users already have smart wallets.
**Recommended: EOA (no Operator needed)**
For wallet integrations where the user signs every transaction themselves, no delegation is needed. The user locks collateral and draws credit directly from their wallet. EOA is the simplest path.
Consider adding an Operator if you want to enable features like auto-repayment or scheduled draws.
**Recommended: Smart Account or EOA + Operator (depends on trust model)**
For agents acting on behalf of a user, the key question is how much autonomy the agent has:
* **Bounded autonomy** (e.g. agent can draw up to \$500/day): Smart Account with a session key that enforces caps on-chain.
* **App-managed autonomy** (e.g. your platform controls the agent): EOA + Operator, where your platform's backend is the authorized caller.
Smart Accounts give you the tightest on-chain guardrails. Operators are simpler if your platform already enforces limits off-chain.
## Related
How operators work, existing operators, and how to build your own.
Credit line creation, drawdowns, repayments, and liquidations.
Fine-grained credit controls and guardrailed accounts.
# Credit Engine
Source: https://docs.sprinter.tech/sprinter-credit/credit-engine
How the Sprinter Credit Engine handles credit line creation, drawdowns, repayments, and liquidations
## Introduction
The Sprinter Credit Engine handles credit line creation, drawdowns, repayments, and liquidations. Key features include:
**Flexible terms** — Overcollateralized or undercollateralized, fixed-rate or variable, short-term or rolling. The credit parameters adapt to the use case, not the other way around.
**Cross-chain portfolio, one credit line** — Collateral assets across all major chains valued as a unified portfolio. 50K staked ETH on Ethereum + 30K in Morpho Earn on Base + 20K WBTC on Arbitrum = 70K credit line, usable anywhere without bridging.
**Productive collateral** — Integrations with leading DeFi strategists Gauntlet and YO provide market-leading yield on your collateral assets such as USDC, ETH & BTC.
## From Credit to Action
Drawing credit is not the end — it is the beginning. The real value of Sprinter Credit is what happens *after* USDC leaves the credit line: credit drawn, USDC delivered, real-world action completed.
Every Sprinter draw sends USDC to a `receiver` address. What that receiver is determines the outcome:
| Integration Type | Receiver | What Happens After Draw |
| ------------------ | ------------------------- | -------------------------------------------------------------------------------------------------------- |
| Card program | Settlement address | USDC settles the card transaction — user pays at a restaurant, buys online, taps Apple Pay |
| Wallet | User's wallet or merchant | User sends a payment, tops up a balance, or pays a friend |
| Agent | Protocol address | Agent executes a swap, enters a yield position, or fills a trade on a DEX |
| Buy Now, Pay Later | Merchant / seller | Purchase completes immediately — user repays over 30 days |
| Subscription | Service provider | Recurring payment drawn automatically via an [Operator](/sprinter-credit/policy-engine#credit-operators) |
The key insight: the draw endpoint is generic (`/draw?receiver=0x...`), but the receiver address is what defines the use case. Sprinter doesn't need to know what the credit is for — it just delivers USDC to the address you specify, and your app handles the rest.
This means any app with a settlement flow can plug into Sprinter: if you have an address that needs USDC, Sprinter can fund it from collateralized credit.
```mermaid theme={null}
flowchart LR
A[User's Collateral] --> B[Sprinter Credit Engine]
B -->|draw USDC| C[Receiver Address]
C --> D[Card Settlement]
C --> E[Wallet Payment]
C --> F[Agent Execution]
C --> G[Merchant / Protocol]
```
## Credit Configurations
Sprinter uses credit configurations to structure different forms of credit. Creating a new credit configuration is currently a permissioned process — if you need purpose-fit credit for your app, we'd love to hear from you!
| | Card Spend | Crosschain Intents |
| ----------------- | ------------------------ | -------------------------------------------- |
| Access | Permissionless | Permissioned |
| Type | Overcollateralized | Zero Collateral |
| Usage Constraints | No | Fills in supported Intent protocols |
| Credit Chains | Base | Base, Arbitrum, Ethereum, Optimism, Unichain |
| Credit Asset | USDC | USDC, WETH, WBTC |
| Collateral Chains | Base, Ethereum | N/A |
| Collateral Assets | All supported | N/A |
| Term | Fixed 30+7 | Up to 4 hours |
| Fees | 50 bps + 15% overdue APR | Dynamic |
## Fees
The following fees apply to the **Card Spend** credit configuration (used by card programs). Crosschain Intents uses dynamic fees — see [Credit Configurations](#credit-configurations).
| Fee | Amount | When It Applies |
| --------------- | ------------------ | --------------------------------------------------------------- |
| Origination fee | **0.50%** (50 bps) | One-time fee charged on each credit draw |
| Overdue APR | **15%** | Charged on outstanding balance after the billing cycle due date |
The **origination fee** is deducted from each draw. For example, drawing 1,000 USDC delivers 995 USDC to the receiver.
The **overdue APR** kicks in only if debt is not repaid by the due date. For Card Spend credit (30-day term + 7-day grace), interest begins accruing after day 37. Repaying before the due date means zero interest.
Fee parameters are set per credit configuration. The values above apply to the Card Spend configuration. Crosschain Intents uses dynamic fees. See [Credit Configurations](#credit-configurations) for the full comparison.
## Credit Issuance
Sprinter Credit currently uses USDC as the main asset for credit issuance.
## Supported Assets & Positions
Sprinter Credit provides one unified credit line — and in the case of collateralized credit, users can deposit assets and DeFi positions across all supported chains. See [Supported Assets & Strategies](/sprinter-credit/supported-assets) for the full list of accepted collateral, earn vaults, and LTV parameters.
## Position Health, LTVs and Liquidations
Sprinter constantly monitors the health of all credit positions according to the defined credit configuration. In the case of collateralized credit, the collateral value is tracked continuously for changes.
**Loan-to-Value (LTV)**
LTV defines how much credit a user can draw relative to the value of their collateral. Each supported collateral asset has its own LTV ratio, reflecting its risk profile.
`Max Credit = Collateral Value x LTV`
For example, if a user deposits 1,000 USDC collateral with an LTV of 80%, their maximum credit line is 800 USDC.
**Maintenance LTV**
Maintenance LTV is the maximum LTV a position is allowed to reach while there is an outstanding balance. It is set higher than the initial LTV to provide a safety buffer before liquidation becomes possible.
`Current LTV = Outstanding Debt / Collateral Value`
As long as the Current LTV stays below the Maintenance LTV, the position is safe. If collateral value drops or debt grows (due to accruing interest) and pushes the Current LTV above the Maintenance LTV, the position becomes eligible for liquidation.
**Position Health Factor**
The Health Factor combines both values into a single number that indicates how close a position is to liquidation:
`Health Factor = (Collateral Value x Maintenance LTV) / Outstanding Debt`
| Health Factor | Status |
| ------------- | ------------------------------------------------ |
| > 1.3 | Healthy |
| 1.0 – 1.3 | At risk — consider adding collateral or repaying |
| \< 1.0 | Eligible for liquidation |
A Health Factor above 1.0 means the position is safe. Below 1.0, the protocol can liquidate part of the collateral to restore a healthy position.
**Liquidations**
When a position becomes eligible for liquidation, Sprinter liquidates only as much collateral as needed to bring the Health Factor back above 1.0 — partial liquidations wherever possible. Liquidators who perform the liquidation receive a 5% bonus on the collateral they claim.
# Sprinter Credit
Source: https://docs.sprinter.tech/sprinter-credit/overview
## Overview
Sprinter Credit is a programmable credit layer for individuals and agents. We don't just issue credit — we make credit *configurable*.
The first version of Sprinter Credit (V1) provided zero-collateral credit for crosschain solvers and processed over \$200m USD in volume within the first months. With V2 we take credit beyond solvers and bring the benefits of *programmable credit* to neo finance and the agentic age.
On a high-level, Sprinter Credit (V2) consists of the following components:
1. **[Credit Engine](/sprinter-credit/credit-engine)**
The core credit issuance and management system. Handles credit line creation, drawdowns, repayments, and liquidations across supported networks.
2. **[Supported Assets & Strategies](/sprinter-credit/supported-assets)**
Collateral assets, earn vaults, LTV parameters, and chain support — all in one reference.
3. **[Policy Engine](/sprinter-credit/policy-engine)**
Credit policies and [Credit Operators](/sprinter-credit/policy-engine#credit-operators) enable Sprinter Credit to 1) provide favorable credit conditions and 2) enable users and applications to delegate and constrain usage of credit — from card programs drawing on behalf of users to agents operating within on-chain guardrails.
4. **Liquidity Layer**
The Sprinter Credit Liquidity Layer provides the liquidity required for the credit engine. The Sprinter Credit Liquidity Hub & App allow Liquidity Providers to earn yield by providing capital.
Sprinter Credit enables applications to get purpose-fit credit lines for their users:
* Card Programmes fund card spend just-in-time, so users don't have to hold assets idle
* Neobanks provide a DeFi-powered liquid savings account, so users can spend their assets while having them earn yield in DeFi
* Wallets let users borrow USDC against their holdings — pay, transfer, or swap without selling
* Agents access a human-delegated undercollateralized credit line to trade extended leverage on Hyperliquid
The moment drawn USDC arrives at its destination, real-world actions are enabled: a card swipe settles, a merchant gets paid, an agent executes a trade. The credit draw is just the trigger; the value is in what it enables. Every Sprinter draw sends USDC to a `receiver` address specified by the integrator, and the receiver is what defines the use case. See [From Credit to Action](/sprinter-credit/credit-engine#from-credit-to-action) for the full picture.
## API Overview
Full API reference with interactive playground.
### Base URL
```
https://api.sprinter.tech
```
No authentication is required. All endpoints are open.
### Supported Chains
The Sprinter API uses **CAIP-2** identifiers for chain references. CAIP-2 (Chain Agnostic Improvement Proposal 2) is a standard format for identifying blockchains: `namespace:chainId` — for EVM chains this is `eip155:`.
You'll see CAIP-2 identifiers in API responses (e.g. the `chain` field in contract calls) and as path/query parameters in several endpoints.
#### Card Spend (Overcollateralized Credit)
| Chain | CAIP-2 Identifier | Chain ID | Role |
| -------- | ----------------- | -------- | ------------------- |
| Base | `eip155:8453` | 8453 | Credit + Collateral |
| Ethereum | `eip155:1` | 1 | Collateral |
#### Crosschain Intents (Zero-Collateral Credit)
| Chain | CAIP-2 Identifier | Chain ID |
| -------- | ----------------- | -------- |
| Base | `eip155:8453` | 8453 |
| Ethereum | `eip155:1` | 1 |
| Arbitrum | `eip155:42161` | 42161 |
| Optimism | `eip155:10` | 10 |
| Unichain | `eip155:130` | 130 |
You can always fetch the current list of supported chains and their collateral configurations from the [`GET /credit/protocol`](/api-reference/sprinter/credit/get-credit-protocol-configuration) endpoint.
# Policy Engine
Source: https://docs.sprinter.tech/sprinter-credit/policy-engine
Credit Operators, delegation, and fine-grained controls for configurable credit
## Overview
The Policy Engine is what makes Sprinter credit *configurable*. Rather than one-size-fits-all credit, every credit line is governed by a policy that defines exactly who can use it, what they can do with it, and under what conditions.
The tighter the constraints, the less collateral is needed — because the protocol's downside risk is bounded. This is how Sprinter can offer favourable or even undercollateralised credit terms: not because the risk disappears, but because it is constrained.
We call this **Closed-System Embedding (CSE)**. It has three parts: the **credit account** the position lives in, whose egress is constrained while debt exists; the **policy** that defines what actions are permitted; and the **recovery module** that unwinds the position repay-first, returning any surplus. Collateral assumes the worst will happen and oversizes against it. CSE prevents the worst from happening.
## Credit Operators
Operators are the delegation primitive in Sprinter Credit. They allow a user to grant a third party — an app, a backend, an agent — the ability to act on their credit position without handing over custody.
### How Operators Work
An operator is a smart contract that sits between your backend and the user's credit position. The user opts in by calling `setOperator()` on the Credit Hub. From that point, the operator can execute actions on the user's behalf — but only within the bounds the operator contract enforces.
**Key trust properties:**
* Operators can **draw credit** to whitelisted receivers — they cannot touch or withdraw collateral
* Operators can **repay debt** on behalf of the user
* Users must explicitly **whitelist receivers** via `addCreditReceiver()` before an operator can draw to them
* **Revocation** is time-delayed (not instant) to prevent abuse during active billing cycles — a user cannot revoke mid-settlement and leave the integrator exposed
```mermaid theme={null}
flowchart LR
A[User] -->|setOperator| B[Credit Hub]
A -->|addCreditReceiver| B
C[Your Backend] -->|draw / repay| D[Operator Contract]
D -->|authorized call| B
B -->|USDC| E[Whitelisted Receiver]
```
### Setting Up an Operator
Deploy an operator contract with your backend address as the authorized `caller`. You can use the existing [`ExclusiveOperator`](https://github.com/sprintertech/remote-collateral-contracts/blob/main/contracts/operator/ExclusiveOperator.sol) or build a custom one.
```solidity theme={null}
// ExclusiveOperator constructor
constructor(address _caller, address _creditHub)
```
The `caller` is the only address that can invoke actions through this operator.
The user calls `setOperator()` on the Credit Hub to authorize your operator contract on their credit position.
```solidity theme={null}
creditHub.setOperator(operatorContractAddress);
```
The user calls `addCreditReceiver()` to whitelist the addresses that the operator can draw to (e.g. your settlement address).
```solidity theme={null}
creditHub.addCreditReceiver(settlementAddress);
```
The operator can only draw to addresses the user has explicitly approved.
Your backend calls the operator contract to draw credit or repay debt — no user signature needed.
```solidity theme={null}
// Draw credit to the whitelisted settlement address
operator.openCreditLine(borrower, settlementAddress, amount);
```
### Existing Operators
| Operator | Description | Source |
| ------------------- | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `ExclusiveOperator` | Single authorized caller, draw to whitelisted receivers only. Designed for card programs and simple delegation. | [View on GitHub](https://github.com/sprintertech/remote-collateral-contracts/blob/main/contracts/operator/ExclusiveOperator.sol) |
The `ExclusiveOperator` is the default choice for most integrations. It enforces a strict model: one caller (your backend), drawing only to receivers the user has whitelisted. No collateral access, no unauthorized destinations.
### Building Custom Operators
Custom operators let you encode your own business logic into the delegation layer. An operator contract must implement the operator interface and be registered with the Credit Hub.
**What you can customize:**
* **Multi-caller access** — allow multiple backends or agents to use the same operator
* **Amount caps** — enforce per-transaction or per-period draw limits on-chain
* **Time windows** — restrict when draws can happen (e.g. business hours only)
* **Co-sign requirements** — require an additional signature for draws above a threshold
* **Action restrictions** — allow only specific actions (e.g. draw but not repay, or repay but not draw)
### Operator Use Case Ideas
Your backend is the sole caller. On each card swipe, it draws USDC to your settlement address. The user whitelists only your settlement address — funds can never go anywhere else.
This is the standard `ExclusiveOperator` pattern used by card integrations like Kast.
A parent sets up a credit position and assigns an operator that their child's wallet can draw from — but with on-chain caps. For example: max $50 per transaction, max $200 per week. The parent can adjust limits or revoke access at any time.
An AI agent is authorized as a caller on an operator with strict bounds: draw up to \$500/day, only to a set of pre-approved protocol addresses. The agent can autonomously execute strategies (yield farming, rebalancing, DCA) within the guardrails the user defined.
A SaaS or subscription service deploys an operator that can draw a fixed amount once per billing period. The user opts in, and the service draws automatically — like a crypto-native direct debit.
A DAO or team locks collateral and deploys a multi-caller operator. Multiple team members can draw from the shared credit line, each with individual caps. Co-sign requirements kick in above a threshold (e.g. draws over \$10K require 2-of-3).
An operator that monitors the user's credit position and automatically repays debt from a designated funding source before the due date — avoiding overdue interest. The user sets it and forgets it.
## Guardrailed Credit Accounts
Sprinter supports the creation of guardrailed credit accounts that grant Sprinter permissions on the issued funds. These accounts constrain how drawn credit can be used — for example, ensuring USDC can only be sent to a specific settlement address or swapped through an approved DEX router.
Guardrailed accounts are useful when the credit configuration requires usage constraints (see [Credit Configurations](/sprinter-credit/credit-engine#credit-configurations)). For instance, the Crosschain Intents configuration uses guardrailed accounts to ensure credit is only used for filling intents in supported protocols.
## Related
EOA vs Smart Account — choosing the right account type.
Credit line creation, drawdowns, health factors, and liquidations.
Liquidation mechanics and position monitoring.
# Risk Management
Source: https://docs.sprinter.tech/sprinter-credit/risk-management
Margin Period of Risk (MPOR)-driven risk framework protecting LPs from shortfall in Sprinter's credit system
## Why Risk Management Matters
Sprinter extends credit against on-chain collateral — vault positions, raw assets, yield-bearing tokens. The primary goal of the risk framework is to protect LPs (the capital providers behind every credit line) from shortfall: a situation where liquidated collateral recovers less than the outstanding debt. Every parameter in the system — LTVs, maintenance thresholds, concentration caps — exists to make that outcome unlikely and bounded.
## The Approach: MPOR-Driven Parameters
Sprinter derives its risk parameters from a single core measurement: **Margin Period of Risk (MPOR)** — the total time it takes to detect an undercollateralised position, trigger liquidation, and convert that collateral back to USDC. The longer that window, the more price can move against the position, and the more buffer is needed.
LTV is an output of that measurement:
```
LTV = 1 − (MPOR buffer + liquidation incentive + slippage margin)
```
This means LTV tiers reflect liquidation mechanics, not arbitrary haircut rules. A raw ETH position carries a higher LTV than a stable vault — not because ETH is less risky, but because ETH can be liquidated in seconds while a vault requires unwinding. The MPOR for ETH is under a minute; for a vault with queued redemptions it can be hours.
## Parameters
### Collateral Tiers (USDC-denominated lending)
| Collateral | Examples | LTV | Liquidation Threshold | Liquidation Bonus |
| ----------------------- | ------------------- | :----------: | :-------------------: | :---------------: |
| Stable vault | Gauntlet USDC Prime | 90% | 94% | 5% |
| Raw volatile | ETH, WBTC | 80% | 85% | 5% |
| Volatile DEX-swap | stETH, cbETH | 75% | 82% | 5% |
| Volatile vault | yoETH | 65% | 75% | 6% |
| USDC SuperVault | Superform USDC | 85% | 90% | 6% |
| Raw stablecoin | USDC | 95% | 97% | 5% |
| RWA / queued redemption | — | Not accepted | — | — |
The **liquidation threshold** is the health factor floor — when a position's collateral value drops below this ratio relative to debt, it becomes eligible for liquidation. The gap between LTV and the liquidation threshold is the buffer: it gives the protocol time to execute liquidation before a shortfall occurs.
### Concentration Limits
Multi-layer caps prevent a single failure from being catastrophic:
| Layer | Cap |
| -------------------------- | ----------------------------- |
| Per vault | 8–20% of TVL (varies by tier) |
| Per protocol (e.g. Morpho) | 40% |
| Per stablecoin (e.g. USDC) | 60% |
| Per chain (e.g. Base) | 70% |
## Getting Your Collateral Accepted
Sprinter uses a structured vault onboarding process to assess new collateral assets. The assessment covers audit history, oracle availability, MPOR measurement, liquidation market depth, and concentration impact. It typically takes 1–2 weeks.
# Supported Assets & Strategies
Source: https://docs.sprinter.tech/sprinter-credit/supported-assets
Collateral assets, earn strategies, LTVs, and maintenance thresholds supported by Sprinter Credit
## Overview
Sprinter Credit supports a range of collateral assets and earn strategies. This page provides a quick reference for what's currently supported — you can always fetch the latest configuration programmatically via [`GET /credit/protocol`](/api-reference/sprinter/credit/get-credit-protocol-configuration).
## Supported Collateral
Collateral can be locked to open an overcollateralized credit line. Each asset has its own LTV based on its risk profile and liquidation characteristics — see [Risk Management](/sprinter-credit/risk-management) for how these are derived.
### Currently Live
| Asset | Symbol | Chain | LTV | Maintenance LTV | Collateral Tier |
| ------------------- | ----------- | ----- | :-: | :-------------: | --------------- |
| USDC | `USDC` | Base | 90% | 92.5% | Raw stablecoin |
| Gauntlet USDC Prime | `gtUSDCp` | Base | 75% | 80% | Stable vault |
| Superform USDC | `superUSDC` | Base | 70% | 75% | USDC SuperVault |
| yoUSDC | `yoUSD` | Base | 70% | 80% | Stable vault |
| yoBTC | `yoBTC` | Base | 55% | 70% | Volatile vault |
LTV values are returned by the API as basis points (e.g. `9000` = 90%). A `null` LTV means the asset is accepted as collateral but parameters are being finalized.
### Collateral Tier Reference
All supported collateral falls into one of these tiers. LTV and maintenance thresholds are set per tier based on the [MPOR-driven risk framework](/sprinter-credit/risk-management#the-approach-mpor-driven-parameters).
| Tier | Examples | LTV | Maintenance LTV | Liquidation Bonus |
| ----------------- | --------------- | :-: | :-------------: | :---------------: |
| Raw stablecoin | USDC | 90% | 92.5% | 1% |
| Stable vault | gtUSDCp, yoUSDC | 75% | 80% | 6% |
| USDC SuperVault | superUSDC | 70% | 75% | 6% |
| Volatile vault | yoBTC | 55% | 70% | 8% |
| Raw volatile | ETH, WBTC | 80% | 85% | 5% |
| Volatile DEX-swap | stETH, cbETH | 75% | 82% | 5% |
| Volatile vault | yoETH | 65% | 75% | 6% |
New collateral assets can be onboarded through a structured assessment process covering audit history, oracle availability, and liquidation depth. See [Getting Your Collateral Accepted](/sprinter-credit/risk-management#getting-your-collateral-accepted).
## Earn Strategies
Earn strategies allow collateral to generate yield while it backs a credit line. When locking collateral, pass the `earn` parameter to [`/lock`](/api-reference/sprinter/credit/calldata-to-lock-asset-as-collateral) to auto-wrap into a vault.
### Currently Live
| Strategy ID | Name | Protocol | Curator | Underlying | Chain | Vault Type | Risk Score |
| --------------------- | ------------------- | ----------- | --------- | ---------- | ----- | ---------- | :--------: |
| `gauntlet-usdc-prime` | Gauntlet USDC Prime | Morpho V1 | Gauntlet | USDC | Base | ERC-4626 | 5 |
| `superform-usdc` | superUSDC | Superform | Superform | USDC | Base | ERC-7540 | 7 |
| `yo-usdc` | yoUSDC | Yo Protocol | Yo | USDC | Base | ERC-7540 | 5 |
| `yo-btc` | yoBTC | Yo Protocol | Yo | BTC | Base | ERC-7540 | 5 |
Use the strategy ID as the `earn` parameter when locking collateral:
```bash theme={null}
curl -X GET 'https://api.sprinter.tech/credit/v2/accounts/0xUSER/assets/usdc/lock?amount=1000000000&earnAsset=0xCOLLATERAL&earn=gauntlet-usdc-prime'
```
Risk scores range from 0–10. Lower scores indicate lower risk. Strategy availability and yields change over time — always check [`GET /credit/protocol`](/api-reference/sprinter/credit/get-credit-protocol-configuration) for the current list.
## Credit Asset
Sprinter Credit currently issues credit in **USDC** on **Base** (`eip155:8453`).
| Asset | Chain | Credit Hub Address |
| ----- | ----- | -------------------------------------------- |
| USDC | Base | `0xb5cf2A13E9aaE413E780379667274626fa9D49f6` |
## Fetching Live Configuration
All of the above is available programmatically:
```bash theme={null}
curl -X GET https://api.sprinter.tech/credit/protocol
```
The response contains per-chain data including:
* `collateral` — supported collateral assets with LTVs and escrow addresses
* `strategies` — earn vault strategies with protocol, curator, and vault details
* `creditHubs` — credit hub addresses and supported credit assets
See the [API reference](/api-reference/sprinter/credit/get-credit-protocol-configuration) for the full response schema.
## Related
MPOR framework, collateral tiers, and concentration limits.
LTV mechanics, health factor, and liquidations.
Live protocol configuration endpoint.
# Sprinter Liquidity Integration Guide
Source: https://docs.sprinter.tech/stash-v1/integration-guide
Guide for crosschain DeFi solvers to integrate with Sprinter Liquidity for on-demand credit borrowing
Request your Sprinter Liquidity API key by dropping a Telegram DM to [@Sprinter\_Intern\_Bot](https://t.me/Sprinter_Intern_Bot) with `/request api key`
## For crosschain DeFi
Sprinter Liquidity enables solvers to **borrow crosschain credit on-demand** to execute user intents without needing pre-funded inventory.
## Overview of the fill lifecycle
```mermaid theme={null}
flowchart TD
A[Solver Detects User Intent] --> B[Solver Previews estimated borrowing quote]
B --> C[Receive Borrow Quote Estimate]
C --> D{Fill using Sprinter Liquidity?}
D -- Yes --> E[Solver Reserves credit and authorizes the fill]
D -- No --> F[Abort Fill]
E --> G[Solver Borrows Liquidity from Sprinter]
G --> H[Sprinter Executes Cross-Chain Swap/Bridge]
H --> I[Intent Protocol Repays Borrowed Credit + Costs]
I --> J[Fill Complete]
```
# Sprinter Liquidity
Source: https://docs.sprinter.tech/stash-v1/overview
Sprinter Liquidity is a credit-based liquidity protocol for crosschain solvers and liquidity providers
# Sprinter Liquidity
Sprinter Liquidity is a credit-based liquidity protocol that connects stablecoin LPs with the actors who need funding for a settlement delay — crosschain solvers filling intents, and asset issuers offering instant redemptions and subscriptions on assets that settle T+X. It bridges the gap between passive capital and high-frequency demand for short-duration credit.
## Two ways to access it
**[Solve RFQ](/solve-rfq)** is the path for asset issuers, wallets and applications: you get a firm quote with liquidity reserved behind it, plus a transaction to send. Sprinter builds the order and fills it.
The **Liquidity API** is the path for crosschain solvers running their own fill infrastructure: you get a borrow quote and an MPC-signed authorization, and you run the fill and settlement yourself. See the [Integration Guide](/stash-v1/integration-guide).
Issuing an asset with a settlement delay? Go to the [Asset Issuer quickstart](/quickstart/asset-issuer) for onboarding and the two runtime calls, and [Pricing & Credit Facilities](/pricing) for what a fill costs and whether you want shared liquidity or a dedicated facility.
## Why Sprinter Liquidity?
### For Liquidity Providers
Sprinter Liquidity is for liquidity providers looking for an attractive yield opportunity based on a new DeFi primitive:
* **High Yield & Low Risk:** Sprinter Liquidity utilizes multiple yield sources to maximize capital efficiency and returns: LPs earn from service fees paid by solvers to access credit as well as proven passive yield sources (such as lending protocols) ensuring low risk.
* **Secure & Credible:** MPC-secured multi-party threshold signing, risk mitigation mechanisms, and smart contract audits by [Veridise](https://github.com/sprintertech/sprinter-stash-contracts/blob/main/audits/VAR_Sygma_labs_Sprinter_liquidity_250212-final.pdf) and [Spearbit/Cantina](https://cantina.xyz/portfolio/fe3c634c-d06d-47c2-a70a-f19d2f820f58) make Sprinter Liquidity a secure platform. Built in partnership with [ChainSafe](https://chainsafe.io), a team with 7+ years of industry expertise across core protocol development, standardization/EIPs and security audits/council work.
### For crosschain DeFi
Sprinter Liquidity enables capital-efficient crosschain execution by removing the need for pre-funded liquidity pools or collateralized loans. Liquidity is automatically managed across chains via a variety of rebalancing and netting protocols. At launch, Sprinter Liquidity initially supports solvers filling orders in:
* Across
* LiFi Intents
* Mayan Finance
* Rhinestone
## How Sprinter Liquidity Works
1. **Liquidity Providers deposit USDC on Base from any chain into the protocol's liquidity hub** - Receiving spUSDC-LP tokens in return. Liquidity is then managed across the pools on supported chains.
2. **Solvers access liquidity instantly, without collateral** – Solvers execute their fills through Sprinter Liquidity. After a fill is completed via credit, Sprinter receives the deposited funds on the source chain, repaying the credit and keeping profits for LPs and solvers. It works as a closed credit system — **Closed-System Embedding** — where the MPC validates all intents to be filled and ensures credit will be repaid.
3. **LPs earn blended yield** – Yield combines a passive baseline from lending protocols such as Aave with the borrow fees paid for access to credit. Capital is deployed where it is needed and earns the baseline while idle.
4. Once **fills are completed**, Sprinter receives funds on the source chain, repays the credit, and distributes profits to LPs and solvers.
By bringing together **liquidity providers and solvers**, Sprinter Liquidity creates a more efficient and scalable solver environment for the entire DeFi ecosystem. It launches with supported:
* **Destination Networks** - Base, Arbitrum, Optimism
* **Tokens** - DAI, ETH/WETH, USDC, USDT, WBTC
* **Protocols** - Any EVM crosschain bridge/swap protocol such as 1inch Fusion+, Across, Debridge Liquidity Network, Everclear, Mayan.Finance with many more upcoming
* **Rebalancing/Inventory Management** - CCTP, native Bridges, Everclear
## How Sprinter Liquidity Enables Zero-Collateral Loans
Sprinter Liquidity enables solvers to borrow liquidity with near zero collateral, and achieves this through a series of mechanisms below:
#### 1. Approved Solvers
On launch only approved solvers can access credit. These solvers:
* Undergo screening and onboarding by the Sprinter team
* Must use authenticated API keys tied to their accounts
* Are rate-limited and monitored to ensure responsible usage
Sprinter also tracks solver performance and creditworthiness over time. Solvers who consistently repay on time may be granted higher limits, while misbehavior results in penalties or revoked access with both informed through regular reviews of:
* Fill accuracy and repayment behavior
* Volume solved and protocols interacted with
* On-chain and off-chain repayment events
#### 2. Transaction-Level Guarantees
Each fill is validated against the user's original intent using:
* Verified source deposits (e.g. via Across)
* MPC-signed authorization signatures
* Controlled function execution (via calldata)
Sprinter acts as an intermediary: the solver never touches user funds directly. The system ensures that repayment is guaranteed by the user's transaction on the source chain before the solver receives liquidity.
#### 3. Protocol Guardrails & Limits
Sprinter enforces:
* Per-solver daily limits (to minimize exposure)
* Per-transaction liquidity caps
* Circuit breakers triggered by irregular repayment behavior
* Slashing (or bond requirements) for higher-risk integrations
#### 4. Solver Risk / Repayment
Liquidity pools initiate the execution, not the solver. The solver does not pull funds itself, but merely instructs the pool and as such never custodies capital. There are no scenarios where a solver can "not execute" or misdirect funds.
#### 5. Liquidity Provider Risk
Sprinter Liquidity is a closed credit system with controlled flows, so solvers cannot lose LP funds. The remaining risks are the same as any DeFi protocol: Security risks in the protocol itself and in the protocols we use (e.g. Aave). We only integrate with partners who meet strict security standards and have strong audit histories as ourselves.
## Fees
Sprinter Liquidity handles crosschain liquidity fills. Revenue is generated from the spread between the amount the user deposited on source and the amount provided on the destination.
### Revenue Components
* **Fill Revenue:** Amount user deposits on source - amount sent to user on destination
* **Borrow Costs:** Cost of liquidity borrowing and crosschain repayment.
* **Solver Costs:** Gas fees and execution costs fronted by solvers.
### Profit Calculation
```
Fill Profit = Fill Revenue - Borrow Costs - Solver Costs
```
### Monthly Distribution
1. Withdraw raw profits from liquidity pools.
2. Deduct solver gas costs.
3. Distribute monthly fill profits to:
| Actor | Description | Fill Profit % |
| -------- | ------------------------------------- | ------------- |
| Solvers | For executing fills | 50% |
| LPs | For providing liquidity | 50% |
| Treasury | Protocol growth & sustainability fund | TBD |
*Initial fee split is reviewed monthly by governance.*
## Start integrating
Quote and fill through LI.FI Intents — two API calls, no fill infrastructure of your own.
Borrow zero-collateral credit on demand and run your own fills.