Ta-da (TADA) sustainability report

NameBlockNodes SAS
Relevant legal entity identifier969500PZJWT3TD1SUI59
Name of the crypto-assetTa-Da
Beginning of the period to which the disclosure relates2025-09-27
End of the period to which the disclosure relates2026-09-27
Energy consumption2.20786 kWh/a

Consensus Mechanism

Ta-Da is present on the following networks: Binance Smart Chain, Multiversx, Solana.

BNB Smart Chain, the programmable chain of BNB Chain and formerly styled Binance Smart Chain, reaches agreement through Proof of Staked Authority, a design that borrows stake-weighted election from delegated proof of stake and rotating, permissioned block production from proof of authority. Bonded stake decides who may produce blocks rather than who wins any individual slot. The network keeps an active set of forty-five operators, ranked by the amount of the native asset bonded to them through self-delegation and through delegation from holders. The twenty-one highest-ranked form the cabinet tier and the next twenty-four are candidates, with everyone below inactive and producing nothing. Rankings are recomputed once a day, so membership of the set turns over on a daily cycle rather than per block.

Within each epoch a consensus group of twenty-one is drawn from the active set, weighted heavily toward the cabinet tier, and those operators take turns proposing in a fixed rotation. Turn length and epoch length are protocol parameters that have been retuned repeatedly as block intervals shortened: successive upgrades cut the interval from three seconds to 1.5, then to 0.75 in mid-2025, and to 0.45 seconds in January 2026. A separate voting layer sits above the rotation, in which validators sign attestations on recent blocks; once enough signatures accumulate a block is treated as final, giving deterministic finality in roughly a second. Should that voting layer stall, the chain falls back to confirmation by accumulated depth, which takes minutes rather than seconds.

Security rests on an honest supermajority of a deliberately small elected set, backed by on-chain penalty logic. A slashing contract watches for double signing, for contradictory attestations in the fast-finality vote, and for repeated failure to produce during an assigned turn. Consequences range from temporary jailing and lost rewards through to removal from the set and forfeiture of part of a validator's own bonded stake. The trade-off is deliberate: a compact, frequently re-elected validator set buys very short block intervals and cheap execution, at the cost of the broader operator base that larger validator sets provide.

MultiversX secures itself with Secure Proof of Stake, a stake-weighted consensus in which validator duty is assigned by verifiable randomness rather than negotiated, run across a sharded state. The network is divided into execution shards, each holding only its own slice of the global state and processing only the transactions belonging to it, alongside a coordinating metachain that notarizes shard blocks, settles cross-shard traffic and handles epoch-level bookkeeping. Mainnet has operated with three execution shards plus the metachain since launch. The sharding is adaptive because the metachain recomputes the shard count at each epoch boundary from processing load and node availability, and can in principle split or merge shards; in practice that adjustment has not been triggered and the count has stayed stable.

An operator becomes a validator by locking a fixed amount of the native asset per node and registering a long-lived signing key. At each epoch — roughly a day — validators are deterministically reshuffled between shards using the protocol's randomness, with a fraction of every shard's membership moved elsewhere, which prevents any group from settling into one shard long enough to coordinate against it. Within a round, randomness is derived from the previous proposer's signature over the last seed, hashed with the round number; every eligible validator computes a score from its public key and that value, and the lowest score wins the right to propose. Agreement on the proposal uses aggregated BLS signatures in two phases, with validators returning signature shares that combine into a single constant-size signature, and roughly two thirds of the group required to commit. Since the Andromeda upgrade the full consensus group of the shard signs each round rather than a smaller randomly drawn subgroup.

Each validator also carries a rating reflecting its record of proposing and signing. A successful proposal adds a small increment while a missed one subtracts several times as much, with the penalty compounding on repeated failures, so recovery is slow by construction. A rating below the threshold at an epoch boundary sends the validator to jail, out of the shards and earning nothing until released. Rating now governs shard assignment at the shuffle rather than selection within a round. A subsequent protocol upgrade separates agreement from execution, letting validators vote on a proposed block before its transactions run and notarizing the resulting state afterwards, which shortens the round substantially.

