EUTBL is a fund share, not a “token project” in the usual sense

EUTBL is the on-chain form of a regulated fund share. Concretely, it is the EUR share class (ISIN FR001400ODL1) of the Spiko EU T-Bills Money Market Fund, a sub-fund of the Spiko SICAV structure. The SICAV was created on May 15, 2024. The fund prospectus is the binding reference for that structure.

If you want a point of comparison, see our USTB review for a tokenized short-duration U.S. government securities product.

The “tokenomics” are therefore mostly the rules of an open-ended money market fund, expressed through a permissioned token wrapper and a redemption/mint operational stack. The key implication is modelability. There is no endogenous incentive loop, no emissions schedule, no liquidity mining. The token is an instrument register.

If you want a quick refresher on terminology, the tokenomics FAQ covers the basics without assuming a DeFi-native framing.

Spiko’s prospectus explicitly frames the share register as being maintained on public Distributed Ledger Technologies (DLT), where shares are “represented as tokens,” and not registered through Euroclear France.

Today, Spiko documents EUTBL as available across multiple networks, with official contract addresses published for EVM chains and separate deployments for Starknet and Stellar via official contract addresses.

Supply mechanics: elastic, flow-driven, and inherently permissioned

EUTBL supply is elastic by construction. New shares exist when subscriptions settle. Shares disappear when redemptions settle. This is the core “mint/burn” rule-set you should care about, because it makes supply a dependent variable of cash flows rather than a governance-chosen monetary policy.

The prospectus specifies the operational constraints around holding and transferring. A wallet must be validated prior to subscription (“Allowlisting”), and SICAV shares “can only be held by and transferred between investors with an Allowlisted address.”

Spiko’s tokenization docs make the same point in plain language. Shares can only be held in allowlisted addresses, and are transferable like ERC-20 tokens only inside that allowlisted set.

Fractionalization exists at the fund layer. Subscriptions and redemptions are supported in hundred-thousandths of a share beyond the minimum amounts.

Minimum subscription constraints are explicit. The Spiko SICAV prospectus lists a 1,000 EUR minimum initial subscription and 1 EUR minimum subsequent subscription for EUTBL, with “All investors” as the investor category, while still excluding U.S. Persons elsewhere in the document set.

On-chain, transfer permissioning is not “soft.” In Token.sol, transfer enforcement checks that both sender and receiver are authorized to call IERC20.transfer via the on-chain authority, reverting otherwise.

NAV-as-price: yield is embedded, not “paid out” to wallets

EUTBL is an accumulating instrument. Income and realized gains are reinvested, so performance shows up as NAV appreciation rather than distributions. The prospectus states distributable sums are fully reinvested.

The Key Information Document states income is capitalized.

That matters for DeFi composability because it removes the need for a rebasing token or a separate rewards distributor. The economic “interest” is purely a pricing function. You hold shares, NAV moves.

This differs from yield-bearing wrappers like USDtb’s design, where the “yield surface” can show up through different packaging choices.

The fund’s objective and constraints are described in the KID. It targets steady performance corresponding to the capitalized €STR (or higher) over the recommended minimum holding period, and enforces short money-market constraints including a weighted average maturity of 60 days or less, maximum residual maturity of 180 days, and weighted average life of 120 days.

Spiko’s own product docs describe the Euro fund as investing in Eurozone Treasury Bills with maturities under 6 months, with average portfolio maturity capped at 2 months, and residual cash held up to 10% to process flows.

NAV publication is treated as first-class infrastructure. Spiko’s docs list online distribution (Bloomberg and AMF) and on-chain distribution (oracle contracts per network).

From a mechanism design perspective, I like that Spiko converges on a single canonical “official price” concept. I dislike that the system still depends on operational relayers to post updates, even if the interface is standardized. Spiko’s tech blog states NAV is calculated by the fund administrator, and that their Oracle contract implements Chainlink’s standard Aggregator interface.

Fees and value flow: where yield is shaved, and where ambiguity creeps in

