MANTRA (MANTRA) sustainability report

NameBlockNodes SAS
Relevant legal entity identifier969500PZJWT3TD1SUI59
Name of the crypto-assetMantra
Beginning of the period to which the disclosure relates2025-09-27
End of the period to which the disclosure relates2026-09-27
Energy consumption38031.76075 kWh/a

Consensus Mechanism

Mantra is present on the following networks: Mantra.

MANTRA is a sovereign layer-one chain built with a widely used modular framework and driven by its Byzantine fault tolerant consensus engine, aimed specifically at assets that carry regulatory obligations. Blocks are committed in rounds rather than mined: one validator from the active set proposes a block, the set exchanges a round of prevotes and a round of precommits, and the block commits once precommits representing more than two thirds of bonded voting power have been gathered. Finality is deterministic and arrives with the commit in a few seconds, with no confirmation depth to wait out and no competing chain tip to resolve in normal operation. Safety holds while validators controlling less than a third of bonded power deviate from the protocol; past that threshold the chain stops producing blocks rather than splitting, which is the deliberate trade this family of consensus makes.

Validators are ranked into a capped active set by the total stake delegated to them, and holders who do not run infrastructure delegate to an operator of their choice and share in its rewards. Penalties are real rather than nominal: signing two conflicting blocks at the same height results in confiscation of a proportion of bonded stake, applied to the validator and its delegators alike, together with permanent removal from the set, while sustained failure to sign incurs a smaller confiscation and temporary suspension. Unbonding takes a fixed waiting period during which stake remains exposed to penalty.

Two features distinguish the chain from others in its framework family. Execution is not limited to one environment: a native contract environment sits alongside an Ethereum-compatible one, sharing state through interface layers so that contracts written for either can call the chain's staking, governance and asset modules directly. And compliance is enforced at the protocol level rather than in individual contracts, so an address that has not satisfied the applicable identity requirements cannot receive a token representing a regulated asset. Interoperability runs over the framework's native inter-chain messaging and, for external networks, through a separate messaging layer.

Incentive Mechanisms and Applicable Fees

Mantra is present on the following networks: Mantra.

Validators are paid from issuance of the native asset together with the fees collected in the blocks they commit, distributed across the active set in proportion to bonded stake. Each validator declares a commission, taken before the remainder is shared among delegators in proportion to their contributions, with a ceiling on how fast that commission may be raised so delegators are not repriced without notice. Delegation is the principal route to participation, and it carries genuine risk rather than only opportunity cost, since the penalties described above apply to delegated stake as well as to the operator's own bond.

Users pay gas fees denominated in the native asset, metered by the computational and storage resources a transaction consumes, with validators able to set a minimum price they will accept. Transactions submitted through the Ethereum-compatible environment are priced through the same accounting rather than through a parallel fee market, so the choice of execution environment does not change what a given amount of work costs. Governance proposals require a deposit, refunded if the proposal reaches a vote and forfeited if it fails to attract sufficient support, which prices the chain's attention and discourages frivolous submissions. There are no recurring rents charged on holdings.

Two changes to the network's economics are worth recording because they affect how its history reads. Following a governance vote passed in late 2025, the native asset was redenominated, with holdings restated at a fixed ratio and a new ticker replacing the former one during 2026; the redenomination altered unit counts rather than any holder's proportional position. Separately, an acquisition of the entities operating the chain was announced in 2026, which changes the ownership of the organizations holding relevant licenses and operating infrastructure without altering the protocol's consensus or fee mechanics.

The compliance modules described above also shape the fee experience in one respect: transfers of regulated assets to addresses that have not cleared the applicable checks fail at the protocol level, and a failed transaction still consumes the gas spent attempting it.

Energy consumption sources and methodologies

Mantra is present on the following networks: Mantra.

The estimate is a node-level one, and this network offers an unusually firm starting point for it. The active validator set is capped by an on-chain parameter and its membership is readable directly from the chain's staking module, so the count of consensus-participating machines is a known quantity rather than something inferred from crawling anonymous peers. That removes the largest single uncertainty affecting most estimates of this kind and shifts the question to what sits behind each of those registered identities.

