Bitlixir.
Lixir (LXR).

01. The exchange and the token

Bitlixir brings a centralized exchange and a prop trading challenge platform into one planned product: spot markets, futures markets and paid futures challenge accounts. Development includes trading, custody, risk and challenge integrations, with progress updates planned throughout the presale.

1.1 The intended exchange experience

Traders will be able to access spot and futures markets and purchase challenge accounts from the same platform, subject to product eligibility. Challenge fees, targets, drawdown limits, account sizes, execution and progression/payout rules form part of the product workstream and will be published as the presale progresses.

1.2 Lixir (LXR) utility

Fee discounts and VIP benefits must be implemented in the exchange itself. Holding a Solana token does not automatically change the exchange fee schedule. The account-to-wallet link, balance verification and eligibility controls must be designed and tested.

1.3 Launch sequence

After the full $3 million raise is completed, Bitlixir will launch the product first and Lixir shortly afterwards. The 20% buyer unlock occurs at token launch; the remaining 80% vests over the next 12 months. Goals are to complete the exchange integrations, validate custody and trading controls, launch the exchange when ready, and enable the token benefits and claims under final terms. Exchange and token launch dates, along with further product details, will be announced as the presale progresses. Announcements will reflect funding progress and operational readiness.

02. Exchange meets prop trading

The intended distinction is a shared trading platform with two participation routes: trading through an exchange account and buying a futures evaluation challenge. Each route needs its own balances, permissions, risk rules and terms.

2.1 Define what an account actually represents

Before challenge sales, publish whether evaluation and subsequent accounts use simulated balances, live company capital or a hybrid arrangement. A displayed account size is not necessarily money deposited or available to withdraw. Define any progression after passing, reward calculation, payout eligibility, review process, appeals and fee-refund policy. Funding arrangements, profit splits and payout eligibility will be published with the account terms.

2.2 Separate the risks and the money

Exchange customer assets, presale escrow, company trading capital and challenge payout reserves require separate accounting and controls. Model challenge fees, payout liabilities, execution costs and adverse trading outcomes before approving pricing. Budget development includes a dedicated assessment of company trading capital and prop payout reserves.

2.3 Product availability and delivery

Spot, futures and challenge access will depend on jurisdiction, customer eligibility and the actual operating model. A prop-firm label does not determine regulatory treatment. Legal review, a futures risk engine and challenge-account controls are required before launch; availability dates will be announced as the presale progresses, and access will depend on eligibility.

03. Spot markets: execution and fees

Spot trading exchanges one asset for another. Bitlixir plans an order-book model: limit orders specify a price and market orders consume available liquidity. A maker adds resting liquidity; a taker removes it. Partial fills, cancelled orders and insufficient balances must be reflected in the ledger.

3.1 Order and settlement design

Every order reserves the required asset balance. Each fill updates both counterparties, fees and available balances atomically in the exchange ledger. Deposits are credited after chain confirmation; withdrawals require security checks and reconciliation. An exchange balance is a custody claim, not an on-chain wallet balance. Supported assets, fee currency and withdrawal costs will be published during the presale.

3.2 Worked spot trade

Spot fee = executed quantity x fill price x applicable fee rate

The example assumes quote-currency fees, full fills and no slippage. Withdrawal charges, spread, taxes and other costs are excluded. A fall to $57,000 instead produces a $300 gross loss; fees add to the loss. These are invented prices and proposed mechanics, not the Bitlixir fee schedule.

04. Futures markets: exposure and P&L

Bitlixir plans futures trading alongside spot. Futures create price exposure rather than ownership of the underlying asset. The futures workstream covers contract type, expiry or perpetual structure, collateral, settlement currency and contract multipliers. This example uses a hypothetical linear, USDC-settled contract with quantity measured in BTC.

Notional N = quantity q x entry price P; initial margin M = N / leverage L

Long gross P&L = q x (exit - entry); short gross P&L = q x (entry - exit)

4.1 Funding is separate from trading revenue

If perpetual contracts are selected, funding may transfer value between longs and shorts. The example payment equals notional x interval funding rate. Positive or negative rates change which side pays. Funding is not assumed to be exchange revenue or money available for LXR buybacks. Actual interval, notional measurement and settlement rules must be published. [2]

