Principal is not yield
hpFLR principal, validator rewards, AMM reserves, swap fees, delegation rewards, and external pool incentives have separate accounting.
Flare-native financial infrastructure
Liquid staking, oracle-protected exchange, and community-directed liquidity on Flare.
Stake with hpFLR, swap tokens, provide liquidity and help shape the platform through governance. Explore each service below to see how it works and get started.
Public on-chainFlare betaDeployed, chain 14
hpFLRPrincipal and rewards accounted separately
Module availabilityShown for the selected network
Protocol model
How Forge works
Keep your staking token liquid, earn rewards and track your positions on chain.
On-chain by default
All actions in the current release are public transactions. Users can independently verify contract calls, balances, accounting, and outcomes on the official network explorer.
Data guards execution
FTSOv2 references constrain protected swaps. Missing, stale, malformed, or divergent mandatory data stops the affected execution.
Incentives belong to deployers
Approved pool deployers choose, fund, disclose, and maintain their own optional reward tokens and stream periods. Forge does not issue or guarantee them.
Platform capabilities
Explore the platform
Choose a service to get started, or expand a card to learn how it works.
01Liquid staking
hpFLR liquid staking
Deposit native FLR one-for-one for hpFLR, retain a transferable principal receipt, enter a FIFO redemption queue, and account for validator rewards separately from principal.
- 1 FLR deposited → 1 hpFLR minted
- Claim validator rewards separately
- Track the vault's reserves and validator stakes
Technical detail
Execution path
The Vault receives native FLR and mints the immutable, fee-free hpFLR token. Operations may release eligible reserve only to the configured staking destination. Pending stake, confirmed stake, returned stake, liquid reserve, recognized loss, and reward liabilities are accounted as distinct states.
Validator allocation and exits
The allocation panel reports the strategy enabled by the selected Vault. Delegation lots and self-bonds are accounted separately. The validator strategy targets 20 million FLR self-bonds per NodeID for 60 days, with other stakeable funds in 14-day delegations staggered weekly. Existing lots retain their original type. At maturity, returned principal funds FIFO exits before any new bond or delegation. A weekly maturity is a liquidity opportunity, not a promise that every redemption clears in seven days.
Redemption and rewards
Redemptions escrow hpFLR in a one-way FIFO queue. Claims become available only as the Vault funds queue positions; the corresponding hpFLR is burned on payment. Validator rewards are recognized from measured native balance changes and distributed through reproducible historical ownership rather than increasing the hpFLR exchange rate.
Trust and current status
P-chain custody, validator operation, and the stake mirror are explicit operational trust boundaries. Authorized root publishers submit off-chain reward allocations; claims verify those published roots on chain. Current liquid, pending, confirmed, and - when enabled - parked and bonded allocation values are read directly from the configured deployment.
02Oracle protected
Swap and typed routing
Compare received tokens, pool fees and network gas across supported markets. Review the price checks available for your trade.
- Stable and volatile Forge markets
- Exact temporary allowances and no stranded hop input
- Official selected-network explorer links for transactions
Technical detail
Quote construction
Flare routes are built from indexed pools across supported venues. Quotes compare executable output and estimated gas, and identify each pool, token transition, fee and minimum received. Price checks and token transfer deductions are shown where applicable.
On-chain enforcement
The executors accept typed venues rather than arbitrary call targets and enforce the signed recipient, amount limits and deadline. Forge protected routes and configured Forge pairs enforce their oracle guards on chain. External routes enforce signed output minimums; supported FTSO reference checks run before submission and do not cover every asset or pool.
Failure behavior
Missing required data, excessive deviation, expired quotes, broken paths or insufficient executable liquidity stop the affected transaction path. The affected status explains the guard only when it triggers; a failed preflight submits no transaction.
03Liquidity
Liquidity and LP vaults
Supply assets to stable or volatile pools, receive LP ownership, and optionally deposit that ownership into vaults that account for historical fees and eligible reward streams.
- Stable and volatile invariant choices
- Slippage-bound liquidity actions
- ERC-4626 vault shares with fee checkpointing
Technical detail
Pool ownership
Liquidity minting and burning are proportional to reserves after permanently locked initialization liquidity. Stable pools normalize decimals and enforce a minimum usable invariant. Removal honors user minimums and permits cannot be invalidated merely by a front-run that consumes the same valid approval.
Fees and vaults
Swap fees are separated from reserves. LP vaults harvest accrued ownership before minting new shares, preserving historical claims for existing holders. Rewards arriving with zero supply are queued, and unelapsed streams are re-queued when the last staker exits.
Risk
LPs bear price movement, price impact, impermanent loss, asset-contract behavior, and market-liquidity risk. FTSOv2 guards constrain configured execution deviation; they are not insurance, a price guarantee, or a promise that liquidity can always be removed at the deposited economic value.
04Governance only
MANA governance
Stake MANA to grow your voting power, vote on proposals and direct pool weights.
- No active MANA mint, rebase, or gauge-emission path
- Transferable staking receipts preserve voting age
- Redeem-anytime staking; proposal snapshot protection
Technical detail
Voting power
Each MANA deposit creates a transferable NFT receipt. Its voting power grows linearly from 1× to 4× over 365 days and stays at 4× thereafter. Transferring a receipt preserves its age. Redeeming burns the receipt and returns its MANA, with no fixed lock period. Each additional deposit starts a new receipt at 1×. Proposals use historical voting snapshots so a transferred receipt cannot count twice in the same vote.
Execution
A proposal must reach the required state and execute with the correct description hash. Governance can exercise only functions exposed by governed contracts and remains subject to invariant checks, hard parameter caps, ownership transitions, and applicable timelocks.
05Deployer supplied
Gauges and external incentives
Stake eligible LP positions for pool fees and, when offered, a pool-specific external reward token supplied and maintained by that pool’s approved deployer.
- Any approved external token except the governance asset
- Any positive deployer-selected stream period with a nonzero rate
- The platform does not fund, endorse, insure, or maintain the token
Technical detail
Authorization
Gauge creation is restricted. Each gauge may be assigned one approved incentive deployer, and only that address can create and maintain the gauge’s external rewarder. LaunchPad-approved projects receive the assignment for their own pool.
Funding
The deployer approves the exact reward amount and funds the rewarder atomically with its chosen positive duration. The resulting rate must be nonzero. Revocation blocks new streams but cannot erase already funded liabilities.
Responsibility
Token behavior, value, disclosures, funding continuity, renewal, and legal obligations belong to the deployer. Reward-token failure is isolated from LP principal so an optional incentive cannot prevent principal withdrawal.
06Approved projects
LaunchPad
Coordinate bounded project funding, price formation, pool creation, liquidity ownership, and the handoff of a project-managed incentive program.
- Governed project approval before execution
- Bounded duration, fill threshold, and incentive count
- Pro-rata LP allocation with explicit rounding ownership
Technical detail
Lifecycle
A project defines its paired asset, contribution window, funding target, minimum fill, curve type, and approved incentive assets. LaunchManager has narrowly scoped pair-creation permission and processes active launches in bounded rotating batches.
Settlement
Successful funding creates liquidity under canonical pair identity and assigns resulting ownership pro rata. Rounding dust is assigned rather than becoming ownerless. Consumed accounting is cleared and unused token allowances are revoked.
Failure isolation
An individual launch that cannot transition is deferred without blocking unrelated projects. Cancellation and completion loops are bounded, and a cap on distinct incentive tokens prevents an attacker from making finalization unexecutable.
07Flare native
Pool Management
Manage your pool's incentives, inspect its WFLR delegation and track harvested rewards.
- At most two configured providers per pair
- Canonical Flare claim-executor path
- Measured WFLR forwarded to LP vault accounting
Technical detail
Delegation
The registry restricts eligible provider identities and the delegation manager applies bounded weights. Removing a provider also clears its lifecycle state, preventing obsolete configuration from remaining silently active.
Harvest
The pair authorizes the manager through Flare’s claim-executor mechanism. A keeper supplies canonical reward proofs; the manager measures the WFLR actually received and forwards that amount to the configured distributor and LP vault.
Reward availability
Pool delegation yield depends on provider performance, rewards made available by Flare and successful reward harvesting.
08Your network wallet
Wallet & Staking
Wrap and send native tokens, delegate to FTSO providers, claim network rewards, participate in foundation votes, and manage your personal validator stakes.
Manage your wallet →How it works
Your wallet signs
The official Flare transaction SDK resolves system contracts from Flare's registry. Transaction signatures remain in your wallet.
Three distinct actions
FTSO delegation assigns wrapped-token vote power without moving the tokens. Foundation voting uses the proposal's historical governance snapshot. Validator staking moves native tokens onto the P-chain and locks them for the selected term; it is not hpFLR minting.
Return and recovery
Once native stake is released, transfer the available balance from P to C. Exported funds awaiting import are displayed separately, with recovery actions to complete the destination import without exporting again.
Swap
Compare swap routes, pool fees and estimated gas on the selected network.
Token Swap
Auto-route
Loading route engine…
Forge direct route
Balance: -
Balance: -
Choose a provider to view its staking token, rewards and redemption queue.
hpFLR Liquid Staking
Mint hpFLR with C2FLR, provide liquidity on Forge, or redeem through the on-chain FIFO queue.
Your C2FLR
-
Your hpFLR
-
Still owed / waiting for liquidity
-
Redemption principal ready to claim
-
hpFLR holder rewards
Checking your reward claim status…
View rewards and claim optionsDeposit C2FLR
1 C2FLR → 1 hpFLRReceive one hpFLR for each native token deposited. Track pooled deposits and validator stakes below.
Redeem hpFLR
On-chain FIFOQueue allowance: -
Redeem 1 hpFLR for 1 C2FLR. Earlier requests are funded first, so your redemption may be paid in parts. Any unpaid amount remains owed in the queue until liquidity is available.
No redemption fee. Wallet network gas is paid separately for approval, joining the queue and manual claims. Queuing moves your hpFLR into escrow; it does not pay you immediately and cannot be cancelled.
Your on-chain redemption positions
Connect your wallet to view your redemption requests.
Claiming the available amount does not cancel the rest. Waiting amounts retain their FIFO priority and become claimable as liquidity returns. Staking maturity is not a guaranteed payout date.
Automatic principal payouts
Opt in to have funded redemptions delivered to this wallet. Actual network gas is deducted from each successful payout, within your limits. No protocol fee. Failed attempts cost the service, not your principal. This consent is separate from reward delivery. Setup requires wallet transactions.
Refresh settings to view your funded positions.
Manual claims remain available for the full allocated amount, with wallet gas paid separately. Partial payouts leave unfunded principal in its original FIFO position.
Vault state
Coston2Liquid reserve
-
Vault native balance
-
Liabilities
-
Recognized rewards
-
Pending validator stake
-
Current mirrored stake
-
Validator allocation
-Next staking period end
-
Principal unlock timing. Reward availability is shown separately below.
Active allocation excludes matured lots and is displayed only when the unexpired confirmed lot inventory matches the canonical stake mirror.
Reserved for FIFO exits
-
Eligible for a new lot
-
Active parked stake
-
Parked / awaiting mirror
-
Active bonded stake
-
Bonded / awaiting mirror
-
Parking term
-
Bond term
-
Parking freezes
-
Next bond roll
-
How exits interact with locked stake
A P-chain delegation cannot be withdrawn before its recorded end. A redemption can be requested at any time and keeps its immutable FIFO position. Liquid reserve funds the oldest exits immediately. As each parked or bonded lot matures, automation returns its exact principal to the Vault and funds queued exits before considering another delegation. hpFLR is burned only when funded native FLR is paid out.
Vault accounting reconciliation
These accounting entries can include completed stake that has not been reconciled. They are excluded from the active allocation above.
Assets recorded by Vault: -
Recorded parked stake: -
Recorded bonded stake: -
Matured lots awaiting reconciliation: -
Your staking rewards
Direct hpFLR holders need no registration. Supported, registered LP, gauge and vault positions can attribute rewards to their underlying holders through the epoch calculator. Third-party reward collection requires approval and holder authorization.
Validator reward status
Checking rewards…
Your reward claim availability
Checking schedule…
Rewards ready to claim: 0 FLR
MIRROR and validator rewards add to one balance as epochs are processed. Claim the full balance in one wallet transaction.
Connect your wallet to load published on-chain reward epochs.
Optional: automatic delivery for legacy validator rewards
To collect all rewards available now, use Claim all FLR above. Automatic delivery is a separate opt-in for legacy validator epochs or your separate Flare network rewards. It does not currently collect MIRROR or new stake-lot rewards.
If you turn it on, a service can submit claims for you. It advances transaction gas and deducts the actual allowed gas cost from a successful reward; there is no service fee. Failed attempts cost you nothing. You choose the maximum gas deduction, minimum amount you receive, and expiry. Setup requires wallet approvals. You can turn it off later.
Check my setup to see whether this optional service is authorized.
Check my setup first, then choose the limits you accept. These are your maximums, not fixed charges.
Yield wrapper positions
Invest hpFLR in a position that earns independently of existing shareholders. Rewards compound into your position. After settlement it converts to common wrapper shares for compatible strategies. You can cancel your position and keep rights to delayed rewards.
Wrap common shares into transferable normalized yield shares, or unwrap them back. Wrapping does not convert an unsettled position.
Refresh to read your positions from the configured wrapper.
Third-party yield integrations
Apply for reward collection by a protocol or strategy that holds hpFLR. Each configuration requires admin approval and holder authorization. Approval authority can later move to governance. Manual holder claims remain available.
Vaults, lending markets and yield strategies apply through this shared review process. Each integration must show how it preserves contributors' earned rewards through deposits, withdrawals and transfers. hpFLR principal remains 1:1, with rewards accounted separately. Share-price, liquidation and yield-maturity behavior require verification for the proposed integration.
Your submitted use case, addresses and review notes are public and permanent on-chain. Do not include secrets or private contact information.
Delivery configuration and reward-only gas limits
Choose who receives the rewards and the maximum gas deduction. You receive rewards minus the gas deduction, in the selected asset. The admin must approve the application, and the holder must authorize it. Failed delivery leaves rewards unclaimed; principal is never charged.
Holder authorization
Register the recipient and claimant from the holder contract. The application details provide exact calls for its governance or contract wallet. An ERC-1271 holder can also authorize by signature; the holder contract verifies who may sign.
Reviewer actions
Connect a wallet and load an application to check this deployment. Gas is deducted from rewards only when you select and authorize that option; otherwise the service pays it.
Application and exact holder calls
Liquidity
Provide liquidity to earn swap fees, delegation yield, and any explicitly configured reward funded by that pool's approved deployer.
Add Liquidity
Volatile / StableAdvanced: token addresses and new-pool proposals
Pool: not yet detected
Enter either token amount. The other is calculated automatically from the pool's reserve ratio. Minimum amounts allow 1% movement.
Remove Liquidity
Advanced: LP contract details
Balance: -
Your Positions
Connect wallet to view positions.
Stake MANA
Your stake is a transferable NFT receipt. Its voting power grows from 1× to 4× over 365 days. Redeem whenever you choose - there is no fixed lock term.
Stake for governance
1× → 4× in one yearEach deposit creates a transferable NFT receipt for your MANA. Every new receipt starts at 1× voting power.
Connect your wallet to view your MANA.
How your receipt works
Voting power belongs to the position, not its original wallet. Transferring the NFT transfers its MANA claim, age, and voting power. Redeeming returns that position’s MANA and burns its NFT; its voting power ends. Other positions keep their age.
Governance proposals use historical voting snapshots, so moving a receipt between wallets cannot count its power twice on the same proposal. Fees already earned remain claimable by the wallet that earned them. MANA is a governance token, not an incentive payout.
Your staking receipts
-
Connect your wallet to view receipts.
Platform Governance
Approve trading pools and infrastructure-provider LSTs. MANA voting receipts carry the voting power; approved provider proposals deploy their own branded staking and rewards contracts.
Total vote power
-
From veMANA
-
From staked MANA
-
Stake multiplier
-
Proposals
Vote For or Against each active proposal. Passed proposals can be executed by anyone.
Loading proposals…
Propose New Pool
Requires veMANA or staked MANA above the proposal threshold.
Launch a verified provider LST
Auto-Voter (AVM)
Choose an eligible receipt to automate existing-pool weight votes. The Auto-Voter does not vote on new-pool proposals.
AVM total VP
-
Status
-
Epoch Info
-
Voting delay
-
Voting period
-
Quorum
-
Earn
Explore swap fees, WFLR delegation yield and pool-funded rewards.
Swap Fees
Forge pools · LP-ownedForge pool swap fees belong entirely to LP holders and are accounted separately from pool reserves. Claim them through your LP position, gauge or vault. Routing through external platforms adds no Forge fee; those venues apply their own pool fees.
Fee rate
Set per pool
LP share
100%
→ Add liquidity in the Liquidity tab.
Deployer-Funded Pool Incentives
Optional · pool-specificAn approved pool deployer may supply its own reward token to its own approved pool. Forge does not issue, fund, custody, endorse, guarantee, or maintain that token or program.
Funding source
Pool deployer
Availability, token behavior, reward rate, continuation, disclosures, and regulatory obligations remain the supplying deployer's responsibility.
Offer rewards for your pool
Fund an incentive program with your chosen reward token and duration.
Manage pool incentivesWFLR Delegation Yield
WFLR-paired pools onlyFlare's network pays WFLR to anyone who delegates to an FTSO data provider. Forge pools that hold WFLR delegate automatically. A keeper bot harvests those rewards and streams them to vault depositors - 100% to LPs, 0% to the protocol.
Eligible pools
Registered WFLR pairs
fXRP / WFLR
USDT0 / WFLR
Reward token
WFLR
Protocol cut
0%
LP Vaults
Deposit LP tokens to earn WFLR delegation rewards, distributed over seven days after each harvest.
Total LP Deposited
-
across all vaults
WFLR / week
-
active reward streams
Your Total Earned
-
claimable WFLR
Configured Vaults
-
ERC4626 · 7-day stream
Connect wallet or loading…
Rewards stream per-second over 7 days after each keeper harvest. fLP tokens are transferable - buyers inherit the live WFLR yield stream.
LaunchPad
Launch an infrastructure-backed LST or fund a new liquidity project.
Launch your provider LST
Governance approvalDownload the provider registration & operating guide
hpFLR is the initial infrastructure LST. Propose a provider's own branded version here. Its native principal mints and redeems 1:1 through an independent FIFO queue. The provider manages its own finances, staking and rewards distribution; the platform does not fund or guarantee its rewards. A new token needs actual liquidity before swaps are executable.
01 / Verify infrastructure
Connect your entity, delegation, submit, submit-signatures or signing-policy wallet. Your registered validators are read from Flare's EntityManager.
Active LaunchPools
Loading launch pools…
Submit Project
Governance approval requiredOpt-in Shielded Transfers
Temporarily separate a public C2FLR or WFLR origin from a later withdrawal without exposing the consumed note or hidden remainder.
Coverage: native C2FLR and WFLR transfers made through this tab only.
The shielded pool hides which current note authorizes a top-up or withdrawal and hides the balance carried into its successor note. It does not hide public transaction amounts, depositing wallets, assets, transaction times, withdrawal submitters, or recipients. Matching values, close timing, or a small anonymity set can still permit correlation.
Shielded
The link from a current C2FLR or WFLR commitment to a valid transition, including the note's pre-transition balance and any balance carried forward.
Always public
Swaps, hpFLR minting and redemption, validator staking, liquidity, LP vaults and rewards, delegation, launches, governance, and ordinary wallet transfers.
Not provided
Private swaps, private staking, hidden public transaction amounts or recipients, private activity after withdrawal, or protection from browser and network metadata.
Each initial or successor note stores a user ciphertext and a separate compliance ciphertext on chain. A holder of the compliance decryption key can decrypt its copy; committee authorization governs official disclosure and ProofRails evidence creation.
Shielded-transfer contract: loading…
Commitments recorded · lifetime
-
C2FLR currently shielded
-
WFLR currently shielded
-
Assets enabled now
-
Lifetime commitments include initial and successor notes, including notes already consumed. Current shielded balances show only assets held by the contract now.
Before you deposit
Understand exactly what the shielded pool does
A private account is a portable viewing key plus rolling per-asset bearer notes - not a server record, password-keyed contract mapping, or private version of the rest of Forge.
Create the private account
Your browser generates a high-entropy viewing key plus a fresh secret and nullifier. The plaintext never goes to a Forge server or contract.
Make a public deposit
Your wallet sends C2FLR or WFLR to the shielded contract. The contract binds the received asset and exact amount into one Merkle leaf.
Protect the recovery kit
Before transaction submission, the browser downloads a password-encrypted portable kit. The kit and password let any compatible client discover successor notes from chain data; losing either can make the balance unspendable.
Transition the balance
Any funded wallet holding the kit and password can prove a top-up or withdrawal locally. The contract consumes the old nullifier and, for a partial spend, records a fresh encrypted remainder note.
Cryptographically hidden
The relationship between entry and exit
- Which current commitment supplied a top-up or withdrawal
- The note balance before transition and any carried remainder
- The note secret and nullifier preimage
- The private Merkle path used by the proof
The proof establishes valid membership and one-time spend authority without publishing those values.
Public on chain
Everything surrounding that relationship
- Initial depositor, asset, amount, transaction, block, and time
- Every public top-up or withdrawal amount, submitter, recipient, transaction, block, and time
- Merkle root, proof, nullifier hash, relayer, and fee when used
A unique amount, short delay, small anonymity set, or reused wallet can still expose a likely correlation.
Depositor
Funds the public entry transaction and creates the note. The deposit address receives no permanent withdrawal privilege.
Account controller
Controls the portable kit and password. This is bearer authority: whoever reconstructs the active note can attempt its first valid transition.
Submitter
Any connected funded wallet that sends the withdrawal transaction and pays gas. Its address is public but is not bound as the depositor.
Recipient
The public address bound into the proof and paid by the contract. It may differ from both depositor and submitter.
Practical privacy checklist
- Use a different funded submitter wallet when reusing the deposit wallet would defeat your objective.
- Choose the recipient deliberately; leaving it blank pays the publicly visible submitter.
- Assume exact amount and timing can correlate entry and exit, especially while the pool is small.
- Do not treat a later swap, transfer, hpFLR action, or staking action as shielded.
- Keep the portable recovery kit and password separate, offline, and unavailable to anyone who should not control the account.
- Use your own network-privacy controls if needed; Forge does not hide IP, RPC, browser, or wallet-provider metadata.
Labels, passwords, references, and collisions
Account label: a local organizer only; it is not sent to the contract and does not define an account. Labels must be unique, and Forge refuses to overwrite an existing recovery kit.
Password: protects the portable file; it is not a contract credential and never becomes an on-chain ledger key. Reuse does not merge accounts because every kit has an independent viewing key, fresh salt, and nonce, but one compromised password could expose every kit using it.
Payment reference: optional encrypted metadata. Reuse has no effect on commitments, ownership, or accounting.
Secret and nullifier: freshly generated for every initial or successor note and unavailable as form inputs. The contract rejects duplicate commitments and permits each domain-bound nullifier hash to transition only once.
Accounting: each recovery kit discovers its own on-chain notes and reconstructs one aggregate balance per enabled asset. Successful transitions consume an old note and create a fresh one for any remainder; the contract never maps balances to a wallet, label, password, or reference.
Counterfeit contracts, hostile pages, and session safety
Contract binding: every commitment, nullifier, and proof includes a privacy domain derived from the exact chain ID and shielded-pool address. A proof made for a counterfeit deployment cannot authorize the configured pool.
Pre-unlock attestation: password fields remain disabled until the authentic client verifies the wallet/RPC chain, pool address and runtime code hash, verifier, hasher, registry, compliance oracle, mutual wiring, signer policy, and domain. It re-attests before deriving the password key and clears each field as soon as the value is read.
Hosted-code limit: no ordinary webpage can keep a typed password secret from malicious JavaScript already controlling that page or a hostile browser extension. Deployment binding prevents cross-contract proof use; it cannot stop compromised code from copying plaintext. Use the published standalone recovery client from a verified release on a clean device for higher-assurance recovery.
Compliance copy and ProofRails
Each initial and successor note stores two ciphertexts: one decryptable through the user's recovery kit and one encrypted to the configured compliance key. The ciphertexts are public; their plaintext balances and note secrets are not.
The official disclosure workflow requires configured committee authorization, decrypts in the separate adapter, and rechecks the commitment, deposit transaction, asset, amount, and spent state before producing a public settlement projection.
ProofRails can sign, package, anchor, and later verify that evidence. It does not receive the secret or nullifier, does not create withdrawal authority, and does not turn public transaction fields into private data. A stolen compliance decryption key can bypass policy even though it cannot spend the note.
Shielded deposit
Public entry · hidden future linkTemporary transfer layer: do not use this contract for long-term storage. Deposit only the amount you intend to transition for personal transaction privacy.
Minimum: -
Local organizer only; it is never sent on chain. A new label creates a portable recovery kit. Reusing an existing label and its password tops up that account's active balance for the selected asset.
Back up both this password and the downloaded recovery kit. Forge stores neither and cannot reset either. This field unlocks only after the authentic client attests the configured chain, pool, bytecode, dependencies, and privacy domain. Verify the browser address before entering it: a counterfeit page or hostile extension can copy anything typed into that page.
Encrypted note metadata only. It may repeat and does not affect the commitment, ownership, or pool accounting.
Submit shielded withdrawal
Public exit · hidden deposit link
Depositor, submitter, and recipient may be three different wallets.
Any connected wallet with the encrypted backup and its password can generate and submit the proof. The submitter only pays gas and is publicly visible as the transaction sender; the contract does not require it to be the deposit wallet or the recipient. Password alone is not enough - the encrypted backup contains the bearer note secret and nullifier.
Connect any funded wallet to act as the public transaction submitter.
This field unlocks only after deployment attestation. The authentic client then uses the password locally and intentionally neither stores nor transmits it. Verify the browser address before entering it; a counterfeit page or hostile extension can copy typed data. The client reconstructs balances from confirmed chain records, and Forge maintains no account database.
Locked. Enter the account label and password to scan confirmed on-chain records.
May be any amount up to the reconstructed account balance. The ZK proof prevents overdrafts and carries hidden remainder into fresh encrypted on-chain state. If the amount spans independently active notes, the wallet must confirm one proof-bound transaction per consumed note.
This proof-bound address receives the withdrawn asset and is public on chain.
Proof generation uses pinned same-origin artifacts and may take several seconds. The old note is consumed atomically; a partial withdrawal creates a fresh hidden-balance note before the transaction completes.
Restore encrypted backup
No plaintext uploadThis portable encrypted file is sufficient for any compatible recovery client to scan the pool and reconstruct current notes when combined with its password. Keep offline copies; Forge stores neither item.
Pool Management
Pool-owned FTSO delegation, harvest accounting and deployer-funded incentives in one place.
Select a pool
Pool FTSO Delegation
View the selected pool's WFLR delegation and provider split.
Registered pairs
-
WFLR held by registered pools
-
Register Existing WFLR Pair
Owner onlyGovernance-created WFLR pairs are registered automatically. This recovery control registers an existing pair with the protocol's primary provider.
Advanced: another existing WFLR pair
Pool Reward Harvests
Read-only summaryTrack WFLR harvested for LP vault depositors. Harvested rewards are streamed through the pool's LP vault.
First configured vault
-
Second configured vault
-
Manage Your Approved Pool Incentive
Deployer-owned
Deployer responsibility: The reward token and every funded amount come from the approved pool deployer, not Forge. Display in this interface is not a platform review, endorsement, promise of value, or guarantee that rewards will continue. LP principal remains withdrawable if the external reward token fails, but that incentive may become unavailable.
Enter an approved gauge to verify the assigned deployer and current program on-chain.
Your wallet
Tokens, delegation & staking
Manage tokens, delegate to FTSO providers, stake with validators and vote on Flare proposals.
Your tokens
Connect your wallet to load balances.
Personal FTSO delegation
Delegate your wrapped-token vote power without transferring your tokens. Updating the split replaces your existing personal FTSO delegations.
Network rewards
Claim your FTSO delegation and validator staking rewards.
Flare network voting
Delegate network governance votes
Choose an address to vote on your behalf. Voting eligibility is determined at each proposal's snapshot.
Validator staking · C-chain ↔ P-chain
Transfer native tokens to the P-chain and stake with a validator. Funds stay locked until your selected end time, then can be transferred back to your C-chain wallet. Each transfer requires an export and an import.
The wallet handles C-chain RPC. P-chain staking needs a separate node connection made directly by your browser.
Your wallet may request a message signature to derive your public P-chain address. No private key is requested or stored.