Solana runs a proof-of-stake network in which the right to produce a block is allocated in proportion to the quantity of the native asset staked to each validator. What sets the design apart is that ordering is established before agreement is sought. A designated leader runs a sequential hash chain, each output feeding the next input, so the chain cannot be computed faster than a fixed number of steps and a transaction's position within it is evidence of when that transaction was received. This construction, called proof of history, spares validators from negotiating timestamps with one another and lets the rest of the protocol treat the order of events as already settled.

Leadership is not auctioned block by block. At the start of each epoch, which runs for roughly two days, a schedule is derived deterministically from the active stake distribution and assigns every short slot in the epoch to a named validator. Slots follow one another a few hundred milliseconds apart. The scheduled leader gathers transactions, executes them and streams the resulting block to the rest of the set in small fragments relayed through a tree structure rather than pushed to every peer at once. Receiving validators replay the block independently and publish votes for the fork they consider canonical.

Fork choice weights those votes by stake, and each vote commits a validator to its chosen fork for a period that doubles with every further confirmation, so abandoning a block grows steadily more costly. A block that a supermajority of stake has voted on is treated as confirmed within about a second, and it is locked in permanently once enough additional confirmations accumulate, which takes on the order of ten seconds. Safety rests on the assumption that participants acting dishonestly control less than a third of staked value. A revision of the voting layer, approved in a stake-weighted validator vote, is being activated on the main network in stages; it retains stake-weighted validation and the existing block distribution scheme while replacing the incremental lockout rule with direct voting that settles in one or two rounds.

Incentive Mechanisms and Applicable Fees

Ta-Da is present on the following networks: Binance Smart Chain, Multiversx, Solana.

BNB Smart Chain pays for its own security out of transaction fees rather than out of new issuance. The native asset carries no protocol-level block subsidy, so every reward reaching a validator or a delegator originates in gas paid by users. When a block is finalized the proposer's collected fees are routed into system contracts and split three ways. A governed fraction is sent to an unspendable address and permanently removed from supply, a slice accumulates in a reward vault used for network-wide purposes such as paying for fast-finality attestations, and the balance sits in the validator-set contract until it is distributed, on a daily cycle, to active validators and the holders who delegated to them.

Participation is staking-based. An operator must self-delegate a substantial amount of the native asset before it can be considered for the active set, and holders may bond additional stake to any validator to lift its ranking. Delegators receive their proportional share of whatever the validator earns, after the commission that validator sets for itself, and only the forty-five ranked operators earn at all: stake bonded to an inactive validator yields nothing. Unbonding is subject to a waiting period, so stake cannot be pulled out the instant misbehavior comes to light.

Penalties are graduated. Missing assigned turns or going offline for a sustained stretch triggers jailing, during which the validator produces nothing and earns nothing. Double signing and contradictory attestations in the finality vote are treated far more severely and can cost the validator a portion of its own bonded stake alongside ejection from the set.

Users face a conventional gas-metered fee model inherited from the Ethereum virtual machine. Each operation carries a gas cost, the sender chooses a gas price, and the total is charged in the native asset. There is no separate storage rent, so the cost of persisting state is bundled into execution gas, and deploying or calling a contract is priced purely by the computation and storage it consumes. The minimum acceptable gas price is a coordinated parameter that operators and infrastructure providers have revised downward several times, keeping ordinary transfers and contract calls inexpensive in absolute terms.

Validators earn from two sources: newly issued units of the native asset and the fees paid by users, both distributed per epoch across the nodes that carried consensus duty. Because validator slots require a fixed stake per node rather than a proportional one, an operator scales by running more nodes rather than by bonding more behind a single one. Holders who do not want to operate infrastructure can route their stake through delegation contracts, which pool contributions, run nodes on the pool's behalf, take a declared service fee, and pass the remainder back to contributors pro rata. Unstaking is not immediate: released stake sits through a protocol-defined delay before it can be withdrawn, and a node stays in service until the protocol formally releases it.

Discipline runs mostly through the rating system rather than through confiscation. A validator whose rating falls below the threshold is jailed at the epoch boundary, removed from its shard and earning nothing; returning requires an unjailing transaction that carries a fixed fee per node and reinstates the validator at a reset rating, treated as a newcomer. There is an exception where jailing would push a shard below its minimum safe size, in which case the validator stays. Outright slashing of stake is reserved for serious misbehavior, alongside removal of validator status, so ordinary unreliability costs foregone rewards and reputation rather than principal.

