Dollar and Coin workspaces
Choose the workspace that matches how you measure success. Dollar focuses on growing USD capital. Coin focuses on growing BTC holdings compared with holding Bitcoin.
Both use the same Agreement model. Your choice changes the questions, strategy selection and measures you see. It does not change the Agreement’s contractual dollar payments or the Buyer’s rights.
Choose your objective
| Dollar workspace | Coin workspace | |
|---|---|---|
| Main result | Dollar gain and NPV at your stated dollar hurdle | BTC surplus against holding matching dated BTC contributions |
| Downside | Probability and severity of losing dollars | Probability and severity of ending below the BTC holding reference |
| Strategy comparison | USD improvement over unhedged Agreements | BTC improvement over unhedged Agreements |
| Adverse paths | Actual paths ranked by dollar outcomes | Actual paths ranked by BTC outcomes |
Open the workspace chooser. Each workspace keeps its own assumptions, selected strategies and completed comparison in your browser. Use Use in another workspace to copy a scenario deliberately. The target’s previous draft is saved aside and can be restored. Existing scenario links and the original research desks remain available.
Four steps
- Research: choose a question, edit assumptions and watch one simulated Bitcoin price path update. Review the Agreement’s cash flows and exits, then run Monte Carlo to see a range of outcomes in your workspace’s units. New starting cases use an illustrative GBM with zero drift and 43% annual volatility, so the terminal price can vary. Existing links retain their own market model. These settings are assumptions, not forecasts.
- Compare strategies: inspect the selected variants on the same simulations used in Research, or change the selection and run again. Start with 256 for exploration; larger runs and separate-seed checks help assess sampling stability. Unhedged Agreements are always included.
- Risk & cash: inspect the loss distribution, cash screen and an actual adverse seed. Dollar and BTC can rank the same path differently.
- Evidence: challenge the completed run with separate seeds or a named stress, review the conventions and export the samples and exact requests.
The price path is one seeded example, not a median path or a forecast. Bitcoin market prices are shown in USD per BTC in both workspaces. The unhedged Agreement preview accumulates net cash in Dollar and monthly BTC conversion equivalents in Coin; the Coin chart is not a funded wallet balance. Monte Carlo reports the selected strategies across matching seeds, using dollar outcomes in Dollar and BTC outcomes in Coin.
Research also links directly to stress maps, the purchase-price solver and Agreement detail. These supporting exhibits retain their USD Agreement measures. The comparison shows trade-offs; it does not search every possible hedge or automatically choose the best strategy for you. Advanced analysis provides custom strategy construction, all assumptions, the full USD Agreement research desk and ledger, monthly exhibits, USD exposure and sensitivity, and historical Agreement vintages. Each exhibit keeps its stated units.
Reading the Coin result
Each Agreement represents one BTC. Purchase funding uses its own entry price, so 240 par Agreements deploy 240 BTC, including when entry prices vary within a month. A purchase premium or discount changes that funding amount. USD receipts and hedge flows convert at the month’s simulated BTC price; their net BTC flow determines additional contributions or recovery. The holding reference retains those same dated net contributions. BTC surplus is recovery minus that reference.
Gross BTC deployment counts all Agreement purchases. Same-month receipts can support later purchases, and hedges can need additional capital. These offsets and costs explain why net contributions differ from gross deployment. The selected-path cohort table reconciles unhedged purchase cost, receipts and gain to the book. Each strategy can require different additional contributions; the comparison does not assume an identical starting wallet.
Economic outcomes include any surviving derivative mark at the horizon. A positive mark is not already received cash; a negative mark can imply an additional terminal economic contribution. Realized-only contributions, recoveries and signed marks are available separately. The economic and realized bridges each retain both their contribution and recovery sides. No BTC discount rate is assumed.
This is an analytical conversion convention, not a funded BTC wallet. Actual conversion trading costs, cash reserves, borrowing and external free BTC are not represented by this benchmark. See hedging methods for the exact definitions.
BTC cash-flow IRR and wallet growth
BTC cash-flow IRR is an annualized return on dated investment cash flows. It is not the annual growth of an entire starting BTC wallet. Purchases are funded at each Agreement’s entry price; USD receipts and hedges convert at monthly spot. IRR accounts for the dates of these BTC contributions and receipts and excludes unused BTC reserves. Falling Bitcoin prices can make dollar receipts buy more BTC, so BTC IRR can be much higher than USD IRR on the same path.
A single contribution of 100 BTC and recovery of 110 BTC gives 10% total return, after any costs already included in those flows. It is also 10% annualized IRR only when those are the only flows and exactly one year apart; over two years the annualized rate is about 4.88%. Dated payments explain why both the rate and the amounts matter.
The Research headline labels this rate This path’s BTC cash-flow IRR. It always describes unhedged Agreements on one seed. Choosing a strategy does not apply that hedge to the preview. Use the strategy selector in completed Monte Carlo results to see the hedged distribution. A draft change does not recalculate an earlier completed comparison.
To check a particular return, use Export this path. The file preserves the completed assumptions, amounts and engine version. Read gross BTC deployed, net contributions and recoveries alongside the dated IRR. Starting-case results can change when assumptions or calculation methods change; figures from an earlier release should stay attached to that release’s saved result.
For a wallet comparison, define the starting BTC budget, reserves, conversion costs, future cash calls and any derivative collateral first. Use the same starting budget for every strategy and holding BTC, and check that the wallet can meet its obligations on every simulated path. The current contribution-matched benchmark does not establish that feasibility.
Understand the Bitcoin growth assumption
The GBM drift setting is a continuous annual parameter. Expected one-year price growth is exp(drift) − 1; median one-year price growth is exp(drift − volatility² / 2) − 1. At the starting 0% drift and 43% volatility, expected price stays constant while median price declines about 8.83% per year. Zero drift is therefore not a flat typical price path. These are properties of the assumed model, before any shock or bump, not market forecasts.
Coin Research shows these implications beside the completed price path. Its growth sensitivity check changes the drift on matching seeds, keeps the configured volatility and selected hedge, and reports BTC cash-flow IRRs separately for unhedged Agreements and that hedge. The check runs only when requested. Read its simulation count and unavailable or ambiguous rates; an exploratory sample does not establish tail stability. To test a truly flat price control, set both drift and volatility to zero and remove shocks and bumps: BTC and USD cash-flow IRRs should then agree.
Read dollar cash needs separately
In both workspaces, operational cash estimates are labelled USD. That screen assumes receipts remain available as dollars under monthly netting. The BTC outcome assumes monthly conversion equivalents. Converting receipts could remove dollars needed for a later margin call, so the two readings do not establish one jointly funded strategy.
A cash allowance checks whether the modeled monthly need exceeds an amount. It does not change trades or simulate forced closure. Daily margin calls and a reserve/conversion policy require further modelling. Read limits and assumptions before relying on a result.
Keep the evidence
Completed results retain their original inputs when the draft changes. A notice tells you when the displayed comparison uses earlier assumptions. Navigation reuses that completed experiment; leaving during a run cancels its unfinished batches.
Saved results from before engine 0.6.0 retain their earlier monthly-purchase conversion convention and carry a legacy-funding notice. Run a new baseline before replaying or comparing them with current results. New evidence packages specify the unit of every summary field; USD cash requirements stay USD inside a Coin package.
Browser storage is bounded. If a sample cannot be saved, export it before closing or reloading; the interface reports the problem. Browser-local drafts are not shared team accounts.
Export assumptions to transfer the draft, or export all samples from Evidence to retain the completed analysis. The run includes its objective, benchmark/conversion conventions, selected strategies, seeds, engine build and data identity. Replaying an adverse path checks that it reproduces its saved outcome.
Ask through MCP
Use the same MCP connection for either objective. For example:
I measure success in BTC. Compare these strategies against holding the matching contributed BTC. Show the downside and state the cash-conversion assumptions.
Or:
I measure success in USD. Compare the dollar gain, loss severity and cash needs of the unhedged Agreements and these hedges.
The hedge_risk_samples tool accepts objective: "coin" or objective: "dollar". An assistant should clarify an unspecified objective before ranking strategies. No second connection or access token is needed just to change objectives.
The measurement guide defines gross purchases, net contributions, recovery ratios, BTC cash-flow IRR and mark treatment. The release model card identifies the supported version and remaining validation limits.