Documentation and policies
This page collects the app documentation in one place: what the dashboard does, which protocols it touches, where contracts live, and which flows have verification evidence. Privacy and security policies cover the website, Yield Hub, staking and the Delegator App.
Action and transaction boundaries
A route can appear for comparison without being executable. Manage buttons only appear when the exact route contracts and its position read plus enter or exit transaction have passed the verification gate.
Verification model
Managed positions are reviewed before launch. The app checks contract addresses, ABI availability, wallet position reads, reward data, and whether enter, claim, and exit flows have enough evidence to be safely enabled in the dashboard.
Active Flare pool lifecycle evidence
These four active pools were tested on Flare mainnet on 14 July 2026 with small deposits from the local runner. Every entry, wallet position read, LP approval, and full LP removal succeeded. Newly discovered Spectra pools remain comparison-only until the same lifecycle is repeated.
Firelight stXRP — 27 Aug 2026
spectra-stxrp-22ebdbdata/test-plans/spectra-stxrp-aug-2026-exit.json
Firelight stXRP — 26 Nov 2026
spectra-stxrp-966d1fdata/test-plans/spectra-stxrp-nov-2026-exit.json
Sceptre sFLR — 30 Sep 2026
spectra-wflr-3f2b19data/test-plans/spectra-sflr-sep-2026-exit.json
Firelight stXRP — 30 Sep 2027
spectra-stxrp-912c6cdata/test-plans/spectra-stxrp-sep-2027-exit.json
Token addresses used across routes
Shared coin contracts are listed once here so they do not repeat on every protocol card.
Upshift vault contracts and runner evidence
Upshift rows are tracked as base yield opportunities, not rFLR reward rows. The dashboard can manage the FXRP deposit and redemption-request lifecycle; final delayed claims stay external until the epoch claim path is verified.
Flare XRP Yield Vault
8% base APY · upshift-flare-xrp-yield-vault-373d7dEpoch follow-up on 2026-05-27 found the vault processed the request and returned 0.249999 FXRP to the runner wallet. Direct final-claim execution remains external until a user-callable claim path is runner-verified.
Monarq XRP Yield Vault
4% base APY · upshift-monarq-xrp-yield-vault-2439d4Epoch follow-up on 2026-05-30 found the vault processed the request and returned 0.249999 FXRP to the runner wallet. Direct final-claim execution remains external until a user-callable claim path is runner-verified.
Protocols, contracts, and evidence
Shared token contracts are listed once above. Each protocol card keeps the route, pool, vault, router, and other protocol-specific addresses that matter for verification.
Sceptre
1 contracts listed · 1/2 route records verifiedFirelight
1 contracts listed · 0/1 route records verifiedRead-only coverage-staking listing. Restricted eligibility, including EU, UK and Switzerland. Review Firelight terms before using the protocol. Information only; deposits are not enabled here.
Capital backing stXRP can be slashed to cover claims. FXRP, smart-contract, upgrade and operator risks apply. Withdrawals require a request and a later claim, typically 30–60 days under current rules; incidents may affect timing. Redeeming shares is not an immediate FXRP withdrawal.
APR is shown as unavailable until a current, official machine-readable rate is verified. Neither points nor share-price changes are converted into APR. Share value is used only for valuation; TVL excludes pending withdrawals.
Read-only runner checks cover contract identity, share accounting, previews, limits and period configuration. Deposit, withdrawal-request and delayed-claim transactions remain unverified and disabled in Yield Hub.
BlazeSwap
3 contracts listed · 1/1 route records verifiedKinetic
6 contracts listed · 5/5 route records verifiedSparkDEX
4 contracts listed · 6/26 route records verifiedEnosys
4 contracts listed · 4/6 route records verifiedClearpool
1 contracts listed · 1/1 route records verifiedCyclo
7 contracts listed · 3/3 route records verifiedFlare Labs
0 contracts listed · 0/0 route records verifiedFlamix
11 contracts listed · 5/5 route records verifiedSpectra
10 contracts listed · 16/16 route records verifiedMystic
1 contracts listed · 3/3 route records verifiedUpshift
4 contracts listed · 2/2 route records verifiedPrivacy policy
Version 1.0 · Review draft ·
Who is responsible
Mark Beijer, operating under the name Flare Oracle, is responsible for the personal data described here (the data controller). Contact info@flareoracle.io for privacy questions or requests.
This policy covers flareoracle.io, including Yield Hub, staking and the network monitor, and the Delegator App at app.flareoracle.io. Independent wallets, blockchains and protocols have their own responsibilities and policies.
You can browse public information without connecting a wallet. Wallet features use public addresses and blockchain records; these can be personal data even when they do not show your name. Never send us a private key, recovery phrase or password.
Information we use and where it comes from
- Website requests: hosting and network services receive IP addresses, requested URLs, timestamps, browser/device information and technical error or security data when delivering the sites.
- Wallet features: addresses you connect or enter, selected networks, public keys used for staking, balances, positions, delegations, rewards and transaction details. Records come from your wallet, public Flare or Songbird networks and the relevant data providers.
- Transaction preparation: token addresses, amounts, slippage settings and, where needed, your wallet address are used to prepare the action you request. Your wallet handles signing; the web interfaces do not ask you to supply a private key or recovery phrase.
- Managed-wallet counter: after a supported Yield Hub action, your address and transaction hash are sent to our server to check the public transaction. The counter stores a salted hash of the address and publishes a total. This is pseudonymisation, not anonymisation; a hash remains potentially linkable to a wallet.
- Local settings: wallet connection state, cached results, pending actions, staking reminders and display preferences may be stored in your browser. Local storage is not the same as a shared server database.
- Messages: if you email us, we receive your email address and whatever information or attachments you choose to include. Please send only what is needed.
Disconnecting a wallet stops the connection, but does not erase browser storage, previous support messages or public blockchain history.
Purposes and legal grounds
We use technical and wallet data to deliver the pages and wallet tools you request, retrieve public positions, prepare transactions and troubleshoot failures. Our legitimate interests are operating a useful, reliable service and protecting it against abuse. Support correspondence is used to answer requests and resolve problems on the same basis.
The managed-wallet counter measures use of supported Yield Hub actions without publishing a list of wallets. Its proposed basis is our legitimate interest in measuring service use; the necessity, retention and balancing assessment must be approved before this draft is adopted. It is separate from wallet-connection analytics.
Optional processing that requires consent must stay off until you choose it, and consent must be withdrawable. A wallet connection, a transaction signature or continued browsing is not blanket consent to analytics. Browser notifications require your browser permission and can be disabled through the site settings and your browser.
Where a specific legal duty requires processing, such as handling a data-rights request, we rely on that obligation. You may object to processing based on legitimate interests. Without a wallet address, wallet-specific tools cannot operate; without contact details, we cannot reply to a message.
Cookies, browser storage and analytics
The sites use browser storage for connection continuity, requested features and preferences. A browser notification permission is not a cookie and does not create an email subscription. The current notification feature uses local browser notifications, not a Flare Oracle push subscription.
- Main website: local storage holds wallet caches, staking public keys and activity, pending deposits or withdrawals, notification settings and theme preferences. Routine wallet caches have a three-minute freshness window; older data can still be used as a fallback.
- Delegator App: wallet connection state uses SDK-managed cookies/storage. The theme cookie is session-based, the sidebar preference cookie lasts seven days, and persisted query results have a 24-hour reuse limit.
- Private review access: authorised reviewers can receive a signed, HTTP-only access cookie with a one-hour lifetime. It is not a general visitor account or advertising cookie.
Cache freshness and reuse limits are not deletion timers. Browser records can remain until replaced, removed by the app or cleared in browser settings. Clear site data separately for each domain; doing so can remove local reminders and pending-action tracking, but does not remove on-chain assets or revoke token approvals.
Optional Reown AppKit analytics is to be disabled in the Delegator App release accompanying this notice. Until that release is verified, the existing app configuration still enables it. Wallet connectivity can still involve technical processing by Reown/WalletConnect and your wallet provider; disabling optional analytics does not make those services anonymous.
Service providers and other recipients
- Hosting and storage: Vercel delivers the main website and processes request and operational data. A Redis-compatible service stores server-side data, including the pseudonymous wallet counter; the production provider and settings must be confirmed before adoption.
- Wallet connectivity: RainbowKit/wagmi and Reown/WalletConnect support connections to your chosen wallet. These services and the wallet provider may receive technical connection data and wallet addresses.
- Blockchain and protocol services: RPC services, including Flare public endpoints and QuickNode, and protocol APIs receive the queries needed for wallet features. Browser-direct requests expose your IP address to the recipient; wallet lookups can also expose the queried address. SparkDEX reward lookups use the wallet address. OpenOcean receives token/amount details and your address when building a swap through our server.
- Public networks: signed transactions and their contents are broadcast to the applicable network and can be viewed, copied and indexed by others.
- Support and administration: authorised developers and the email service handling our shared mailbox can access information needed for support or operations. Information may also be disclosed where a lawful request or legal obligation requires it.
Relevant provider notices include Vercel and Reown. External protocol, wallet and social links take you to independently operated services. This notice does not replace their policies.
International processing
Internet infrastructure, wallet services and blockchain networks may process information outside the European Economic Area. We cannot promise that all processing stays in the EU. For transfers under our control, an applicable lawful transfer mechanism, such as an adequacy decision or standard contractual clauses with any necessary additional safeguards, must be established.
The actual provider arrangements, regions and safeguards remain subject to verification before adoption of this draft. Ask info@flareoracle.io for information about the safeguards applicable to your data. Public blockchain publication is distinct from a controlled transfer to a contracted provider.
How long information is kept
- Browser records: see the storage section above. Some pending-action records have age filters, but those filters do not guarantee that the underlying browser entry is deleted.
- Wallet counter: the current implementation has no automatic expiry for salted wallet identifiers. They avoid repeat counting for the lifetime of the counter. A proportionate retention decision and deletion process are required before this draft is adopted; the current behaviour is not a promise of time-limited retention.
- Support, logs and incident records: retention must be limited to the time needed to answer a request, investigate a problem, maintain security or meet an identified legal obligation. Provider log settings, mailbox rules and any longer legal holds must be recorded before adoption; this draft does not claim an unverified fixed deletion period.
- Blockchain records: public transactions may remain indefinitely. Flare Oracle cannot edit or erase the blockchain or copies held by independent participants.
Your rights and choices
Where the GDPR applies, you can request access, correction, erasure, restriction or portability of your personal data, subject to the conditions for each right. You can object to legitimate-interest processing and withdraw consent for processing based on consent, without affecting earlier lawful processing.
Email info@flareoracle.io with your request and enough context to locate the relevant data. We may need proportionate verification that it concerns you, but will never ask for a private key or recovery phrase. Requests normally receive a response within one month. If a permitted extension is needed because of complexity or number of requests, we must explain it within that first month.
You can complain directly to a data protection authority, including in the country where you live or work or where the alleged infringement occurred; you do not have to contact us first. Authorities include the Dutch Autoriteit Persoonsgegevens and Finland's Office of the Data Protection Ombudsman.
Blockchain permanence does not remove your rights over off-chain data we control. We will explain any lawful limitation on a request. Yield rankings and route checks are informational; the interfaces do not make decisions about you with legal or similarly significant effects solely by automated processing.
Security, children and policy changes
These financial tools are not directed at children. Do not send us children's information; contact us if you believe it has been provided. No internet service or smart contract can be guaranteed secure. Our information security policy summary explains the scope of our responsibilities and how to report a concern.
Changes will be dated here. Material changes to purposes or processing require appropriate notice before they take effect and fresh consent where required; a policy update alone is not consent.
Information security policy
Public summary · Version 1.0 · Review draft ·
This is the public summary of the proposed internal policy for both Flare Oracle sites and the Delegator App. The full internal policy is maintained privately for the developers. Operational procedures, access records and recovery information are not published here.
Responsibility and requirements
Mark Beijer is the proposed policy owner and privacy/security contact through info@flareoracle.io. Both developers have production access. The internal policy sets requirements for individual accounts, least-privilege access, MFA, protected secrets, reviewed releases, data minimisation, incident handling and tested recovery. These are requirements to adopt and verify, not a claim that every control has already been independently checked.
Wallets and protocol boundaries
The interfaces prepare wallet actions; your chosen wallet signs them. Check the network, destination, asset, amount and approval before signing. Contract checks and small transaction tests reduce some integration risks but are not a smart-contract audit, a guarantee of returns or protection against protocol failure. Third-party contracts, blockchain consensus and your wallet remain outside our control.
Report a security concern
Email info@flareoracle.io with the subject “Security report”, the affected page, an explanation and minimal reproduction steps. Redact personal information and secrets. Ask for a suitable secure channel before sending sensitive evidence. Never send funds, passwords, recovery phrases or private keys.
Do not access another person's data, disrupt services or move anyone's funds. Stop testing when a problem is demonstrated and report it privately. This contact route does not authorise testing of third-party services, offer a bounty or promise legal safe harbour.
Incidents and review
The internal policy requires the team to assess reports, contain incidents, preserve necessary evidence and notify affected people and authorities where legally required. It does not promise 24/7 monitoring or a fixed response time. The policy must be reviewed at least annually and after significant changes or incidents. No ISO certification or independent security certification is claimed.