Archive

Origins

Created by m0dest on January 5, 2026

Game Principles

• luck should play a small role
• speculation is a feature, not a bug
• fees should be small, but real
• whales cannot ruin gameplay for others
• the mechanics need to be simple (leave room for magic)
• there must be ways for chaos to be added by us
• classes matter but do not give outsized advantages
• people should not leave the game empty-handed
• the prize pool for the winners should be substantial

Simulation Model

Most NFT ecosystems are analyzed through price charts and liquidity metrics. Very few are modeled as bounded populations with behavioral heterogeneity under compounding fiscal stress.

purpose

• stress test a closed NFT population under escalating tax pressure
• model adversarial enforcement where agents police each other
• observe emergent elimination dynamics
• study survival curves under stochastic behavior
• examine how trait distributions influence systemic collapse

model definition

This is a discrete-time, agent-based, stochastic elimination model with Beta-distributed behavioral traits and linear fiscal escalation.

There are 6,969 agents. The system runs until only 69 remain.

Eliminations occur exclusively through enforcement failure during audits.

Population is partitioned via a categorical distribution:

• 65% Common
• 25% Bureaucrat
• 10% Wealthy

Classes only affect audit throughput capacity.

There is no class mobility, no reproduction, no entry, and no exit beyond elimination. This is a closed finite population system.

behavioral traits

Each behavioral slider defines a Beta distribution over [0,1].

• Risk
• Ruthlessness
• Forgetfulness
• Wealth skew

The Beta distribution is critical. It allows:

• left-skewed populations (most agents near 0)
• right-skewed populations (most near 1)
• symmetric bell-like distributions
• highly concentrated behavioral clusters

Unlike Gaussian curves, Beta distributions:

• respect probability bounds
• avoid infinite tails
• maintain controllable shape parameters

This makes the simulation a parameterized population curve system rather than a simple random draw.

Starting balances are sampled from a scaled Beta distribution between 0.01 ETH and 3.0 ETH.

This is not a lognormal or Pareto heavy-tail economy. It is intentionally bounded. The system studies behavioral collapse, not wealth-inequality runaway dynamics.

fiscal pressure

Daily tax evolves as:

T_d = T_base + T_increment * (d - 1)

This is a linear growth function. Pressure increases monotonically until structural failure.

audit process

30% of audits are weighted toward known delinquents:

P(target) proportional to days_unpaid

This creates a positive feedback loop:

• delinquents accumulate visibility
• visibility increases audit probability
• audit pressure accelerates elimination

The remaining 70% are blind audits. This prevents total deterministic collapse while preserving social enforcement pressure.

elimination mechanics

Elimination occurs only when:

• a target has unpaid taxes
• an audit triggers billing:

bill = (days_unpaid + 1) * tax_today

• the target cannot pay or forgets

This creates:

• nonlinear punishment shocks
• discrete elimination events
• sudden balance cliffs

Population decline is not continuous. It is stepwise and stochastic.

Audit probability per agent:

P(audit) = ruthlessness * (1 + wealth_skew * (wealth_norm - 0.5))

This introduces:

• behavioral heterogeneity (ruthlessness)
• wealth-biased enforcement
• linear wealth normalization

It is not logistic. It is not threshold-based. It is a linear modulation of aggression.

findings

Who knows how accurate this simulation is. Probably not very accurate as degens will be degens. But this simulation gave us more insight than just going in blind. we believe we have set the game up in a way that balances all aspects, though expect to see the unexpected.

Smart Contract Architecture

Death & Taxes is an onchain elimination game built around two NFT collections and a small set of contracts that enforce the rules, track player status, and distribute the final prize pool.

The Building Blocks

• Citizens (NFT collection): The main player assets. Each Citizen represents a player's “life” in the game and can be traded throughout gameplay.
• Game Contract: The rules engine. It tracks whether each Citizen is up to date, under audit, insured, or eliminated, and it enforces what actions are allowed at each phase of the game.
• Evaders (NFT collection): The “afterlife” collection. If a Citizen is eliminated through the game, the Citizen is burned and the owner receives a corresponding Evader NFT.
• Treasury: A vault contract that accumulates the game's proceeds and, once the game ends, lets remaining Citizens claim equal shares.
• Rendering Contract: A helper contract that serves the Citizens' metadata and switches how a Citizen appears based on whether life insurance is active.

Two Ways a Citizen Can Leave the System

• Game elimination (external burn required by design): Elimination is not automatic. If a Citizen is audited and doesn't resolve it in time, anyone can execute elimination onchain. To support this mechanic, the Citizens contract includes a custom external burn function callable by the Game Contract. This lets the game burn a Citizen without requiring owner approval, which is essential to make “death” enforceable onchain.
• Self burn (owner-initiated): Citizen owners can also burn their own Citizen using the collection's standard burn behavior. This is distinct from game elimination: a self burn reduces the onchain survivor count but does not represent being “killed” by another player through the audit process. This action also does NOT mint an evader.

High-Level Game Flow

1. Live gameplay

   • Time progresses in repeating “days.”
   • Citizens can pay taxes to stay current, including paying ahead for a buffer.
   • If a Citizen falls behind, other players can initiate an audit.
   • Audits create a deadline. If the deadline passes unresolved, elimination can be executed by anyone.

2. Evaders and visual history

   • When elimination happens through the game, the Citizen is burned and an Evader is minted to the Citizen's current owner.
   • Citizens metadata can update based on insurance; Evaders capture a finalized snapshot at the moment they are minted.

3. Settlement

   • The game ends when the onchain survivor count reaches the target.
   • At that point, the Treasury is unlocked and each remaining Citizen can claim an equal share of the total Treasury.

Design Ideals

• Rules are enforced onchain, so the game doesn't depend on trusting a server.
• Player-driven enforcement: audits and eliminations require participants to act, making the game publicly observable.
• Clear, permanent outcomes: elimination burns are final, and the system produces an onchain record of survival and elimination.

Security

• Onchain enforcement: Tax status, audits, elimination eligibility, and settlement are all determined by contract state, not a server.
• Permission boundaries: Core gameplay actions are open to players; only a limited “IRS” role can grant special abilities (like bailouts/bribes/limits), and those abilities are still constrained by the rules.
• No automatic eliminations: Elimination requires an explicit transaction, which reduces surprise state changes and keeps actions observable on the public ledger.
• Treasury safety model: Funds are distributed via pull-claims (each survivor claims), avoiding a single admin-driven mass payout. The treasury unlock is permissionless once conditions are met, improving liveness.
• Recipient contract risk: ETH is sent to payment recipients and claimants; if a recipient address is a contract with restrictive receive/fallback behavior, transfers can fail and block that specific action.
• Metadata and permissions: Citizens metadata can change based on game state (insurance). Only the game contract can trigger metadata refresh events, which prevents arbitrary third parties from forcing updates.

A significant amount of care has gone into the system's security posture. The contracts follow established best practices, and the test suite provides 100% coverage across the codebase.

If you have any questions or concerns, please reach out to dev@transientlabs.xyz