The Tokenomics of STASIS EURO (EURS)

EURS is a euro stablecoin where the “real float” is the product

EURS (STASIS EURO) is not trying to be a high-FDV token with a narrative. It is trying to be a settlement instrument that tracks €1 and moves across rails that crypto actually uses: CEXs, DeFi pools, and multi-chain plumbing. The token is an ERC-20 on Ethereum at its token contract address (0xdb25…7ad8), and the contract’s decimals are 2, which matches “cents-style” accounting rather than 18-decimal DeFi-native conventions.

The design choice that matters most for market behavior is not the peg mechanism in the abstract. It is how much EURS is effectively available to trade, and under what conditions that float can expand, contract, or get stuck. On that score, EURS reads like a classic issuer-controlled stablecoin: centrally managed issuance and redemption, plus explicit on-chain control hooks for freezing, blacklisting, and fee parameter changes.

If you are modeling EURS as “124M coins times price equals market cap,” you are doing the wrong work. CoinGecko does list 124,125,940 as circulating and total supply and shows max supply as infinite in its aggregator supply listing. But STASIS also publishes a separate “in circulation” figure on its transparency dashboard that is much lower at the time of capture. That gap is where the liquidity structure lives.

Supply mechanics: discretionary issuance, owner-burn, and why “circulating supply” is contested

On Ethereum, EURS presents a “total supply” figure that aggregators may treat as circulating supply by default. For issuer-controlled stablecoins, that mapping can be directionally wrong for liquidity analysis, because issuer-controlled inventory and operational wallets can be large and not meaningfully tradable.

If you want a terminology baseline for how “circulating,” “total,” and “float” get used (and abused), the supply metrics FAQ is a helpful refresher.

STASIS’s transparency dashboard, however, reports 7,364,968 EURS in circulation at the time of capture, alongside a chain-by-chain breakdown (for example, €7,310,291.14 on Ethereum and €3,889,835.71 on Polygon “via 3rd party bridge”). Those numbers cannot both represent the same definition of “circulating” as typical aggregator frameworks use. Practically, it implies the “token contract totalSupply” view is not a good proxy for tradable float, and STASIS is trying to publish an “outstanding liabilities” view that nets out issuer-controlled inventory or other non-market balances.

Mechanically, the smart contract supports issuer-controlled supply changes. The function createTokens(uint256) can increase total supply, but it hard-requires msg.sender == owner. Similarly, burnTokens(uint256) is owner-only and reduces tokensCount (the value returned by totalSupply()).

Two implications follow, and they are liquidity implications, not “tokenomics narrative” implications.

First: there is no algorithmic issuance schedule and no credible notion of “unlock cliffs.” Supply is a policy decision, gated by the contract owner.

Second: if you want to understand EURS market impact, you should track (a) how much sits on venues and in pools, and (b) how much can be mobilized quickly from issuer-controlled wallets and bridging contracts. The second component can be “non-circulating” under STASIS’s transparency definition while still being very real supply that can hit the market if operational policy changes.

One more detail matters for modelability: the token is implemented through a proxy pattern. That is not automatically bad, but it does mean “what the contract can do” is not the only question. “Who can upgrade or steer the proxy” is part of your risk model.

Finally, STASIS’s legal terms include a line that “all EURS will be generated when the Ethereum Smart Contract is deployed.” That statement is in tension with the on-chain contract design, which includes an owner-only mint function. The correct way to handle this is not to pick a side. It is to treat public docs as imperfect, and anchor “supply truth” to on-chain state plus issuer disclosures.

On-chain control surface: blacklisting, freezing, fee switches, and delegated transfers

EURS is built with explicit administrative levers.

Blacklisting: The contract defines a BLACK_LIST_FLAG and blocks transfers if either party is flagged. In transfer, it returns false when (addressFlags[msg.sender] | addressFlags[_to]) hits the blacklist flag. There is also an owner-only setFlags function to set these flags per address.

Freezing transfers globally: The owner can freeze and unfreeze transfers via freezeTransfers() and unfreezeTransfers(). Both are owner-gated, and the transfer paths short-circuit when frozen is true.

Transfer fees as a controllable parameter: EURS includes fee logic in transfer, transferFrom, and delegatedTransfer. The contract can charge a fee to a feeCollector unless either side is flagged with ZERO_FEE_FLAG. The owner can change fee parameters using setFeeParameters.

