overview

what is factory?

factory is a concentrated liquidity AMM (automated market maker) built on octra. traders swap tokens; liquidity providers deploy capital within custom price ranges and earn fees while the market price is inside their range.

unlike traditional amms that spread liquidity evenly from zero to infinity, factory positions are capital-efficient: the same amount covers a tighter range and earns proportionally more fees while active.

factory runs natively on octra, an octra-VM l1, not a bridge or a layer on top.

key properties

• concentrated liquidity, lps set a price range. capital outside it earns nothing and is not at risk.
• multiple fee tiers, three fee levels for different pairs.
• permissionless, any OCS-01 compatible token pair can be listed by deploying a pool. no approval needed.
• non-custodial, funds stay in your wallet until you submit a transaction.
• octra-native, runs directly on the octra VM, not a bridge or layer on top.

overview

how it works

factory uses a tick-based concentrated liquidity model similar to uniswap v3, adapted for the octra VM and the AML contract language. each pool tracks a current price (as a square-root ratio) and a set of initialized ticks that mark the boundaries of active LP positions.

pools

each pool is a contract that holds reserves for one token pair at one fee tier. the factory registry tracks every deployed pool, and the router handles swap routing across pools.

swaps

on a swap, the router uses the quoter to find the best path and expected output, then submits the trade to the pool. the pool steps through initialized ticks, consuming liquidity from each active position until the input is fully used.

positions

an LP position is defined by a lower tick, an upper tick, and a liquidity amount, stored per owner. when the price is inside a position's range, it accrues a share of fees proportional to its share of active liquidity.

for traders

swapping

to trade you need an octra-compatible wallet and some OCT for fees. two wallets are supported: Factory Wallet and 0xio, both desktop browser extensions.

getting started

1. install a wallet, Factory Wallet or 0xio (desktop browser extension), and create or import your octra wallet.
2. open the factory app and click connect wallet.
3. pick the token pair and enter an amount, the quoter shows the expected output and price impact.
4. click swap and confirm in your wallet.

exact input vs. exact output

factory supports both directions:

• exact input, you set how much you spend; the output varies with price.
• exact output, you set how much you receive; the input is calculated and may vary slightly.

for traders

fee tiers

each pool is deployed at one of three fee tiers. the fee is taken from the input token on every swap and distributed to active lps in that pool.

a pool's fee tier is fixed at deployment. the same pair can have several pools at different tiers, with separate liquidity.

for traders

price impact & slippage

price impact

price impact is the price change your trade causes. larger trades relative to pool depth move the price more. the interface shows estimated price impact before you confirm.

slippage tolerance

slippage tolerance bounds how much the price may move between quote and execution. if the final price is outside the bound, the swap reverts and your tokens are returned. the default is 1.0%; raise it for volatile assets or thin pools.

for lps

providing liquidity

liquidity providers deposit two tokens and earn a share of swap fees while the market price is inside their chosen range. you only earn fees while the price is in range.

adding a position

1. open the liquidity tab, pick a pool, and click add liquidity.
2. select a token pair and a fee tier.
3. set a price range. it must bracket the current price to be active right away.
4. enter the amounts, the interface computes the required ratio for your range.
5. click add liquidity and confirm in your wallet.

impermanent loss

as the price moves within your range, the pool rebalances your holdings between the two tokens. if you withdraw at a different price than you entered, you may hold fewer tokens than if you had simply held. narrower ranges amplify this alongside the higher fee income.

for lps

price ranges

when you open a position you set a lower price and an upper price. your liquidity is active, and earns fees, only while the market price is between them.

narrow vs. wide ranges

out-of-range positions

if the price leaves your range, the position stops earning and becomes 100% one token. it stays open and resumes earning when the price returns. you can close it at any time.

for lps

collecting fees

fees accrue inside the pool contract and are credited to your position. they are not sent to your wallet automatically, you claim them.

how to collect

1. open the positions tab.
2. find a position with unclaimed fees, the interface shows the pending amount per token.
3. click claim and confirm in your wallet.

you can collect without closing the position; it does not affect your liquidity or range.

protocol

token standard

factory supports any token that implements the OCS-01 standard, octra's equivalent of ERC-20. OCS-01 defines a common interface for fungible tokens on the octra VM: transfers, balance queries, and allowances.

creating a pool

factory is permissionless, anyone can create a pool for any OCS-01 compatible token pair, with no approval or governance vote. each pool is a standalone contract deployed through the factory registry; the same pair can have several pools at different fee tiers.

protocol

security

smart contract risk

factory contracts are written in appliedml (.aml) and compile to octra bytecode. the public AMM passed an automated adversarial security audit by claude opus 4.8: all confirmed critical and high findings were fixed and re-verified on-chain. a formal third-party human audit is planned for the future; use it with funds you are comfortable risking on devnet software.

