Tevaera (TEVA) Price

TEVA is Tevaera's native utility token for its onchain gaming ecosystem. Official documentation lists its uses as Teva Chain transaction processing fees, operating nodes to support a decentralized gaming platform, play-and-earn economies for game agents, tournaments, and game modes, and community governance. These are protocol and ecosystem functions; they do not mean that holders obtain equity in the project company, fixed income, or redemption rights. The token is designed for different parts of the network and gaming economy, but whether specific functions are available still depends on the relevant product and governance implementation.

TEVA's uses can be divided into the network layer, gaming-economy layer, and governance layer. At the network layer, it is listed as a token related to Teva Chain transaction processing fees and node operation; at the gaming-economy layer, it is designed for play-and-earn mechanisms involving game agents, tournaments, and game modes; at the governance layer, it carries the community's voting rights over ecosystem development. Therefore, “TEVA can be used in games” does not mean every in-game item must be purchased with TEVA, nor does holding the token itself automatically generate gaming rewards. Actual transactions, participation eligibility, and reward conditions are determined by the relevant product or governance rules.

Each TEVA represents one vote, but voting power must first be activated through delegation. Holders may delegate their voting power to their own address or to a third-party address; the controller of an address that receives voting power becomes a Delegate and may represent that voting power in governance decisions such as Tevaera Improvement Proposals. Delegation changes which address exercises voting power; it does not mean transferring token ownership to the delegate. Before delegating, holders should distinguish the consequences of “voting for yourself” from authorizing third-party representation, and verify the actual rules of the governance interface and proposal.

TEVA has a total supply of 4 billion tokens. The official allocation framework is: community and ecosystem 51%, early supporters 20%, team and advisors 18%, foundation 7.5%, and liquidity 3.5%. Community and ecosystem includes 36% for ecosystem and growth, 10% for Teva Guard, and 5% for the airdrop. These percentages describe the allocation framework for total supply, not the amount freely tradable at a particular time. In particular, ecosystem incentives, airdrop eligibility, and subsequent allocations must still be implemented under their respective rules; an individual's obtainable amount cannot be inferred solely from category percentages.

The official allocation document states in its TGE plan that 382.4 million TEVA, or 9.56% of total supply, is planned to be circulating; this is a TGE-based arrangement and should not be treated as the current real-time circulating supply. The document also states that, within the circulating portion, 1% is allocated to early investors, 3.5% is for trading liquidity, and community tokens are provided through airdrop claims. Vesting and cliffs determine when certain allocations begin to unlock. For example, team and advisors are at 0% at TGE, followed by a 12-month cliff and vesting over 48 months; the foundation is at 0% at TGE, followed by a 3-month cliff and vesting over 12 months. Different early-supporter rounds have their own TGE percentages, 3-month cliffs, and 12- or 24-month vesting periods.

The current TEVA contract listed in the official token documentation is on the Base network, at 0x00309D634d11541b857f927BE91aD2f0bD78894c; the same document separately lists the old zkSync Era contract address, 0xdbFF7c6d368904680706804645cAfA4dEfa3c224. These labels indicate that the network and contract are inseparable conditions for identifying the asset. The “old zkSync Era contract” should not be treated as an address freely interchangeable with the Base contract, and the token name alone cannot determine whether cross-network transfers are possible. Before transferring, depositing, or interacting with a contract, both the network and contract address supported by the platform should match.