Security contact

No disclosure programme is live and no address is published yet. What has to finish before either exists, what will be in scope, and what to do with a finding in the meantime.

Spec v0.9.1, reviewed 2026-09-08

Risk

There is no security contact yet, and no reward programme. No contracts exist, no address has been published, and no reward has been funded. Anybody presenting a Fyber disclosure address today is not presenting one.

This page exists so that the shape of the programme is visible before it opens, and so that a researcher who finds something in the published specification knows there is somewhere for it to go once there is.

What will be published here


Disclosure address	To be published, alongside a public key for encrypted reports
Response commitment	To be published: acknowledgement window and triage window
Programme host	To be decided between a hosted platform and a self-run programme
Reward scale	To be decided and funded before the programme opens, not after
Scope	The deployed contracts, at their published addresses, at the deployed bytecode

What has to finish first

Nothing opens until the sequence below has run, in order. It is the plan of record, and at the time of writing none of it has started, because the specification is still being reviewed against its own red teams.

Internal review of the code against the frozen specification.
The specification frozen, and every blocking measurement resolved. Those are on What is measured before launch.
A first private audit, weighted toward the price layer: the pool observer, the signed-price verifier, the composite and its clamping, the branch's reentrancy lock and burn paths, and the Closer key.
A public contest.
A second private audit and a formal review.
A funded disclosure programme, opened before anything holds real money.
Launch at four branches and one hundred thousand dollars of debt each, for fourteen days.

Every report from steps 3 to 5 is published in full, including findings acknowledged rather than fixed. A protocol that cannot fix anything after deployment has no honest way to publish a partial audit.

What will be in scope, and what will not

In scope. Anything that lets a party take value they are not owed, block a function the specification says can never be blocked, move a price the specification says nobody can move, or break one of the properties on Invariants.

The properties most worth attacking, because the whole design rests on them: that repaying, adding collateral and closing succeed in every state; that no signer group can carry more than 49% of the median; that a position never becomes liquidatable because the price rose; that the day's borrowing limit cannot touch a liquidation threshold; and that a failure inside any FBR or vault contract cannot make a core operation fail.

Out of scope. The economics. A parameter you consider badly chosen is a disagreement with the specification, not a vulnerability, and the right route for it is the public contest at step 4 or a note on the specification itself. The same goes for the risks already written down on the Risks pages: an issuer default, a frozen collateral balance, a sequencer outage and a spin-off with no on-chain credit are disclosed exposures rather than findings.

Also out of scope: anything about a third-party interface, which is not the protocol and is not operated by anybody here.

What to do with a finding today

The specification is public and so is this documentation. If you have found a defect in the design rather than in code, the useful thing is a written note against the numbered rule it breaks, published or sent to the addresses named in the repository once they exist.

If you later find something in deployed code and no programme is open yet, the ordinary norms apply and this page will not pretend otherwise: the protocol has one key that can freeze for at most 72 hours and close a branch for good, held by a 2-of-3 Safe whose address will be published. Until it expires, 365 days after deployment, that key is the only response that exists to a live incident, and reaching it quickly matters more than reaching it privately.

After it expires, there is no response at all beyond users exiting, which is why steps 1 to 6 above are not negotiable.

The monitoring that runs alongside

An open-source watcher is published with the contracts. It alerts on the accounting identity breaking, a branch frozen or halted for more than an hour, dispersion above one per cent for half an hour, a reporter diverging from its public venue by more than half a per cent, a reporter renouncing, a source group absent for an hour, a reference print quarantined, a contradiction lasting an hour, a saturated pool, a seizure of staked FBR, a branch ladder locking, a pool falling under 30% of supply, the peg-module reserve under 5%, the depeg guard opening, and any freeze the Closer key sets.

Anybody can run it. During the key's life the development addresses commit to running it continuously, and that commitment is worth exactly what such a commitment is worth, which is why it is written here as a commitment and not as a property of the code.