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 · Coston2 live rehearsal
Liquidity, staking, governance, and verifiable settlement—kept in separate trust domains.
The Forge is a modular protocol for oracle-protected exchange, hpFLR liquid staking, public liquidity coordination, opt-in shielded transfers, and independently verifiable evidence. Each surface states what is on chain, what remains operational, and what the platform does not promise.
Public on-chainCoston2 applicationLive, chain 114
Shielded transfersAttested testnet deployment
Flare mainnetNot deployed
Protocol model
One application, explicit boundaries
The interface composes several systems without pretending they share the same assets, permissions, privacy properties, or failure modes.
Public unless explicitly shielded
Normal protocol activity is visible on chain. Only the dedicated shielded-transfer path obscures the link between one deposit and one withdrawal.
Data guards execution
FTSOv2 references constrain protected swaps. Missing, stale, malformed, or divergent mandatory data stops the affected execution.
Evidence has a defined claim
ProofRails can prove exact reconciled bytes were signed and anchored. It does not make arbitrary metadata true or convert testnet activity into certification.
Platform capabilities
Start with the summary. Expand for the complete model.
Every card links to its executable interface. Open “Technical detail” for transaction flow, enforcement boundaries, and current limitations.
01Public on-chain
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
- Principal and validator rewards remain separate liabilities
- Coston2 currently has liquid accounting but no mirrored validator stake
Technical detail
Execution path
The Vault receives native FLR and mints the immutable, fee-free hpFLR token. Operations may release bounded FLR only to the configured staking destination. Pending stake, confirmed stake, returned stake, liquid reserve, recognized loss, and reward liabilities are accounted as distinct states.
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. The deployed Coston2 instance is liquid and reconciled, but it does not currently claim an active mirrored validator delegation or validator-reward lifecycle.
02Oracle protected
Swap and typed routing
Request a route across verified venues, receive an amount-bound quote, and execute only a continuous token path whose configured FTSOv2 limits still hold on chain.
- Stable and volatile Forge markets
- Exact temporary allowances and no stranded hop input
- Official Coston2 explorer links for every transaction
Technical detail
Quote construction
The same-origin route engine searches only configured venue types, approved assets, bounded hop counts, and continuous token paths. A quote names every venue, pair, token transition, expected output, oracle boundary, block, and expiry.
On-chain enforcement
The aggregator accepts typed venues rather than arbitrary call targets. It uses exact temporary token allowances, applies a fresh oracle-derived minimum to each venue, checks realized output afterward, and rejects any hop that leaves part of its exact input behind. Forge pairs also enforce their configured oracle guard when called without the application.
Failure behavior
No route, stale data, missing policy, excessive deviation, expired quote, broken continuity, or insufficient executable liquidity stops the transaction path. The affected status explains the guard only when it triggers; a failed preflight submits no transaction.
03Opt-in shielded
Shielded transfers
Move C2FLR or WFLR through a dedicated anonymity pool and prove a later withdrawal without publicly revealing which pool deposit supplied it.
- Not embedded in AMM pools and not a private swap
- Token, amount, timing, transactions, and recipient remain public
- Encrypted compliance copy with threshold-governed official disclosure
Technical detail
Deposit
The browser generates a secret and nullifier locally, derives a MiMC note commitment, encrypts the exact note for user recovery and the configured compliance key, and creates a password-encrypted local backup. The contract receives the asset, binds the actual transferred token and amount into the final Merkle leaf, records the ciphertext, and inserts the leaf.
Withdrawal
The browser decrypts the local backup, reconstructs the confirmed Merkle tree from deposit events, verifies the reconstructed root against the contract, and produces a Groth16 proof locally using hash-pinned same-origin artifacts. The proof binds the root, nullifier hash, recipient, token, amount, relayer, and fee. The contract rejects reused nullifiers and unknown roots before transferring value.
What is and is not hidden
The proof hides deposit-to-withdrawal linkage, not asset type, amount, timing, transactions, recipient, browser/network metadata, or later activity. Matching amounts, short time gaps, or a small anonymity set can allow probabilistic correlation. After withdrawal, an ordinary swap or transfer is public.
Selective disclosure
Configured signers approve the hash of the exact encrypted plaintext bytes. The adapter decrypts in memory, rechecks commitment, deposit sender, token, amount, spent state, and approval hash, then sends only the public settlement projection—not the secret or nullifier—to ProofRails.
04Public on-chain
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.
05Governance only
BBX governance
Use fixed-supply BBX for time-weighted governance, proposal voting, gauge direction, and fee participation without a protocol-issued incentive stream.
- No active BBX mint, rebase, or gauge-emission path
- Historical checkpoints resist flash-acquired voting power
- Time locks and execution state constrain proposals
Technical detail
Voting power
Vote-escrow positions represent time-locked governance ownership. Proposal and quorum calculations use historical timestamp checkpoints; tokens acquired after voting begins do not retroactively add power. Liquid staking vote weight is likewise checkpointed.
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.
Scope
BBX is the governance asset. Supported gauges are fee-only at the protocol level, and retained legacy minter, rebase, and seasonal distribution bindings remain disabled. External pool incentives are a separate deployer responsibility.
06Deployer 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.
07Approved 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.
08Flare native
WFLR delegation yield
Delegate WFLR held by eligible liquidity pools to approved FTSO data providers and stream measured claimed rewards to associated LP vaults.
- 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.
Boundaries
Delegation rewards are not hpFLR validator rewards, swap reserves, or deployer-funded incentives. Provider performance, Flare reward availability, keeper liveness, and canonical proof availability can affect the stream.
09Verifiable evidence
ProofRails evidence
Reconcile a cited settlement, construct a deterministic signed evidence archive, anchor its complete hash, and verify content, signer identity, transaction provenance, and confirmation policy together.
- Separate API, worker, database, queue, and signing roles
- Exact settlement verification before receipt creation
- Anchoring proves bytes existed—not that every assertion is true
Technical detail
Evidence construction
The service verifies chain, success, confirmations, asset, sender, receiver, and exact amount, then creates a deterministic six-file archive. Canonical file names, lengths, hashes, signature, signer fingerprint, complete ZIP hash, and on-chain anchor transaction form one verification result.
Service separation
The request API does not receive signing or anchor private keys. Workers do not receive administrative or API-pepper secrets and reject accidental HTTP serving. PostgreSQL holds project-scoped durable state; authenticated Redis/RQ coordinates durable jobs and locks.
Deployment boundary
The EvidenceAnchor is live on Coston2 and the complete flow passed repeated rehearsals. The API/worker/database/queue/adapter plane currently runs separately from Cloudflare Pages; static hosting does not provide continuous evidence processing.
Swap
Find the best executable route across Forge and supported Flare liquidity venues.
Token Swap
Auto-route
Loading route engine…
Forge direct route
Balance: —
Balance: —
hpFLR Liquid Staking
Mint hpFLR with C2FLR, provide liquidity on Forge, or redeem through the on-chain FIFO queue.
Your C2FLR
—
Your hpFLR
—
Queued / unfunded
—
Ready to claim
—
Deposit C2FLR
1 C2FLR → 1 hpFLRThe vault mints hpFLR for your deposit. Eligible pooled liquidity is released to P-chain validator staking and is counted as confirmed stake only after the on-chain stake mirror observes it.
Redeem hpFLR
On-chain FIFOQueue allowance: —
If vault liquidity is available, the oldest queued positions are funded immediately. Otherwise your request keeps its FIFO position.
Your on-chain redemption positions
Connect your wallet to load positions from the configured on-chain queue.
Vault state
Coston2Liquid reserve
—
Recognized assets
—
Liabilities
—
Recognized rewards
—
Pending validator stake
—
Confirmed validator stake
—
Your staking rewards
Direct hpFLR holders need no registration. LP, gauge, and vault exposure is attributed to the underlying wallet by the epoch calculator.
Connect your wallet to load published on-chain reward epochs.
Liquidity
Provide liquidity to earn swap fees, delegation yield, and any explicitly configured reward funded by that pool's approved deployer.
Add Liquidity
Volatile / StablePool: not yet detected
Remove Liquidity
Balance: —
Your Positions
Connect wallet to view positions.
Lock BBX → veBBX
Lock BBX to earn veBBX voting power. Your votes determine which new trading pairs get created on Forge.
Create Lock
Balance: —
Voting power
—
Unlock date
—
Manage Locks
Connect wallet to view your veNFTs.
Your Voting Power
veBBX
—
Staked BBX ×mult
—
Stake multiplier
—
Total vote power
—
—
Stake BBX
1× → 4× over 3 weeksStaking BBX earns time-weighted governance vote power. The longer you stake without withdrawing, the higher your multiplier. Any withdrawal resets the clock.
Staked: — BBX · Wallet: — BBX
Pool Governance
Propose new trading pairs. veBBX + staked BBX holders vote — a passed proposal creates the pool on-chain and configures FTSO delegation atomically.
Total vote power
—
From veBBX
—
From staked BBX
—
Stake multiplier
—
Proposals
Vote For or Against each active proposal. Passed proposals can be executed by anyone.
Loading proposals…
Propose New Pool
Requires veBBX or staked BBX above the proposal threshold.
Auto-Voter (AVM)
Delegate your epoch voting to the protocol strategy. Your veNFT votes automatically each epoch on the highest-priority pool proposals.
AVM total VP
—
Status
—
Epoch Info
—
Voting delay
2 min
Voting period
3 days
Quorum
4% veBBX
Earn
Return comes from fees, Flare delegation, or separately funded external assets. Forge does not issue protocol incentive emissions.
Swap Fees
Automatic · all poolsEvery swap charges a fee that stays inside the pool. Your share grows automatically — nothing to claim or stake. You receive it when you remove liquidity.
Volatile pools
0.3%
Stable pools
0.05%
→ 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.
Protocol incentive emissions
Disabled
Funding source
Pool deployer
Availability, token behavior, reward rate, continuation, disclosures, and regulatory obligations remain the supplying deployer's responsibility.
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.
WFLR 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 streamed WFLR delegation rewards. 7-day anti-snipe window per harvest.
Total LP Deposited
—
across all vaults
WFLR / week
—
active reward streams
Your Total Earned
—
claimable WFLR
Active Vaults
3
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
Bootstrap new projects with protocol-owned liquidity.
Active LaunchPools
Loading launch pools…
Submit Project
Governance approval requiredOpt-in Shielded Transfers
Use a dedicated shielded-transfer contract to break the public link between one deposit and its later withdrawal.
This is optional and separate from Forge AMM pools. Only actions submitted from this Privacy tab to the dedicated shielded pool receive deposit-to-withdrawal unlinkability. Swap, hpFLR, liquidity, lock, governance, earn, vault, launch, and delegation activity is public on chain. Token, amount, timing, transactions, and withdrawal recipient remain public; a unique amount or small anonymity set may permit correlation. A shielded transfer is not a private swap. Each deposit also stores an encrypted compliance copy on chain. A holder of the compliance decryption key can decrypt that copy; committee authorization governs official disclosure and ProofRails evidence creation.
Shielded-transfer contract: loading…
Confirmed deposits
—
Native pool balance
—
WFLR pool balance
—
Proof system
Groth16 · MiMC
Shielded deposit
Public entry · hidden future linkMinimum: —
Back up this password securely. Forge does not store it and cannot recover or reset it. You need both the encrypted note backup and its password to restore the note and withdraw.
Shielded withdrawal
Public exit · hidden deposit linkThis password is processed locally and is never stored by Forge. There is no platform password-recovery path.
Proof generation uses the pinned same-origin circuit and proving key and may take several seconds. The note is marked spent before funds transfer.
Restore encrypted backup
No plaintext uploadKeep an offline copy of this encrypted file and a separate secure backup of its password. Forge stores neither for you.
FTSO Delegation
Pools holding WFLR delegate to data providers. Rewards auto-compound into LP.
Delegation Manager
WFLR LP pools delegate voting power to Forge's FTSO data provider node. Delegation rewards are claimed by the keeper bot and streamed directly to LP vault stakers — 100% to LPs, 0% protocol extraction.
Registered pairs
—
Total delegated WFLR
—
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.
FTSO Harvest
Keeper-onlyHarvesting is performed automatically by the Forge keeper bot each reward epoch (~3.5 days). It fetches FSP reward Merkle proofs and calls harvestAll(pairs, proofs, epochs). WFLR flows to LP vaults and streams over 7 days.
First configured vault
—
Second configured vault
—