rules the core Checking status

Rules

Understand eligibility, work verification, reward budgets and payout rules.

On this page

Rules version —

What the network does

Foltri uses token holdings to determine eligibility. Submit verifiable work in your browser and follow each funded distribution through settlement. The browser searches for SHA-256 nonces; the server validates and credits them; Solana is used for transfers and transaction evidence. This work is participation scoring, not consensus security or a service sold as useful compute.

Eligibility

One full hold unit is required. The server takes the minimum balance across 3 fresh finalized reads at distinct slots, at least 10 seconds apart. The checks are per wallet, not a simultaneous chain-wide snapshot. A window freezes eligibility before it starts. Later balance changes apply to a later window; an RPC failure means eligibility is unknown for upcoming windows. The limit is per wallet, not per person.

Units = floor(confirmed token base units ÷ hold unit). Each complete unit adds 2%, up to 15% per wallet.

Challenges and verification

An address-only wallet connection reads your public key. Start asks for a domain-bound session signature, not a transaction or token permission. The server binds the challenge to that wallet, window, rules version, difficulty, expiry and submission limit.

Proof input and acceptance

Hash exactly 72 bytes: 32-byte challenge ID, 32-byte decoded Solana public key, then 8-byte unsigned big-endian nonce. The server recomputes SHA-256. Accept if leading zero bits are at least the challenge target, and server receipt time is in [start, end). A repeated accepted proof returns the original result without adding work.

challenge_hex = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
wallet_hex    = d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
nonce_be_hex  = 0020000000000614
nonce_decimal = 9007199254742548
sha256_hex    = 00161d762d7bae4c3713329e1c602c46ce940358b7f377a7abaebb9c8c75051e
leading_zero_bits = 11

Credited work

A proof earns 2 to the power of the server’s target difficulty. Extra leading zeros do not increase credit. Local hashes per second measure computation on your device; accepted work measures validated, difficulty-weighted participation. A reported device type does not increase rewards.

Window budgets

A window lasts 60 seconds. Only the confirmed reward share of project creator fees received in the trailing 60 minutes enters F60. Divide F60 by 60, round down, and cap it by available funds and 1 SOL. Below 0.001 SOL, the window records work without creating a reward liability. A partial window at startup has zero budget unless it was reserved beforehand.

Available = max(0, reconciled balance − window reservations − unlocked liabilities − locked liabilities − reserve). F60 already represents the reward share; it is not split again. Confirmed fee split: 70% rewards, 15% buyback, 15% infrastructure. Split rounding dust belongs to infrastructure.

Caps and redistribution

Each complete hold unit adds 2% of the original window budget, up to 15% per wallet. Work share can exceed that cap. When an allocation hits its cap, the remainder is weighted by work among wallets that still have room. Integer remainder is assigned by fractional remainder, then wallet address, without exceeding any cap. Anything still unallocated remains available in the reward wallet.

Settlement and payments

An estimate is recomputed from the open window and is not owed. Settlement moves earned amounts to each wallet’s unlocked balance. When payment processing is enabled, a settled balance of at least 0.002 SOL can be queued and locked for payment. Submitted is not paid; confirmed payments are finalized on chain. Unknown outcomes stay locked while the existing signature is checked. Later holdings cannot revoke settled work.

Hold unit adjustments

The initial hold unit is configured in token base units. If a sufficiently fresh 24-hour price reference values one unit above 1 SOL, the threshold may halve no more than once per 24 hours. Adjustments apply to later, unprepared windows. Missing price evidence pauses adjustments and preserves the published unit. 0.50–1.00 SOL is an adjustment target, not a guaranteed price.

Reading published unit and price-source status…

Rejected proofs

A rejected proof does not add work. Reconnect or refresh eligibility only when prompted; stale challenges cannot submit to a later window.

duplicate
Already accepted. No additional work was credited.
expired
The challenge expired. Request another challenge.
wrong_wallet
This challenge belongs to another wallet. Restart the session.
below_target
The nonce did not meet the assigned target.
unknown_challenge
Request a new challenge.
window_closed
The window ended before receipt. Wait for the next window.
ineligible
A fresh qualifying snapshot is required for the window.
malformed
The submission could not be decoded.

Worked examples

These examples illustrate the calculation. They are not project earnings or ledger entries.

Proportional
Ten wallets with identical work and 15% caps each receive 0.001 SOL from a 0.01 SOL budget.
Cap & redistribute
With a 1 SOL budget, a wallet with 40% of the work and a 15% cap receives 0.15 SOL. If the nine other wallets have equal work and room under their caps, they split the remaining 0.85 SOL. Integer remainder follows the deterministic rounding rule.
Everyone capped
Five wallets capped at 15% each can receive at most 0.75 SOL from a 1 SOL budget. The other 0.25 SOL stays in the reward wallet.
Zero budget
Even with accepted work, a 0 SOL window settles 0 SOL in rewards.

Verification and data sources

Mining and settlement entries are server records. A funding or payment entry is called on chain only when supported by a finalized transaction and signature. The public Ledger links the supporting records. Times are displayed in Eastern Time, with UTC in detailed records. A missing or unknown value is shown as an em dash.