Fees are charged in gas and paid in the native asset. A transaction's cost has two components: a movement component covering the transfer itself and the bytes of attached data, and an execution component covering whatever contract code runs. Gas is quoted as a limit up front and the unconsumed remainder is refunded after processing, so a generous limit costs nothing beyond what was actually used. One arrangement is distinctive: a fixed share of the gas fee of every smart contract call — currently three tenths — accrues to the account that deployed the contract and can be claimed on demand, which turns contract usage into a direct revenue stream for its developer and makes it practical for an application to sponsor the fees of its own users. Cross-shard transactions carry the additional cost of the metachain settlement that moves them between shards.

Two streams of payment reach validators. The protocol issues new units of the native asset on a defined schedule and distributes them at the close of every epoch to validators and to the stake delegated to them, in proportion both to that stake and to the voting credits the validator actually accrued over the epoch; an operator that missed its slots or stopped voting accrues fewer credits and receives a correspondingly smaller share. Holders who do not wish to run hardware delegate through a stake account to an operator of their choice, retain control of that account, and receive the reward net of whatever commission the operator has set. Delegated stake becomes active and inactive only at epoch boundaries, so capital committed to securing the network cannot be pulled out on demand.

Users pay a fixed base fee for every signature a transaction carries. Half of that amount is destroyed and half is paid to the validator that produced the block. A transaction may attach an optional priority fee, quoted per unit of requested compute, which under a protocol change adopted in 2025 goes in full to the block producer; this is the mechanism that rations capacity when demand exceeds what a slot can hold. Program execution is metered in compute units against a per-transaction ceiling, so the cost of a contract call tracks the work it requests rather than a flat tariff.

Storage is charged once, not continuously. An account has to hold a minimum balance scaled to the number of bytes it occupies in order to be exempt from rent, and that balance is a refundable deposit rather than a fee: closing the account returns it. Recurring rent collection has been switched off at the protocol level and rent-paying accounts can no longer be created, so ongoing storage charges do not form part of the fee model as it now stands.

Staked assets are not confiscated by the protocol. No implemented mechanism automatically destroys a validator's stake for equivocation or for being offline; the cost of downtime is forgone reward set against operating expense, including the fees an operator pays to submit its own votes. A scheme to record provable duplicate-block violations on chain, as groundwork for any future economic penalty, is still at proposal stage and would not itself remove stake.

Energy consumption sources and methodologies

Ta-Da is present on the following networks: Binance Smart Chain, Multiversx, Solana.

The energy figure for BNB Smart Chain is built upward from the node population rather than downward from operator revenue, which is the appropriate treatment for a staked network where block production is not a computational race. Nothing about the fee model or the value of the native asset determines how much hardware is deployed: the size of the validator set is fixed by protocol, and the wider population of non-validating nodes is driven by demand for chain access.

The estimate has three inputs. The first is the number of machines. The elected validator set is known from the chain itself, while the surrounding population of full and archive nodes is approximated from peer-discovery crawls, public node listings and network scans, all of which observe only nodes willing to accept inbound connections and therefore tend toward undercounting. The second input is a representative hardware profile per node, inferred from the client software's published requirements, which on this chain are demanding relative to slower networks of the same family, since sub-second block intervals and rapid state growth push operators toward high core counts, large memory and fast solid-state storage. The third is the electrical draw of such a machine, taken from measurement of comparable configurations on the bench, both under sustained load and at idle, because a validator idles between its assigned turns and that baseline draw is a real part of the total. Aggregating the per-machine figure across the estimated population, with an allowance for the overhead of the facilities housing it, gives the network total.

Several qualifications belong with the result. It is a modeled estimate resting on observed node counts and stated software requirements, not metered consumption at the socket. Where evidence is thin, the assumptions chosen lean toward overstating rather than understating consumption. Figures are revised as crawler coverage and hardware information improve. Finally, apportioning a share of the network total to any single asset issued on the chain is done from observed on-chain transfer volumes, which measures how heavily an asset is used rather than the energy it uniquely causes.

