Home Data Gathering Data Modeling Data Analytics Data Science Software Contact Download CV

Data Modeling Case Studies

Simulation, implementation guides, and decision models for situations where intuition is not enough.

This section covers the models that shape product and infrastructure decisions: Monte Carlo risk studies, system-capacity simulations, implementation specs, and queueing models that make tradeoffs visible before they become expensive.

Monte Carlo studies Implementation specs Scenario analysis Queueing models
February 2025

Collateral 50 percent - Why We Doubled the Safety Net

A Monte Carlo study that made tail risk visible enough to justify raising the collateral floor from 30 percent to 50 percent.

Collateral risk reduction chart
October 2024

From White Paper to Build Spec - Writing the Tokenomics Implementation Guide

Turning an economic design document into module boundaries, ownership, and a build sequence engineers could actually ship against.

Implementation timeline for tokenomics build spec
June 2024

Token Supply, Demand and Capacity - Drafting ICN's First Predictive Model

A first predictive simulator linking emissions, capacity, utilization, and price to answer board-level questions about network design.

Token economy variable map
June 2024

Optimizing Queueing Models in Server Systems

Using queueing theory to reason about throughput, wait times, and architecture tradeoffs instead of hand-waving about server efficiency.

Queueing model diagram
Close

Collateral 50 percent - Why We Doubled the Safety Net

1. Problem

The question was simple and uncomfortable: was a 30 percent collateral floor actually enough to protect the rewards system under realistic volatility? The answer mattered because intuition around safety margins is cheap and tail events are not.

2. Approach

I built a Monte Carlo stress test that linked price volatility, capacity growth, utilization, and reserve depletion. The point was not to produce one magical number. It was to map how insolvency risk behaved under different collateral floors.

3. Evidence

Tail-risk drawdown chart
The 5th percentile reserve path made the downside visible enough that the old threshold stopped looking conservative.
Insolvency risk reduction by collateral floor
Moving from 30 percent to 50 percent materially changed insolvency odds rather than cosmetically improving the chart.

4. Outcome

The modeling supported a move to a 50 percent collateral floor, cutting modeled insolvency risk sharply and giving governance and engineering a much clearer rationale for the change.

5. Tech stack

6. Useful links

7. Related reading

8. Call to action

If you need to turn a vague risk debate into a model with decision-grade outputs, I can help design the simulation and the narrative around it.

Close

From White Paper to Build Spec - Writing the Tokenomics Implementation Guide

1. Problem

Economic papers are useful until engineering has to implement them. The gap between a convincing tokenomics narrative and a buildable system is usually filled with ambiguity, circular dependencies, and unclear ownership.

2. Approach

The implementation guide decomposed the economic design into modules, interfaces, and sequencing. Instead of rewriting the white paper, it translated the intent into work packages engineers and auditors could reason about.

3. Evidence

Tokenomics implementation timeline
The timeline made the critical path explicit and stopped the team from arguing in circles about what had to land first.

4. Outcome

The guide became a bridge document: concrete enough for engineering, faithful enough for the economic design, and structured enough for audit and governance review.

5. Tech stack

6. Useful links

7. Related reading

8. Call to action

If you need to turn a strategy document or white paper into something engineering can ship against, I can help write the translation layer.

Close

Token Supply, Demand and Capacity - Drafting ICN's First Predictive Model

1. Problem

The white paper described caps and incentives, but it did not answer the board-level questions: what happens if adoption stalls, demand spikes, or emissions stay fixed while capacity changes? We needed a first predictive model, not another static diagram.

2. Approach

The simulator linked demand curves, emission rules, network capacity, utilization, supply, and price so the team could compare scenarios instead of debating them abstractly.

3. Evidence

Token economy variable map
The model worked because the feedback loops were explicit enough to challenge assumptions instead of hiding them in spreadsheet formulas.
Demand crash scenario under inflation rule
Scenario views made it much easier to discuss where the simple inflation rule broke down under stress.

4. Outcome

The model provided a first shared simulation surface for emissions and capacity decisions, and it became the basis for later, more detailed stress testing.

5. Tech stack

6. Useful links

7. Related reading

8. Call to action

If your product or network design still depends on hand-wavy assumptions about supply, demand, or utilization, I can help turn it into a model people can interrogate.

Close

Optimizing Queueing Models in Server Systems

1. Problem

Teams often talk about throughput and latency as if they are properties of the hardware alone. In practice, the queueing discipline and routing pattern can change the system behavior just as much as the servers themselves.

2. Approach

This project used queueing models to compare single-queue, multi-server, and multi-queue setups so the tradeoffs could be discussed quantitatively rather than rhetorically.

3. Evidence

Queueing model comparison output
Model comparisons made it clear which gains came from added servers and which came from better queue structure.
Multi-server multi-queue with delay diagram
Once routing and delay penalties are visible, the architecture conversation becomes much more concrete.

4. Outcome

The work provided a simple framework for thinking about server-system efficiency and load-balancing tradeoffs, which is exactly the kind of clarity modeling should create.

5. Tech stack

6. Useful links

7. Related reading

8. Call to action

If your architecture decisions still rely on intuition about load and wait times, I can help build the model that makes the tradeoffs explicit.