UDS is a coordination token, while UGOLD is the game’s inflation valve

Undeads positions itself as a multi-genre Web3 games studio, with UDS intended to sit above the in-game economy as the “governance” and settlement asset for key actions, per the token overview.

In the whitepaper’s framing, UDS is used across transactions and interactions, staking, and “critical governance decisions.”

UGOLD is explicitly the in-game currency with variable supply, minted based on user activity and demand, and partially controlled via burn events for progression and eligibility gates. That design choice matters because it makes UDS scarcity legible, while pushing most day-to-day inflation pressure into UGOLD.

Supply, premint reality, and the allocation map

UDS is described as an ERC-20 token on Ethereum.

Total supply is documented as capped at 250,000,000 UDS in project materials and major trackers.

One practical note: the Undeads tokenomics page renders “Token Supply” twice, once as 250,000,000 and again as 100,000,000. The vesting table on that same page sums to 250,000,000, so the 100,000,000 figure reads like a stale UI artifact rather than a different economic regime. I would still treat this as a documentation hygiene red flag, not as a new claim about supply.

Allocations and release rules (project-published)

The whitepaper also describes the macro-policy as a capped 250 million supply, unlocking gradually over 48 months after TGE.

On major trackers, UDS is tracked with max supply 250,000,000 and contract address 0x712bd4beb54c6b958267d9db0259abdbb0bff606.

Utility sinks, payments, and internal fiscal flows

UDS has real in-product “payment rail” intent. It is used for breeding costs, marketplace purchases, and other progression accelerations.

Breeding is priced in UDS, and the whitepaper is explicit that the cost is variable and “subject to adjustment based on multiple economic factors.” This is good for keeping the economy stable in the face of demand shocks. It is also a straight line to operator discretion risk if the adjustment process is not credibly constrained or transparently governed.

Breeding-related acceleration also shows concrete UDS-denominated prices by rarity in the whitepaper (for example: Common 135 UDS, Uncommon 335 UDS, Rare 1079 UDS, Epic 2298 UDS). Those are hard sinks in the sense that they create demand to acquire and spend UDS, even if the ultimate destination of spent tokens depends on implementation details not fully specified in public docs.

Trading flows are described as UDS-settled: items can be traded in the Undeads marketplace “using a UDS token.” The design also mentions an internal AMM mechanism enabling players to exchange UGOLD into UDS to make purchases.

The marketplace section goes further: it states exclusive use of UDS for marketplace transactions, and that marketplace transactions will pay an “X% fee” to the Community Treasury. The problem is that X is not specified in the whitepaper text, so you cannot model fee capture or treasury accumulation without either code-level confirmation or an explicit parameter disclosure.

Staking emissions: a capped pool, but not a credibly neutral process

The staking story is straightforward at the headline level. There is a dedicated staking rewards allocation of 50,000,000 UDS over 48 months.

The whitepaper also claims staking rewards are paid out as a combination of UDS and UGOLD at roughly a 9:1 ratio, capped by the initial staking allocation. If accurate in live contracts, that structure reduces the amount of UDS that must be emitted to sustain engagement, while still giving players a liquid reward stream via the inflationary in-game currency.

On the project’s staking UI, Undeads advertises staking periods up to 2 years, “up to 50% APR,” and a max APR limit of 50%. It also states a staking pool of 50,000,000 UDS and “more than 1,000,000 UDS every month.” That monthly number is directionally consistent with a 50M / 48-month pool, but it is not the same thing as a deterministic emission curve. APR is a function of participation and reward allocation logic, not just the pool size.

One line in the whitepaper is worth treating carefully: it says staking rewards are “held on Undeads corresponding wallets.” If rewards are custody-managed or staged via operator-controlled wallets before distribution, then even “capped” emissions still carry operational trust assumptions.

Governance and parameter control: where discretion actually sits

The whitepaper describes UDS as a governance token, with voting rights unlocked by holding or staking a minimal amount, and with staking required for key game features and governance eligibility. No concrete “minimum” value is specified in the public text. That is not fatal, but it means governance access is not yet a parameter you can audit.

On-chain, the UDS token contract is not a Governor. It is an ERC-20 with burn functionality plus a guarded “distribution” method. The verified token contract mints its initial supply to itself and exposes transferTo, which transfers tokens from the token contract’s own balance to a target address. That function is gated by a haveRights modifier, which delegates to an external “rights” contract. In plain terms: an admin allowlist can stream tokens out of the premint vault.

The “rights” dependency itself is not just a deployment-time constant. Both the token contract and other system contracts use a GuardExtension pattern that includes setRights, which can update the rights contract address, and that call is itself gated by haveRights. That is a recursive trust loop. If you already have rights, you can potentially rewrite who has rights.