With the same quantity, an exit at $57,000 produces a $300 gross loss: leverage amplifies the percentage effect on margin, not the absolute P&L for a fixed quantity. Contract multipliers matter; inverse contracts need different formulas. [3]

05. Futures risk, margin and liquidation

A futures venue needs a dedicated risk engine in addition to order matching. It must monitor collateral, unrealized P&L, open orders, concentration and maintenance requirements continuously. Product design covers isolated/cross margin, collateral haircuts, mark-price sources and liquidation procedures.

5.1 Simplified maintenance example

Margin equity = collateral + unrealized P&L - accrued charges

Assume the previous $6,000 position has $1,200 collateral and, for arithmetic only, a fixed $60 maintenance requirement. With $6 of accrued charges, equity reaches $60 after a $1,134 loss. For 0.1 BTC, that is an $11,340 adverse move from $60,000 to $48,660.

This is a simplified threshold calculation, not a liquidation quote. Real maintenance depends on current notional, risk tiers, other positions, fee buffers and mark price; liquidation can occur earlier. Stops can slip, and market gaps can exceed collateral. The leverage and maintenance figures above illustrate the calculation; the actual risk schedule will be published with the futures product.

06. Prop challenges within the exchange

The planned prop experience lets a trader purchase a futures evaluation challenge within the Bitlixir interface. Exchange trading and challenge trading share a product environment while maintaining distinct account balances, permissions, risk rules and histories. A challenge fee purchases an evaluation service; it is not a deposit into a withdrawable trading balance.

6.1 Illustrative challenge calculation

Assume a $50,000 simulated account, a $250 evaluation fee, an 8% profit target, a 5% total loss limit and a 2% daily loss limit. The profit target is $4,000; total permitted loss is $2,500; daily permitted loss is $1,000.

With a static total floor, the breach boundary is $47,500. A $1,200 daily equity loss would breach the illustrative daily rule even though it is below the total limit. Trailing drawdown, start-of-day equity, open P&L, resets, commissions and timezone can change the outcome; each must be explicit before sale.

Example reward: $2,000 eligible profit x assumed 80% split = $1,600

A simulated $50,000 account does not imply $50,000 cash is funded or withdrawable. The $1,600 reward is an example contingent on rules and reserves, not a promised payout. Account sizes, targets, fees and splits will be published with the challenge offering; the figures above illustrate the calculations.

07. Prop economics and payout reserves

Illustrative cohort only: 1,000 evaluation purchases at $250 generate $250,000 gross receipts. Assume 200 qualify and 50 receive an average $1,600 reward during the period: reward payments total $80,000. The 150 other qualifiers may create future obligations; they are not assumed to be permanently cost-free.

7.1 Sensitivity and solvency

If 100 traders instead receive $3,000 each, rewards total $300,000. With the same $25,000 and $60,000 costs, the cohort has a $135,000 cash deficit. Qualification and payout rates cannot be treated as fixed; outstanding qualifiers and market stress must be modeled.

Company trading capital and reward reserves must cover the operating model and obligations. A displayed challenge balance is not a reserve calculation. Customer deposits and refundable presale escrow cannot cover challenge losses or payouts. The proposed buyback basis is eligible trading-fee revenue; any future addition of prop revenue would require its own published policy.

08. Trading fees, VIP savings and revenue

The final fee schedule will distinguish markets, maker/taker execution, VIP eligibility and any LXR discounts. Fee revenue depends on executed notional and the effective rate after discounts and rebates. Do not multiply volume by leverage a second time or count both counterparties unless the volume convention explicitly represents both billable sides.

Gross trading fees = sum of each billable fill notional x its effective fee rate

8.1 VIP/LXR discount example

An assumed 20% relative discount on a 0.10% spot rate makes the effective rate 0.08%. A $10,000 billable fill then costs $8 instead of $10, saving $2. A 20% discount means multiplying the rate by 0.80; it does not mean subtracting 20 percentage points. Discount levels and holding thresholds will be published with the VIP policy.

8.2 Revenue is not profit

If the $45,000 eligible net fees are followed by $35,000 operating/tax/reserve requirements, cash above those needs is $10,000. Buybacks can use only the amount allowed by both the revenue allocation rule and the cash reserve rule. Challenge fees, customer collateral and trader-to-trader funding are excluded from this worked fee basis.

