How Turret prices silver, memecoins and stocks

A loan needs a price. When you deposit collateral on Turret, that price helps determine how much USDG you can borrow and when your position becomes eligible for liquidation.

But a silver token, a memecoin and an Apple Stock Token do not get their prices from the same place. Their markets have different hours, different liquidity and different ways of going quiet. We built the oracle checks around those differences.

An oracle is the part of the system that gives the lending contract a usable price. On Turret, that can mean reading an existing Chainlink feed, checking exchange data against onchain trading, or calculating a price directly from an onchain pool.

What stays the same across loans

Each market follows the same basic lending model. You deposit one supported collateral token and borrow USDG from that market's separately funded pool. Your debt includes the amount borrowed and accrued interest. You can repay debt, add collateral or, when the position meets the required checks, borrow more or withdraw collateral. Repaying the full debt lets you recover the remaining collateral.

The pools are separate: USDG supplied to the AAPL pool funds AAPL-backed loans, and USDG supplied to the CASHCAT pool funds CASHCAT-backed loans. They still share dependencies such as USDG and Robinhood Chain.

The asset changes the evidence required to value and sell the collateral. That affects when borrowing is available and how much debt the market allows against it.

Three assets, three price paths

Collateral	Where Turret gets its price	What that means
SLV	The SLV/USDG Uniswap v3 pool, averaged over five minutes	Prices the token in its onchain market, including outside the underlying market's hours
CASHCAT	Multiple exchange sources, checked against its onchain trading route	Combines external price evidence with the market used to sell collateral
Robinhood equity tokens	The token's Chainlink feed, plus Turret's market-session and execution checks	Follows the token's reference price, with borrowing conditional on usable data and liquidity

The SLV contracts described here are deployed, and their owner activation has been verified. Borrowing still depends on live price, liquidity and service checks passing. The market page shows current availability; a 24/7 price design does not promise uninterrupted lending.

Silver: reading the market that trades the token

The weekend problem was straightforward. A reference feed tied to the underlying market can retain its last published price while that market is closed. Asking for it every second just returns the same observation. It does not create a fresh silver price.

For SLV, we built a direct oracle around the token's SLV/USDG Uniswap v3 pool. It measures how much USDG one raw SLV token is worth in that pool. It does not ask a stock exchange to publish a new quote first.

The contract uses five minutes of pool price history, rather than taking the price at a single instant. This is a time-weighted average price, or TWAP. Uniswap v3 records cumulative price information that lets a contract calculate an average over a chosen period. Uniswap's oracle documentation explains the underlying mechanism.

For new borrowing, Turret also checks that the current pool price has not moved too far from that average and that the pool meets its liquidity requirements. It verifies the expected pool and tokens, their decimals, and the SLV token's corporate-action metadata. A relevant metadata change requires a new observation window before quotes become usable again.

This reuses the onchain price-history approach we use in CASHCAT's checks. SLV takes a simpler route: one direct SLV/USDG pool, without CASHCAT's independent exchange-price comparison.

That difference matters. SLV's oracle measures the onchain token market. It is not a live worldwide spot-silver benchmark, and it does not make the underlying silver market trade over the weekend. The token can trade at a premium or discount while reference markets are closed. The quote is also denominated in USDG, not independently converted into U.S. dollars.

A pool can keep producing an average even when nobody has traded recently. The time at which we calculate the quote must not be mistaken for the time of a fresh trade. And a thin pool is easier to move: averaging and liquidity checks reduce some risks, but they do not make a single trading venue an independent price source.

Memecoins: why CASHCAT gets another check

For CASHCAT, our supported memecoin market, Turret uses several exchange sources, including Gate, MEXC and KuCoin. Our price service compares that evidence with the onchain route used to sell CASHCAT and accounts for USDG's market value.

The onchain side uses recent price history as a check on what the external sources report. The service signs short-lived reports, and the lending transaction can include the required oracle update. A report that was acceptable when the page loaded can expire before a wallet confirmation finishes.