Beyond the active set, three further populations consume power and must be sized separately. Candidates outside the active set run infrastructure while waiting to be elected, and their machines draw power whether or not their operator is currently validating. Full nodes operated by exchanges, explorers, applications and the chain's own service infrastructure hold complete copies of the ledger without participating in consensus, and are estimated from public listings and network observation. Nodes serving remote procedure calls to applications carry query load that can exceed a validator's own work at busy times, and are counted within that population.

Representative hardware is derived from the published requirements for running the node software, which state processor, memory, storage and bandwidth expectations. Measured power draw for machines of that description, taken under load and at idle, is applied across each population and weighted heavily toward idle, because a node in a chain of this size spends the great majority of its time validating and gossiping rather than working hard. Supporting an additional execution environment raises the computational demand per transaction somewhat but does not change the shape of the estimate.

The limitations are stated plainly. Operators commonly run redundant and backup machines that are invisible from outside, so the count behind each registered identity is an assumption rather than an observation. Hosting arrangements obscure how many physical devices underlie a given endpoint. Where evidence is thin the conservative assumption is preferred, more likely to overstate than understate, and figures are revised as observation improves.

Key energy sources and methodologies

Mantra is present on the following networks: Mantra.

Locating this network's machines rests on a mixture of disclosure and observation, weighted toward disclosure more than is typical. Validators publish identity information because delegation depends on reputation, and a chain built for regulated assets attracts operators who are themselves regulated or institutional and who therefore disclose where they operate as a matter of course. That gives a geographic distribution for the capped active set founded on stated fact rather than inference. Candidates outside the active set are generally visible on the same basis. Full nodes and query-serving infrastructure are located through network observation and hosting provider address ranges, with materially less confidence.

Each located machine is matched to published statistics for the grid supplying its region, and the renewable share reported is the average across those grids weighted by the consumption attributed to each location rather than by machine count.

Two limitations bear particularly on this network. First, a capped and partly institutional validator set is small, so the distribution is built from few observations and a single operator relocating can move the result perceptibly, where a network of thousands of nodes would absorb the same change without notice. Second, institutional operators favor commercial hosting facilities that do not publish their supply arrangements, so a regional grid average substitutes for the actual supply of a specific building. Grid statistics are annual and regional and conceal daily and seasonal variation, and contractual renewable purchases are not counted because the method describes the physical grid mix a machine draws from.

Energy intensity per transaction is period consumption divided by transactions settled in the period. Because the validator set is capped, consumption is close to fixed with respect to throughput: an additional transaction causes almost no additional energy, and the intensity figure falls as the network is used more without any change in the underlying energy use. It should be read as an average across the period rather than as the marginal energy cost of one further transfer. Source data is processed by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy: Share of electricity generated by renewables.

Key GHG sources and methodologies

Mantra is present on the following networks: Mantra.

Emissions are derived from the consumption estimate by applying a grid carbon intensity to the electricity drawn at each location, reusing the distribution established for the renewable share and summing across validators, waiting candidates, full nodes and query-serving infrastructure. The boundary covers operational electricity only; manufacture of the hardware and construction of the facilities housing it are outside it, and no factor is applied for either.

Scope 1 covers emissions from sources under the direct control of node operators, which for servers in commercial hosting facilities means occasional backup generation during outages. It is a negligible contributor here and is reported as such rather than modeled in detail. Scope 2 covers emissions embodied in purchased electricity and accounts for effectively the entire footprint.

One structural point shapes this network's emissions profile. Because the active validator set is capped by protocol parameter, total emissions are bounded by a number the protocol fixes rather than by market conditions. Growth in usage adds work to machines that are already running rather than adding machines, and an increase in the value of participation does not draw additional hardware into consensus the way it does on networks where security scales with expenditure. Emissions move when the cap changes, when the pool of waiting candidates grows, or when operators relocate.

Greenhouse gas intensity per transaction is period emissions divided by transactions settled in the period, and inherits the caveat given for energy intensity: consumption is close to fixed with respect to throughput, so the quotient describes an average rather than the emissions caused by one further transaction. Uncertainty compounds through the calculation, since an error in the machines assumed behind each registered identity propagates into consumption and from there into emissions, and grid intensities are annual averages concealing substantial variation across a day and a year, which a small and geographically concentrated node population is less able to average out. Figures are restated each period as observation improves. Carbon intensity data is processed by Our World in Data from Ember and the Energy Institute's Statistical Review of World Energy, and is made available under a Creative Commons BY 4.0 license: Carbon intensity of electricity generation.