Forged Whitepaper

Forged is a financial ecosystem for fUSD issuance, collateralized credit, structured liquidity, synthetic exposure, market intelligence, and onchain identity. zkLTC provides the native collateral base. fUSD, the short-form ticker for ForgedUSD, acts as the primary accounting and settlement asset across the platform.

The system is built around a simple economic spine: collateral can be converted into credit, credit can become liquidity or margin, liquidity can support trading and liquidations, trading activity can be indexed into market intelligence, and participation can become persistent reputation. The result is not a collection of isolated tools, but a connected financial environment where vaults, liquidity pools, perps, market data, identity, and competition reinforce one another.

This paper is intended to make the system legible. It explains how the major components work, what economic relationships they create, which parameters shape behavior, and how value and information move through the platform.

Forged is designed to make LiteForge function as a complete financial environment rather than a sequence of disconnected applications. The platform combines issuance, leverage, liquidity, trading, analytics, discovery, identity, and competition around a shared stable asset.

The central design choice is product-level composability. fUSD issued through collateralized vaults can be deployed into the Stability Pool, used as perps margin, supplied to the Perps Pool, routed through payments, or used as an accounting unit for analytics and competition. DEX intelligence expands the surface from internal protocol state to broader market awareness. Profiles, missions, badges, squads, and leaderboards turn financial behavior into persistent participation history.

Forged therefore operates as both protocol infrastructure and an application layer. The protocol defines the economic rules. The data layer makes those rules observable. The product layer turns them into accessible financial actions.

Forged is organized into five major layers.

2.1 Protocol Layer

The protocol layer contains the contracts that hold collateral, mint and burn fUSD, enforce collateralization rules, process liquidations, manage synthetic positions, account for pool shares, operate payments, and record progression-related state.

Core protocol modules include:

• fUSD / ForgedUSD token.
• Vault Manager.
• Stability Pool.
• fUSD swap router.
• Perps Manager.
• Perps Pool.
• Loop Manager and position contracts.
• Faucet contracts.
• Payment Registry.
• Identity, points, mission, season, and squad modules.
• Activity emission infrastructure.
• Bridge module.

The protocol layer is where enforceable state lives. A vault either has collateral and debt or it does not. A perps position either exists or it does not. A pool share represents a proportional claim under the rules of that pool. Product surfaces can present state in different ways, but protocol accounting remains the underlying source of truth.

2.2 Price and Oracle Layer

Price data supports collateral valuation, mint capacity, liquidation thresholds, swap quotes, and perps settlement. Vaults rely on oracle-priced zkLTC valuation. Perps rely on signed mark prices for settlement-sensitive actions, with reference pricing used to constrain settlement behavior.

Forged separates visual market data from enforceable settlement data. Charts and streams provide market context. Signed or oracle-backed values provide inputs to contract logic. This distinction matters because display data can move quickly and be aggregated for convenience, while settlement data must be fresh, bounded, and verifiable.

2.3 Data and Indexing Layer

The data layer reads contract events, organizes account and protocol history, builds analytics, materializes DEX markets, derives leaderboard metrics, and powers activity feeds. Contracts remain the source of enforceable state; the data layer makes that state searchable, comparable, and interpretable.

The same layer also connects internal Forged activity with broader DEX intelligence. Tokens, pools, trades, transfers, holders, wallets, and routes become part of the same market surface as vaults, perps, fUSD, and identity.

2.4 Product Layer

The product layer exposes the system through vaults, Shield, Stability Pool, fUSD Swap, Perps, Perps Pool, Loop, DEX Terminal, Activity, Analytics, Profiles, Missions, Squads, Leaderboards, Faucet, Payments, and Bridge surfaces.

Each surface represents a capability rather than a standalone product. Vaults create fUSD. The Stability Pool supports vault liquidations. Perps create synthetic exposure using fUSD. The Perps Pool supplies counterparty liquidity. Loop creates recursive collateralized exposure. The DEX Terminal makes surrounding market activity readable. Identity and progression systems make participation visible.

2.5 Identity and Progression Layer

Profiles, XP, badges, missions, seasons, squads, and leaderboards convert transactional activity into persistent participation signals. This layer creates a social and competitive structure around financial behavior without replacing the underlying economic mechanics.

fUSD is the base stable asset of Forged. The token supports controlled issuance: minting is tied to authorized protocol paths rather than arbitrary creation. This allows fUSD supply expansion to be connected to collateralized debt, system liquidity, and configured issuance rules.

3.1 Role inside the ecosystem

fUSD serves multiple functions:

• Debt asset for vault issuance.
• Deposit asset for the Stability Pool.
• Margin asset for perps.
• Liquidity asset for the Perps Pool.
• Settlement asset for payments.
• Accounting unit for analytics, rankings, and economic measurement.

A shared stable asset gives the system internal coherence. Credit, liquidity, trading, payments, and progression can all reference the same unit. Instead of each module inventing a separate accounting base, Forged uses fUSD as the common denominator.

