Brics Finance

2The payout problem

A token that pays its holders from its own trading fees has one input: people trading it. That input is largest in the first days and smallest when attention has moved on. The payout therefore peaks when it is least needed to hold a community together and collapses when it is most needed. There is nothing underneath it: no asset the protocol owns, no income that does not depend on the next trade.

Two further problems follow from how such tokens are usually built:

• Sampling. Weighting holders by a few snapshots a day invites timing: buy before a sample, sell after. Any design that does not integrate continuously over time has to be defended against this, and usually is not.
• Invisibility. A holder’s commitment is a number in a table. There is no durable, public record of having held through the quiet weeks, so there is nothing to lose by leaving and nothing to show for staying.

Brics Finance addresses each: it banks part of every dollar into assets that pay on their own (§6); it weights by the time integral of balance, to the second (§4); and it turns time held into something visible and permanent (§10).

4Holding and weight

A holder is any key-controlled wallet with a $BRICS balance. Nothing is staked, locked or deposited. Token accounts owned by a program derived address (the bonding curve, liquidity pool vaults, bridge custody, multisig vaults) are excluded automatically, because a PDA is off the ed25519 curve and cannot be controlled by a key. Additional owners can be excluded by policy and are listed on the addresses page.

The weight of an account

For an epoch [t₀, t₁) of 21,600 seconds, the weight of a token account with balance b(t) is

w = ∫ b(t) dt  over [t₀, t₁)   (raw units × seconds)

where b(t) is piecewise constant, changing only at the block time of a finalized transaction that touched the account. The opening balance is the post-balance of the last such transaction at or before t₀. A holder’s weight is the sum over the accounts of every wallet linked to them for that epoch, and their share is their weight over the total.

How the history is obtained

The indexer takes a finalized snapshot of every token account for the mint on each pass. For each account whose balance or owner changed, it walks that account’s own signature history since the last indexed signature and records the account’s post-transaction balance from each transaction’s postTokenBalances, at its block time. The snapshot identifies which accounts moved; the account history establishes exactly when. A closed account disappears from the snapshot and its history is walked once more to record the final zero.

Why timing earns nothing

Buying a balance B for Δ seconds contributes B·Δ. A buyer who enters one second before close earns one second of weight; with the epoch at 21,600 seconds, that is 1/21,600 of what the same balance earns by holding throughout. The only way to a large weight is balance held over time. There is no sample to hit.

Linking

A holder may link up to 4 wallets per chain with one message signed by both. Links take effect from the next epoch and never rewrite the past; a wallet belongs to at most one holder at a time. Splitting balance across wallets cannot increase share, because weight is additive.

6The Foundation

The Foundation’s share of each settled epoch buys three assets in fixed proportion:

The harvest rule

Each purchase is a lot (u, i₀): raw units bought and the asset’s index at purchase: the multiplier for xStocks, the price for USDY, a constant 1 for anything without a yield mechanism. At index i the lot’s principal floor is

floor(i) = ⌈ u · i₀ / i ⌉      harvestable(i) = max(0, held − floor(i))

and the invariant is held · i ≥ u · i₀ at all times: the vault always holds at least the underlying it bought. Only the excess, interest and reinvested dividends, may leave, and it leaves as Payday revenue. Rounding is always against the harvester. A 5% index rise on a lot of 1,000,000 units frees exactly 47,619 units, not 47,620; the database trigger refuses the latter.

Enforcement

1. The protocol computes harvestable units in integer fixed point (indices × 10¹²) and throws on any request above it.
2. A harvest is journaled before anything is sold. A BEFORE INSERT trigger re-checks the invariant against the database’s own lot and harvest rows and refuses any row that would touch principal.
3. Lots and harvests are append-only; no code path updates or deletes them.

What it does not mean

This is a rule about the vault’s holdings. It is not a floor under the price of $BRICS, and $BRICS confers no right to redeem against, withdraw or claim any Foundation asset. The Foundation’s dollar value moves with equity markets; what cannot go down is the underlying it holds. Because supply only falls, the underlying held per token only rises.

Custody

Foundation purchases arrive in the payout wallet and are moved at once to a separate Foundation wallet. The payout key signs deliveries and never holds the vault. Moving yield back out for a harvest needs the Foundation key, which can be kept offline; until it signs, the harvest waits and is shown on the status page.

