The first-loss buffer

This is the mechanism that lets Fortell say a trader's losses do not reach the people whose capital funds the seats. It is worth reading rather than taking on trust, and this project agrees: an internal review once found the backer page already claiming machine-proved first-loss absorption at a time when the pool had no buffer account at all and a losing seat put its loss straight onto backer money. The copy was corrected the same day. What follows is the mechanism that had to be built before that claim could go back up.

#What it is, in one paragraph

Fortell keeps its own cash in the same account as backer capital. That cash is the buffer. When a funded seat closes at a loss, the loss is written off the buffer first, so the value of a backer's stake does not move at all. Fortell tracks how much of the buffer is already promised to seats that are currently live, and it may only ever withdraw the part that is not.

#Whose money is which

Three quantities, and keeping them apart is the entire design.

Because Fortell's cash physically sits with backer capital, every figure that describes what backers own subtracts it. What a backer's share is worth, what may be withdrawn, and what may be deployed into a seat are all computed with the buffer taken out first. The buffer is in the account, but it is not backer money and is never priced as if it were.

#Why it is cash and not an accounting entry

This is the part that matters most and it is easy to skip past.

A buffer that were only a number in a ledger would let a loss be written off against capital that was never there. That is worse than having no buffer at all, because it would look like protection while backer money silently absorbed the loss anyway. So the buffer is real money in a real account, and the check anyone can run is whether the recorded buffer is actually less than or equal to the cash in the account. If it is not, the protection is not backed and nothing else on this page is worth reading.

#Why a shortfall stops the world instead of leaking

The interesting decision is what happens when the buffer is not enough. There were two options:

1. Absorb what the buffer has and pass the rest through to backers. Best effort.

2. Refuse the settlement entirely.

Fortell takes option 2. If the buffer cannot fully cover a seat's loss, the transaction that would close that seat does not land.

This is the difference between a guarantee and a marketing sentence. Under option 1 the claim "trader losses never touch backer capital" is true only while the buffer happens to be big enough, and a backer has no way of knowing in advance whether it will be. Under option 2 there is no sequence of events in which a loss reaches backer money, because the transaction that would do it fails. The failure mode is a stuck seat and a loud error, not a quiet haircut, and the fix is for Fortell to top the buffer up.

The reasoning is written into the source: blocking the settlement until the buffer is topped up is the correct behaviour, and the alternative is silently charging backers for Fortell's own sizing mistake.

There is a second, narrower guard beside it: a seat cannot eat more buffer than was reserved for that specific seat. Without it the pool would still be solvent overall, but a different live seat's protection would silently be gone and its close would be the one that broke.

Neither guard should ever fire, because a seat cannot lose more than its reserve in the first place. They are there to fail loudly if that ever stops being true, rather than to quietly reassign somebody else's cover.

#A seat cannot be funded before its cover exists

Checked when the seat is funded, not when it closes. Adding a new seat's reserve to the already-reserved total must not exceed the buffer, or the funding transaction fails.

Doing this at funding time rather than at close is the whole point. At close the seat has already traded, and discovering that the protection was missing at that moment is the worst possible time to find out.

The buffer is also excluded from what can be deployed. Its entire job is to be sitting in the account when a seat loses, so it can never be sent out as seat capital.

#The reserve is derived, not typed in

The amount of cover a seat reserves used to be a number supplied by whoever funded the seat. Pass a small one and the seat is funded with protection it does not have, the total understates what live seats collectively need, and the shortfall only surfaces later, on whichever seat happens to lose. The one number that must never be wrong was the one number nothing checked.

It is now read out of the seat's own account and recalculated. The pool reads the seat's size and its drawdown limit, works out the cover that combination requires, and refuses to fund it if the supplied figure disagrees. It also checks that the account it is reading is genuinely a Fortell seat, because otherwise any account with convenient bytes in the right places would do, and the caller picks the account.

#Topping it up is open to anyone. Taking it out is not.

Anyone may add to the buffer. No permission, no signature from Fortell. The reasoning is worth quoting: needing a governance signature to top it up is exactly how a buffer ends up empty at the moment it is needed.

Only Fortell may take from it, and only the unreserved part. Two bounds apply at once: the withdrawal cannot dip into cover that a live seat is relying on, and it cannot leave the pool short of what queued withdrawals need. The first bound was found to be necessary by the verification harness rather than by inspection.

#How to check any of this yourself

Three records exist on chain for every movement of the buffer: one when it is funded, one when it is withdrawn, and one when it absorbs a loss. Between them the buffer's entire history can be reconstructed and compared against the account, without trusting a dashboard.

The checks worth running, in this order, because each fails differently:

1. Is the recorded buffer actually backed by cash in the account? If not, stop. The guarantee is not backed and nothing further matters.

2. Is everything the live seats have reserved genuinely held? The reserved total should never exceed the buffer.

3. Is the buffer above zero at all? Every proved property about the buffer is trivially true when there is no buffer. A green proof beside a zero protects nobody.

Then, for each live seat, its reserve should equal its size multiplied by its drawdown limit, and the reserves of all live seats should sum to exactly the reserved total.

Checking it yourself has the addresses and the method.

#The one number this page will not tell you

How much is in the buffer right now.

That is deliberate and it is the most important instruction here. A figure for it was once written into a standing review rule as a fact about the world. It was true when written and false a few hours later, and anybody citing it would have been asserting the opposite of reality.

So the rule is a procedure, not a value: read the buffer and the reserved total off the chain before restating anything about first-loss cover, and treat the buffer as unfunded only if your own read says so. The live figures are on Fortell's transparency page, and the authority behind that page is the chain itself.

The answer is also different per pool and per day, so it has to be asked each time. On mainnet the question does not arise yet, because there is no pool there.

#What this constrains about earning yield on idle capital

Worth knowing if you are a backer, because it bounds a thing that would otherwise look like free money.

The buffer has to be liquid. Idle pool capital parked somewhere to earn yield can only ever be the surplus above what queued withdrawals need, plus the buffer, plus the reserve kept for withdrawal liquidity. Park more than that and withdrawals break and the first-loss guarantee breaks at the same moment, because they are the same failure.

The size of that surplus is a reading, not a constant. It shrinks every time a seat is funded, and seats are funded automatically without anyone starting them.