3.2 Issuance model

The primary issuance path is collateralized vault debt. zkLTC is deposited into a vault, fUSD debt is minted against it, and the vault must remain within configured collateralization rules.

The issuance model is intentionally overcollateralized. A vault cannot mint fUSD equal to the full value of its zkLTC collateral. It must maintain a buffer. In the current vault configuration, minting and normal position adjustments require a minimum collateral ratio of 200%. This means that every 1 fUSD of debt must be backed by at least 2 fUSD worth of zkLTC collateral at the oracle price.

The 200% requirement is not a cosmetic threshold. It defines the capital efficiency and resilience of the credit system. A lower ratio would allow more debt against the same collateral but would leave less room for collateral-price declines. A higher ratio would make fUSD issuance more conservative but less capital efficient. At 200%, the system requires substantial overcollateralization while still allowing zkLTC holders to access fUSD liquidity without selling collateral.

3.3 Supply contraction

fUSD supply contracts when debt is repaid or liquidated. During repayment, fUSD is transferred back to the vault system and burned against outstanding debt. During liquidation, fUSD repaid by a liquidator or offset by the Stability Pool is also burned against unsafe debt. This burn mechanism connects fUSD supply to the debt book: minting expands supply, repayment and liquidation reduce it.

The Vault Manager is the core credit engine of Forged. It allows zkLTC collateral to support fUSD debt while enforcing collateralization constraints.

A vault is a collateralized debt position. It contains two primary balances:

• Collateral: native zkLTC locked in the vault.
• Debt: fUSD minted against that collateral.

The vault system is overcollateralized by design. fUSD is not created as unsecured credit. It is minted only when collateral value, oracle price, and protocol limits allow the resulting position to remain above the required collateral ratio.

4.1 Collateralized debt position logic

The central equation is the collateral ratio:

Collateral Ratio = Collateral Value / fUSD Debt

Collateral value is calculated from the vault’s zkLTC balance and the current oracle price. Debt is the outstanding fUSD minted by the vault.

For example, assume zkLTC is valued such that a vault’s collateral is worth 1,000 fUSD. With a 200% minimum collateral ratio, the maximum debt allowed by the ratio is 500 fUSD:

1,000 collateral value / 500 debt = 200%

If the vault mints 400 fUSD, its collateral ratio is 250%:

1,000 / 400 = 250%

The difference between 250% and the 200% minimum is the operating buffer. The larger the buffer, the more room the position has before it becomes constrained or eventually liquidatable.

4.2 Why overcollateralization matters

Overcollateralized debt serves three purposes.

First, it protects fUSD issuance. Since fUSD is created against collateral, the system requires collateral value to exceed debt value. This gives the protocol room to absorb price movement before debt becomes unsafe.

Second, it creates transparent solvency rules. A vault does not depend on subjective creditworthiness. Its health is measured by collateral value, debt, and protocol thresholds.

Third, it enables permissionless liquidation. When a position falls below the liquidation threshold, the system does not need to negotiate with the borrower. The position becomes actionable under predefined rules.

The cost of this structure is capital inefficiency. A 200% ratio means the borrower must lock significantly more collateral value than the fUSD they mint. Forged chooses this tradeoff to keep the credit system conservative and legible.

4.3 Vault lifecycle

A vault can move through several states.

Deposit collateral: zkLTC is locked into the vault. This increases collateral but does not create debt by itself.

Mint fUSD: the vault increases debt and receives newly minted fUSD. The transaction is valid only if the resulting debt respects the debt ceiling, minimum debt, and minimum collateral ratio.

Repay debt: fUSD is returned and burned, reducing debt. Repayment improves collateralization because the same collateral backs less debt.

Withdraw collateral: zkLTC is removed from the vault. Withdrawal reduces backing and is permitted only if the remaining vault stays above the minimum collateral ratio.

Close vault: the full debt is repaid, fUSD is burned, and remaining collateral is returned.

Liquidation: if the vault falls below the liquidation threshold, debt can be repaid or offset and collateral can be seized according to liquidation rules.

4.4 The 200% minimum collateral ratio

The 200% minimum collateral ratio is the standard requirement for minting and normal vault adjustments. It applies when opening a debt position, minting additional fUSD, or withdrawing collateral.

This means the vault must satisfy:

Collateral Value × 10,000 >= Debt × 20,000

Equivalently:

Collateral Value >= 2 × Debt

The ratio is enforced after the proposed action. A vault with 300% collateralization can mint or withdraw until it approaches the 200% boundary. A vault already near 200% has very little room for additional borrowing or collateral withdrawal.

The 200% threshold is therefore the capital-efficiency boundary. It is not the liquidation point. It is the minimum safe operating requirement for voluntary vault actions.

4.5 The 150% liquidation ratio

The liquidation ratio is 150%. A vault becomes liquidatable when its collateral ratio falls below this threshold.

This means a vault can exist between 200% and 150%, but it becomes constrained. It may not be able to mint more fUSD or withdraw collateral, but it is not yet liquidatable. The zone between 200% and 150% acts as a stress buffer.

