Become a front-end

The protocol has no official front end. The reference interface is specified but operated by third parties, and no contract function assumes any interface exists. If you want to run one, nothing stops you, and nothing authorises you either — there is no registry, no allowlist and no approval.

What follows is the obligation list. Some of it is legal, some of it is product discipline, and the last section is the part people usually ask about first.

There is no on-chain kickback

This was a decision, not an oversight. Either a front-end share is coded at genesis, or it exists outside the protocol forever. This specification codes none.

If you want to be paid for running an interface, the routes are all off-chain: charge your users directly, run a rate-delegation service they opt into, or operate a keeper alongside the interface and take the liquidation share. What you cannot do is take a cut of protocol revenue, because the protocol has no mechanism to give you one.

The same rule applies to rate managers. A delegate may charge a fee, but it is paid outside the protocol, and the reference interface only lists managers whose published management fee is at most 0.25% of debt per year. That is a listing criterion applied by an interface, not a contract rule (Rule R-1.6.1, Rule R-5.9.3).

Mandatory disclaimers

Ten disclosures must appear before a user's first transaction, be individually attested with a checkbox, and appear in your terms of service (Rule R-15.4.1):

1. The exact nature of the collateral. Collateralised tracker certificates, Swiss-law ledger-based securities, secured and limited recourse, conferring no right to the underlying shares. The issuer was incorporated on 23 October 2025, has no operating history and no rating, and is not a regulated entity.
2. The price is computed, not quoted. It is an hourly composite of several groups of sources, so it is an estimate rather than an executable quote, and the ratio required to borrow rises with the protocol's own uncertainty. A worked numeric example is required — the reference case is a token quoted on-chain at 132.64 USD while the same exposure was worth 28.84 USD elsewhere.
3. Liquidation risk, at any hour. The threshold applies every hour of every day, and there is no waiting period outside the intervals the protocol defines.
4. Sequencer risk. The chain operator can filter or reorder transactions with no delay, and possibly with no verified uptime feed.
5. fyUSD is not electronic money, not a deposit, and not guaranteed.
6. fyUSD and sfyUSD carry no rights and no claim on any entity. No governance right, no vote, no share of profits, no claim against any company, foundation or person; and nothing in your interface may be an offer or solicitation in respect of any other asset.
7. Issuer and custodian risk. The feed may keep publishing the share price while the token is worth nothing.
8. Immutability. No parameter can be corrected after deployment. An unanticipated corporate action such as a spin-off can cause a permanent loss with no human guard. A failing component closes its branch rather than being repaired.
9. The Closer. A key held by the development company can freeze certain functions for at most 72 hours and can irreversibly close a branch or the protocol, until day 365. It can never issue, modify, or block repayments and withdrawals. After that date no human intervention is possible.

Number 8 and number 9 are the two most commonly omitted and the two least excusable to omit.

Attestation

There is no on-chain blocking of any kind in Fyber — no blocklist, no address freeze, no check on who anyone is — and there never will be, because adding one would destroy the argument that the protocol has no identifiable issuer (Rule R-12.8.1).

What your interface must do (Rule R-15.4.3):

• Attestation of the terms of service before the first transaction.
• A periodic review, with a written trace.

What you must never say

Prohibited in every communication, without exception (Rule R-15.4.2, and the brand rules):

• Any promised yield. Display a realised figure and its formula. Never "up to X percent", never a projection, never a headline rate.
• Any tax argument, however implicit. "Without triggering a taxable event" and every variant of it.
• Any promise about FBR. FBR is the protocol token: fixed supply of 100 million, no sale, earned by using the protocol and by providing liquidity, staked as sFBR for a share of revenue, a boost and a backstop. It never pays the Stability Pool yield — borrower interest does — and it governs nothing in version 1. You may state those facts. You may never promise a price, a listing, a yield, a sale or a date, and you may never assert that no token exists.
• Any suggestion that the Stock Tokens are shares. They are certificates backed by shares. "Tokenised stocks" is acceptable only if a legal page states the exact nature.
• Any claim of absence of risk. The word "safe" appears nowhere.
• "Fully decentralised", for as long as the Closer key exists. The claim the protocol makes is "no identifiable issuer".
• "Paid to borrow" as a promise.

What you must display

Branch state, always visible. Per branch: the current state — LIVE24, DEGRADED, FROZEN, paused, circuit, mint freeze, upgrade freeze, Closer freeze, shut down, dormant — and what it changes. The rules you display must change with the state (Rule R-15.1.8).

One risk number for a borrower. The price at which the position would be liquidated, debt × MCR / coll. It does not move when the market shuts, which is the point of showing it. Not a health factor, not a coloured gauge, not a score (Rule R-15.1.2).

Remaining capacity, with the reason. debtCeiling() − getEntireDebt() per branch, in real time, together with which of the four terms of the ceiling is currently binding and the dates and conditions of the next capacity tier (Rule R-15.1.5).

Both yield numbers, with their formulas. The prospective figure — pool share × average rate × debt / pool — and the 30-day realised figure from the wrapper share price, with the fraction of assets currently in collateral being sold and the current discount. Under both: the statement that the number falls if borrowers pay less or the pool grows, and that nobody promises it (Rule R-9.4.1, Rule R-15.1.9).

The redemption queue position. How many positions and how much fyUSD sit ahead of the user, from a walk of SortedTroves, with a one-click rate increase (Rule R-15.1.7).

The powers page. The Closer's Safe address, its expiry with a countdown, any freeze in force and when it ends, the cumulative freeze budget consumed per branch, the liquidation freezes remaining, and the published doctrine. Plus each dormant branch's canActivate() result with the failing criterion, its current value and its threshold; each branch's current and next capacity tier; and a link to the zero-setter deployment report (Rule R-15.1.13).

Public liquidation history. For each one: the regime, the price used, the bonus, and the mode — pool liquidation, direct liquidation, or settlement (Rule R-15.1.11).

PSM state. Reserve, remaining intake capacity, and the two implied prices, so a user can compare them with whatever a DEX quotes.

How to phrase constraints

Every constraint is stated as a guarantee, and the guarantee must be mathematically true (Rule R-15.2.1, principle P9):

If you cannot state a constraint as something true, do not state it as a guarantee.

Anti-patterns

No artificial countdowns. No scarcity messaging. No aggressive defaults — the amount slider starts at half the maximum, not at the maximum. No animated counters, no confetti, no mascot, no gradients that read as a game. The comparison to hold in mind is a private bank's lombard credit desk, not a yield farm.

Practical notes

• Gas. The expected usage is a mobile wallet browser with a user who holds no ETH. An ERC-4337 paymaster is the intended answer; whether one is available to a third-party interface is an open question you should verify.
• Hints. Compute SortedTroves insertion hints off-chain with findInsertPosition and pass them; without hints, insertion is O(n).
• Do not reduce the quote to a price. Read the whole struct. regime, confBps, pRef, pLiq, pRedeem, bandBps, preAction, quietEdge, edgeUntil and degradedSince are all things a user needs to see. In particular, show the available LTV and the reason it is where it is.
• Poke the dormant branches. Calling LiquidityOracle.poke() on every visit to a dormant branch's page is what fills the depth buffer that activation requires. It costs your users nothing and it is how the branch eventually opens.
• Handle typed errors. The contracts revert with custom errors, not strings. Decode them and say what actually happened.

Last reviewed: 2026-09-07 · Spec v0.4