From Etherscan’s decoded constructor arguments for UDSToken, the initial rights contract address is 0xDcF111A56573eA8fd1bfEE790B45bb433017966C.

That rights contract does not have verified source code published on Etherscan. You can see Etherscan prompting the creator to “Verify and Publish” the contract. For an access-control primitive, that is a meaningful transparency gap. You can infer the interface, but not the exact authorization rules, admin update flow, or any edge-case behavior.

CoinGecko also points to a vesting contract address for UDS. Following that pointer lands on a verified vesting contract at 0xd321Fb8758b193A65BA7C13903C8272252e493A2, which holds a large UDS balance and supports claim flows.

This vesting contract is also rights-gated. It includes admin functions to pause and unpause distribution, update the token address being distributed, and update merkle roots used for claims. Each of those admin functions is gated by haveRights. Mechanically, that means the operator side can halt claims, change eligibility data, or even point the vesting system at a different token contract, subject to whatever governance exists inside the (unverified) rights contract.

Finally, don’t ignore the corporate center of gravity. The Undeads site footer references Sezual Pte Ltd. That is not inherently bad. It does anchor accountability. It also makes “governance token” language easier to misread if tokenholders assume protocol-style constraints that do not exist in the disclosed contract architecture.

Risk register (ranked) and dominant risk

Dominant risk: operator discretion over distribution and vesting eligibility

The core structural risk in UDS is not “inflation.” Supply is capped on paper. The core risk is who decides who gets the already-minted tokens, when, and under what eligibility logic.

On-chain, UDS distribution is intertwined with a rights-based admin system. The UDS token contract exposes a privileged transfer method (transferTo) gated by haveRights, and it can be repointed to a new rights contract via setRights.

The vesting contract that CoinGecko labels as the vesting endpoint is even more sensitive. It is merkle-root driven, and admins with rights can update roots, pause distribution, and update the token address used for distribution.

In a best-case implementation, this gives the team speed. You can ship, fix, rerun campaigns, and recover from mistakes. That’s the trade-off. The cost is that tokenholders are structurally subordinated to a permissioned control plane unless the rights system is constrained by strong transparency, multisig policy, timelocks, and credible governance procedures. The public docs do not provide those constraints in a way you can audit end-to-end, and the core rights contract is not source-verified on Etherscan.

Top 3 risks

  1. Rights-plane capture (dominant). Trigger: a rights-authorized actor updates the vesting merkle root, pauses claims, updates the vesting token address, or changes the rights contract itself. Mechanism: rights-gated admin functions (updateRoot, pause/unpause, updateToken, setRights) plus an unverified rights contract implementation. Who bears it: airdrop recipients, vesting beneficiaries, and secondary holders exposed to unexpected circulating supply changes. Measurable indicators: on-chain events and calls on the vesting contract (RootUpdated, Paused/Unpaused, TokenUpdated), changes in the vesting contract’s UDS balance, and any migration to a different rights contract address.

  2. Economic parameter drift inside sinks and fees. Trigger: the team changes variable UDS costs (breeding) or marketplace fee settings in response to demand, inflation, or retention goals. Mechanism: whitepaper-described costs are explicitly “subject to adjustment,” and the marketplace fee is described as “X%” without a published value, leaving a large policy surface that can move without tokenholder consent. Who bears it: players (sudden cost increases) and holders (demand and treasury capture assumptions shift). Measurable indicators: updated in-client pricing, changes in average UDS spent per breeding or acceleration action, and disclosed fee policy changes tied to marketplace flows.

  3. Unlock overhang and distribution-to-market risk. Trigger: large scheduled unlocks from ecosystem, marketing, reserve, or staking allocations hit liquid markets faster than demand grows. Mechanism: multiple allocations unlock monthly or quarterly over multi-year periods, and staking rewards are distributed over 48 months, creating persistent sell-pressure potential even without new minting. Who bears it: secondary market buyers and LPs who underwrite liquidity during unlock-heavy periods. Measurable indicators: token unlock calendar updates (as tracked by major aggregators), net exchange inflows, and sustained declines in vesting contract balances over time.

If you’re approaching UDS as an investor, the diligence work is less about “is the supply capped” and more about “is discretion constrained.” Verify who controls the rights plane. Verify whether those controls are time-locked, multi-sig governed, and publicly documented. For definitions and framing, the tokenomics FAQ can help, and for deeper dives you can browse our research notes.

For teams building similar systems, this is also where tokenomics design either earns trust or leaks it. If you want tokenomics consulting on how to keep iteration speed while reducing operator discretion, the usual fixes are boring but effective: explicit parameter bounds, timelocks, publishable governance processes, and minimizing upgrade keys wherever possible.



This article is part of our Tokenomics Deep Dive series.