Skip to content
ubi.fun
Esc
↑↓navigate↵open⌘Jpreview
On this page

Verify any payout

Every holder payout follows a locked, public formula on public data. Here's how to check one yourself.

The holder pool does not ask for your trust. It publishes its work. Every daily payout is the output of a locked, deterministic formula over public chain data, published before it takes effect, with a 1-hour window in which anyone can recompute it and call out a discrepancy.

The lifecycle of a payout

  1. The epoch closes. Each UTC day is one epoch. Its boundary is the last block before midnight UTC.

  2. The formula runs. The day’s pool inflow is measured on-chain and splits between eligible UBI holders by time-weighted balance across the epoch’s blocks, from the Oct 2, 2026 round (earlier rounds used the balance at the boundary block, and rounds before Sep 27, 2026 first split between coins by their share of the day’s traded volume). From the Oct 7, 2026 round, the v2 fee split settles first: each v2 token’s vault gets 18.05% of that token’s fees as a leaf of its own. Remainders from rounding carry into the next day, so nothing leaks.

  3. The dataset publishes first. The complete result, every input, every account’s entitlement, and the Merkle tree over them, is published and pinned to IPFS before anything is submitted on-chain.

  4. The root enters review. The tree’s root is submitted to the rewards distributor, where it sits behind a 1-hour timelock before activating. This window exists so the published dataset can be independently checked against the chain.

  5. Payouts go out. After activation, the keeper claims every included account’s cumulative entitlement on its behalf, with the published Merkle proof. The distributor only ever pays the account named in the leaf, so the keeper can’t redirect anything, and anyone can still claim directly. Later roots always contain every account’s full lifetime total, so a late or missed payout never costs you anything.

Checking a payout yourself

To verify a pending root, recompute it: take the epoch’s boundary blocks, read the pool inflow from the fee splitter, reconstruct UBI holder balances from chain logs, apply the proportional split with floor rounding, build the Merkle tree, and compare your root to the pending one. From the Oct 2, 2026 round, each holder’s weight is their time-weighted balance over the epoch’s N blocks: the balance held at the start counts for all N blocks, a change in block b counts from b through the boundary block, and the sum is divided by N and floored. The published dataset lists every holder’s weight, and its exact bytes (the ones the on-chain dataset hash commits to) are served at https://api.ubi.fun/ubi/epoch/<day>/dataset as well as on IPFS. The published dataset gives you every intermediate value to diff against, so a discrepancy is pinpointable, not just detectable. From the Oct 7, 2026 round it also lists the v2 fee split: for each vault token, its pool, its protocol share over the day (from the PositionManager’s distribution logs between the two closing distributions, counted once the token’s creator NFT sits in its vault) and the part paid to its vault, which you can recompute as share × 1805 / 4105.

Eligibility rules you’ll need: a holder counts if it has a positive balance at the boundary (from the Oct 2, 2026 round, a positive time-weighted balance over the day), has no contract code at the boundary (from the Sep 28, 2026 round, an EIP-7702 delegation designator, 0xef0100 followed by the delegate address, still counts as a wallet; FOMO and Bitget Wallet accounts look like this), and is not one of the protocol’s own addresses; entitlements below $0.01 accumulate until they cross the floor. Creator vaults appear as leaves only for their v2 fee split refunds, never as holders.

The infrastructure holding the funds is Morpho.s Universal Rewards Distributor. Its role and trust assumptions are explained in Security model.

Was this page helpful?