At the fund layer, the prospectus provides explicit fee ceilings. For the EUTBL sub-fund, management fees are listed at 0.30% incl. tax (P1), and operating expenses and other services are capped at 0.10% incl. tax (P2).

Entry and exit fees at the fund level are shown as “None” in the prospectus fee table for subscriptions and redemptions.

The KID gives a different, realized-fee view that is arguably more relevant for expected drag. It reports management and administrative/operating fees of 0.16% per year (based on actual costs during the last year) and estimated transaction costs of 0.06% per year.

Spiko’s own platform documentation states “annual fees” for Spiko Euro of 0.25% per annum, calculated and deducted daily on a pro-rata basis from accrued interest, and displayed net of fees.

For context, tokenized treasury products like Ondo’s OUSG often present fees differently across layers and access paths.

These three numbers do not cleanly reconcile from public docs alone. The binding constraint is the prospectus fee schedule and caps. The KID is a backward-looking cost disclosure under PRIIPs rules. Spiko’s platform fee statement reads like a productized “net fee” claim. Treat this as structural uncertainty unless you have a complete, current fee stack for your specific access path and share register choice.

One more important flow detail. Even if the fund charges no entry/exit fees, on-chain transfers and redemptions incur network transaction fees that vary by the DLT used, and are borne by the investor.

Control surface: the system is rule-based, but the rules are editable

EUTBL is not permissionless money. It is a regulated share register with an on-chain enforcement layer. That enforcement layer has explicit administrative power, and it is intentionally designed to be upgradeable.

Spiko’s tech blog documents upgradeable contracts via OpenZeppelin’s UUPS proxy pattern.

The on-chain authority model is explicit in code. PermissionManaged gates “restricted” functions via an external IAuthority contract that decides whether a caller can invoke a selector on a target.

The PermissionManager implements a group-mask permission system. It can add or remove users from groups, set group admins, and set per-target, per-selector requirements. Admin is group 0, and requirements unions include an admin override.

Spiko’s tech blog explains they cap the number of permission groups at 256 and represent memberships as bytes32 bitmasks for predictable gas, then lists seven operational groups including a super-admin multisig, an emergency pause operator, a daily mint/redemption operator, an oracle operator, a burner role for the redemption contract, and an allowlister.

At the token contract level, admin capabilities are concrete. Token.sol exposes restricted mint, burn, pause, unpause, and an ownership reset function.

Redemption is also formalized as an on-chain process, not an informal “burn and trust us” path. The Redemption contract is an ERC-1363 receiver. A redemption request is initiated by transferAndCall, recorded as PENDING with a hard-coded maximum delay of 14 days, then either executed (restricted operator burns the input token) or canceled (anyone can cancel after deadline and refund the user’s tokens).

Minting has its own operational throttles. The Minter contract includes per-token daily limits and a max delay parameter. If a mint would exceed the daily limit, it becomes a pending operation that can later be approved by a restricted operator.

Finally, there is a governance-like lever at the legal layer. The prospectus says the list of DLTs used for share registration “may be expanded at the discretion of the Management Company,” with investors to be notified.

This is the central tension. The system is engineered with clean interfaces and explicit parameters. Yet the parameter authority is centralized, and upgrade paths are designed in. That is defensible for regulated instruments. It is still the dominant driver of “tokenomic” risk because it breaks the assumption that the rule set is immutable.

Risk analysis: where the mechanism strains

The fund-level risk profile is intentionally low. The KID classifies the synthetic risk indicator as 1 out of 7, while still flagging DLT and wallet risks as meaningful.

The main “crypto-native” risks are not market beta. They are control rights, operational dependence, and oracle correctness.

We track similar failure modes and integration tradeoffs in our research reports, especially where admin surfaces and oracles intersect.