The thresholds create three practical states:

For example, consider a vault with 1,000 fUSD worth of collateral and 500 fUSD of debt. The ratio is 200%. If collateral value falls to 800 fUSD, the ratio becomes 160%. The vault is below the normal 200% operating requirement but still above the 150% liquidation threshold. If collateral value falls to 740 fUSD, the ratio becomes 148%, and the vault is liquidatable.

4.6 Liquidation price

The liquidation price is the oracle price at which a vault’s collateral ratio reaches the liquidation threshold. It depends on collateral amount, debt, and the liquidation ratio.

Conceptually:

Liquidation Price = Debt × Liquidation Ratio / Collateral Amount

With 10 zkLTC collateral and 500 fUSD debt, the 150% liquidation value is 750 fUSD. The liquidation price is therefore 75 fUSD per zkLTC:

500 × 150% = 750 required collateral value
750 / 10 zkLTC = 75 fUSD per zkLTC

If zkLTC trades above 75, the vault remains above liquidation. If the oracle price falls below 75, the vault becomes liquidatable.

4.7 Liquidation mechanics

Liquidation resolves unsafe debt by repaying or offsetting fUSD debt and seizing collateral at a penalty. The current liquidation penalty is 10%.

A liquidator can repay up to the vault’s outstanding debt, subject to available collateral. For every 1 fUSD of debt repaid, collateral worth 1.10 fUSD can be seized at the oracle price. This extra 10% is the liquidation incentive and penalty.

Example:

• Vault debt: 500 fUSD.
• Liquidator repays: 100 fUSD.
• Liquidation penalty: 10%.
• Collateral seized: 110 fUSD worth of zkLTC.

After this liquidation slice:

• Vault debt decreases by 100 fUSD.
• Vault collateral decreases by 110 fUSD worth of zkLTC.
• The repaid fUSD is burned.
• The liquidator receives the seized collateral.

Liquidation can be partial. If the liquidator repays less than total debt, the vault remains open with reduced debt and reduced collateral. If enough debt is repaid, the remaining position may move back above the liquidation threshold. If the position remains unsafe, further liquidation can occur.

4.8 Stability Pool liquidation path

The Stability Pool provides a second liquidation path. Instead of an external liquidator supplying fUSD, the vault system can use pooled fUSD from the Stability Pool to offset unsafe debt. The offset fUSD is burned, and seized zkLTC collateral is sent to the pool.

The economic effect is similar to external liquidation:

• Unsafe vault debt is reduced.
• fUSD used for repayment is burned.
• Collateral is removed from the vault.
• The collateral is distributed to Stability Pool participants through pool share accounting.

The difference is that the fUSD source is pooled liquidity rather than a single liquidator. The Stability Pool therefore acts as standing liquidation capacity for the system.

4.9 System limits

The vault system includes additional constraints:

• Debt ceiling: limits total fUSD debt that can be minted through vaults. The current configured ceiling is 1,000,000 fUSD.
• Minimum debt: prevents dust vaults. The current minimum debt is 10 fUSD.
• Minimum collateral ratio: currently 200%, used for minting and withdrawal safety.
• Liquidation ratio: currently 150%, used to determine liquidation eligibility.
• Liquidation penalty: currently 10%, used to calculate collateral seized during liquidation.
• Oracle valuation: collateral value is determined through the oracle price.

These limits define the vault system’s issuance envelope. The debt ceiling controls aggregate expansion. The minimum debt controls position granularity. The collateral ratios define individual vault safety. The penalty creates liquidation incentive.

The Stability Pool is the liquidation absorption layer for the vault system. It holds fUSD that can be used to offset debt from liquidated vaults. In exchange, the pool receives seized zkLTC collateral.

5.1 Economic function

The pool creates a standing source of fUSD liquidity for liquidations. Without such a pool, liquidations depend entirely on external actors choosing to repay unsafe debt. With pooled fUSD available, the protocol can resolve unsafe positions through existing system liquidity.

The Stability Pool aligns fUSD holders with system solvency. Pool participants supply fUSD that can be burned against unsafe debt. In return, they receive exposure to collateral distributed through liquidations.

5.2 Share accounting

The Stability Pool uses shares. Deposits mint shares, and shares represent a proportional claim on the pool’s combined value:

• fUSD held by the pool.
• zkLTC collateral received through liquidations.

When the pool is empty, depositing 100 fUSD mints 100 shares. When the pool already has value, new shares are minted in proportion to the current pool value. This prevents new deposits from diluting existing participants’ accumulated collateral gains.

Example:

• Pool value before deposit: 1,000 fUSD.
• Total shares: 1,000.
• New deposit: 100 fUSD.
• Shares minted: 100.

If the pool later contains 900 fUSD and 220 fUSD worth of zkLTC collateral, total pool value is 1,120 fUSD. A participant holding 10% of shares can withdraw approximately 10% of both components: 90 fUSD and 22 fUSD worth of zkLTC, subject to actual token balances and oracle valuation.