Notably, the constructor initializes fee parameters to a fixed fee of DEFAULT_FEE = 5e2, and sets the variable fee numerator to zero. With 2 decimals, that constant reads like “5.00” in token units. I am not asserting this fee is currently active on typical transfers because that is a state question, not a code question. The point is that fees are possible, adjustable, and centralized.

Delegated transfers (gas abstraction): The contract implements delegatedTransfer, which uses ecrecover with a per-sender nonce to authorize transfers and includes fee flows. STASIS markets this as delegated payments, explicitly claiming users can avoid paying gas in ETH and instead pay fees in EURS or other supported assets in the STASIS wallet context.

This is a coherent product choice. It also means there is no clean separation between “token” and “payments stack.” The token contract anticipates relayers, fee collection, and policy flags. That is great for UX. It raises the importance of governance and operational transparency for anyone treating EURS as a core treasury asset.

Backing and redemption: the peg is off-chain, and the terms matter

STASIS positions EURS as fully backed by assets “generally but not exclusively” consisting of euro deposits or other EUR-denominated low-risk and liquid assets. It also emphasizes that the funds are held in a safeguarded account structure and are not bank deposits covered by deposit guarantee schemes, which is a real distinction in a stress event.

On redemption mechanics, STASIS states:

Redemption price: each EURS is set at EUR 1, and “for redemptions, no fees shall apply,” redeemed at par.

Redemption flow: users redeem by sending EURS on-chain to the STSS treasury wallet address, after which STASIS transfers euros from a segregated bank account to the user’s bank account. The redeemed EURS are “frozen or subsequently burnt.”

That last sentence matters for supply optics. If redeemed tokens are burned consistently, then totalSupply should track outstanding liabilities more closely over time. If redeemed tokens are instead frozen and retained, then totalSupply becomes less informative for float analysis. The on-chain contract supports burning, but it is owner-only, so you are trusting operational policy.

STASIS also reserves the right to prohibit specific wallet addresses from receiving or transferring EURS if directed by law enforcement, courts, or regulators. That policy-level statement aligns with the on-chain flagging and freezing surface described above.

Fiscal flows: where fees can exist, and where they explicitly do not

EURS is a stablecoin, so there is no protocol-native “staking yield,” no emissions, and no burn-to-accrue value loop. Fiscal flows are operational.

On-chain transfer fees (optional): The contract can route a fee to a feeCollector on transfers, and the owner can change fee parameters. In practice, stablecoins typically keep such fees at zero for normal transfers because liquidity is the business. But the important part for a risk-adjusted tokenomics view is that the fee switch exists and is centrally controlled.

Redemption fees (explicitly “no fees”): STASIS’s terms explicitly state no fees apply to redemptions and that each token redeems at par.

Bridge-related costs and risk externalities: STASIS’s transparency materials warn that bridging to some chains occurs through third-party services and that STASIS assumes no responsibility or liability for the security of bridged tokens. That disclaimer is not a “fee,” but it is an economic term. It pushes expected loss from bridge exploits onto users and integrators, which should influence where you accept EURS liquidity and how you haircut bridged balances.

Reserve transparency / assurance as an operating cost: STASIS claims a transparency stack including daily account statements and third-party audits, and lists specific report dates on its EURS transparency materials. I cannot responsibly compress the content of those PDFs here because the download links are not exposed in the captured page text, but the existence and cadence claims are still part of the token’s operational promise.

Liquidity structure: EURS is small-float money with multi-rail fragmentation

STASIS’s transparency dashboard reports 7,364,968 EURS in circulation and then splits that across chains, with Ethereum and Polygon dominating the disclosed distribution at the time of capture. From a liquidity structure realist perspective, two things matter here.

1) Effective float is probably closer to “in circulation” than “totalSupply.” When aggregators report a much larger “circulating supply,” they are applying a generalized crypto-asset framework. For an issuer-controlled stablecoin, that label can be misleading if large balances sit in issuer-controlled addresses, escrow-like wallets, or other non-market buckets. STASIS publishing a lower “in circulation” number is essentially admitting that “tradable float” is a curated figure, not a raw on-chain primitive.

2) Fragmented rails create localized peg stress. EURS liquidity is not a single pool. It is a set of venue-specific and chain-specific micro-markets, including circulation on Polygon “via 3rd party bridge,” plus smaller amounts on other networks. In practice, this means:

When EURS trades off-peg, it is often not “fundamental insolvency” being priced in immediately. It can be a local liquidity imbalance. Thin pools, bridge friction, or CEX withdrawal constraints can produce transient dislocations. With a small effective float, those dislocations can be outsized relative to the token’s headline market cap.