Top 3 risks

  1. Administrative control and rule mutability (dominant). Trigger: a compliance event, incident response, regulatory change, or business decision that motivates new transfer constraints, pauses, upgrades, or operator policy changes. Mechanism: PermissionManager can change per-function requirements and group admins, while Token.sol exposes restricted mint/burn/pause and UUPS upgrades, meaning the enforcement surface is editable by privileged actors. Who bears it: all token holders, and especially DeFi integrators relying on continuous transferability and stable semantics. Measurable indicators: upgrade events on proxy contracts, changes to PermissionManager group admin sets, token pause events, and observable increases in failed transfers due to allowlist enforcement.

  2. Oracle integrity and timing mismatch. Trigger: delayed NAV publication, data pipeline outage, or inconsistent feed usage across chains. Mechanism: NAV is calculated off-chain and then published on-chain through oracle contracts implementing the Chainlink AggregatorV3 interface. If integrators treat NAV as a live spot price, stale updates can misprice collateral or create liquidation edge cases. Who bears it: DeFi users using EUTBL as collateral, and protocols taking oracle risk. Measurable indicators: oracle update frequency, round progression, and divergence between last published NAV and contemporaneous off-chain NAV publications on official channels (AMF, Bloomberg).

  3. Liquidity under stress without formal gates. Trigger: a concentrated redemption wave, especially during adverse market conditions or operational disruptions. Mechanism: the KID states the product does not provide a mechanism to cap or suspend redemptions (“gates”), so large redemption volume can force asset sales under unfavorable conditions, decreasing NAV. Who bears it: redeeming investors via slippage in NAV, and remaining holders via mark-to-market impact. Measurable indicators: sustained increase in redemption volume, widening bid-ask or realized losses in the portfolio, and deviations of fund performance from €STR over short horizons.

Dominant risk: administrative control and rule mutability

If you want one sentence that captures EUTBL’s on-chain tokenomics, it is this: the instrument is economically simple, but institutionally permissioned. That permissioning is not just “KYC at the edge.” It is embedded into the transfer function itself. Token.sol checks that both sides of a transfer are authorized by the on-chain authority and reverts otherwise.

In isolation, that is fine. Regulated shares cannot behave like bearer assets. The real problem is second-order. A permissioned transfer rule is predictable only if the authority rule set is stable. Here, the authority is programmable. PermissionManager can change requirements for any target and selector. It can also change who is allowed to administer each group. Admin has an override unioned into requirement checks.

This means you do not have a single static “canTransfer” predicate. You have a mutable predicate plus a governance system that can rewrite it. In mechanism design terms, you do not have a constitution. You have a constitution plus an executive branch that can amend it without an on-chain vote.

Spiko does disclose the intended operational separation. Their tech blog documents distinct roles such as emergency pause operators, daily mint/redemption operators, and oracle operators. That improves internal safety. It does not remove discretionary power. It just distributes it across keys and processes.

The minting pipeline makes this visible. The Minter contract includes daily limits and a max delay parameter that can be updated by restricted actors. When the daily limit is exceeded, a mint becomes pending and requires later approval. This is a sensible operational throttle. It is also an optional choke point if ever tightened aggressively.

Redemptions are also operator-mediated at the execution step. A user initiates via ERC-1363 transfer-and-call. Execution burns the token held by the Redemption contract, and cancelation becomes available after the deadline. Again, clean interface. Still not fully autonomous.

None of this is inherently “bad.” It is just a different class of asset. The right way to hold EUTBL in a DeFi strategy is to assume: (a) transferability is conditional, (b) the authority surface can change, and (c) upgrades are a normal operating tool, not a tail event. Spiko’s own docs explicitly state that, in compliance with regulations, the funds “retain admin rights over their shares,” so shares cannot be lost or stolen. You should read that sentence as: “this behaves like a managed register, because it is one.”

One practical implication for integrators: build around allowlist-aware routing and fail-closed transfer assumptions. Do not assume DEX-style free circulation. Spiko itself states secondary transfers are legally binding and reflect permanent transfer of ownership once signed by the holder.

If you are building products around EUTBL and want external review on parameter surfaces, privilege boundaries, and failure modes, that is the narrow slice where tokenomics consulting and tokenomics design discipline are actually useful for an instrument like this. Keep it concrete. Map every “restricted()” call and every upgradable proxy to an operational playbook and an integration risk budget.



This article is part of our Tokenomics Deep Dive series.