5.3 Liquidation absorption

When the Stability Pool absorbs a liquidation, fUSD is burned and zkLTC enters the pool.

Example:

• Stability Pool balance: 10,000 fUSD.
• Unsafe vault debt offset: 500 fUSD.
• Liquidation penalty: 10%.
• Collateral sent to pool: 550 fUSD worth of zkLTC.

After the offset:

• Pool fUSD decreases from 10,000 to 9,500.
• Pool receives 550 fUSD worth of zkLTC.
• Pool total value becomes 10,050 fUSD, assuming unchanged collateral price.

The extra 50 fUSD value reflects the liquidation penalty captured by the pool. Pool participants do not receive a separate claim ticket; their existing shares now represent a claim on a pool with a different asset mix and, in this example, higher total value.

5.4 Asset composition

The Stability Pool can become increasingly collateral-heavy if many liquidations occur. Depositors enter with fUSD and may exit with a mix of fUSD and zkLTC. This is the economic tradeoff of providing liquidation capacity: fUSD is used to retire unsafe debt, while collateral is received in exchange.

The pool is therefore not a fixed-yield deposit product. Its return profile depends on liquidation flow, liquidation penalties, zkLTC price movement, and the timing of deposits and withdrawals.

The fUSD swap router provides conversion between zkLTC and fUSD. Its role is to improve internal liquidity by allowing capital to move between native collateral and the protocol stable asset.

6.1 Price-aware conversion

The router uses oracle-based pricing to quote conversions between zkLTC and fUSD. The basic conversion is straightforward:

zkLTC input × oracle price = fUSD value

For the reverse direction:

fUSD input / oracle price = zkLTC output

Fees and limits are applied on top of this valuation. The router is therefore not an AMM with a constant-product curve. It is a liquidity facility whose execution is bounded by oracle price, available reserves, per-trade caps, daily outflow caps, and configured fees.

6.2 Liquidity limits

The router can only pay out what it holds. A zkLTC-to-fUSD swap requires sufficient fUSD reserves. An fUSD-to-zkLTC swap requires sufficient native zkLTC reserves. Trade-size limits and daily outflow caps reduce the probability that one direction drains all liquidity.

The distinction between price and liquidity is important. The oracle can define fair value, but reserves define executable size.

6.3 Role in the broader system

Internal conversion supports the rest of Forged. Vaults create fUSD, but users and protocol participants may need to move between collateral and stable units. The router gives the ecosystem a native conversion path that does not depend entirely on external markets.

Forged perps provide synthetic LTC exposure using fUSD as margin. The system supports long and short positions, leverage, funding, fees, liquidation, and pool-based counterparty liquidity.

7.1 Position structure

A perps position is defined by:

• Side: long or short.
• Margin: fUSD committed to the position.
• Leverage: exposure multiplier.
• Notional size: margin multiplied by leverage.
• Entry price: signed mark price at opening.
• Current mark price: signed mark price used for settlement.
• Maintenance margin: required equity floor.
• Funding snapshot: funding state when the position was opened.

Example:

• Margin: 100 fUSD.
• Leverage: 5x.
• Notional: 500 fUSD.
• Entry price: 100 fUSD per LTC.
• Side: long.

The position behaves as if it has 500 fUSD of LTC exposure. A 10% increase in LTC price creates approximately 50 fUSD of unrealized profit before fees and funding. A 10% decrease creates approximately 50 fUSD of unrealized loss.

7.2 Entry fee and effective margin

The perps system charges an entry fee on notional. The current entry fee is 0.10% of notional.

Using the previous example:

• Margin supplied: 100 fUSD.
• Notional: 500 fUSD.
• Entry fee: 0.5 fUSD.
• Margin recorded after fee: 99.5 fUSD.

The position’s effective margin is therefore lower than the amount initially supplied. This matters because equity and liquidation are calculated from margin after fees, not simply from the wallet amount transferred into the position.

7.3 PnL calculation

For a long position:

PnL = Notional × (Current Price - Entry Price) / Entry Price

For a short position:

PnL = Notional × (Entry Price - Current Price) / Entry Price

A long profits when the mark price rises. A short profits when the mark price falls.

Example long:

• Notional: 500 fUSD.
• Entry: 100.
• Current: 110.
• PnL: 500 × 10 / 100 = 50 fUSD.

Example short:

• Notional: 500 fUSD.
• Entry: 100.
• Current: 90.
• PnL: 500 × 10 / 100 = 50 fUSD.

Losses are symmetric in the opposite direction.

7.4 Equity

Position equity is margin plus PnL minus funding owed:

Equity = Margin + PnL - Funding Owed

Equity determines what can be returned on close and whether the position is liquidatable. If equity is positive, the trader can receive remaining value after applicable exit fees. If equity is zero or negative, the position has consumed its margin and may create bad debt for the pool if not liquidated in time.

7.5 Maintenance margin and liquidation