09. Buyback execution and permanent burns

The proposed mechanism uses an approved portion of eligible trading-fee revenue to purchase LXR after the exchange and token are operational. Execution can be periodic under a published policy. The policy must identify the venue, fee basis, allocation rate, reserve floor, approvals and reporting; the final percentages will be published through the token-policy workstream.

Example: $50,000 gross fees - $5,000 costs = $45,000 eligible net fees

B = min(10% x $45,000, $10,000 cash above reserves) = $4,500

The chart allocates the $50,000 gross-fee total: $5,000 costs, $4,500 buyback allowance and $40,500 retained for operating needs and reserves. The allowance is 10% of net fees, or 9% of this gross total.

9.1 Execution and reporting

Under the net-fee example, a $4,500 budget with $50 execution costs leaves $4,450 to buy tokens. At an assumed average fill price of $0.01, the purchase is 445,000 LXR. Report actual cash spent, execution costs, volume-weighted average price, tokens acquired, wallet movements and any burn transaction. Slippage changes the number acquired.

If required cash reserves leave only $2,000 available, the maximum budget falls to $2,000 even when the revenue-based allowance is $4,500. A discretionary pause can stop future purchases. Buybacks do not guarantee a price increase, market depth or a return.

10. Burn allocation and supply math

Independent illustration: suppose 500,000 LXR have been bought. If a future policy burns 60% and retains 40%, then 300,000 LXR are burned and 200,000 remain in the disclosed treasury. These percentages are examples, not an adopted policy.

New outstanding supply = prior outstanding supply - tokens actually burned

An executed on-chain burn permanently reduces supply. Future burn events can be paused or ended; already burned units cannot be recovered. Treasury retention does not reduce outstanding supply and is not a burn. A temporary lock restricts access without destroying tokens.

The twelve-event example assumes the same quantity every time; actual purchases depend on revenue, reserves, market price and execution costs. Supply reduction alone cannot establish token value. Mint controls must prevent replacement issuance if the published model promises a fixed maximum supply. [1]

11. Revenue scale: 30% buybacks

The following scenario explores fee-funded LXR purchases using 30% of eligible net trading-fee revenue. This is an illustrative policy allocation; the final operating policy will publish the rate and controls.

Monthly buyback allowance = eligible net monthly fee revenue x 30%

$10,000,000/month x 30% = $3,000,000/month; x 12 = $36,000,000/year

The $10M example leaves $7M of eligible net revenue before operating expenses, taxes, company capital and payout/reserve needs. A 30% revenue allocation is not a 30% profit margin. Actual purchases remain limited to cash above those needs. If only $2M/month is available above reserves, the annual cash-limited budget becomes $24M rather than $36M.

11.1 The trading volume behind the scenario

At an assumed effective fee yield of 0.05% and $1M/month in rebates/provider costs, $10M eligible net fees would require $11M gross fees: $11M / 0.0005 = $22B monthly billable trading notional. This is scale arithmetic, not a forecast of Bitlixir volume. Funding transfers and customer deposits are excluded.

The annual totals assume twelve operating months at the stated revenue level after product and token launch. Launch timing, revenue variation and reserve needs will determine the actual period and spending.

12. Annual buybacks and burn sensitivity

Apply the $36M annual buyback scenario at different assumed average execution prices. For this separate illustration, 50% of acquired LXR are burned and 50% are retained in a disclosed treasury. These prices and the burn split are hypothetical; final execution and allocation rules will be published.

Tokens bought = cash spent / average execution price; tokens burned = tokens bought x 50%

12.1 Worked $0.10 execution scenario

$3M/month / $0.10 = 30M LXR acquired each month. A 50% burn removes 15M LXR/month. Across twelve identical months, purchases total 360M LXR and burns total 180M LXR. Starting from 1B outstanding and assuming no other burns, year-end outstanding supply would be 820M LXR. The remaining 180M acquired LXR stay in treasury and remain part of outstanding supply.

12.2 Market capacity and supply limits

Execution depends on available sellers, circulating supply, market depth, slippage and costs. A constant-price calculation cannot assume more tokens can be purchased than exist or are offered. For example, $36M / the Stage 5 price of $0.01 equals 3.6B LXR, exceeding the initial 1B supply; that combination is infeasible as an annual constant-price purchase scenario.