This is also where FDV thinking breaks down completely. A “max supply is infinite” label is technically correct under a “mintable stablecoin” lens, but economically irrelevant. EURS supply expands only if someone wants exposure and can onboard, and contracts if redemption demand clears operationally. The real constraint is balance-sheet and compliance throughput, not token code scarcity.

Risk analysis: EURS is a claim on an operator

EURS works when you treat it like what it is: a centrally issued liability with an on-chain wrapper. You get euro exposure with blockchain transferability. You also inherit operator risk, governance risk, and liquidity venue risk.

Dominant risk: redemption and reserve integrity under stress.

STASIS’s terms describe EURS as backed by comparable-value assets like euro deposits or other EUR-denominated low-risk and liquid assets, held in safeguarded accounts. Its transparency dashboard goes further, claiming reserves are stored in central bank accounts and displaying a breakdown showing a “Lithuanian Central Bank via Nexpay” line at the time of capture.

That is directionally reassuring. It is not the same thing as guaranteeing timely redemption for all holders in all conditions. The mechanism-level failure mode is straightforward:

If redemption demand spikes, EURS holders are effectively running a liquidity test against STASIS’s operational capacity, banking rails, safeguarding structure, and asset liquidity. Even if assets are high quality, you still have settlement timing, compliance checks, and coordination risk. If any part of that chain slows, on-chain EURS starts trading as a discounted claim on future euros, and the discount is set by the cheapest available exit, which is often a DEX pool or a single CEX order book.

Supply optics amplify this. Public aggregators can list ~124M “circulating,” while STASIS publishes ~7.36M “in circulation.” In a stress event, market participants will not patiently reconcile definitions. They will react to whichever number supports their worst-case. That is not a branding problem. It is a liquidity problem.

On-chain admin controls layer on top. Even if a freeze is intended for compliance, the existence of owner-controlled global freezing and address flagging changes the tail risk distribution for DeFi integrators. If a large pool or lending market ends up with blacklisted exposure, composability breaks in ways that look like “smart contract risk” even though the trigger is governance.

For a comparable “issuer risk wrapped in a stablecoin ticker,” contrast EURS with the GUSD tokenomics review, which frames similar trust and liquidity questions in a USD context.

If you want more background on how these failure modes show up in practice, our crypto research reports cover recurring liquidity and integration pitfalls across tokens.

Top 3 risks

1. Trigger: large redemption wave or partial loss of confidence in reserve handling. Mechanism: redemption throughput limits and settlement delays cause EURS to trade as a discounted claim, with the discount discovered in thin on-chain/CEX liquidity rather than in an orderly primary market. Who bears it: secondary market holders, LPs in EURS pools, protocols using EURS as collateral. Measurable indicators: widening EURS deviations vs €1 on venues, shrinking DEX pool depth, and divergence between aggregator “circulating supply” and issuer “in circulation” figures.

2. Trigger: compliance action (court/regulator/law enforcement request) or issuer policy change. Mechanism: address-level restrictions via terms plus on-chain blacklist flags and global freeze capability break transferability and DeFi composability. Who bears it: affected wallet holders, protocols holding EURS in contracts that cannot remediate quickly, and LPs exposed to frozen balances. Measurable indicators: on-chain transfer failures, evidence of blacklisting logic in the contract (BLACK_LIST_FLAG, setFlags) and freeze functions.

3. Trigger: third-party bridge exploit, bridge halt, or bridge-provider insolvency. Mechanism: bridged EURS representations become impaired or unredeemable on the destination chain, creating chain-specific depegs and trapping liquidity away from primary redemption rails. Who bears it: bridged EURS holders, cross-chain LPs, and protocols accepting bridged EURS as “same as mainnet EURS.” Measurable indicators: sudden supply/flow anomalies on the bridged chain, widening price gaps between chain markets, and issuer disclaimers that bridge risk is user-borne.

If you are integrating EURS into a protocol or treasury policy, the actionable move is to treat “EURS” as a family of exposures: issuer exposure, chain exposure, and bridge exposure. Do not let a single ticker flatten those risks.

If you need help stress-testing parameters or designing a safe integration policy, this is where token economy design and limited-scope tokenomics design services can be worth paying for, because most failures are about liquidity routing and admin constraints rather than “token incentives.”

This article is part of our Tokenomics Deep Dive series.