Each leverage tier has a maintenance margin requirement. The maintenance requirement is calculated as a percentage of notional. A position becomes liquidatable when equity is less than or equal to required maintenance.

Current configured tiers are:

The tier system makes larger positions and lower-leverage bands carry more explicit maintenance room. It also prevents the highest leverage from being used at large notional sizes.

Example:

• Margin after fee: 99.5 fUSD.
• Notional: 500 fUSD.
• Maintenance margin: 1%.
• Required maintenance: 5 fUSD.

The position becomes liquidatable when equity falls to 5 fUSD or below. Since equity starts at 99.5 fUSD, the position can absorb roughly 94.5 fUSD of adverse PnL and funding before reaching maintenance. On 500 fUSD notional, that corresponds to approximately 18.9% adverse price movement before considering funding.

7.6 Liquidation price

The liquidation price is the mark price where equity reaches maintenance.

For a long position, adverse movement is downward. The simplified relationship is:

Liquidation PnL = Maintenance + Funding Owed - Margin
Liquidation Price = Entry Price + (Liquidation PnL × Entry Price / Notional)

For a short position, adverse movement is upward:

Liquidation Price = Entry Price - (Liquidation PnL × Entry Price / Notional)

Because Liquidation PnL is usually negative at opening, the long liquidation price sits below entry and the short liquidation price sits above entry. Funding owed moves the liquidation price closer to the current market because it reduces equity.

7.7 Liquidation flow

Perps liquidation is permissionless. A valid fresh signed price is enough to evaluate and liquidate an unsafe position.

When a position is liquidated:

1. 1A signed mark price is verified.
2. 2Funding is updated.
3. 3Position equity is calculated.
4. 4If equity is above maintenance, liquidation is rejected.
5. 5If equity is at or below maintenance, the position is closed.
6. 6The position’s margin is moved into the pool.
7. 7If equity is positive, a liquidator bounty is paid from that remaining equity.
8. 8If equity is negative, the deficit is recorded as bad debt.

The current liquidator bounty is 0.5% of remaining equity. This incentivizes timely liquidation without granting the liquidator the entire remaining position value.

7.8 Settlement against the pool

The Perps Pool is the counterparty to trader PnL.

When a trader loses, the pool benefits because margin and settlement inflows remain in the pool. When a trader wins, the pool pays the trader. This is why perps liquidity is economically different from a passive deposit: LPs are underwriting trader profits and losses.

Closing flow:

• The trader’s held margin is deposited into the pool.
• The system calculates equity.
• If equity is positive, the pool pays the trader the resulting amount after applicable profit fee.
• If equity is negative, the shortfall is recorded as bad debt.

7.9 Exit profit fee

Profitable closes are subject to a close-profit fee. The current fee is 1% of realized profit, capped by equity. This fee applies only when the position has positive PnL. It does not tax the return of original margin as profit.

Example:

• Margin after entry fee: 99.5 fUSD.
• Realized PnL: 50 fUSD.
• Equity before exit fee: 149.5 fUSD.
• Exit profit fee: 0.5 fUSD.
• Returned to trader: 149.0 fUSD.

7.10 Funding and skew

Funding transfers value based on long-short imbalance. When long open interest exceeds short open interest, long positions pay funding. When short open interest exceeds long open interest, short positions pay funding.

The funding rate is derived from market skew:

Skew = (Long OI - Short OI) / Total OI

A fully one-sided market produces maximum skew. The current maximum funding rate is 0.01% per hour at full skew. Partial skew scales proportionally.

Example:

• Long OI: 750,000 fUSD.
• Short OI: 250,000 fUSD.
• Total OI: 1,000,000 fUSD.
• Skew: 50% long.
• Funding rate: 0.005% per hour paid by longs.

Funding creates pressure against one-sided positioning. It does not guarantee balanced open interest, but it makes crowded exposure more expensive over time.

7.11 Signed price settlement

Settlement-sensitive actions use signed mark prices. The signed price contains market identity, price, timestamp, and signature. The contract verifies:

• Price is nonzero.
• Timestamp is not too old.
• Timestamp is not too far in the future.
• Signature is valid and non-malleable.
• Signer is authorized.
• Price is within the configured deviation guard versus the reference oracle when the reference check is active.

Current signed-price timing parameters are:

• Maximum price age: 30 seconds.
• Maximum future skew: 5 seconds.
• Reference deviation guard: 5% when configured.

This model gives perps fast execution while keeping settlement prices bounded by contract-verifiable attestations. The visual market feed can update continuously, but contract settlement uses signed data.

7.12 Open interest and utilization controls

Perps exposure is constrained by open interest caps and pool utilization. Current maximum utilization is 60% combined open interest relative to pool liquidity.

This means that if the pool has 100,000 fUSD of available liquidity, combined long and short open interest cannot exceed 60,000 fUSD under the utilization rule. This prevents the trading book from becoming too large relative to the pool that must settle PnL.