Actual reporting will use realized prices and on-chain supply changes. Burns permanently remove units; retained treasury tokens remain outstanding. Buyback spending and supply reduction describe the mechanism, while token prices continue to depend on market demand and liquidity.

13. Presale stages and allocation maths

The $3M full-raise target is divided into seven funding stages. Price increases are triggered by confirmed USDC credited to escrow. Contributions crossing a threshold are split between the affected stages using each applicable price.

13.1 Stage-crossing example

If $49,900 is already credited and a buyer contributes 200 USDC, the first 100 USDC purchase at 0.009 and the next 100 at 0.00925. The allocations are approximately 11,111.1111 and 10,810.8108 LXR: 21,921.9219 LXR in total before atomic-unit rounding. A qualifying referrer receives 15%: approximately 3,288.2883 LXR.

13.2 Supply and cap accounting

Completing all seven funding ranges allocates approximately 295,190,531.134 LXR before rounding. The sale vault reserves 300M LXR, leaving approximately 4,809,468.866 unused. Unused sale tokens remain controlled under the published reserve policy. Funding ends at 3M USDC; the allocation ceiling remains 300M.

Target launch reference: 0.036 USDC per LXR, implying $36M fully diluted valuation at 1B supply. This is 4x Stage 1 (+300%) and about 3.429x Stage 7 (+242.86%). It is a planning target, not a guaranteed trading price or return. Market price depends on demand and liquidity; actual returns also depend on vesting, execution and fees.

14. Referral rewards and token allocation

An eligible referrer receives LXR equal to 15% of the referred buyer’s purchased allocation. The buyer keeps their full allocation. Rewards are funded from a dedicated 45M LXR reserve within the initial 1B supply; the allocation is carved out of ecosystem tokens.

Referral reward = eligible purchased LXR x 15%

A 10,000 LXR referred purchase earns 1,500 LXR. Under the proposed matching vesting schedule, 300 unlock at token launch and 1,200 vest over 12 months. A 100,000 LXR purchase earns 15,000, split into a 3,000 initial unlock and 12,000 vested over the year.

The 45M reserve covers 15% of the maximum 300M sale-vault allocation. If every purchase in the staged model is eligible and referred, aggregate rewards are approximately 44,278,579.670 LXR before rounding, leaving about 721,420.330 LXR in the referral reserve.

14.1 Attribution and reward controls

The contract workstream includes immutable purchase attribution, per-wallet reward records, no self-referrals, reserve limits, refund/cancellation handling and vesting claims. Rewards activate following successful raise finalization and token launch. Eligible territories, anti-abuse checks and the unused-reserve policy will be published with the referral terms. Link creation is a preview until verified contract attribution opens.

15. Supply and presale economics

Other allocations: 240M treasury, 115M ecosystem, 150M team and 150M liquidity tokens. Referral rewards are a separate 45M line. The six categories total 1B LXR. The $920,000 liquidity/market-operations cash budget (30.67% of the raise) is separate from the 15% liquidity token reserve.

The referral and sale vaults use separate accounting. Token mint controls enforce the supply specification; actual burns reduce outstanding supply. Reserve release policies will be published through the presale.

16. Buyer vesting and claim math

Selected schedule: 20% of each buyer allocation becomes available at token launch. The remaining 80% vest continuously over the following 12 months. There is no additional cliff. This schedule guides the contract implementation, testing and independent audit workstream.

Vested(A, t) = A × [0.20 + 0.80 × min(max(t / D, 0), 1)]

Here A is the purchased allocation; t is elapsed time after the launch timestamp; D is the agreed 12-month interval expressed using exact start and end timestamps. Before token launch, vested tokens are zero. Claimable tokens equal vested tokens minus tokens already claimed. Integer rounding must never exceed the allocation; the final claim receives the remainder.

At the maximum sale-vault allocation, 240M LXR would vest over one year: approximately 20M per month. Monthly figures illustrate the linear curve; actual entitlements use elapsed time. Vesting limits release timing but does not guarantee demand, liquidity or price stability.

Whole-sale values above illustrate the maximum 300M reserve. Under the staged model, approximately 295.191M buyer tokens imply 59.038M initially vested and 236.152M vesting over the year. Actual entitlements use confirmed purchases.

