Midnight’s Live DUST Model Puts Sponsored Private Transactions Under a Real Capacity Test

Midnight’s move into production in March 2026 turned its DUST model from an elegant token-design idea into an operational question. The network generated its genesis block on March 17, 2026 and made its public debut later that month, initially with a federated validator model. Its central economic claim is unusual: NIGHT is transferable and used for governance and ecosystem incentives, while DUST is a shielded, non-transferable resource that is generated by holding NIGHT, decays over time, and pays for network use.

That changes the framing of fees. A user does not necessarily buy a volatile asset immediately before sending a transaction. A developer can designate generated DUST to support an application’s users. And DUST is not meant to circulate as a transferable payment instrument. Yet none of that makes capacity infinite. Every privacy-preserving transaction still consumes scarce resources: bytes in a block, execution work, storage access, and especially cryptographic proof verification.

The practical test is therefore more demanding than, “Are transactions cheap?” It is this: can Midnight allocate finite capacity fairly and predictably when applications sponsor private user activity, without quietly rebuilding an auction-style gas market under another name?

For builders, the answer depends on understanding DUST as a rechargeable capacity entitlement, not as free money. A “gasless” user flow can be excellent product design. It can also conceal a cost transfer, a throughput bottleneck, and a set of privacy leaks that appear outside the shielded fee itself.

The separation Midnight is trying to create

On most smart contract networks, the same native asset performs several jobs at once. It can be held as an investment, used in governance, staked or otherwise committed to security, transferred between users, and spent to bid for block space. That coupling can create awkward user experiences. A user who wants to call an application must acquire the token. A popular token can make routine activity more expensive. During congestion, fees can become a de facto auction for transaction priority.

Midnight separates the value-bearing asset from the operational resource.

NIGHT is the transferable, unshielded token. CoinDesk describes it as a token used for governance, block-production rewards and ecosystem incentives. The same reporting describes DUST as shielded, non-transferable and decaying, used exclusively for transaction fees. Holding NIGHT produces DUST over time, with generation proportional to NIGHT holdings.

That division has four intended effects.

First, it reduces the need for an ordinary user to hold a volatile token merely to take a routine action. A wallet can consume DUST generated from its own associated NIGHT position, or use a developer’s designated DUST capacity.

Second, it makes sponsorship more native. A business that wants customers to use a private identity check, loyalty programme, ticketing flow or regulated asset application can cover the protocol resource cost without handing users transferable tokens.

Third, it makes DUST harder to treat as a secondary money. Because DUST is not transferable and decays, it is designed to be consumed as a resource rather than accumulated, traded or remitted.

Fourth, it separates some fee volatility from NIGHT’s market price. A higher NIGHT price does not automatically mean a higher per-transaction DUST charge. That does not remove economic cost. It moves the economic question from a spot purchase of gas to the capital and operating model required to maintain NIGHT-backed capacity.

CoinDesk’s 2025 blockchain report described this dual-token structure as a way to distinguish speculative value from the network fuel used for shielded activity. The report also said that Midnight’s design aims to avoid treating DUST as an anonymous transferable asset.

The distinction is important, but it should not be exaggerated. DUST can change how costs are experienced. It cannot repeal the fact that validators can verify only a finite amount of work per block.

The DUST lifecycle, from NIGHT holding to block inclusion

The cleanest way to think about the model is as a lifecycle with six stages. Some broad properties are public. The precise protocol parameters, including generation rates, decay functions, transaction resource schedules, block ceilings and sponsorship authorization format, are not fully specified in the public reporting cited here. Builders should treat those as implementation values to obtain from current network documentation and testnet measurements, not as constants to infer from marketing language.

1. NIGHT provides the capacity base

A NIGHT holder has the base asset from which DUST is generated. The public description is not that NIGHT is burned on every transaction. Instead, NIGHT holdings generate a renewable operational resource over time. The Block compared the model to a battery that recharges, while CoinDesk noted that generation is proportional to NIGHT held.

For an operator, this means NIGHT is closer to capacity backing than prepaid gas inventory. The operator’s question is not simply, “How much DUST do I own today?” It is, “How much DUST can my NIGHT backing replenish per hour or per day, after accounting for current decay and expected use?”

2. DUST accumulates, but not forever