no admin keys

pool contracts have no owner function or upgrade path after deployment. the factory registry can deploy new pools but cannot modify existing ones.

reporting issues

found a bug or vulnerability? reach out on twitter @factory_oct or via the contact link in the footer.

private swaps

what is a private swap?

a normal swap is fully public. anyone reading the chain can see that a wallet sent one token and received another, so the trade is tied to that address forever.

a private swap breaks that link. instead of trading directly, the user hands the swap to a relayer: an independent operator that runs the trade on the user's behalf. the chain then shows the relayer trading, not the user. the funds going in and the tokens coming out are settled through the relayer, so an outside observer cannot connect the two sides to the same person.

what is and is not hidden

private swaps provide unlinkability. the input is sent as a stealth transfer of OCT, so anyone who looks a wallet up on an explorer only sees that a stealth transfer happened, not that a swap took place, and cannot tell what, if anything, was received. hidden: that a swap occurred at all, and the link between the funds put in and the tokens taken out. visible: only that a generic stealth transfer occurred, with no hint of its purpose. this is unlinkability at the stealth layer, not a fully shielded balance.

private swaps

how a private swap works

the whole flow takes a few simple steps. the user stays in control of their funds throughout, and never has to trust the relayer with anything it cannot be held accountable for.

1. the user chooses the token to receive, the amount, and where to receive it. the input is always the user's encrypted OCT (octra's encrypted balance), so a private swap always starts from encrypted OCT.
2. the app selects staked relayers from the public registry and computes the optimal split. no single relayer is ever given more than about 70% of the FACT-equivalent of its own stake, and that cap is what drives the automatic split. the user may also split a swap across relayers manually, though doing so costs more in total fees.
3. the relayer registers the job on the on-chain slashing escrow: it posts sha256 of the encrypted order plus a delivery deadline, bonded by its stake. that commitment is a hash that pins exactly what the relayer promised to do. the app reads it back from the escrow and checks that it matches the order before any payment is made.
4. the input is sent as a stealth payment to the relayer, and the order reaches it off-chain. this is safe because the order is encrypted specifically to the relayer's published view key with ecdh key agreement (x25519), so only that relayer can decrypt it, not the chain and not anyone else. the commitment from the previous step already fixed its hash, so the relayer can only act on the exact order that was sent.
5. the relayer runs the swap on the public factory AMM and delivers the result through the delivery contract, as a stealth output only the user can claim. and because the swap runs on the same public factory pools, it keeps the full liquidity depth: the same price and slippage as a public swap, with no separate, shallower private pool.
6. on-chain, observers see only the relayer swapping. the payment and the delivery are never tied together.

because the relayer commits on-chain before any payment is made, and is bonded by its own stake, it cannot quietly take the user's funds. the next sections explain exactly what backs that promise.

private swaps

delivery and claiming

the output is not handed over in the clear. the relayer wraps it and posts it to the delivery contract as a stealth output tagged for the recipient. on-chain it looks like any other stealth output, with no link to the original payment.

only the holder of the claim secret, the user, can claim that output. the app claims it on the user's behalf, and it is then withdrawn into a spendable balance. nobody else can claim or redirect it, and the relayer cannot pull it back once it is posted. it can be claimed at any time, five minutes later or a year later, and only at that moment is the claimer revealed on-chain.

private swaps

relayers

a relayer is an independent operator that settles the swap on the user's behalf. it briefly takes the input that is sent, runs the trade on the public AMM, and delivers the result back. relayers compete to serve swaps, ranked by reputation, and earn a small fee for the service.

discovery

relayers announce themselves to a public registry that the app reads, so available relayers show up automatically. there is no central gatekeeper: anyone can join by staking funds and running the relayer software, the app or the relayer code itself.

capacity

a relayer accepts at most about 70% of its staked collateral in a single swap. that rule guarantees the relayer always has more at stake than the funds it is settling, so if it ever misbehaves there is enough collateral to make the user whole.

a swap larger than a single relayer can take is automatically split across several relayers, each within its own limit, then recombined on delivery.

reputation

relayers build reputation by delivering reliably, swap after swap. the app prefers higher-reputation relayers when it routes, so steady, honest operators win more flow, while a relayer that fails or stalls loses standing and sees less.

private swaps

staking

to accept swaps, a relayer must lock up FACT collateral in the staking vault. this stake is what protects the user: if the relayer fails to deliver, the stake is what pays the compensation. a relayer with no stake cannot take swaps.

there is a minimum stake to operate, and a relayer's capacity scales with how much it has staked (the 70% rule above).

unbonding

