How FinDaS built Midnight's $DUST token economy from the ground up.
What started as a tokenomics validation for IOG's privacy blockchain became a year-long collaboration that produced 27+ deliverables, a novel dual-asset design, and a network that launched with over $1 billion in circulating market cap.
Input Output Group worked with FinDaS to design and validate the Midnight network tokenomics, delivering a novel dual-asset design enabling blockchain privacy and regulatory compliance features for developers. FinDaS understood our unique and complex needs, acting as a trusted partner to our research team. FinDaS' blockchain market understanding, tokenomics knowledge, and critical thinking were valuable assets, helping elevate our design choices. Their professional, timely, and detailed work exceeded our expectations. I highly recommend FinDaS.
TL;DR
- Client: Midnight, a privacy-preserving L1 blockchain developed by Input Output Group (IOG), the team behind Cardano
- Challenge: Design a two-token economy with nine hard constraints simultaneously: $DUST had to be accessible, uncensorable, decentralized, DDoS-resistant, and non-pegged to $NIGHT, while requiring no centralized exchange and no third-party matching service
- Approach: FinDaS built a scored design matrix across all nine constraint dimensions, systematically eliminated four of five possible $DUST acquisition mechanisms, and landed on a staking-based generation model, stress-tested across hundreds of agent-based Machinations simulation runs
- Result: Midnight launched with over $1 billion in circulating market cap and has maintained a top-70 position since, with daily trading volume consistently exceeding 30% of market cap
What problems did Midnight have?
The brief was incomplete, and that became apparent quickly
IOG brought FinDaS in to review and validate Midnight's existing tokenomics. Within the first working sessions, it became clear the real task was larger: the $DUST token (the network's resource fee token) had no complete economic design. The constraints were real and severe, but no mechanism had been selected that satisfied all of them simultaneously. What arrived as a review engagement became a build.
$DUST had to be valuable, unpegged, and accessible at the same time
Midnight's privacy architecture imposed a hard requirement: $DUST could not be directly convertible from $NIGHT on a fixed basis. But $DUST also needed intrinsic value to deter DDoS spam, while remaining accessible to any user on any chain, without relying on centralized exchanges or third-party liquidity providers. These constraints pull in opposite directions. A pegged token is simple and accessible; an unpegged fee token with enforced value is neither.
Every obvious solution failed at least one hard constraint
There are only a handful of ways a user can acquire a token: buy on an exchange, swap on-chain, receive via faucet, earn it, or convert from another asset. FinDaS mapped each option against nine design dimensions: obtainability, decentralization, censorship resistance, non-pegging, accessibility, DDoS resistance, transaction price stability, phase compatibility, and simplicity. Centralized exchanges were excluded by design. Faucets scored poorly on decentralization and censorship resistance. Direct NIGHT-to-DUST conversion skated too close to the non-pegging requirement. Atomic swaps introduced third-party dependence that made the system censorable. The scoring made the right answer legible.
An exercise in simplicity
IOG's engineers are among the best in blockchain. They had modeled a range of potential attack vectors in careful detail, several of which produced proposed countermeasures that added real protocol complexity. In working sessions, Hristo walked the team through the game theory behind each concern: who would execute the attack, what they stood to gain, what it would cost them, and whether any rational actor would do it. In most cases, the answer was no. Identifying and removing mechanisms that addressed incentives no attacker actually had was one of FinDaS's most concrete contributions to the final design.
How did FinDaS approach the problem?
Protocol and Business Deep Dive
FinDaS began by mapping Midnight's full ecosystem: the role of $NIGHT as the consensus and governance token, the function $DUST was required to serve as a network resource token, the phased rollout of Midnight's capabilities, and the regulatory positioning IOG intended to preserve. The key early insight was that $DUST is not a conventional token. It is closer to a protocol resource, like gas on Ethereum, but with the additional hard constraint that it must not be pegged to the primary token. That reframing changed how every subsequent design decision was evaluated.
Token Utility and Value Capture Design
FinDaS built a structured design space document, scoring every viable DUST acquisition mechanism across nine constraint dimensions. Swaps scored 0.72 out of 1.0. Faucets scored 0.61. Variable NIGHT-to-DUST conversion scored 0.75 but pushed the non-pegging constraint to its limit. The generation model (users stake $NIGHT and continuously accrue $DUST) scored 0.94. Hristo presented the full scoring matrix to the IOG research team as the basis for the direction. The team aligned. The recommendation was not instinct; it was the output of a framework.
Economic Modeling
FinDaS built the token economy across three complementary tools. In Google Sheets, the team modeled $NIGHT block rewards, treasury flows, APY projections across multi-decade time horizons, and GlacierDrop distribution scenarios across multiple claim rate assumptions. In Machinations, FinDaS built agent-based simulations of user behavior and network congestion, running hundreds of scenarios to test how different transaction pricing functions performed under load. Monte Carlo simulation covered probabilistic outcomes on network utilization and $DUST supply dynamics.
Stress Testing and Valuation
FinDaS analyzed Ethereum, Bitcoin, and Cardano's fee architectures as reference points and recommended variable, complexity-based transaction pricing over fixed fees, because fixed fees cannot adapt to congestion without creating exploitable arbitrage. The team also modeled the "whale attack" vector directly: a scenario where large $NIGHT holders deliberately inflate transaction prices to suppress yield for smaller delegators. The economic analysis showed the attack was self-defeating. The design held.
Documentation and Launch Readiness
Over 27 deliverables were produced across the engagement: design space explorations, parameter proposals, simulation methodology documents, findings reports, block reward calculators, pricing function implementations, feedback responses, and a TGE readiness review. The $NIGHT parameters scoping and block rewards proposal established design targets for inflation rate and staking participation, calibrated to support long-term value retention without over-rewarding early participants.
35%+ of the design process was elimination. The scored constraint matrix ruled out four of five possible $DUST acquisition mechanisms before a single line of the final model was written.
What did FinDaS change?
1. The $DUST acquisition model
Before the engagement, Midnight had no settled mechanism for how users would obtain $DUST. After, the design is anchored on generation: staking $NIGHT continuously produces $DUST, giving users a native, decentralized, uncensorable path to network access with no third-party matching service, no centralized faucet, and no pegged conversion.
Outcome: $DUST became a derivative of productive economic behavior (staking) rather than a token requiring its own liquidity infrastructure. Simpler to build, simpler to audit, and harder to attack.
2. Transaction pricing model
Variable, complexity-based pricing replaced any fixed-fee approach. Transaction cost reflects the computational and storage complexity of each operation, with the ability to spike during congestion. This preserves usability for honest users while making DDoS attacks prohibitively expensive at scale, without imposing a hard transaction cap.
Outcome: Network access is predictable under normal conditions and costly for attackers at scale, without requiring a centralized fee oracle.
3. Block rewards structure
FinDaS modeled and proposed the initial parameters for $NIGHT block rewards, targeting a specific long-term inflation rate and staking participation range, calibrated to balance delegator incentives, block producer economics, and token supply management. Projections were built through 2049. A key design decision was how block subsidies and variable rewards split across empty and full blocks, ensuring block producers remain incentivized regardless of network utilization in early phases.
Outcome: Block producers and delegators had a clear, modeled economic case for participation from day one rather than relying on launch-day momentum.
4. GlacierDrop distribution
FinDaS modeled multiple scenarios for the allocation of unclaimed GlacierDrop tokens, distributing them across block rewards, the foundation, and the treasury in proportions calibrated to avoid supply shocks while reinforcing long-term alignment.
Outcome: Token distribution preserves protocol sustainability without concentrating supply or creating a post-launch overhang.
5. Protocol complexity reduction
In multiple working sessions with IOG's engineering team, Hristo worked through proposed attack countermeasures that added protocol complexity without a corresponding reduction in real risk. By mapping the game theory (who executes the attack, what they gain, what it costs) FinDaS identified mechanisms that addressed scenarios no rational actor would pursue. Those mechanisms were removed.
Outcome: A leaner protocol with a smaller audit surface and a faster path to launch.
What were the results?
Midnight launched with over $1 billion in circulating market cap (not FDV, circulating). The network has maintained a top-70 position by market cap since launch. Daily trading volume has consistently exceeded 30% of market cap, a ratio that reflects genuine market liquidity rather than thin order books.
The broader crypto market downturn affected Midnight, as it did every asset in the space. The network's top-70 position has held regardless, a meaningful signal that the token design did not introduce self-inflicted structural pressure during the correction.
The engagement also validated a pattern FinDaS has seen repeatedly: a tokenomics review brief that goes deep enough will discover the work required is larger than originally scoped. For Midnight, validation became design, simulation, parameterization, and full launch readiness, delivered across 12 months of sustained collaboration with one of the most technically rigorous research teams in the industry.
Over the past year, we have had the pleasure of working closely with Hristo. Our relationship has been built on trust and mutual respect, and his contributions have been invaluable to our project. We genuinely cannot think of a single instance where Hristo came even close to disappointing our Chief Architect, Jon. His ability to consistently meet and often exceed expectations is remarkable, and we simply struggle to identify any areas for improvement. We are excited to continue working with Hristo in 2025 as we prepare to launch our mainnet. Additionally, we would be delighted to welcome him as part of our extended group of advisors and hope he will consider staying with our team for the long-term.
Key takeaways.
Map constraints before solutions
Midnight's $DUST problem had nine hard design constraints. Evaluating every acquisition mechanism against all nine simultaneously, in a scored matrix, eliminated bad options objectively rather than by instinct. Any dual-token design with competing requirements should start here.
Game theory beats complexity
The engineering team's instinct was to add countermeasures for every conceivable attack. FinDaS's contribution was demonstrating which attacks had no rational incentive structure. Removing those mechanisms made the protocol simpler, cheaper to audit, and faster to ship.
Resource tokens are not ordinary tokens
$DUST is not a governance token, a utility token, or a staking reward. Designing it required a distinct framework built around accessibility, censorship resistance, and DDoS deterrence rather than value accrual. These are different problems from the ones most tokenomics frameworks are designed to solve.
Staking-based generation is underused in dual-token architectures
The scoring matrix showed that generating a resource token by staking the primary token outperforms swaps, faucets, and direct conversion across almost every constraint dimension. For projects building a resource layer on top of a governance or consensus token, this mechanism should be the starting point.
What's next.
FinDaS's relationship with Midnight and the IOG team extended beyond the initial engagement. With mainnet live, the focus shifts to ongoing parameter calibration as real network data becomes available: validating simulation findings against on-chain behavior and adjusting block reward and fee parameters where the models warrant it. Dr. Szluinska's invitation for Hristo to join Midnight's extended advisory group reflects the nature of the working relationship built across 12 months: not a vendor handover, but a continuing collaboration.
Bring your project to a real token economist.
Free, no obligation, no juniors. We'll answer every question about your token design and tell you candidly where the weak spots are.
The questions we keep getting.
How do you design a dual-asset token economy for a privacy blockchain?
Start by mapping what each token must do independently and what relationship is acceptable between them. For Midnight, FinDaS built a scored constraint matrix across nine design dimensions, which identified staking-based generation as the only mechanism that satisfied all constraints simultaneously.
What is the difference between a resource token and a utility token?
A utility token grants access to a product or service and accrues value through demand. A resource token is consumed to pay for protocol operations and must prioritize stability, DDoS resistance, and accessibility over speculative value. Most tokenomics frameworks are built for utility tokens; resource tokens require a distinct design approach.
How do you prevent DDoS attacks in a blockchain fee model without using fixed fees?
Variable, complexity-based fees scale the cost of each transaction with its computational footprint, making large-scale spam exponentially more expensive while keeping costs predictable for honest users. For Midnight, FinDaS recommended this approach after analyzing Ethereum, Bitcoin, and Cardano fee architectures and stress-testing across hundreds of congestion scenarios.
What causes dual-token designs to fail after launch?
The most common failure is an implicit peg between the two tokens, which collapses the rationale for having two in the first place. The second is inadequate acquisition paths for the secondary token, creating dependence on third-party liquidity. The third is excessive protocol complexity from countermeasures that address theoretical attacks with no viable incentive structure.
How do you stress-test tokenomics before a mainnet launch?
FinDaS uses three tools: Google Sheets for deterministic modeling (vesting, emissions, treasury flows), Machinations for agent-based simulation of user behavior under varying conditions, and Monte Carlo simulation for probabilistic outcome distributions. For Midnight, hundreds of runs were completed before any parameter was finalized.
Why should a resource token like $DUST not be pegged to the primary governance token?
A pegged resource token is economically equivalent to a single-token system. For a privacy blockchain, a peg would link transaction costs directly to the primary token's market price, making network access unpredictably expensive during bull markets. A non-pegged resource token generated through staking keeps transaction costs stable while maintaining economic separation between the two tokens.