The estimate is built up from the machines the network runs on, since nothing in this consensus rewards computational work and there is consequently no mining hardware whose economics could be modeled. The relevant population is the validator nodes staking in the execution shards and the metachain, together with the observer nodes that hold state and serve queries without taking part in consensus. Observers matter here: they are numerous, they run continuously, and omitting them because they do not validate would understate the infrastructure the network depends on.

Sizing that population draws on two kinds of source. Registered validators and their shard assignments are visible in on-chain state and can be counted exactly, including nodes currently jailed or queued, which still occupy hardware. The observer and supporting node population is not directly enumerable and is approximated from network crawlers and publicly reachable peer data, adjusted upward for nodes that do not announce themselves. Sharding complicates the count slightly, since a single operator commonly runs several nodes across different shards on shared or adjacent hardware, and treating each node as a separate physical machine would inflate the result.

Hardware is inferred from the reference specification the node software publishes — processor class, memory, and solid-state storage sized for the shard's history — on the reasoning that operators provision to meet that specification without much margin. Power draw for the resulting device classes is taken from controlled bench measurement covering idle as well as loaded operation, rather than from manufacturer ratings, because a node's duty cycle is dominated by waiting. Total consumption is the aggregate over the estimated population at those rates across the reporting period.

The caveats are the substance of the method rather than a footnote to it. Node counts, hardware profiles and utilization are inferred from public observation and stated requirements, not metered directly, and each carries its own error. Where the evidence is thin the conservative assumption is chosen, meaning the one that yields a higher figure, so the result is more likely to overstate the footprint than to understate it. Estimates are revised as crawler coverage and measurement improve, which limits how far consecutive reporting periods can be compared.

The figure reported for this network is assembled from the machines that run it rather than inferred from any single aggregate quantity. The starting point is a count of active nodes, put together from network crawlers, publicly reachable cluster and gossip information, and data operators choose to publish. That population is then divided by role, because a validator taking part in voting, a machine that only replays the ledger, and the infrastructure that answers application requests do not draw comparable amounts of power.

Each role is matched to a representative hardware profile derived from the resources the client software is documented to need. Requirements here are heavy by the standards of proof-of-stake systems, running to many processor cores, large memory and fast solid-state storage, and the profiles reflect that rather than assuming commodity equipment. Electrical draw per profile is taken from controlled bench measurement of equivalent devices, capturing both the load imposed by processing and the draw of a machine that is powered up but idle, since a node consumes electricity continuously whether or not it is producing a block. Multiplying profiles by the estimated population across the hours of the reporting period gives consumption for the network as a whole. Where a figure is attributed to one asset issued on the network rather than to the network itself, the share is taken from observed on-chain transfer activity for that asset.

The output is an estimate and should be read as one. The node count rests on what is visible from outside, and operators are under no obligation to be visible; the hardware mix is inferred from stated requirements rather than surveyed; and facility overheads such as cooling and power conversion are approximated rather than metered. Where the evidence does not settle a question, the assumption adopted is the one more likely to overstate consumption than understate it, and figures are restated as observation improves or as protocol changes alter the work a node must perform. The network's own climate reporting is published at Solana Climate Dashboard.

Key energy sources and methodologies

Ta-Da is present on the following networks: Binance Smart Chain, Multiversx, Solana.

The renewable share reported for BNB Smart Chain follows from where its machines physically run, so the method begins with locating them. Node addresses visible through peer discovery and public network observation are resolved to hosting providers, autonomous systems and countries, producing an approximate geographic distribution of the validator and full-node population. Where that observation is too sparse to stand on its own, the distribution of a network with a comparable staking design and operator economics is substituted, on the reasoning that similar incentives attract similar operators into similar hosting markets.

That distribution is then matched against national electricity statistics. Each country's share of generation coming from renewable sources is taken from Share of electricity generated by renewables, compiled and processed by Our World in Data from Ember's yearly electricity datasets and the Energy Institute's Statistical Review of World Energy. Weighting those country-level shares by the portion of estimated node capacity sitting in each gives a single renewable percentage for the network.