when a relayer wants its stake back it requests an unstake, which starts an unbonding period. during unbonding the stake is still slashable, so a relayer cannot dodge a penalty by unstaking the moment it fails to deliver. only after the period ends, with no open obligations, can it withdraw.

private swaps

slashing and safety

this is what makes handing a swap to a relayer safe. every protection is on-chain and does not rely on trusting the operator.

commitment first. the relayer posts its bonded commitment and deadline on-chain before any payment, and the app checks it. funds are sent only once a real, slashable obligation exists.

independent watchtowers. a committee of watchtowers watches the chain and checks, objectively, whether the delivery arrived by the deadline. they read the same public data, so honest watchtowers always reach the same verdict. for now this committee is run centrally, a temporary measure while the model is being tested, and it opens up into a public m-of-n committee as the network matures.

group decision. a slash only executes when m-of-n watchtowers agree, so no single watchtower can rob an honest relayer, and no single relayer can bribe its way out. if a relayer fails to deliver, the watchtowers vote to slash its stake, and the slashed amount is paid to the user as compensation.

what happens to the user

private swaps

fees

a private swap has two small costs on top of the trade itself. a service fee the relayer earns for settling the swap, between 0.3% and 0.5% of the swap depending on how much FACT the relayer has staked, and a gas reserve the relayer keeps to cover its own on-chain steps: claiming the payment, decrypting the order, running the swap, and delivering the result.

both come out of the amount sent, and the app shows the net result before confirmation, so there are no surprises.

the underlying trade still pays the normal pool fee tier (0.05%, 0.30%, or 1.00%), exactly like a public swap. private routing does not change how the AMM itself charges.

so in total the user pays the pool fee tier, the relayer's service fee, and the small gas reserve. all of it is shown as a single net result before confirmation.

private swaps

running a relayer

anyone can run a relayer and earn the service fees. the operator stakes FACT to set their capacity, then runs the relayer service, which watches the chain for incoming payments and settles them automatically, along with its operator panel for status and controls. it can run on a vps or server, or simply on a personal computer.

the more an operator stakes, the larger the swaps it can take and the more flow it can earn. the stake is always at risk if it fails to deliver, which is exactly what keeps the network honest.

rewards

FACT points

FACT points reward genuine protocol usage and determine the share of a future FACT distribution allocated to each wallet. points are recorded per wallet for every qualifying action. they are preliminary: balances accrue during the current period and convert to FACT at the token generation event.

how you earn

daily streak

sustained participation compounds. each day on which a wallet interacts with the protocol, through a swap, a liquidity operation, or a claim, applies a +3% multiplier to the engagement points earned that day. a missed day resets the multiplier to zero.

tiers

cumulative points determine a tier: bronze, silver, gold, platinum, and diamond. thresholds increase steeply, each several times the previous, so higher tiers are reached over a season rather than immediately. each tier applies a small additional multiplier; the primary differentiation on the leaderboard derives from activity rather than from tier.

leaderboards

separate leaderboards are maintained for overall points, swap count, volume, and liquidity-days. the points page in the application shows each wallet rank, current streak and tier, and a complete breakdown of point sources.

tokenomics

FACT supply

wallet

factory wallet

factory wallet is a non-custodial browser extension for the octra network. it holds OCT and any OCS-01 token, signs your transactions locally, and connects to the factory app in one click. your keys are encrypted on your device and never leave the extension.

it is the recommended way to use factory. it runs in the browser, asks you to approve every transaction in a popup, and bundles multi-step actions (wrap, approve and swap) into a single atomic confirmation.

wallet

what you can do

• hold and send OCT and any OCS-01 token.
• swap and add liquidity on factory, each multi-step flow is one atomic transaction you approve once.
• track your positions, see your open liquidity positions with a link to manage them in the app.
• private balance, keep an encrypted balance that stays hidden on chain.
• accounts and networks, manage several accounts, switch between devnet and mainnet, and pick your language (english, russian, chinese).

wallet

security model

factory wallet is non-custodial. the 32-byte seed and the key that encrypts your vault live only inside the extension background, never on a server or a web page; only your signature and public key go on the wire. every transaction needs an explicit approval in the wallet popup before it is signed.

• your vault is encrypted with a memory-hard scrypt key derived from your password.
• the wallet auto-locks after a configurable idle time and wipes the key from memory.
• a connected site can read only your address, it can never move funds without a separate approval.
• the code was reviewed by a multi-agent security audit with a council of six reviewers.

wallet

security audit

factory wallet was reviewed by a multi-agent adversarial audit with claude opus 4.8: twelve specialized finder agents, a per-finding skeptic pass that refuted false positives, and a council of six senior reviewers (cryptographer, key-custody, browser-extension security, red-teamer, transaction integrity, code quality). every actionable finding was fixed.