2100x / Protocol workbench

Before a position.
Understand the promise.

Explore one fictional BTC/USD position. See what a price move means for the participant, the liquidity pool, and the amount needed to settle.

Every price and balance below is a fictional input you control. There is no live market feed, oracle, account, or deployed protocol behind this worksheet.

01 / One position, both sides of the ledger

Build a scenario.

USD amounts are entered to the cent.
Calculations do not move money.

Start with an example
Fictional BTC / USD

Choose inputs, then calculate.

1–100× for this worksheet only. This is not a proposed launch limit; “2100x” is the project name.

Hypothetical funds available to cover this position’s profit. Margin is separate.

You set this assumption. No real price verification is performed.

Use a decimal point and at most two decimal places, without commas or currency symbols.

Scenario ledger

SIMULATED

No calculation yet.

Trace the outcome.

Calculate to see profit or loss, equity, and whether the stated balances cover a hypothetical settlement.

02 / An obligation does not disappear

When liquidity has to wait.

SIMULATED PROFIT CLAIMS

Two fictional profit amounts have been finalised: Alice is owed $120, then Bo is owed $80. The dedicated repayment pool starts empty. Add fictional funds, allocate them in order, then let each beneficiary withdraw their reserved amount.

This is an independent demonstration. The price inputs above do not create claims here. Posted trading margin is held separately and is not part of this repayment pool.

Free repayment liquidity
$0.00
Unreserved funds in this example
Reserved for withdrawal
$0.00
Already assigned to beneficiaries
Still awaiting funding
$200.00
Finalised profit not yet reserved
Total withdrawn
$0.00
Fictional completed withdrawals

Dedicated funding only. No deposit or transfer is made.

First settled, first funded

Allocation visits at most two claims per step. A partial payment stays with the oldest unfunded claim before the next one receives funds.

Loading the fictional repayment ledger.

FIFO ledger · settlement order is preserved
Claim / orderProfit claimWithdrawnAvailable to withdrawAwaiting fundingAction
Illustrative risk guard / blocked

Existing obligations come first.

New risk stays blocked while profit claims await funding or no free risk capital remains.

Reserve first. Withdraw separately. In the proposed contract, anyone could trigger a bounded allocation step; only the beneficiary could withdraw their reserved funds. A failed withdrawal would leave that reservation intact and would not stop funding the next claim.

A queue records debt; it does not create liquidity. There is no promised waiting time or guaranteed future funding. Unfunded claims are not a substitute for launch capital. This example does not divert another trader’s margin, and proposes no XO distribution while participant obligations remain open.

Browser arithmetic only. Clearing this guard never opens trading or confirms that a real pool is safe.

03 / What this proves

A visible accounting path.

For one hypothetical linear position, we can trace the price change to profit or loss, preserve negative equity, and expose a liquidity shortfall. A stale or divergent price assumption blocks an illustrative settlement. A separate claim ledger illustrates partial FIFO funding and beneficiary withdrawals without erasing the balance still owed.

04 / What remains

The protocol itself.

Live price checks, liquidation, funding and fees, collateral custody, pool risk, contract permissions and admin powers are not implemented here. Neither are wallet transactions, real deposits or withdrawals, or BTC payment rails.

The next implementation must be tested and independently reviewed. These browser models are not evidence that a production protocol is secure or fully decentralized.