17. Buyer allocations: purchase and vesting examples

The following buyer examples use the Stage 5 price of 0.01 USDC per LXR. Actual purchases use the current stage, including split pricing at boundaries. After the full raise, the product launches first and Lixir follows; token launch begins 20% initial release and 80% continuous vesting over 12 months.

Allocation A = credited USDC / 0.01; initial unlock = A x 20%

17.1 Worked 1,000 USDC purchase

100,000 LXR are allocated. At token launch 20,000 become vested. The remaining 80,000 vest continuously: approximately 6,666.67 LXR per month-equivalent. After three months 40,000 are vested; after six months 60,000; after nine months 80,000; after twelve months the full 100,000.

At month 6: 100,000 x (20% + 80% x 6 / 12) = 60,000 vested LXR

If the buyer has already claimed 25,000 LXR by month six, the next available claim is 60,000 - 25,000 = 35,000 LXR. Claims use elapsed time and exact timestamps, with integer rounding and final remainder handling.

17.2 Whole-sale release

At the maximum 300M sale-vault allocation: 60M unlock at token launch and 240M vest across the following year. At month six, 180M are cumulatively vested. Liquidity and other reserve releases are separate policies and also affect circulating supply.

The purchase values illustrate allocation arithmetic; final contribution limits and eligibility will be published with the sale terms. Buybacks and burns do not change a buyer’s original purchased allocation or vesting schedule.

18. The full raise must be met

Success requires the full 3,000,000 USDC target credited to escrow. The seven-stage price schedule allocates approximately 295.191M LXR within a 300M sale-vault ceiling. Confirmed funding, stage-boundary splitting, rounding and vault limits are enforced together.

18.1 Sale timing and launch announcements

Launch dates and remaining product details will be announced as the presale progresses. Separately, an enforceable sale closing timestamp, cancellation policy and refund process must be set before contributions open. Otherwise, an unsuccessful raise could hold funds indefinitely. After a successful raise, the agreement must also address prolonged non-delivery, use of reserves and buyer remedies; this paper does not promise refunds after proceeds have been spent.

18.2 SOL and USDC payments

USDC settlement is proposed to keep the price and funding condition consistent. A buyer may ultimately be able to start with SOL, but the final system must use a reviewed conversion route or oracle design. Contributions should count only the amount actually credited to escrow after conversion; slippage, fees, expiry and failure behavior must be explicit. The conversion route is part of the payment-integration workstream.

The presale workstream covers sale timing, buyer limits, operating structure, eligibility, program deployment and token mint setup. Verified addresses and purchase instructions will be published when the payment system opens. The contract development plan includes escrow, refunds and the selected vesting schedule.

19. Publication milestones

The checkpoints below set out the planned publication of verification, audit and delivery evidence. The $50,000 checkpoint is selected for project/team KYC and the presale smart contract audit; the later percentage checkpoints remain proposals. Each checkpoint update will include the actual review status and supporting evidence.

19.1 Audit language must match the evidence

Publish the scope, version, reviewer, report date and remediation status when available. A scoped code review is not an audit of the entire exchange, proof of solvency, regulatory approval or a guarantee. Publish the actual report only with the reviewer’s permission and after handling security-sensitive material.

19.2 KYC information and security controls

Project/team KYC verification is planned at $50,000 raised. Publish verification status and provider evidence without identity documents. Exchange customer KYC/AML publications describe provider arrangements, required checks and operational status. Do not publish customer identity documents or personal records. A provider contract does not establish that onboarding controls are integrated or effective. Required presale buyer checks must operate before an affected buyer can contribute; later milestones refer to exchange onboarding.

19.3 Escrow remains protected

Reaching $50,000 or the $650,000, $1.3M or $1.95M checkpoints does not release sale funds. Work and publications during an all-or-nothing raise need separate pre-sale resources. Only full, valid funding and successful finalization can enable release under the final contract. Launch dates and remaining details will be published as the presale progresses; the readiness pack will report the conditions for opening.

20. Use of the raise

These planning allocations total $3M. The extra $400,000 is assigned to liquidity/market operations; all other dollar budgets stay unchanged. Displayed percentages are rounded. Supplier quotes and delivery costs will refine these planning envelopes. If approved, releases should follow contracts, invoices, recorded approvals and a published reporting policy. Escrow release is conditional on successful finalization.

