USTBL is a regulated money-market fund share, with ERC-20 rails
USTBL is not a “protocol token” in the usual sense. It is the on-chain technical form of a share in the Spiko US T-Bills Money Market Fund with ISIN FR001400ODM9.
On the asset side, the fund’s mandate is narrow: it invests exclusively in U.S. Treasury Bills with maturities under 6 months, and targets returns aligned to the Effective Federal Funds Rate (EFFR).
On the investor experience side, the important design choice is capitalization. Income is reinvested, so your token balance stays flat while the per-share NAV ratchets over time, as described in the Key Information Document.
Spiko frames the structure as UCITS-regulated and AMF-approved, with the custody and admin stack centered on CACEIS (custodian and fund admin), BNY Mellon (sub-custodian for U.S. T-bills), and JPMorgan (USD correspondent bank).
For U.S.-based readers, there is a practical constraint you cannot ignore: the Key Information Document states the product is not marketed to investors falling under the definition of “U.S. Persons” (as summarized in the prospectus).
The tokenization layer matters, but it does not replace the fund. It replaces parts of the registry and transfer plumbing. For a related “fund share on-chain” framing, compare this to tokenized fund shares like BCAP.
Supply is elastic, but float is permissioned and fragmented
USTBL has no meaningful “emissions schedule.” Supply expands when new shares are subscribed and contracts when shares are redeemed. Public trackers reflect this as an infinite max supply and show circulating and total supply moving together; see the current supply data.
As of the CoinGecko snapshot available on March 3, 2026, CoinGecko lists 199,179,250 as both circulating and total supply.
Here is the liquidity-structure catch: USTBL is issued across multiple networks, and “circulating supply” becomes a reporting choice, not a single on-chain truth. Spiko lists deployments across Ethereum, Polygon PoS, Arbitrum One, Base, and Etherlink (plus Starknet, and Stellar in the broader address table).
On Ethereum specifically, Etherscan shows the ERC-20 as a token contract “with 5 decimals” and reports a Max Total Supply number for that chain instance.
That split is why fully diluted valuation narratives are basically noise here. The economic supply is “shares outstanding,” but the tradable float is constrained by (1) which chain those shares sit on and (2) who is allowed to custody and receive them.
USTBL can only be held in allowlisted addresses. Spiko states your wallet address is allowlisted before shares are minted, and that transfers are free between allowlisted addresses.
The restriction is not just policy text. The token contract enforces a whitelist at the transfer layer by checking the Permission Manager (via authority.canCall) for both sender and receiver, and it can also be paused by authorized actors.
Finally, Spiko’s own platform UX splits holders into two modes. In Standard Mode, shares are held and managed on the platform. In Expert Mode, you can self-custody, choose the network where shares are issued, and subscribe using e-money tokens via trusted third parties.
Net effect: you should assume “circulating supply” overstates effective circulating supply for DeFi use. A large slice of shares can exist in custody contexts that never touch composable smart contracts, even if the registry is tokenized.
Minting and redemption are the real “unlock schedule”
The closest thing USTBL has to an unlock schedule is operational. It is the path from fiat or stablecoin into shares, and from shares back into cash or stablecoin, under regulated cutoffs and smart-contract controls.
On the traditional fund side, the KID states subscription requests (amount-based) and redemption requests (share-count-based) are centralized no later than 10:30 a.m. CET on business days and executed on the basis of the last known NAV. Orders received after that are carried over to the next business day.
On the token side, Spiko’s EVM contracts introduce explicit control points for issuance and redemption:
1) Minting (issuance). The on-chain Minter contract has a per-token daily limit. If an issuance would exceed the configured daily limit, the mint can be blocked into a pending state rather than reverting, and then later approved by an authorized actor.
This matters for liquidity. It creates a throughput ceiling for “new float” on any given day, even if demand spikes. In a stressed market, that is exactly when you want issuance to be elastic.
2) Redemption (burn). The Redemption contract is wired to ERC-1363 so a user can initiate redemption by sending tokens to the redemption contract with data specifying an output route. That creates a pending redemption request.
The maximum execution window is explicit in code as MAX_DELAY = 14 days in the redemption workflow. If the redemption is not executed before the deadline, anyone can cancel and the input tokens are refunded to the user.
Execution itself is permissioned. An authorized actor executes redemption by burning the tokens held by the redemption contract.
That combination is a strong statement about where liquidity really lives: shares are transferable 24/7 among allowlisted wallets, but the “exit to cash” remains a controlled workflow with deadlines, minimums, and authorized execution. The redemption contract even supports per-input minimum redemption amounts as a configurable parameter.
Value accrual and fee flow: price goes up, supply does not “rebase”
USTBL’s value accrual is structurally simple. The portfolio holds U.S. T-bills, income is capitalized into the NAV, and USTBL represents the share claim. There is no reward token, no staking yield, no inflation funded by dilution. For a contrast case in how on-chain yield is packaged, see our YLDS tokenomics.
Fees, though, have two “truths” depending on what you read:
Spiko’s documentation states annual fees of 0.25% per annum, calculated and deducted daily on a pro-rata basis, with deposits and withdrawals at 0%.
The KID’s cost section, based on the last year’s actual costs, reports 0.35% per year for “management fees and other administrative or operating fees,” plus an estimated 0.06% per year in transaction costs, and states there are no entry costs, no exit costs, and no performance fees.
I treat this as a modelability issue, not a gotcha. For tokenomics purposes, what matters is the mechanism: fees are extracted at the fund level and show up as a lower NAV trajectory, not as token transfers, burns, or a protocol treasury.
NAV is published through traditional data feeds (Bloomberg) and mirrored on-chain through oracle contracts. If you want definitions for the moving parts here, our tokenomics FAQs cover the basics.
The ATM contract uses the oracle value with a time-to-live constraint (oraclettl) and derives min/max from the latest two rounds, then uses that price for buy/sell conversions between the fund token and a configured stable token.
Governance reality: a permission manager, not a DAO
USTBL has no governance token. Parameter control sits with authorized actors in a Permission Manager system. The Permission Manager contract implements an authority model that determines which addresses can call which function selectors on target contracts.
This is why “admin risk” is not theoretical. The USTBL token contract exposes restricted admin functions to mint, burn, pause, unpause, and upgrade, and the transfer whitelist logic lives inside the transfer hook.
Spiko explicitly states that, in compliance with regulations, the funds retain admin rights over their shares “ensuring that your fund shares cannot be lost or stolen.” That is a user-protection feature, and it is also a composability constraint. The same control plane that can recover assets can also freeze flows.
On audits, Spiko provides an audit table across multiple components and dates. That includes Trail of Bits (EVM contracts, October 2023), Pessimistic (ATMv2, April 2025), and several later audits for MultiATM, minter, and Stellar contracts through 2025.
From a liquidity-structure perspective, audits help reduce “code may rug you” risk. They do not change the fact that the system is designed to be permissioned, upgradeable, and regulator-compatible. You are underwriting both smart-contract correctness and the integrity of the authorization process.
Risk register: where USTBL can break (and who eats it)
The fund-level risks Spiko highlights are classic money-market exposures: sovereign default risk (U.S. government default on short-term obligations), low interest rate risk (yields can go negative if rates go low enough), and FX risk for investors whose reference currency differs from the fund currency.
For Web3 integrations, the dominant risks shift. The biggest failure modes come from permissioning, redemption execution, and oracle-driven liquidity plumbing, because those are the mechanisms that shape effective float and exit liquidity.
If you’re modeling these risks across protocols, see our crypto research for related work on liquidity and design assumptions.
Top 3 risks
-
Dominant risk: Control-plane and compliance intervention risk
Trigger: regulatory action, sanctions screening, policy change on eligibility, or an internal incident response (lost keys, suspected theft).
Mechanism: USTBL is transfer-restricted to allowlisted addresses, enforced in the token’s transfer logic via the authority system. Admins can pause transfers, and privileged roles can mint and burn.
Who bears it: holders relying on secondary transfers for liquidity, DeFi protocols using USTBL as collateral, market makers attempting to arbitrage NAV, and any integrator whose contracts cannot be allowlisted or whose allowlist status can change.
Measurable indicators: rising failed transfers due to whitelist checks, increases in paused periods or administrative interventions, shrinking number of active allowlisted counterparties able to custody tokens, and widening gaps between on-chain swap quotes and published NAV feeds.
This is dominant because it directly attacks the thing crypto markets price first: exit certainty. With USTBL, you can have a high-quality T-bill portfolio and still end up with illiquid on-chain inventory if your address, your counterparty, or your integration path is not eligible. The same architecture that makes USTBL viable under UCITS and AMF oversight also ensures there is no “permissionless redemption arb” to compress spreads when liquidity gets thin.
The trade-off is real. Spiko’s structure aims to be safer than typical tokenized RWAs by anchoring everything in regulated custody and admin controls. In return, USTBL behaves less like a freely circulating bearer asset and more like a permissioned share ledger that happens to speak ERC-20. That is fine for treasury holders. It is a constraint for DeFi. -
Redemption execution and timing risk (operational liquidity mismatch)
Trigger: market stress, elevated redemption volumes, bank/holiday schedules, or delays in authorized execution of redemptions.
Mechanism: off-chain subscriptions/redemptions are centralized at a daily cutoff, while on-chain redemptions are recorded as pending requests that require authorized execution and have a hard deadline window in code.
Who bears it: holders who need immediate cash-out, protocols depending on deterministic redemption to manage solvency, and arbitrageurs trying to keep secondary prices aligned with NAV.
Measurable indicators: increasing share of pending redemption requests, longer time-to-execution, repeated cancellations after the maximum delay, and persistent DEX discounting versus NAV during high-demand exit windows. -
Oracle and instant-liquidity plumbing risk (price, TTL, and market-making dependency)
Trigger: stale oracle updates, feed disruptions, chain congestion, or adverse price rounding during fast market moves.
Mechanism: the ATM contract enforces an oracle freshness window and uses oracle prices to compute conversions between USTBL and a stable token, including rounding rules. If the oracle is “too old,” the contract reverts.
Who bears it: anyone relying on “instant” conversion rails, especially integrations that promise 24/7 liquidity, and lenders using USTBL as collateral whose liquidation logic depends on reliable pricing.
Measurable indicators: reverted ATM trades due to TTL checks, delayed oracle rounds, and volatility in on-chain swap spreads even when off-chain NAV is stable.
One structural mitigant worth noting is that Spiko has pursued “liquidity without selling” integrations. On September 30, 2025, Spiko announced an integration with Morpho and SG Forge stablecoins (EURCV and USDCV), allowing borrowing against EUTBL/USTBL collateral and citing a 96.5% limit loan-to-value for these tokenized money-market shares.
This does not remove the dominant risk. It just changes the pathway where it shows up. If the collateral itself is permissioned and subject to admin control, then leverage and “instant liquidity” can amplify rather than smooth stress events.
If you are designing a vault, lending market, or corporate treasury workflow around USTBL, treat this as a float design problem first and a yield problem second. This is where targeted tokenomics consulting can be useful, mainly to map operational cutoffs, allowlist constraints, and redemption execution into concrete solvency and liquidity assumptions.
This article is part of our Tokenomics Deep Dive series.