Open interest limits can also apply separately to long and short sides. These controls shape market capacity and reduce the chance that one-sided exposure overwhelms available liquidity.

The Perps Pool provides fUSD liquidity against which traders settle profits and losses. It is the counterparty liquidity layer for the perps system.

8.1 NAV-floating shares

Deposits mint pool shares. Shares represent proportional ownership of pool net asset value rather than a fixed redemption amount.

When the pool is empty, deposits mint shares using a precision offset. After the pool has existing shares, new shares are minted according to current NAV:

Shares Minted = Deposit Amount × Total Shares / Pool NAV

This means new LPs enter at the current pool value. If the pool has grown due to fees or trader losses, new deposits receive fewer shares per fUSD than early deposits. If the pool has shrunk due to trader profits, new deposits receive more shares per fUSD.

8.2 How pool value changes

Pool NAV changes through several channels:

• LP deposits increase NAV and mint shares.
• Trader entry fees add fee inflow.
• Trader losses and liquidation residuals add settlement inflow.
• Trader profits create outflows.
• Liquidator bounties create outflows.
• Withdrawals reduce NAV and burn shares.
• Protocol reserve cuts route part of fee income away from pool NAV.

Pure fees are split by reserve logic. The default reserve cut is 15% of fee inflow, with the remaining 85% staying in the pool. Settlement inflows such as trader losses are not treated as fee income and do not receive the same reserve cut.

8.3 Trader PnL and LP exposure

The Perps Pool’s core economic role is to warehouse trader PnL.

If traders lose more than they win, pool NAV rises. If traders win more than they lose, pool NAV falls. Fees can offset some trader profitability, but they do not eliminate the pool’s counterparty exposure.

Example:

• Pool NAV: 100,000 fUSD.
• Trader closes with 5,000 fUSD profit.
• Pool pays 5,000 fUSD before considering applicable fees.
• Pool NAV decreases.

Another example:

• Pool NAV: 100,000 fUSD.
• Trader loses 5,000 fUSD.
• Margin settlement remains in the pool.
• Pool NAV increases.

LP returns therefore depend on trading flow, fees, liquidation timing, utilization, and market direction of trader positioning.

8.4 Withdrawal model

Withdrawals use a request-and-execute structure. The current cooldown is 24 hours, and withdrawal requests expire after 7 days.

The reason is economic rather than cosmetic. If LPs could withdraw instantly, they could attempt to exit immediately before adverse pool events while remaining exposed to upside during calm periods. A cooldown reduces that free-option behavior.

During the cooldown, pending shares remain economically exposed. The amount received at execution is calculated at current NAV, not the NAV at request time.

8.5 Utilization-aware withdrawals

Before executing a withdrawal, the system checks whether removing liquidity would breach the perps utilization cap. If existing open interest would exceed allowed utilization after the withdrawal, execution is blocked.

This links LP exits to market obligations. The pool cannot freely return liquidity if that liquidity is needed to support active open interest.

Loop introduces recursive collateralized exposure. It combines borrowing, conversion, and position-specific management to amplify zkLTC-linked exposure through vault-style mechanics.

9.1 Difference from perps

Loop and perps both create leveraged exposure, but their mechanics differ.

Perps are synthetic derivative positions. A perps trader posts fUSD margin and settles PnL against signed mark prices and the Perps Pool.

Loop positions are collateral/debt structures. A loop position deposits zkLTC, mints fUSD, swaps fUSD into more zkLTC, and deposits that additional zkLTC back into the vault. The result is more collateral exposure and more debt inside a vault-based structure.

9.2 Recursive exposure logic

A simplified loop cycle looks like this:

1. 1Deposit zkLTC collateral.
2. 2Mint fUSD against the collateral.
3. 3Swap the fUSD into more zkLTC.
4. 4Deposit the acquired zkLTC back into the vault.
5. 5Repeat or stop based on desired exposure and collateral ratio.

Each loop increases both collateral and debt. The position becomes more sensitive to zkLTC price movement because more collateral exposure is supported by borrowed fUSD.

Example:

• Initial collateral: 100 fUSD worth of zkLTC.
• Minted debt: 40 fUSD.
• Swapped into additional zkLTC: 40 fUSD worth, before execution effects.
• Final collateral: 140 fUSD worth of zkLTC.
• Final debt: 40 fUSD.
• Collateral ratio: 350%.

A more aggressive loop could continue minting and swapping until the ratio approaches the loop’s configured minimum. The closer the loop moves toward the minimum, the more sensitive it becomes to adverse price moves.

9.3 Position architecture

Loop uses user-specific position contracts coordinated by a manager. The position contract interacts with the vault system, while the manager tracks account metadata and enforces loop-specific limits.

This architecture isolates each loop position. The user’s loop has its own position address and vault state rather than mixing all loop users into a single aggregate vault.

9.4 Loop collateral ratio

Loop positions are constrained by both the underlying vault rules and loop-specific rules. The loop minimum collateral ratio cannot be lower than the vault minimum collateral ratio. This means Loop cannot be used to bypass vault safety. It can only operate within equal or stricter constraints.