Energy intensity is a separate quantity and is defined marginally: the additional electricity associated with one further transaction being processed, rather than the annual total divided by the transaction count. On a chain that produces blocks on a fixed schedule whether or not they are full, the marginal figure is far smaller than a simple average would suggest, and the two should not be used interchangeably.

Three limits are worth stating plainly. An observed hosting location identifies a grid but not a procurement arrangement, so an operator buying renewable power on a carbon-heavy grid is indistinguishable from one that is not. Cloud and proxy infrastructure can place a node's apparent location away from the hardware actually running it. And national annual averages smooth over the hourly and seasonal variation in generation mix that a continuously running machine actually draws from.

The renewable share is derived from where the network's machines physically are, since the electricity they consume comes from the grid serving that location and from nothing else. Node positions are inferred from publicly observable network data — the addresses peers advertise, routing information, and the hosting providers those addresses belong to — and aggregated to country level. Finer granularity is deliberately avoided: the inputs do not support it, and it would expose operator detail without improving the result. The exercise covers validators across all execution shards and the metachain as well as the observer nodes counted in the consumption estimate, since each of them draws power wherever it sits.

Some portion of the node set cannot be located this way. For that remainder, the observed geographic distribution of a structurally similar network is substituted — similar in the sense of a comparable reward and participation design, on the reasoning that networks recruiting operators on similar terms tend to end up with operators in similar regions. The substitution applies only to the unplaced portion, never to the distribution as a whole.

Country weights are then matched to national electricity generation mixes to yield a renewable share for the power the infrastructure consumes. The generation data comes from Share of electricity generated by renewables, compiled by Ember and the Energy Institute's Statistical Review of World Energy and processed by Our World in Data. These are annual national averages, describing the grid an operator draws from rather than any specific supply arrangement it may have entered into, and variation within a year or within a country is averaged away.

Energy intensity is reported as the marginal energy cost of one more transaction — the additional consumption caused by adding a transaction to the load already being processed — rather than as total consumption divided by transaction count. For infrastructure that draws power continuously regardless of how busy it is, and that is provisioned for peak rather than average load, the two quantities are far apart, and the marginal figure moves with throughput even when the node population has not changed.

The renewable share is derived geographically. Node locations are inferred from what the network exposes about itself: addresses observable through crawlers and public cluster information, resolved to a country or region. Coverage is never complete, because operators may sit behind hosting providers or relays that obscure where the hardware physically sits. Where the geographic spread of this network cannot be observed directly, the distribution of a structurally similar network stands in as a proxy, chosen because its validator economics and agreement protocol place comparable demands on operators and therefore tend to attract them to comparable locations.

Each located node is then assigned the generation mix of the grid that serves it. Those regional mixes come from Share of electricity generated by renewables, compiled by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy. Weighting each region's renewable share by the estimated consumption sitting in that region produces a network-wide proportion. The result describes the grids the infrastructure draws from, not contractual purchases: an operator buying renewable certificates is not treated differently from a neighbor on the same grid, because that distinction cannot be observed from outside.

Energy intensity is reported separately and means something narrower than total consumption divided by transaction count. It is the marginal quantity of energy associated with processing one further transaction. That distinction matters for a network of this type, where validators run continuously at close to constant power regardless of how full the blocks are, so the incremental energy attached to an additional transaction is small while the standing consumption of the validator set is not. Both the renewable share and the intensity figure therefore move with two separate things: the composition and location of the node population, and the grid statistics for the years covered, which are themselves restated as national reporting is revised.

Key GHG sources and methodologies

Ta-Da is present on the following networks: Binance Smart Chain, Multiversx, Solana.

Emissions for BNB Smart Chain are derived from the same geographic picture used for the energy mix, then converted using regional carbon factors. Node locations are approximated from peer-discovery data, public network observation and hosting attribution, and where coverage is insufficient the distribution of a structurally similar staked network stands in. Each location carries the carbon intensity of its national grid, drawn from Carbon intensity of electricity generation, processed by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy and published under a CC BY 4.0 license. Multiplying the electricity attributed to each region by that region's grams of carbon dioxide equivalent per kilowatt-hour, and summing across regions, gives the annual emissions figure.

