The digital check idea
An OffAir offline promise behaves more like a signed digital check than instant final cash. The promise is created locally, then synchronized, claimed, and settled when connectivity returns.
Back to OffAir
Risk system and policies
OffAir's trust layer for offline promises.
OffAir lets people create bounded offline payment promises, but it does not assume every device, wallet, or counterparty is safe. Score, trust, blocklists, quarantine, and policy limits work together like an immune system for local settlement.
risk decision
allow / warn / block
Trust is earned, risk is bounded, settlement is verified after reconnect.
local trust
wallet lineage
risk score
on-chain blocklist
Simple analogy
Think of a neighborhood tab, not a magic offline bank.
In the US, imagine a local diner, campus pop-up, or farmers market that lets known customers keep a small tab. People who come back and pay cleanly can get more flexibility. A stranger with inconsistent behavior gets a smaller limit or a warning.
What is score?
A practical trust note from 0 to 100.
The score is not a moral judgment. It is an operational risk signal used by the app and protocol policy before an offline promise is accepted.
High trust
80-100
Clean history, settled promises, low pending exposure, and predictable reconnect behavior.
New or unknown
~50
Usable with tighter limits because the device has not yet built enough local evidence.
High risk
0-30
Suspicious, inconsistent, blocked, or quarantined behavior can prevent offline promises.
What OffAir observes
The app looks for behavior that matters when there is no live server approval. Good evidence increases confidence. Unsettled or inconsistent evidence lowers it.
1Long time offline
More uncertainty because recent state cannot be verified.
2Many pending promises
Higher exposure before clearing.
3Inconsistent local history
Potential replay, tampering, or broken journal state.
4Settled payments
Trust improves when promises are reconciled cleanly.
5Clean sessions
Healthy sync and device behavior reduce friction.
6Rejected claims
Risk rises when clearing fails or evidence is disputed.
allow / warn / block
Before an offline payment, the app asks one question.
Does this device and counterparty look safe enough for the requested offline amount?
Proceed normally
The score, policy, amount, reserve, and local evidence are within the expected risk range.
Show a visible warning
The user can continue only after understanding why the promise is riskier than usual.
Stop the operation
The promise is above limit, the wallet is blocked, or the risk evidence is too weak.
Practical US examples
The exact language changes by culture, but the safety logic is the same: keep small local commerce usable while limiting abuse.
Campus seller with clean history
A student has used OffAir at club events for months, syncs often, and has no rejected claims. The app can allow a faster flow with a higher local limit.
Pop-up booth with a suspicious device
A device returns after weeks offline with many pending promises. The app lowers the limit, shows a warning, or refuses the offline path.
Compromised wallet
If evidence points to a stolen wallet or fraud pattern, a local block can protect one user and an on-chain block can protect the protocol.
Local trust, blocklists, and quarantine
OffAir separates mild doubt from serious protocol risk. Not every suspicious signal needs a global ban.
Local trust
Your phone can remember that you have traded cleanly with a person before. This local reputation can work even before a central service is reachable.
Two blocklist levels
A local blocklist says your app no longer trusts a wallet. The global protocol layer now uses a Merkle Root plus compact historical events instead of storing every wallet in one on-chain array.
Quarantine
Quarantine is a pause state. If the backend sees altered app state, high exposure, or unusual behavior, it can stop offline budget and limit synchronization until the risk is reviewed.
Identity continuity without raw device tracking
OffAir no longer treats a fresh wallet as a completely fresh reputation. The app derives a private Device Reputation Anchor from salted local signals, then uses wallet lineage, cooldowns, and trust ceilings to make disposable-wallet abuse harder.
Device Reputation Anchor
The app mixes local installation salt, device capability signals, policy epoch, and strong hashing. Raw MAC addresses, serials, Android IDs, and human identity data are not stored.
Wallet lineage
A new wallet on the same reputation anchor inherits a risk floor, trust ceiling, cooldown state, and unresolved exposure. Creating a new wallet is no longer an instant reputation reset.
Adaptive exposure
Good lineage can recover over time through clean settlements. Degraded, rooted, tampered, or reset-heavy lineage gets lower fast-offline limits or verified-only settlement.
Blocklist Root + Historical Ledger
The scalable blocklist model separates current state from historical memory. Solana stores a compact active-state commitment and append-only event pages; apps, backends, and indexers can reconstruct the active set from history.
Merkle Root state
The canonical active blocklist is represented by one 32-byte Merkle Root, an epoch, an update timestamp, event count, active count, authority, and accrued protocol-fee accounting.
Append-only ledger
LISTED and DELISTED events are written into compact history pages with wallet, action, epoch, timestamp, reason hash, admin cost, and unresolved obligation.
Proof and recovery model
The program includes Merkle membership proof validation and records administrative costs so delisting can recover obligation, entry review cost, exit review cost, and the 10% risk-pool fee.
Trust tiers shape the fast offline limit.
OffAir keeps limits in SOL, not dollars. Dollar references are only mental models for humans. The protocol stores and enforces SOL-denominated capacity.
new
~0.054 SOL
Small everyday promises for a device with little history.
trusted
~0.215 SOL
Higher fast offline capacity after clean sessions and settlement evidence.
high_trust
~1.073 SOL
Expanded capacity for strong local and protocol reputation.
Current MVP policy example. Values can change as the protocol is tuned.
Three protection layers
The risk system is not one switch. It combines local context, backend policy, and blockchain enforcement.
Local app
Contextual reputation, warning screens, local blocklist, and offline amount checks.
Policy backend
Risk analysis, budget provisioning, quarantine, sync review, and policy distribution.
Blockchain
Strong blocklist, replay protection, claim, settlement, burn, and auditable records.
What OffAir does not promise
Clear boundaries make the product safer and easier to understand.
It does not say every offline promise is guaranteed final money.
It does not remove counterparty risk.
It does not need a bank-like account to create a local promise.
It does not turn a risky stranger into a trusted payer just because the UI is smooth.
Market context, without copying banks
Payment systems around the world already teach users that fraud, reversal, and identity risk need explicit UX. OffAir applies that lesson to offline crypto promises while staying clear that it is not Pix, Zelle, a bank account, or a stored-value product.
FTC payment app safety guidanceUS consumer guidance emphasizes verifying who you are paying and treating app transfers carefully.Banco Central do Brasil MED guideBrazilian Pix rules show how mature payment networks use formal fraud, dispute, and return procedures. OffAir uses this only as a risk-communication analogy.
Risk-aware UX is the product boundary.
OffAir is designed so offline payments stay useful for communities without hiding that deferred settlement has risk.