Building PegLab: An Open-Source Engineering Workbench for Stablecoin Stress Testing

PegLab is an open-source workbench for stress-testing stable asset designs : collateral models, redemption limits, oracle behavior, before anyone deploys real collateral against them.

Every stablecoin team eventually asks the same question, usually after something has already gone wrong: would our peg have survived that?

Terra asked it in May 2022. Several smaller algorithmic and overcollateralized designs have asked it since, at smaller scale, with the same answer. The pattern is consistent: the failure mode is rarely a mystery once you can see it on a chart. The reserve ratio was too thin for the redemption rate it had to absorb. The oracle had a delay that became fatal under a fast collateral move. The liquidation threshold was tuned for a calm market, not a bank run.

What’s missing isn’t hindsight. It’s a way to ask the question before deployment, with the design’s actual parameters, against a fixed set of adverse scenarios, and get back a number instead of a guess.

PegLab is an open-source repository that does exactly this : a design-test-compare workbench for stable asset mechanisms, built to be read, run, and forked.

What PegLab actually does

PegLab is an engineering workbench, not a forecasting tool and not a market simulator. You configure a stable asset design, run it against ten fixed stress scenarios, and get back a deterministic set of metrics: peg stability, recovery time, worst drawdown, collateral ratio, and a bucketed failure-probability rating with rule-based recommendations attached.

The whole flow looks like this:

Three things make this useful rather than decorative:

It’s bounded. Three collateral models : fiat-backed, crypto-backed, overcollateralized. Ten scenarios, not a hundred. No algorithmic or delta-neutral mechanisms in v1. That scope was deliberate: a tool that tries to simulate everything ends up validating nothing convincingly.

It’s explicit about what it isn’t. PegLab does not model live oracle feeds, real order-book microstructure, or endogenous trader behavior and it says so, in the README and in every simulation result. The assumptions aren’t a disclaimer buried in the docs; they’re returned alongside the metrics every time you run a test. A tool that pretends to be more accurate than it is becomes less useful, not more impressive.

It’s auditable, not magical. The failure-probability rating and the recommendations aren’t model-driven black boxes. They’re threshold rules if worst drawdown exceeds a bound, the recommendation engine says so and tells you why. You can read the rule. That matters more than it sounds like it should, because the moment a risk score can’t be explained, nobody downstream trusts it under pressure.

What it looks like

The compare view: two designs, one scenario, standardized metrics side by side.

What this is built to be different from

PegLab isn’t trying to compete with live monitoring dashboards or academic peg-stability papers ; it’s filling the gap between them: something interactive enough to test a specific design’s parameters, but fixed and bounded enough to actually finish building.

The architecture, end to end

PegLab is split into three layers that don’t know about each other’s internals; which is the part of this build that’s actually worth walking through if you care about why it’s structured this way.

The detail worth noticing: the engine has zero dependency on the web layer. It’s a standalone Python package you can pip install and run from a script with no server running at all. The actual mechanism-design logic is testable and reviewable in isolation, separate from anything to do with FastAPI routes or React state.

What happens inside a single stress test

Here’s the part that matters most: what actually happens when you click Run.

Every step is deterministic given the same inputs. That’s the design choice that makes the tool’s claims defensible : there’s no hidden randomness inflating or deflating a result between runs. If two people run the same config against the same scenario, they get the same answer, and they can both trace why.

The compare view: where this earns its keep

A single simulation tells you whether one design survives a scenario. The comparison view tells you something more useful: which tradeoffs are you actually making between two architectures.

This is where the reserve-ratio-versus-recovery-time tradeoff actually becomes visible instead of theoretical. A higher buffer reduces insolvency risk but doesn’t reduce recovery time for free: you can see exactly where that tradeoff sits for the specific parameters you chose, not for some generic textbook case.

Why I built it this way

I came into digital assets after about 16 years across derivatives trading, structured finance, market-making, and treasury/FX risk : fields where what happens to this position in a stress scenario isn’t an academic question, it’s Tuesday. The thing that struck me moving into stablecoin and tokenized-finance work was how often peg-survival claims were made in prose rather than tested against parameters anyone could inspect.

Get Vishnu Govind’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

PegLab isn’t trying to replace a real risk desk’s tooling. It’s trying to be the thing that exists before a team builds a real risk desk : a fast, explicit, falsifiable first pass at stablecoin risk modeling and mechanism design, with the assumptions in full view rather than implied. The underlying questions are the same ones that show up across tokenomics and financial infrastructure work generally: how much friction does this design have before it breaks, and where exactly does that friction show up first.

The repo is intentionally finishable rather than ambitious in scope, which was itself a decision: a tool that tries to simulate every collateral type and every market condition in v1 usually ships nothing. Three models, ten scenarios, and a comparison view that’s actually useful :that’s the bet.

What’s next

v1 is deliberately narrow : that was the point, not a limitation to apologize for. The roadmap from here:

• Additional collateral model families beyond the v1 trio (algorithmic, delta-neutral, RWA-backed, yield-bearing)
• Export and report generation, so a run can leave the tool as a shareable artifact
• Saved projects or persistence beyond the current local-only state
• Richer governance and oracle-failure scenario surfaces, which are intentionally thin in v1

None of these are blocked on anything : they’re sequenced behind a working v1, the same way the v1 scope itself was sequenced behind getting something finished first.

Try it

git clone https://github.com/vishnugovind10/peglab.git
cd peglab
python -m pip install -e engine[dev]
python -m pip install -e backend[dev]
cd frontend && npm install

Or skip the UI entirely and run it from the command line:

cd examples
python run_example.py --config usdc_style_config.json --scenario bank_run
python run_example.py --config makerdao_style_config.json --scenario collateral_crash

Full architecture notes are in ARCHITECTURE.md, and the explicit model boundaries are in docs/assumptions_and_limitations.md : read that one first if you’re evaluating whether the numbers mean what you’d want them to mean.

The repo is open source under MIT. Issues, forks, and additional scenario contributions are welcome; particularly around governance failure modes and cross-chain collateral risk, which are deliberately left thin in v1.

PegLab: github.com/vishnugovind10/peglab