Generated DUST is shielded and decays. This is a crucial feature. If DUST did not decay, a high-NIGHT holder could build an ever-growing inventory of future block-space claims, even while the network is quiet. If it decays, unused capacity loses value over time. The holder is encouraged to size capacity to expected activity rather than hoard it indefinitely.

A useful abstract balance model is:

DUST available at time t = decayed prior balance + new generation - DUST consumed

The details matter. A slow decay curve permits larger reserves and smoother service through peaks. A fast curve makes the model more like a continuously replenishing allowance. Neither is inherently better. The appropriate choice depends on whether Midnight wants applications to absorb short traffic spikes, or instead wants usage to remain close to an operator’s sustained NIGHT-backed rate.

This is one of the first parameters an application team should measure in practice. A developer cannot responsibly promise uninterrupted sponsorship until it knows the generation cadence, maximum retained balance if any, decay schedule and any limits on delegated capacity.

3. The holder designates DUST capacity

Midnight’s public materials say a NIGHT holder can designate DUST resources to others, allowing developers to cover transaction costs for users.

That word, “designate,” matters. The product goal is not necessarily to send DUST to a customer like a token transfer. Instead, a holder can authorize another identity, wallet or application flow to draw against its renewable resource budget.

A practical sponsorship design needs clear policy boundaries:

• Which Compact contract or application identifier may use the designated DUST?
• Which user identities or wallets qualify?
• Is there a per-user limit, a per-action limit, or a daily aggregate cap?
• Does the authorization expire?
• Can the sponsor revoke it immediately?
• What happens if several users submit transactions at the same time near the remaining budget limit?

Without those controls, sponsorship is an open tab. An application becomes vulnerable to spam, scripted claims, intentional proof-generation load and simple mistakes in its own front end.

4. The wallet constructs a transaction

A sponsored transaction still requires a wallet-side decision. The wallet must construct the intended application action, generate or obtain the zero-knowledge proof required by the relevant Compact logic, and attach the authorization that identifies the allowed fee source or sponsorship route.

The exact transaction wire format is implementation-specific. Conceptually, however, the transaction has at least four separable components:

1. Application intent: what state transition the user wants.
2. Private witness and proof: the secret data and cryptographic proof that establish the action is valid without revealing protected facts.
3. Fee authorization: proof that the user or sponsor has sufficient DUST capacity for the declared transaction resource cost.
4. Publicly necessary envelope data: enough information for network propagation, ordering and validation.

This distinction matters because fee privacy is not identical to total transaction privacy. A shielded DUST payment can hide the amount of a user’s fee balance or the relationship between a DUST source and a specific payment, depending on protocol design. It does not automatically conceal the fact that a transaction was broadcast at a particular time, entered through a particular wallet connection, invoked a visible application endpoint, or had a particular size and proof class.

5. Validators perform admission checks

Before a transaction consumes a block slot, nodes need to decide whether it is admissible. A reasonable admission path checks, at minimum:

• Transaction syntax and signature validity.
• Validity of the relevant zero-knowledge proof.
• Non-reuse or nullifier-style protections where the shielded system requires them.
• Whether the fee authorization is valid.
• Whether the designated DUST source can cover the transaction’s resource charge.
• Whether the transaction fits current network and block-level limits.

The protocol must make those checks before inclusion because a sponsored model otherwise creates an obvious attack: a user can produce expensive invalid proofs or flood a sponsor’s authorization channel with transactions that exceed the sponsor’s remaining capacity.

The cost of proving also belongs in this stage, though it is often paid off-chain by the wallet, application or a hosted proving service. A transaction may have a low or invisible user-facing fee but still require expensive local hardware, battery use, server capacity or outsourced prover infrastructure.

6. Inclusion consumes finite block resources

Once admitted, the transaction competes for a finite share of a block. The relevant accounting should not be a single vague “fee.” It should be a resource vector.

A privacy transaction can consume:

• Block bytes: the transaction body, commitments, ciphertexts, proofs and metadata.
• Execution units: state transition work performed by the contract environment.
• Proof-verification units: validator computation needed to verify a zero-knowledge proof.
• State and storage resources: reads, writes, commitments and long-lived state growth.
• Propagation bandwidth: the network cost of distributing the transaction before it reaches a block.

That is the real capacity test. If a block has limits for one or more of these dimensions, then an application cannot exceed them simply because its sponsor has accumulated a large DUST balance.