Engineering covers staff, contractors, spot/futures integrations and challenge systems. The budget workstream includes cost validation for the combined platform, company trading capital and prop payout reserves. Security covers audits, testing and infrastructure. Legal/compliance/operations covers professional advice, required setup, administration and financial controls. Liquidity is company capital reserved for a documented market-operations policy; it is not customer money or a promise to support the token price.

Legally permitted spending depends on the issuer structure, jurisdiction, offering classification and binding sale terms. A published budget does not make a use lawful by itself. Founder or staff compensation can be considered only as disclosed, reasonable, documented business remuneration with the required approvals and tax treatment. Do not treat the raise as personal spending money or an automatic dividend pool.

Customer deposits, sale escrow, operating treasury and buyback funds should have separate accounting and controls. Material budget changes and related-party spending require a defined approval and disclosure process. Obtain jurisdiction-specific legal and accounting advice before collecting or using proceeds.

21. Revenue, buybacks and possible burns

Bitlixir is considering purchases of LXR funded by platform trading-fee revenue after the exchange is operational. The allocation rate, eligible revenue, cadence and reserve controls are being developed for publication alongside the operating policy. VIP discounts will reduce fee revenue and must be included in the model.

Buyback budget B ≤ min(α × eligible net fee revenue, available cash above required reserves)

The eventual policy must define net fees after rebates, referrals and provider charges; the allocation rate α; operating and tax reserves; execution venues; conflict controls; and public reporting. Buybacks must not use customer balances or failed-sale escrow. The proposed model funds them from earned platform revenue, not from recycling the presale into artificial demand.

Sensitivity illustration: if eligible net fee revenue were $100,000 and α were 10%, the maximum fee-based budget would be $10,000 before reserve constraints. At assumed prices of $0.005, $0.01, $0.02 and $0.04, that would purchase 2M, 1M, 0.5M or 0.25M LXR respectively, before execution costs. These are scenarios, not forecasts or policy commitments.

21.1 A burn is permanent; the program can be periodic

Bought tokens could be held in treasury or a disclosed portion could be burned. A genuine Solana token burn permanently reduces the token balance and supply. The buyback-and-burn policy could be limited in duration or paused under disclosed rules, but an executed burn cannot be reversed. If the intention is temporary supply removal, use a time-locked reserve instead and do not call it a burn. Burn allocations and scheduling form part of the token-policy workstream. [1]

22. Delivery plan and controls

22.1 Policy publication workstream

Confirm the final price denomination, sale deadline, contribution limits, refunds and post-success delay terms; approve reserve vesting and budget; specify discount/VIP eligibility; decide whether a buyback policy is discretionary and whether burns are intended. Marketing and sale terms must match the implemented contract.

22.2 The next technical step

Finalize the sale state machine before coding: full target, deadline, cancellation, successful finalization, escrow release, buyer refunds and vesting. Then compile and test the program. The contract redesign will apply these requirements to escrow, refunds and claims.

23. Accountability and technical references

23.1 Risk and accountability

Risks include total loss, product failure, delays, custody or key compromise, contract defects, illiquidity, market volatility and changing legal requirements. Announced schedules remain subject to disclosed delivery risks. There is no guaranteed listing, return, buyback or VIP entitlement. These limitations do not waive applicable rights or permit misleading statements.

23.2 Operator and jurisdiction

The operating structure and jurisdiction form part of the business workstream. The responsible seller, governing terms and support contact will be published before payments open, with product access aligned to applicable requirements.

23.3 Technical reference

[1] Solana, Burn Tokens: solana.com/docs/tokens/basics/burn-tokens.

[2] Coinbase, Funding rates: help.coinbase.com/en/coinbase/derivatives/funding-rate. [3] CME Group, Calculating Futures Contract Profit or Loss: cmegroup.com/education/courses/introduction-to-futures/calculating-futures-contract-profit-or-loss. These explain general mechanics; Bitlixir account terms will define its implementation.

This litepaper presents the Bitlixir product plan and token model. A full whitepaper will follow with expanded specifications and operating policies. Deployment, testing, independent reviews and verified transaction evidence will be published through the delivery workstream. Final sale terms and operating policies will accompany the relevant product releases.