The manager enforces:

• Minimum loop collateral ratio.
• Maximum debt per position, if configured.
• Route liquidity checks.
• Adapter availability.
• Vault minimum debt where relevant.

9.5 Decrease and exit logic

Reducing a loop means unwinding part of the recursive structure. The position can swap some collateral back into fUSD, repay debt, and leave the remaining position with a safer ratio. Exiting attempts to unwind enough collateral into fUSD to repay the outstanding debt and close or empty the position.

The exit path is constrained by available safe collateral and swap liquidity. If there is not enough safe collateral to convert into fUSD, the position may require wallet repayment or additional collateral before it can fully close.

9.6 Exposure characteristics

Looped exposure compounds price sensitivity. If zkLTC rises, the position benefits from holding more collateral exposure than the initial deposit alone would have provided. If zkLTC falls, collateral value falls while debt remains denominated in fUSD. That causes the collateral ratio to compress faster than it would in an unlooped vault.

Loop is therefore structurally closer to recursive borrowing than to a derivative. It does not settle PnL against a pool. Its pressure point is the vault collateral ratio.

The DEX Terminal extends Forged from a protocol into a market intelligence platform. It indexes and organizes token, pool, factory, trade, transfer, holder, wallet, and route data.

10.1 Why market intelligence belongs inside Forged

Forged activity does not happen in isolation. Collateral, fUSD, liquidity, synthetic exposure, token discovery, and wallet behavior all exist inside a broader market. The DEX Terminal gives that market structure.

Without a data layer, market participants see fragmented contracts and raw transactions. With the DEX Terminal, they can interpret liquidity, trade flow, holders, routes, wallets, and protocols as part of a coherent market map.

10.2 Token and pool discovery

Token and pool surfaces reveal where liquidity and activity are concentrated. They support comparison by:

• Liquidity.
• Volume.
• Price movement.
• Pool composition.
• Holder distribution.
• Trade count.
• Recent activity.
• Protocol or factory origin.

This makes the terminal useful both for directional discovery and market quality assessment. A token with rising volume but thin liquidity has different execution characteristics from a token with deep liquidity and distributed holders.

10.3 Wallet intelligence

Wallet intelligence shifts analysis from assets to actors. Balances, transfers, trades, labels, and PnL-style metrics can be used to understand how accounts interact with the market.

This enables a different kind of transparency. Instead of only asking what an asset did, the terminal can ask who acted, how often, with what size, through which pools, and with what historical pattern.

10.4 Routing

Route intelligence identifies supported execution paths across indexed liquidity. A route is not merely a price quote; it is a path through available pools and protocols subject to liquidity, supported execution logic, and confidence in the underlying market data.

The route builder’s strategic role is to make execution more reliable by treating market structure as data infrastructure. The interface can display a path, but the important layer is the backend interpretation of executable routes, pool depth, and supported adapters.

10.5 Relationship to the rest of Forged

The DEX layer broadens Forged beyond internal protocol activity. Vaults, fUSD, perps, and identity define the internal system. DEX intelligence maps the surrounding market. Together they create a fuller financial environment: issuance, leverage, trading, liquidity, discovery, and reputation.

The identity layer gives persistent structure to platform participation.

11.1 Profiles

Profiles attach public identity and metadata to addresses. They provide the base surface for reputation, achievements, activity history, squad membership, and social context.

In a financial product, identity is not only cosmetic. It gives repeated activity continuity. A trader, vault participant, LP, mission completer, or squad member can accumulate a recognizable public record.

11.2 XP and badges

XP accumulates progression. Badges represent achievements, roles, or milestone completion. Together, they create a visible record of participation across financial and social surfaces.

The design separates accounting from reputation. Financial contracts handle collateral, debt, liquidity, and settlement. The progression layer records participation patterns and achievements.

11.3 Missions

Missions direct activity toward specific platform behaviors. They can represent vault activity, trading, liquidity provision, DEX exploration, social actions, or season-specific objectives.

Missions serve three functions:

• They make platform capabilities discoverable.
• They create structured participation goals.
• They convert activity into reputation and progression.

11.4 Squads and leaderboards

Squads convert individual participation into group competition. Leaderboards rank activity by configured metrics and seasons, making performance visible across accounts and groups.

Leaderboards are not a replacement for protocol accounting. They are derived views over activity. Their value is comparative: they make participation legible at the ecosystem level.

Forged relies on indexed data to make activity usable. Onchain events are read, decoded, stored, and projected into activity feeds, analytics, leaderboards, DEX views, wallet intelligence, and profile history.

12.1 Event-derived state

Contracts emit events when state changes. Deposits, mints, repayments, withdrawals, liquidations, pool deposits, position opens, position closes, payments, missions, badges, and squad changes all produce event streams.

The indexer turns these streams into readable history. It does not replace contracts as the authority over current enforceable state, but it makes the historical record accessible.