Illustrative arithmetic, assumptions printed

This is an illustration of the mechanism, not a projection. Every input below is an assumption chosen to show scale; none is a forecast.

The honest reading: early on, the Foundation’s yield is small beside fees. Its value is that it cannot shrink and every epoch of fees adds to it, so it is the one part of Payday that grows through a quiet market rather than disappearing with it.

7Settlement, end to end

Close and weigh

An epoch settles once its window has closed. The pot is fixed as the Payday share of revenue booked in the epoch plus the previous epoch’s carry-out. Per-account weights are computed from indexed events (§4) and summed per holder, using the wallet links in force for that epoch. Owners never linked by anyone become holders of their own.

Reconcile

Before anything is written, a deterministic sample (the 25 heaviest accounts and 25 chosen by hashing the epoch number) is re-weighed from scratch through a second, independent RPC provider, reading each account’s signature history and transaction post-balances directly. Any disagreement throws, the epoch stays open, and nothing is published.

Allocate and commit

The pot is split by largest remainder: each holder receives ⌊pot·w/W⌋, and the remaining units go one each to the largest fractional remainders, ties broken by holder id. The result sums to the pot exactly and nobody receives more than the ceiling of their exact share. Weights, per-account weights, obligations (each carrying the holder’s Set for that epoch), the Merkle root and the manifest hash are written in one database transaction. A statement-level trigger refuses the whole batch if the epoch would owe more than its pot.

Buy

Each holder’s amount is split across their Set by largest remainder in basis points; amounts wanting the same asset are batched into one purchase. Every purchase is quoted by Jupiter with a maximum slippage and journaled with the quote, the minimum acceptable fill and each holder’s contribution, under an idempotency key payday:<epoch>:<asset>.

Execute and push

In plan mode the process stops here: everything is computed, quoted and published; nothing is signed. In execute mode the executor first refuses to start if the payout wallet cannot fund every planned purchase, re-quotes each purchase and refuses to fill below the journaled minimum, then signs the swap, waits for finality and records the fill. Filled units are split back to holders in proportion to their contribution and pushed as TransferChecked transfers (with transfer-hook accounts resolved where the mint requires them), creating recipients’ token accounts at the protocol’s expense. Purchases and deliveries may only move forward in status; their amounts are frozen by trigger.

Opening a token account costs about 0.002 SOL, so a very small payout can cost more to send than it is worth. A holder’s payout below the delivery minimum (0.02 SOL per asset in their Set at launch) is carried, with its reason, to their next payday and released once the total clears the minimum. Carry is journaled and never lost. If no route can buy an asset, that part of the payout uses the default Set for the epoch. A purchase still unsent after an hour is quoted again at the current price rather than left stuck, and a failed delivery is retried a bounded number of times before it is shown on the status page for the operator.

Build

When every delivery to a holder for an epoch is confirmed, a floor is laid: its material is the asset family that made up most of the delivered value. Deliveries worth less than a cent lay no floor.

12Threat model

Report a vulnerability to hello@bricsfinance.fun. See /.well-known/security.txt.

14$BRICS

What we will never claim

• A price target, an APY, a return, or that any payout is guaranteed.
• That $BRICS is an investment, a security, a fund, or a claim on the Foundation.
• That “the Foundation only grows” refers to the price of $BRICS. It refers to the underlying the vault holds.
• Any listing, partnership, audit or market figure that does not exist.

“Dividend” is used colloquially. Payday is a protocol distribution, not a corporate dividend.

15Prior art: Mosaic Finance

Mosaic Finance ($MOS, mosaicfi.xyz) shipped first, and the idea of paying token holders in tokenized equities they choose is theirs. Their documentation is clear and their draw randomness, a commit and reveal oracle against a manifest hash fixed beforehand, is sound. Everything below is taken from their public documentation, site and API as read on 2026-09-11.

The structural difference is the Foundation: a protocol that banks part of every dollar into assets that pay on their own accumulates something a protocol that pays out everything cannot catch up to later. The economic disadvantage is equally structural: launching on pump.fun means a creator fee set by the venue rather than a 2% fee set by the protocol.