IFR Benefits Network
This page describes what the current shop app actually keeps in your browser, what the backend stores, and what is public by design. It is an honest technical status, not a finalized legal policy.
Your browser
Everything below lives only in this browser. You can inspect and clear the app's own keys and caches here. Clearing them does not affect backend records or on-chain data, does not touch wallet-provider storage or any other site's data, and does not disconnect your wallet.
The app stores a small set of localStorage keys whose names start with ifr.shop. : your preferred role, the last seller business ID you used, recent checkout session references and your customer receipts. These stay in this browser and are never sent as analytics.
After a successful checkout proof, this browser keeps a receipt: the exact text you signed (which contains your full wallet address, the shop, the checkout and its terms) and your signature, so you can re-verify it on this device. The shop server keeps no customer history. Clearing browser data or changing device loses these receipts for good.
When you create a customer checkout pass, its control token is kept only in this tab's sessionStorage so the pass survives a page refresh. Closing the tab discards it.
The service worker keeps a CacheStorage cache named ifr-benefits-* with the static app shell so pages load faster. It holds application files, not your activity. If you clear it, the app can create it again when it next loads assets.
-
localStorage keys
-
sessionStorage keys
-
app shell caches
Reading this browser's IFR Benefits data...
Backend
What the Benefits backend keeps, and what it deliberately does not keep:
Your wallet address is sent with the checkout proof, checked in that single request (signature, on-chain eligibility, whether it belongs to the seller) and then dropped. The backend stores no customer wallet address, no hash or fingerprint of it, no copy of your signature or signed text, no lock or balance amounts, no block numbers and no payment transaction hashes, and it keeps no customer history.
For each checkout the backend keeps a merchant session record: a fresh random checkout ID, the shop, the offer terms, status, timestamps, which lock source qualified, and whether the proof came from a seller-controlled wallet. It also keeps the seller wallet that opened the checkout and seller-side audit events. These records let one checkout be redeemed exactly once; they are not anonymous, and timing or offer details may still be linkable with other information.
Customer checkout passes are created without any wallet. Their control tokens are stored only as hashes.
Because no customer identity is stored, IFR does not enforce per-customer redemption limits. A shop that wants such limits must enforce them in its own systems.
Public by design
Some data in this system is intentionally public:
Seller profiles and product catalogs published on the Benefits Network are public by design and can be indexed by search engines.
The app reads public on-chain data such as ETH, IFR and IFRLock status. Any approve or lock transaction you sign is a public Ethereum transaction, visible to anyone on the network forever.
Third parties
Using the app can involve these external services, each under its own policy:
Your browser-injected Ethereum wallet provider and the public RPC endpoints used for chain reads see your IP address and the requests made through them, under their own policies. To check eligibility, the backend asks its Ethereum RPC provider for your on-chain lock and balance, so that provider sees your wallet address in that request.
Hosting and proxy infrastructure may log IP addresses and request paths. Rate limiting uses short-lived counters keyed by IP address or pass ID, never by wallet address. Wallet addresses and signatures travel only in request bodies, never in URLs.
Coinbase Wallet is offered as a fallback connector. The full WalletConnect modal is only active when a WalletConnect Project ID is configured; when it is, connecting through it involves WalletConnect infrastructure.
The AI Copilot only loads when you open it, and it is embedded with referrer policy no-referrer. Uniswap is only contacted when you explicitly click a swap link.
Seller history
Seller session history shows the status of each checkout, whether a customer proof was verified, the qualifying lock source and whether the proof came from a seller-controlled wallet. It contains no customer wallet address, because the backend does not keep one. This is not anonymity: a seller who sees you at the counter, the time of a checkout or public on-chain data can still connect information, and anything you sign on-chain is public.
Open items
The backend has a manual operator tool for counting and removing expired, unlinked authorization artifacts after an approved cutoff. It does not automatically delete checkout sessions, session audit records, reward records or passes linked to sessions. The customer-privacy upgrade was applied on 11 October 2026: current records no longer contain customer wallet addresses or customer history. Backups created before the upgrade still contain such data until they are deleted after a short acceptance window. The long-term server-side retention, deletion and support policy is not finalized. This page therefore makes no promise that backend records can be deleted on request, and it does not claim compliance with GDPR or any other specific legal framework. There is no dedicated privacy support channel at this time. When a final policy exists, this page will be updated to match it.
What you can always do today: clear this browser's local app data with the controls above, disconnect your wallet in your wallet app, and simply stop using the service. On-chain transactions you have already signed remain public on Ethereum and cannot be altered or removed by anyone.