That gives CASHCAT evidence from outside its onchain pools. It also adds dependencies: Turret operates the reporting service and signing key, and the service depends on its data providers. Several sources do not turn our own signer into a decentralized oracle network.

When exchange prices and onchain trading corroborate a fall, the system can recognize it promptly. If required sources are stale or disagree beyond the allowed limits, new borrowing can become unavailable. The CASHCAT article explains what that means for an existing loan.

This is the design for CASHCAT. Adding another memecoin would require checking that token's sources and sale liquidity; listing a Uniswap pool alone would not establish that it is suitable collateral.

Stocks: Chainlink prices with trading-session checks

For ordinary Robinhood equity tokens such as AAPL and NVDA, Turret reads the token's onchain Chainlink reference feed. Robinhood documents these as per-token prices that already incorporate its corporate-action multiplier. Applying that multiplier a second time would misprice the collateral. Feed decimals and token units also need to be handled consistently. Robinhood's price-feed documentation describes these conventions.

Turret adds checks around that reference price before allowing a new loan. For extended sessions, its monitors compare current trades and quotes through Alpaca with the onchain token price, accounting for token scaling. The session determines the data source: consolidated U.S. market data for premarket, regular and after-hours trading, and Blue Ocean data for overnight trading. Alpaca documents the four-session schedule and overnight feeds.

The monitors also check operational readiness and simulate selling collateral through the actual onchain route. A short-lived signed approval lets the borrowing contract verify that the required checks passed recently.

That is conditional 24/5 support. Holidays, stale observations, wide spreads, token restrictions or failed sale checks can keep borrowing unavailable during a scheduled session. A reopening timer shows when a market can begin qualifying, not a promise that a loan will be available at that second.

Why loan terms can differ

Price checks are only part of a market's configuration. The terms also set how much someone can borrow and how much total lending the pool can support.

Term	What it controls and why it can differ
Maximum borrowing LTV	Debt as a share of collateral value when borrowing or withdrawing collateral. A lower limit leaves more room for price falls and interest before liquidation.
Liquidation LTV	The debt-to-collateral ratio above which a position becomes eligible for liquidation. The threshold must leave room for sale costs, the liquidation bonus and price movement during execution.
Minimum loan	The smallest permitted outstanding debt, unless repaying in full. Small liquidations can cost more in gas than they earn, so the minimum is also an operational choice. It does not guarantee profitable liquidation.
Market borrowing cap	The maximum total outstanding principal across the pool. It limits exposure to that collateral and its sale route. Actual borrowing also requires available USDG in the pool.

These are choices made for each deployment. They need to account for price behaviour, available sale liquidity and operating costs; an asset label alone does not establish suitable limits. Different assets can share the same terms, and a higher borrowing limit does not establish that a market is safer.

Some differences also reflect when a market was deployed. Parameters such as minimum debt and LTV thresholds are fixed in the existing contracts, so changing them requires a replacement market. Existing loans remain attached to their original contracts until repaid or explicitly migrated. Check the terms shown for your particular loan, including its APR, rather than assuming another asset's terms apply.

A price and a successful liquidation are different things

A liquidation needs both a valid valuation and a buyer for the collateral. Reading prices more often cannot manufacture liquidity or make a sale profitable after gas costs.

The SLV replacement separates the checks for new borrowing from those for liquidation. New borrowing keeps stricter current-price and liquidity requirements. Liquidation uses its own TWAP path, retaining price-history, minimum historical liquidity, token and metadata checks. A sharp move outside the borrowing limits should not, by itself, remove the liquidation quote needed to manage an existing loan.

That change addresses a quote-availability problem. It cannot guarantee that selling collateral will recover the debt. Our simulations still found severe price-drop scenarios where the available sale proceeds were insufficient. A five-minute average can also lag a fast move.

For borrowers, the practical distinction is simple: an available quote does not guarantee execution, and a borrowing pause does not make an existing position safe. Debt and interest continue through price interruptions. Check the current transaction quote and your position's risk level, and leave room for prices to move.