Four costs that should never be collapsed into one number

“Fee” is too imprecise for Midnight’s model. An application operator should track at least four separate costs.

Economic cost

This is the cost of obtaining and maintaining the NIGHT position that generates the DUST capacity. It includes capital tied up in NIGHT, price risk, custody, governance exposure and the opportunity cost of holding the asset rather than deploying capital elsewhere.

It may be smoother than repeatedly purchasing gas, but it is still a cost. In effect, the sponsor pays for recurring access to capacity by holding the asset that produces it.

Protocol fee

This is the DUST consumed for a particular transaction. The user may see zero cost because the application pays it. The protocol does not see zero cost. It sees a charge against a DUST balance or designation.

For product analytics, report both the gross protocol fee and the party that covered it. Otherwise, a dashboard can misleadingly call an application “free” when it is actually operating a substantial DUST subsidy programme.

Proof cost

This is the compute and infrastructure burden of generating and verifying zero-knowledge proofs. It may fall partly on the user’s device, partly on the sponsor’s hosted infrastructure, and partly on validators.

The proof cost can be material even if the DUST amount is tiny. A system that makes users generate large proofs on mobile hardware may be technically private but commercially unusable. A system that centralizes proving services may be convenient but can create availability and metadata risks.

Congestion cost

This is the cost imposed when demand exceeds immediate block capacity. It does not have to appear as a higher DUST price. It can emerge as delay, rejection, queued work, stricter sponsor quotas, higher service tiers, or priority rules.

That last category determines whether Midnight avoids a gas market or recreates one indirectly.

If all valid transactions are admitted in a first-come, first-served queue and excess demand creates waiting time, congestion is paid in latency. If applications reserve capacity through fixed quotas, congestion is paid through planning and foregone flexibility. If sponsors can pay more DUST, hold more NIGHT, or use a privileged channel to jump the queue, congestion is again priced, even if the price is not quoted as a conventional gas bid.

The key question is not whether there is a visible gas slider. It is what scarce resource determines priority when the blocks are full.

Capacity planning for a DUST-sponsored Compact application

Midnight’s broad distribution was significant. CoinDesk’s 2025 report said the Glacier Drop and Scavenger Mine phases registered more than 4.5 billion NIGHT claims across more than 8 million unique addresses, while Midnight’s airdrop programme targeted eligible wallets across eight chains. These figures show the scale of the initial distribution effort, not usable DUST capacity, because a claim total and an active capacity commitment are different measures.

For an operator, capacity planning starts with measured transaction profiles, not token headlines.

Define:

• r as DUST generated per unit of NIGHT per day.
• N as NIGHT committed to sponsorship.
• G = N × r as daily DUST generation.
• d_i as DUST charged for transaction type i.
• v_i as expected daily volume for transaction type i.
• P as peak multiplier for the worst expected traffic interval.
• R as a reserve sized for service continuity.

Then baseline daily consumption is:

C = sum of (v_i × d_i)

A sponsor is sustainable only if long-run generation is at least normal consumption:

G >= C

That equation is necessary but insufficient. The service must also survive bursts. If the application expects a marketing event, a payroll run, an airdrop claim period, or an institutional batch submission, it needs enough available DUST at the start of the event to cover peak consumption. It also needs block-level capacity to include the transactions in the required time window.

Consider an illustrative planning model, not a statement of Midnight’s live parameters. An application supports 50,000 daily actions, each with a measured average charge of 1.4 DUST. Its ordinary requirement is 70,000 DUST per day. If 20 percent of a three-times traffic spike arrives during one hour, the event requires 42,000 DUST in that hour. A two-day continuity reserve adds 140,000 DUST of ordinary-use cover, subject to decay. The sponsor therefore needs both a NIGHT position that replenishes at least 70,000 DUST daily and a policy that preserves enough immediately available DUST for the peak.

The team should then stress-test at least five conditions:

1. A tenfold spike in eligible users.
2. A proving-service outage that causes retries.
3. A malicious user repeatedly submitting valid but uneconomic sponsored actions.
4. A block congestion period in which confirmation latency grows.
5. A DUST generation shortfall caused by an incorrect estimate, changed transaction complexity or sponsor reallocation.

