Loading
The capital behind the two places in this system that need capital at risk: the bond a resolver posts to rule on a dispute, and the first-loss cover behind the collateralized lane.
BRSR is not a claim on Robinhood, on Robinhood Chain, on Paxos or on USDG, and none of them endorses this. It is not a deposit and it is not a share. Debt in this system exists inside the collateralized lane and nowhere else, so nothing here lends, borrows or pays interest outside it.
One billion BRSR, created in the token's constructor and split four ways in the same transaction.
The token has no owner, no minter, no pauser and no upgrade path. The whole supply exists already, and a mint is refused once the supply is non-zero. What changes over time is who holds each share, and three of the four holders are contracts this page reads directly.
Two charges, both in USDG. One is being made today; the other waits on a credit lane governance has not named.
The facilitator fee accrues in USDG to the treasury the escrow already pays, at 0x7f2D…6d21. The spread would land at the same address in the same asset. Neither is invented for this page: they are the two charges the payment path was built to make, and only the first one is being made.
Two legs, because the two lines arrive in different assets. The first one takes three steps: the fee has to become BRSR before it reaches a share.
Read from the contract.
The BRSR/USDG pool has not been initialised, so there is nothing for a buy to trade against. The price floor in the contract is set where it refuses every trade. Governance sets a real one before the pool is seeded.
First-loss capital for the collateralized lane, and the fee rebate a staked balance earns.
Staking BRSR in this pool is underwriting agent credit. When a borrower in the collateralized lane defaults past the collateral they posted, this pool covers the shortfall before the protocol does, and that cover is taken out of stake. A loss is taken from every staker in proportion to their share, on the way out as much as while staying: an exit is priced when it completes, so asking to leave before a default does not escape one.
A large enough default takes the entire pool. That is not an edge the contract avoids: a first-loss pool that cannot be emptied is not first loss. When it happens the outstanding shares stop being worth anything. Spread already accrued survives, because it was earned before the loss and is held in USDG, outside the stake entirely.
In exchange the pool is where the credit-lane spread is paid, in USDG, once a lane exists to pay it. The buyback compounds purchased BRSR into the same pool. A staked balance also takes a rebate off the facilitator fee on that party’s own settlements. None of these is a rate. None is promised. What arrives depends on how much the system is used.
Read from the staking contract, not from a plan.
Connect a wallet to stake or to see a position.
Everything above is read from the contract and does not need a wallet. A position does.
What a resolver stands to lose for ruling badly on a disputed delivery.
Held by the dispute registry, in the currency it names.
Governance sets the floor at the staking contract, and the registry reads it on every vote.
Putting the bond in BRSR makes the token the security budget of the dispute layer. A resolver who rules badly loses BRSR, which is the version of “the token secures the network” that can be checked against a contract.
The cost of that is real. A bond denominated in a volatile asset can fall below the value it secures, and governance can raise the floor after the fact but cannot raise it faster than a price moves. The answer here is a floor governance tunes, plus a higher floor it can set against an individual resolver. A price feed would make adjudication depend on an oracle the dispute layer otherwise does not need, which is the dependency it exists to avoid.
Every parameter named on this page is behind a two-of-three signature and a 48-hour delay.
The tier table, the bond floor, the buyback’s limits and the address of the credit lane are all set by proposal. Pending proposals, who has approved them and when each becomes executable are on the governance page.