The split between scopes matters for interpretation. Scope 1 covers emissions from sources the network's operators control directly, such as on-site fuel combustion, which for a population of general-purpose servers in rented facility space is generally negligible and is reported as such. Scope 2 covers the indirect emissions embodied in the electricity those machines purchase from the grid, and that is where effectively the whole footprint sits. Emissions upstream of operation, in the manufacture and eventual disposal of the hardware, fall outside this accounting boundary.

Greenhouse-gas intensity mirrors the energy definition: the incremental emissions associated with one additional transaction, not the annual total divided by throughput.

Uncertainty in the emissions figure compounds the uncertainty in the two inputs behind it. Any error in the estimated electricity total propagates directly into the result, and the geographic attribution adds error of its own, since grid carbon intensity varies by more than an order of magnitude between countries and a misplaced share of node capacity moves the answer substantially. Annual national averages also mask the hourly variation in grid intensity to which a machine running around the clock is fully exposed.

Emissions are calculated from the energy estimate and the same geographic distribution, applying grid carbon intensity in place of generation mix. Node locations are inferred from publicly observable network data and grouped by country, covering validators across the execution shards and metachain as well as the observer nodes included in the consumption figure. Where part of the node set cannot be placed, the distribution of a structurally similar network stands in for that remainder. Each country weight then carries the average carbon intensity of that country's electricity generation, and applying the weighted intensity to the energy estimate produces the emissions total.

The result is split across two scopes. Scope 1 covers emissions from sources the network's operators control directly — on-site combustion, refrigerant loss, standby generators — and for a network of this shape it is effectively zero, because the infrastructure is servers housed in facilities the operators do not own and nothing under their direct control burns fuel. Scope 2 covers the indirect emissions embodied in the electricity purchased to run that infrastructure, and it accounts for virtually the whole figure. Emissions further up the chain, from manufacturing and shipping the hardware or constructing the facilities, lie outside both scopes and are not counted.

Carbon intensity values are taken from Carbon intensity of electricity generation, compiled by Ember and the Energy Institute's Statistical Review of World Energy with substantial processing by Our World in Data, and made available under a CC BY 4.0 license. They are location-based annual averages for national grids, so an operator buying contracted clean power is not distinguished from one on ordinary supply in the same country, and any such arrangement is invisible to this method.

GHG intensity is the marginal emission attributable to one additional transaction, computed on the same marginal basis as the energy intensity figure. Every uncertainty beneath it compounds into it — the node population, the hardware profile, the inferred locations, the national intensity averages — so it is properly read as an indication of magnitude rather than a precise per-transaction measurement.

Emissions are derived from the same geographic picture used for energy sources, applied to a different set of grid statistics. Node locations are inferred from addresses observable through crawlers and public cluster information and resolved to a region; where direct observation falls short, the geographic distribution of a structurally comparable network is substituted, selected on the basis that its incentive design and agreement protocol impose similar operating demands.

Each region is then paired with a carbon intensity for its electricity, taken from Carbon intensity of electricity generation, compiled by Our World in Data from Ember's yearly electricity data and the Energy Institute's Statistical Review of World Energy and made available under the CC BY 4.0 licence. Multiplying the electricity estimated to be consumed in a region by that region's carbon intensity, and summing across regions, gives the emissions attributable to running the network.

The disclosure separates two scopes. Scope 1 covers emissions from sources the operators of the infrastructure control directly, such as fuel burned on site; for a network of this kind, whose nodes are ordinary servers in rented facilities, this is normally nil or immaterial, and a zero figure reflects the absence of such sources rather than an omission. Scope 2 covers the indirect emissions embodied in the electricity those machines purchase, and is where essentially the whole footprint of this network falls.

Greenhouse gas intensity follows the same marginal logic as its energy counterpart: it expresses the emissions associated with one additional transaction rather than an average obtained by dividing an annual total by throughput. Because validators consume electricity at a fairly steady rate whether or not blocks are full, the marginal figure is small and is not a proxy for the footprint of the network as a whole. Both the absolute emissions and the intensity figure are sensitive to the grid statistics underlying them, which are revised as national energy reporting is updated.