12.2 Market-derived state

DEX indexing materializes tokens, pools, factories, trades, transfers, holders, candles, routes, and wallets. This creates a market graph that can be searched and ranked.

Market-derived state differs from protocol state. A vault’s debt is directly stored in a contract. A token’s market profile is derived from many trades, transfers, pool states, and holder changes. The DEX layer organizes that derived information into a market surface.

12.3 Snapshots and derived metrics

Some metrics are naturally event-based. Others require snapshots or aggregation. Perps pool history, price history, liquidity history, leaderboards, and analytics often depend on periodic or derived views.

Examples include:

• Total fUSD supply and debt.
• Vault count and collateralization distribution.
• Stability Pool value and composition.
• Perps volume, fees, open interest, funding, and liquidations.
• Perps Pool NAV and utilization.
• DEX token volume and liquidity.
• Wallet activity and behavioral labels.
• XP, badges, missions, squads, and seasonal rankings.

12.4 Data as product infrastructure

The data layer is not merely reporting. It is part of the product. Without indexing, the protocol would remain functional but difficult to interpret. With indexing, Forged becomes navigable: positions, markets, history, competition, and reputation become visible.

This is especially important for a multi-module ecosystem. A vault event, perps close, Stability Pool deposit, DEX trade, and badge claim can all be separate onchain or offchain events. The data layer provides the connective tissue that makes them part of one coherent system.

The Payment Registry adds structured payment requests and settlement records to Forged. It allows payment intent to be represented as protocol state rather than informal wallet-to-wallet transfers.

A payment request can define payer, recipient, asset, amount, and status. Completion records settlement, while cancellation resolves unused requests. This creates a lightweight payment layer around fUSD, native assets, and supported token flows.

The strategic role of payments is not complexity. It is composability. Once payment requests are represented in the system, they can appear in profiles, activity, analytics, reputation, and future commerce-oriented surfaces.

The Bridge module represents cross-environment asset movement through a controlled relay model. Its purpose is to model the lifecycle of asset movement: initiation, authorization, relay, minting or release, and replay protection.

In this structure, a trusted relayer or authorized path confirms movement from one environment to another. The module demonstrates how asset flow can be represented and controlled across domains while maintaining accounting constraints on the destination side.

The bridge system is best understood as infrastructure scaffolding: it defines the shape of cross-environment movement and the assumptions required for it. As the ecosystem matures, bridge design can evolve toward stronger verification, broader asset support, and tighter integration with the rest of Forged.

Forged uses configurable parameters because financial systems require adjustable boundaries. The important question is not whether parameters exist, but what they control and how they shape economic behavior.

15.1 Vault parameters

Vault parameters define the credit envelope:

These parameters determine how much fUSD can be created, how much collateral must back it, and how unsafe positions are resolved.

15.2 Perps parameters

Perps parameters define market capacity and settlement behavior:

These parameters shape how aggressive the market can become, how quickly funding accrues, how settlements are priced, and how much exposure the pool can support.

15.3 Perps Pool parameters

Perps Pool parameters define LP liquidity behavior:

These parameters control how fees are split and how quickly LP liquidity can exit.

15.4 Loop parameters

Loop parameters define recursive exposure boundaries:

• Minimum loop collateral ratio, constrained to be at least the vault minimum collateral ratio.
• Maximum debt per position, if configured.
• Swap adapter availability.
• Route liquidity requirements.
• Vault-level debt and collateralization constraints.

Loop cannot override the vault system. It operates within vault constraints and adds additional checks for recursive exposure.

The natural direction for Forged is deeper market coverage, stronger liquidity systems, broader perps support, expanded identity mechanics, richer DEX intelligence, improved routing, more sophisticated analytics, and progressive hardening of operating assumptions.

The long-term shape is an integrated financial environment where collateral, stable assets, leverage, liquidity, trading, discovery, reputation, and competition reinforce one another.

Collateral ratio: Collateral value divided by outstanding debt.

Debt ceiling: Maximum aggregate fUSD issuance allowed through the vault system.

fUSD / ForgedUSD: Stable asset and primary unit of account in Forged.

Funding: Value transfer between long and short perps exposure based on market skew.

Liquidation: Resolution process for positions that fall below required collateral or margin levels.

Liquidation penalty: Additional collateral value seized during vault liquidation beyond the debt repaid.

Maintenance margin: Minimum equity required to keep a perps position open.

Margin: fUSD committed to a perps position.

NAV: Net asset value of a pool after accounting for inflows, outflows, fees, and PnL.

Notional: Total synthetic exposure controlled by a leveraged position.

Overcollateralization: Requirement that collateral value exceeds debt value by a defined ratio.

Pool share: Proportional ownership claim on pool NAV.

Signed price: Authorized price attestation used for perps settlement actions.

Stability Pool: fUSD pool used to absorb liquidated vault debt.

Vault: Collateralized debt position used to mint fUSD from zkLTC collateral.

zkLTC: Native asset of litVM and collateral asset in Forged.