The right output is not one “gas budget.” It is a table by transaction class, resource profile, per-user quota, target confirmation time, required DUST reserve and fallback path.

What happens when sponsorship runs out

DUST exhaustion is not an edge case. It is a normal state transition that every application must design for.

When a sponsor has insufficient designated DUST, the ideal outcome is early, explicit and non-destructive failure. The wallet should learn this before it spends substantial effort generating an expensive proof, and the user should receive a clear choice.

A robust fallback ladder looks like this:

1. Preflight check: Query or locally derive whether sponsorship remains for the intended action.
2. Soft reservation: Reserve the estimated DUST amount briefly while the transaction is constructed, if the protocol and application architecture support it.
3. User-visible fallback: Offer a self-funded DUST route, a delayed submission route, or a retry time.
4. Queue only when meaningful: If replenishment is expected soon, queue the action with a clear expiry and no false confirmation.
5. Protect critical actions: Reserve a portion of sponsorship capacity for compliance, account recovery, settlement or emergency actions.
6. Rate-limit discretionary activity: Pause low-value actions before depleting capacity needed for essential flows.
7. Alert operations: Trigger alerts on reserve thresholds, abnormal proof failures and rapid consumption concentration.

A bad design simply says “gasless” until a transaction fails. A good design displays sponsorship as a conditional benefit: covered while allowance remains, with a predictable alternative when it does not.

Shielded fees do not eliminate metadata

Midnight’s privacy proposition is broader than fee concealment. The network uses zero-knowledge proofs and a hybrid ledger approach intended to let applications combine public and private data, with selective disclosure where needed. The Block reported that shielded assets can hide balances and counterparty details, while Compact is designed to help developers build privacy-preserving applications without requiring deep zero-knowledge expertise.

Still, developers should audit metadata independently. A private transaction can leak useful signals even if its fee source and amount are shielded.

Potential leakage points include:

• Timing: A transaction sent immediately after an off-chain event may be linkable to that event.
• Network layer data: An IP address, wallet-provider connection, RPC endpoint or hosted prover request can expose a user relationship before the transaction reaches the chain.
• Transaction size and proof shape: Distinct actions may have distinguishable byte sizes or proof-verification profiles.
• Application routing: A visible contract call, public state update or endpoint can reveal which service a user accessed.
• Failure patterns: Repeated sponsor exhaustion, retries or quota-denial responses can reveal eligibility or usage intensity.
• Selective disclosure: Data deliberately disclosed to a counterparty, auditor or regulator is no longer private to that recipient.
• Cross-context correlation: A user’s public NIGHT management, sponsorship relationship and private application activity can be correlated through off-chain records or careless wallet behavior.

This is why “shielded fee” should not be used as shorthand for “anonymous application.” Privacy is a system property. It includes wallet UX, proving architecture, network transport, sponsor policies, logs, analytics, customer support procedures and the application’s own disclosure rules.

Does DUST avoid a gas market?

It can avoid some characteristics of a conventional gas market. A user may not need to acquire NIGHT before every action. A developer can sponsor usage directly. DUST cannot be casually transferred as a fee token. And decay makes it less suitable for hoarding.

But DUST does not abolish scarcity. It changes the location where scarcity is managed.

The economically honest description is that Midnight transforms a spot market for transaction inclusion into a capacity-management system. NIGHT backing determines the rate at which DUST can be replenished. DUST balances determine how much near-term activity can be sponsored. Protocol resource rules determine which transactions fit into blocks. Application policy determines who receives the subsidy when demand exceeds the sponsor’s allowance.

That may be a better system for consumer applications and privacy-sensitive enterprise workflows. It may produce more predictable user experiences than asking every user to buy and manage gas. But its success will depend on whether capacity rules are transparent, whether sponsorship tools expose real reserve levels, whether proof costs are manageable, and whether congestion policy is explicit.

The test for a claimed gasless Compact application is simple:

• Who ultimately bears the economic cost?
• What DUST resource does each action consume?
• What happens at the sponsor’s depletion threshold?
• What happens when blocks are resource-constrained?
• Which data are shielded, and which metadata remain observable?
• Can the application prove that its fallback path is fair to users?

If those answers are clear, DUST can function as a useful abstraction layer between users and blockchain resource accounting. If they are not, “gasless” is only a label for a fee that has moved elsewhere.