TL;DR

Xeon Protocol is pioneering advanced liquidity unlocking and risk management tools for ERC-20 tokens.

We provide investors with OTC tools to unlock liquidity from their tokens, or manage risk. Investors can use any ERC-20 token as collateral for a loan / cash advance. Investors can hedge or speculate any ERC-20 token using Call Options, Put Options, or Equity Swaps.

With a holistic approach to deliver support for any ERC-20 token on every capable blockchain, and through modern user experiences. Our tools will be served through multiple interfaces; web, social apps, and dedicated apps. With plans to integrate AI to augment the Defi experience.

We are on a mission to build an investor-focused ecosystem of DeFi tools that support liquidity unlocking and risk management for any token on every blockchain.

Dollar-Sized Potential of our Total Addressable Market

By exploring the TAM, we can better understand the scope of opportunity that lies ahead for Xeon Protocol and its token holders. This analysis will not only highlight the potential market size in dollar terms but also shed light on the growth opportunities.

ERC-20 Dominance and Market Opportunity

The ERC-20 standard dominates the blockchain space, accounting for over 74.87% of the total value locked (TVL) across all blockchain platforms, approximately $80.05 billion. This substantial market represents a vast opportunity for Xeon Protocol to leverage its liquidity unlocking tools and capture significant value.

Market Size Represented by ERC-20 Trading Volume

With a daily trading volume of over $3.8 billion, ERC-20 tokens highlight the size and activity of the market we support. Tapping into this volume, Xeon Protocol can provide advanced liquidity management solutions, enhancing trading efficiency for users.

Total Liquidations and Liquidatable Assets

The EVM DeFi space has seen over $1.5 billion in total liquidations, with many assets still liquidatable. Xeon Protocol’s risk management tools can effectively tap into this market, optimizing asset liquidation processes and safeguarding investments.

Invest in the Future with XEON Token

By investing in the XEON token, you access tools that unlock liquidity and manage risk across these vast markets. Join us and capitalize on the future of decentralized finance.

Our ecosystem comprises of 4 pioneering OTC platforms:

• Neon Lending

• Neon Hedging

• Neon Swaps

• Neon Farming

Each platform comprises of products that serve specific use cases. Use cases for each product/tool are shown on next page.

With an initial focus on ERC-20 token standard, we offer the following tools to enable liquidity unlocking and risk management:

XEON Defi Tool Suite:

Utility on the right,

1. Lending | Liquidity unlocking

2. Options Trading | Hedging & Speculation

3. Equity Swaps | Risk management & Speculation

4. OTC Swaps | Risk management

Use cases can be mixed in all product offerings depending on traders OTC risk tolerance.

ERC20 Tools

Lending / Borrowing

• Deposit any ERC-20 token and use it as collateral for a Defi cash advance.

Options Trading

• Trade ERC-20 backed Call and Put Options.

Equity Swaps

• Swap rights to gains or losses on a ERC-20 for a duration of time.

OTC Swaps

• Sell or Buy ERC-20s OTC without using a Dex.

Our flagship product is the Lending tool, the pioneer product during public Testnet.

A visualization of how the protocol is intended to streamline processes towards various goals.

Equity Swaps allow parties to swap limited reciprocal loss or gains for a period of time.

Exchange exposure on a bag of tokens with another party for a duration of time. Both gains and losses on the underlying assets belong to the Equity Swap buyer/taker at the end or expiry. Payoff is paid in underlying tokens if taker/buyer is in profit, and in quote currency when the writer is in profit. This is because equity swaps are also bought in quote currency of the underlying token.

In the normal world, getting a loan involves putting up collateral, receiving liquidity, and having your assets held by the lender. With equity swaps, instead of getting liquidity, you pass on the gains from your assets, locking in their value at a fixed amount for a set period.

Read PL/ Calculations for a deeper understanding into settlement.

Equity Swap Features:

• Underlying asset or tokens being swapped, the collateral.

• Start price valued in quote currency of the underlying token.

• Expiry date or duration.

• Cost to buy hedge, quoted in quote currency of the underlying token.

When swapping exposure on a bag of ERC20 tokens with equity swaps:

• Both parties have to provide equal collateral.

• Gains are limited to 100% of one party's collateral.

• Losses are limited to 100% of one party's collateral.

• Settlement is processed in quote currency of the underlying token.

Screenshot

Example, scroll to Equity Swaps.

• Writer supplies ERC-20 collateral when writing the Call Option.

• Writer dictates Cost to Takers.

• Taker pays cost directly to Writer when buying the Call Option.

• Both parties can initiate a request to topup collateral {Topup Requests}.

• Collateral is only moved from both parties balances when the party accepts a request.

• Settlement is only done after the expiry date has passed.

• Equity Swaps cannot be deleted after expiry like Options.

• Both parties can also request to change the expiry from future to current date.

• No caps on deal terms: collateral amount, cost amount, duration and strike price.

Our proprietary DynamicPact features allow for the adjustment of deal terms after the deal has started running. Through Zap Requests or Topup Requests, parties can consensually modify collateral, costs, and expiry dates.

Once a hedge has been taken or starts running, it can't be cancelled, but our users have the option to modify it mid term in order to manage their trading strategies.

1. Top-up Request

2. Zap Request

Zap Request:

A Zap Request is a handy feature that speeds up settlement by setting the expiry date to the present moment. It's particularly useful when a deal isn't going well, and both parties just want to move on from it. This means they agree to settle the deal immediately, based on the current market prices, and deal with any resulting profit or loss.

Anyone involved in the deal can initiate a Zap Request before it officially expires. However, it only becomes official when the other party agrees to it, a process known as Zap consensus, which updates the expiry date to the present.

Users must note that accepting Zap Requests is entirely voluntary; the other party can't be compelled to comply.

Topup Request: Strengthening Collateral

A Topup Request allows for the addition of more collateral to the deal, whether it's by increasing the amount of the underlying asset or raising the cost. Either party in the deal can request a topup from the other.

If the request is accepted, the necessary collateral is deducted from both parties' balances and securely locked into the deal, ensuring a solid collateral position.

This is the logical approach we expect investors to have when viewing trades on our platform.

Taker Perspective

Call Option

Take the right to buy XXX tokens from Writer for xxxx if price goes above xxx in the next xxx days. Profit increases for taker as price goes higher. Profit is the difference in strike and market value. Loss is premium paid (in quote currency) to writer, if price is below strike price at expiry.

Put Option

Take the right to sell XXX tokens to Writer for xxxx if price goes below xxx in the next xxx days. Profit increases for taker as price goes lower. Profit is the difference in strike and market value. Loss is premium paid in quote currency) to writer, if price is above strike price at expiry. If price goes in anticipated direction, the difference between strike price and current price is the profit per token for the Taker.

Equity Swaps

Take full value exposure to the underlying tokens, XXX, offered in trade by Writer. If price goes up, gains belong to the Taker. If price goes down, losses belong to the Taker. During the duration of a swap, profit is uncapped and depends on how the underlying tokens swapped soar in price. Loss is capped to the maximum value of collateral/premium you deposit to take the swap.

Writer Perspective

Call Option

Offer guarantee to sell XXX tokens to Taker for xxxx if price goes above xxx in the next xxx days. Loss increases for Writer as price goes higher. Loss is difference in market value and strike value. Profit is premium paid (in quote currency) by Taker, if market price is below strike price at expiry.

Put Option

Offer guarantee to buy XXX tokens from Taker at market if price goes below xxx in the next xxx days. Loss increases for Writer as price goes lower. Loss is difference between strike and market value. Profit is premium paid in quote currency) by Taker if price is above strike at expiry. If price goes in anticipated direction, the difference between strike and current price is the profit per token for the option Taker.

Equity Swaps

Offer full value exposure to the underlying tokens, XXX, in trade to Taker. If price goes up, gains belong to the Taker until expiry or settlement date, Writer is locked in or guaranteed at Taker collateral value. Likewise, if price goes down, losses belong to the Taker. If value of Takers collateral is equal or less than the value to be compensated to Writer, then the Swap is settled liquidating all the Takers collateral.

Trade Loss Perspective

Underlying assets or tokens refers to the ERC20 tokens placed in the trade by the writer.

• Premium and Loss to Taker is always paid in the quote token of the underlying asset.

• Profit to Taker is always paid in underlying assets in the trade.

• Loss to Writer is always settled in the underlying assets.

• Profit to Writer is always paid in the paired currency of the underlying assets.

Unique Selling Points

• No Liquidation:

  • Unlike other protocols, you can ride through volatility without the risk of liquidation. Each deal carries a max loss for both parties that come into effect only at expiry or when the deal is exercised.

• Isolated Risk Silos:

  • Assets and liquidity are utilized on a per-deal basis, at the discretion of the user, ensuring localized risk management.

• OTC Customization:

  • Traders agree to terms on a peer-to-peer basis, with customizable parameters such as APY, duration, and more. All conditions are mutually agreed upon by the parties involved.

• Freedom Enhancing Features:

  • Our proprietary DynamicPact features allow for the adjustment of deal terms after the deal has started running. Through Zap Requests or Topup Requests, parties can consensually modify collateral, costs, and expiry dates.

• No Supply Caps:

  • We impose no caps or limitations on the amount of assets or liquidity that can be deposited or utilized in a deal, providing unparalleled flexibility.

• Ever-Expanding Support:

  • Beyond ERC-20s, we will support all tokens on our deployed blockchains and offer interfaces on Web, Farcaster, and Telegram. Leveraging AI, our products will provide an exceptional DeFi experience.

    By integrating Real World Asset (RWA) projects as asset providers, we will tap into real-world volume, expanding DeFi's reach like never before and bridging traditional and decentralized finance.

Defi is split between lending and the risk management, the two pillars for any healthy market. However platforms offering these tools mostly cater for less volatile assets, majors and stables. Whilst being extremely restrictive and dull.

Imagine unlocking liquidity from any ERC-20 token in a seamless, modern experience designed for 2024. XEON is poised to lead the way, pioneering next-gen tools for the ultimate DeFi experience.

In 2024, ERC-20 tokens dominate crypto, with billions of dollars expected to flow through them in the coming months. The demand for modern, freedom-enhancing DeFi solutions is at an all-time high.

Join us as we revolutionize ERC-20 liquidity management with XEON.

Our Approach

If your favorite meme coin, launched just last week, isn't available on mainstream DeFi platforms like Aave, it's likely due to their protocol limitations. These limitations include supply caps, predetermined APYs, and LTVs. Xeon Protocol, on the other hand, imposes no restrictions on ERC-20 supply. You can deposit any amount and set any terms for your liquidity.

Advanced OTC Mechanisms

Instead of utilizing pools and creating protocol risk, which inherently imposes systematic restrictions on trading, we sidestep these norms. We employ advanced OTC mechanisms that permit targeted asset utilization in deals. Thereby localizing risk to two parties, eliminating liquidation triggers caused by price volatility and allowing for custom (per-deal) APYs in every deal. We believe this approach enhances trading freedom for ERC-20 investors.

Enhanced Freedom

Xeon Protocol is focused on delivering freedom-enhancing Defi tools, an alternative to simply swapping tokens on Dex to manage your portfolio—which immediately realizes gains or losses. With Xeon, you are able to put those tokens into an equity swap, put/call option, or lend them out, allowing you to manage risk without sacrificing future growth potential.

Additionally, some ERC-20 tokens may have low liquidity, and directly swapping them may incur high slippage. Xeon allows you to easily place OTC swaps that bypass the limitations of liquidity pools, enabling more efficient and flexible trading.

This protocol earns and rewards it's investors only using Real Yield. The following streams of income exist for XEON Protocol;

• Buy/Sell Tax

• Cashier Fees - We charge a withdrawal fee on major tokens.

• Settlement Fees - We charge a settlement fee on all payoffs.

• Cancellation Fees - We charge a cancellation fee on expired un-exercised options.

• Premium Services Subscription - We will token gate premium product features.

• Commission from Native Hedge Liquidity.

• Commission from Native Loan Collateral.

Buy /Sell Tax

XEON token will be traded on DEX with buy and sell fees for every swap. These fees help support our ecosystem growth, as is the standard these days.

Cashier Fees

All ERC-20 token withdrawals are taxed by the protocol. They are converted to WETH or ETH and allocated towards revenue sharing just like #buy-sell-tax above.

Settlement Fees

Settlement fees are collected upon the finalization of a deal within our platform. These fees are designed to be automatically deducted from the payoff amount only, not the collateral in the deal.

Cancellation Fees

Any deals that are cancelled or deleted after they expire incur a fee similar to the settlement fee.

Premium Services Fees

Our ancillary services like AI assistants are token-gated, premium features will be accessible for a fee.

Commission - Hedge Liquidity

By enabling projects and their investors to hedge their native token on our protocol, we add value to their ecosystem and in turn charge a fee on the settlement pay-offs.

See Native Hedge Liquidity

Commission - Loan Collateral

By enabling projects and their investors to use their native tokens as loan collateral on our protocol, we are able to bring native lending volume from almost any ERC20 token to our protocol. In turn we charge a fee on the settlement pay-off.

See Native Loan Collateral

XEON stakers are rewarded for simply staking tokens on our protocol. To earn additional rewards, stakers are advised to assign their staked tokens to a farming pool of choice. As stipulated in Quick Guide.

The protocol leverages its technology to generate real yield that it will bring back to investors for sharing. In the case of assigned tokens, only the assigned tokens are able to claim a share of the rewards attributed to the farming pool.

Xeon protocol relies on Real Yield to reward its investors, as stipulated here Protocol Income

Reward Distribution

Protocol revenue is not distributed automatically to all stakers. Instead stakers should claim manually a share of the revenue, based on the share of tokens staked in the whole pool.

• rewards are converted to ETH an distributed through the staking contract.

• stakers have to assign tokens to a pool before rewards are sent there for claiming.

• reward distribution will be done monthly for general staking, and is subjective for farming pools assignable.

• rewards from each farming pool have to be claimed manually, one by one on each relevant pool.

All revenue or proceeds made by the protocol is send to the staking contract for distribution.

There are two types of Native Hedge Liquidity Pools:

• Native Equity Swaps

• Native Options

Native Equity Swaps

A project can use its pooled tokens to write native equity swaps. This means the project on behalf of its investors who assigned tokens, is the writer, and will take full liability or risk on the outcome of those equity swaps.

We rely on projects having their own farming strategies and farmers to write these native equity swaps.

Example:

Xeon Protocol assigned farmers can identify demand for our token, beyond a price they deem reasonable based on the stage we are, in the crypto market cycle.

The farmers assess that we are in a bull market for the next 6 months maximum then we trend downwards, and that offering equity swaps with a duration of 1 year may be lucrative, carrying minimum to no risk.

XEON investors can stake tokens and assign them to a XEON hedge liquidity pool.

The farmers then write Equity Swaps with XEON as underlying asset for a duration of 1 year, pricing the option based on lucrative OTC rates.

Conclusion:

The goal for Xeon Protocol and its investors is to pass the downside risk to the taker, if the price of XEON is below the start price or value when the swap expires in 1 year.

Native Options

A project can use its pooled tokens to write native call or put options. This means the project on behalf of its investors who assigned tokens, is the writer, and will take full liability or risk on the outcome of those options.

We rely on projects having their own farming strategies and farmers to write these options.

Example:

Xeon Protocol assigned farmers can identify demand for Put Options of our token (XEON as underlying asset).

The farmers assess that we are in a bull market for the next 2 years minimum, and that these put options with a duration of 1 year appear lucrative with minimum to no risk.

XEON investors can stake tokens and assign them to a XEON hedge liquidity pool.

The farmers then write Put Options with XEON as underlying asset for a duration of 1 year, pricing the option based on lucrative OTC rates.

Conclusion:

The goal for Xeon Protocol and its investors is to profit from the cost paid by the option takers, if the price of XEON is above the strike price or value when the option expires in 1 year.

XEON holders can stake their tokens to both empower the protocol whilst also earning rewards for their contribution to the protocol's growth.

Staking XEON tokens enables us to define clear farming strategies available for our investors.

We have a separate staking contract for our native token NEON. Enabling wallets to:

• Stake XEON

• Assign Staked XEON

• Unassign Staked XEON

• Unstake XEON

Stake XEON

Our Beta approach to staking locks the staking pool in 30 day cycles. During which staking, unstaking, assigning and unassigning is disabled. This simplifies staking and gives the protocol the ability to create fixed term investments in the ecosystem using the staked tokens.

30 day cycles are then followed by 3 day stakeWindow periods before another 30 day lock cycle begins. The 3 day windows are called stakeWindow. During which staking, unstaking, assigning and unassigning is allowed.

The owner starts this contract once and it gives investors 3 days to stake and assign tokens before the 30 day lock cycle starts.

The owner is the only one who can set a new nextUnstakeDay - which is the day the next 30 day cycle expires. This can only be done once during the stakeWindow.

Assign Staked XEON

Only during stakeWindow.

After a wallet stakes tokens, you then need to decide which assignment pool you want to assign a specific portion of your staked tokens to.

Investors can assign tokens to use in:

• Liquidity - Native Equity Swaps and Options Liquidity

• Collateral - Lending collateral for the protocol to access funding in the ecosystem.

• Mining - Incentivizing how hedges / trades / deals are awarded to a miner for settlement.

By assigning tokens you then earn a portion of the revenue generated by tokens in that pool. See revenue for how it is generated and moved for sharing.

Investors determine whats lucrative for them based on the earning prospects of each pool. The pools are created in such a way that investor tokens are not at risk as they earn.

Assigned tokens are staked first, this means you still earn general staking dividends.

Unassign Staked XEON

Only during stakeWindow.

Investors can pull out of assignment pools and have tokens back in the general staking pool. You will lose all income from the pools your tokens were assigned to, but still earn general staking dividends.

Tokens are still staked at this point.

Unstake XEON

Only during stakeWindow.

A wallet can unstake tokens from our smart contract only during stakeWindow, and have them moved into their wallet.

In a bid to maximize the revenue generated, XEON Protocol aims to provide Native Token Hedging, for both individuals (XEON investors) and outside projects.

The aim is to provide projects and their investors with the means to hedge their ERC20 tokens for profit or risk management. This service has an industry wide scope to create and capture the hedge volume of all projects that have native ERC20 tokens on Dexes.

XEON Holders

Xeon token holders will be the first to have the ability to stake their XEON tokens and then assign them to a hedge liquidity pool. By doing this they are providing native hedge liquidity for our protocol. This means that XEON protocol, through our farming strategists, will use the staked tokens as collateral and write equity swaps or call options, with the intention of bringing the profit or proceeds back to the investors who assigned tokens to the native hedge liquidity pool.

Example

XEON Protocol, with the approval of the investors who stake and assign tokens to the native hedge liquidity pool, can write a native equity swap for 1 year, during a period when we anticipate our token price will decrease in value.

This means that if XEON token's price falls by 50% during that one year, that loss is compensated by the taker of the native equity swap. However if the price increases then the loss belongs to the stakers who assigned tokens to the native hedge liquidity pool.

As such, native equity swaps written by the protocol will be managed by professionals who can bring the best and safest farming results for out investors.

Outside ERC20 Tokens

In addition to providing native hedge liquidity functionality to XEON investors, we will expand this feature to also support other projects who wants to use this farming strategy for their own token investors.

Other projects can bring their own native ERC20 tokens to our protocol, and have the ability to stake their ERC20 tokens and then assign them to a hedge liquidity pool under their token address. By doing this they are providing native hedge liquidity for their token using our protocol. This means that other project owners / famers, will use the staked tokens as collateral and write equity swaps or call options, with the intention of bringing the profit or proceeds back to the investors who assigned tokens to their native hedge liquidity pool.

Example

VELA Protocol, with the approval of the investors who stake and assign tokens to VELA's native hedge liquidity pool, can write a native equity swap for 1 year, during a period when they anticipate their token price will decrease in value.

This means that if VELA's token's price falls by 50% during that one year, that loss is compensated by the taker of the native equity swap. However if the price increases then the loss belongs to the stakers who assigned tokens to VELA's native hedge liquidity pool.

As such, native equity swaps written by VELA are their sole responsibility, and all risk or liability lies with their investors.

This means that the project will be able to use this pool as collateral, and request loans in ETH or other stables for a duration of time, on our lending platform.

Project partnerships are crucial to Xeon Protocol in order to bring as much token variety as possible. This is a win win scenario for us and the projects we partner. They will provide their investors with an value adding risk management services, the project itself in turn will benefit from having more revenue or liquidity for growth.

Pool Collateral

A project can use its pooled tokens as collateral to access loans on our lending platform. This means the project on behalf of its investors who assigned tokens, is the borrower, and will take full liability or risk on the outcome of those loans.

We rely on projects having their own farming strategies and farmers to write these. Each project depending on its intended use of the borrowed liquid cash, will repay and reward its collateral poolers using other revenue streams.

Example:

Xeon Protocol assigned farmers can identify demand for Put Options of our token (XEON as underlying asset).

The farmers assess that we are in a bull market for the next 2 years minimum, and that these put options with a duration of 1 year appear lucrative with minimum to no risk.

XEON investors can stake tokens and assign them to a XEON hedge liquidity pool.

The farmers then write Put Options with XEON as underlying asset for a duration of 1 year, pricing the option based on lucrative OTC rates.

Conclusion:

The goal for Xeon Protocol and its investors is to profit from the cost paid by the option takers, if the price of XEON is above the strike price or value when the option expires in 1 year.

Overview:

This platform caters to a wide audience by offering the flexibility to support any ERC-20 token as collateral. Users have the option to either lend or borrow, setting custom terms for each deal. This includes specifying the duration of the loan, the expiry date of the offer, the tokens requested in return, and the interest rate. Such personalized loan deals help match lenders' risk tolerance with borrowers' needs, ensuring mutually beneficial agreements.

Benefits:

1. Versatility: Accepts any ERC-20 token as collateral.

2. Customization: Tailor loan terms to suit individual requirements.

3. Transparency: Clear terms and conditions prevent misunderstandings.

4. Security: Collateral is securely held in a vault.

5. Automation: Validators/miners enforce agreements.

How It Works:

1. Loan Request: Borrowers specify desired terms including collateral type, loan amount, interest rate, and repayment schedule.

2. Review and Approval: Lenders evaluate requests and approve based on their criteria.

3. Agreement: Once both parties agree on terms, the loan is initiated.

4. Disbursement: Borrower receives tokens; collateral is locked.

5. Repayment: Borrower repays loan according to the agreed schedule. Upon completion, collateral is returned.

Lenders review loan requests to determine if they meet their criteria and risk tolerance levels. They can choose to fulfill these requests by agreeing to the borrower's specified terms. Once an agreement is reached, the terms are locked in, and the loan process officially begins. The borrower receives the requested tokens while the collateral remains in the vault as security. Both parties must then abide by the established terms, including repayment schedules and interest rates. This setup ensures transparency and security in the lending and borrowing process.

Lending Tool Features:

• Support for any ERC-20 token as collateral

• Option to lend or borrow

• Set custom per-deal terms:

  • Duration of the loan

  • When the offer expires

  • Tokens requested in exchange

  • Interest rate

Conditions:

• Borrow using any ERC-20 as collateral.

• A borrower has to deposit their collateral into the vault. Then create a loan request for a specific ERC-20 token and amount, at custom terms.

• These are time based loans, with an option for fixed duration loans.

• Loan amount can be in quote currency of the collateral token, or other.

• Collateral is measured at market value for both parties, during the entire loan lifespan.

• Lenders liquidity is transferred to the Borrower immediately, whereas the Borrowers collateral is held in the Vault until settlement.

• Collateral is not automatically liquidated on price volatility, the price can go below a threshold and still recover above it, during the lifespan of a deal. This means that if you put up 1000 GPU tokens as collateral for a 0.3 ETH loan, that will be paid back as 0.6 ETH. On expiry, the GPU tokens only need to have enough value to cover the 0.6 ETH owed, otherwise they are all liquidated to settle the debt.

• This settlement process is synthesized in our settlement function to give the same outcome in one function call, without needing to sell tokens.

Read PL/ Calculations for a deeper understanding into settlement.

A call option gives the taker or buyer of the option, the right, but not the obligation, to buy a specific amount of an underlying asset (in this case, ERC20 tokens) at a predetermined price (strike price) within a specified period (expiration date).

A call option allows the taker to benefit from potential token price increases. If the market price of the token is above the strike price on expiry, the holder can exercise the option, profiting from the excess value between market price and strike price.

Read PL/ Calculations for a deeper understanding into settlement.

Call Option Features:

• Underlying Asset or tokens

• Strike price quoted in paired currency

• Expiry date or duration

• Cost or premium to buy hedge, quoted in paired currency

• Hedge writer always has to provide collateral, thus the payoff (if any) to the taker is always in underlying assets, whereas for writer payoff is always in paired currency of the underlying tokens.

Screenshot

Example, scroll to Call Options.

Conditions of use:

• Writer supplies ERC-20 collateral when writing the Call Option.

• Writer dictates Cost to Takers.

• Taker pays cost directly to Writer when buying the Call Option.

• Both parties can initiate a request to topup collateral {Topup Requests}.

• Collateral is only moved from both parties balances when the party accepts a request.

• Taker only can exercise the option before the expiry date.

• After expiry date has passed, Taker has no right to exercise the option.

• Unexercised options are deleted by Miners or the Writer.

• If a miner deletes an expired hedge a fee is charged to Writer.

• If writer deletes an expired hedge no fee is charged to Writer.

• Both parties can also request to change the expiry from future to current date.

• No caps on deal terms: collateral amount, cost amount, duration and strike price.

Pitch

This platform enables you to unlock liquidity, manage risk, or speculate on any ERC-20 token you own, without selling.

The best use cases for our protocol are liquidity unlocking and speculation.

There are no restrictions to rules, allowing you to freely utilize any hedge or loan type to unlock liquidity from your assets. For instance, you can create a Call Option for and request that Takers pay half the market value of the collateral instead of charging a low cost like 10%. This is all based on the confidence that the underlying asset will more than double during the trade.

Get Current Value of tokens

The primary ability of Xeon Protocol is the ability to value any ERC-20 token in quote currency, as long as they are listed on a DEX that utilizes the standard Uniswap Interface Library.

This happens through the getUnderlyingValuefunction, the core engine of our vault smart contract.

Leveraging this core vault function as the engine, we are able to build tools that enable investors to deposit their ERC20 tokens into our vault and:

• Hedge risk (cover tokens against price drops without selling)

• Speculate (speculate on price movements to accumulate more tokens or its quoted currency)

• Leverage capital (buyers pay for higher exposure than their capital is worth)

• Unlock liquidity (use tokens as collateral to get a loan, LTV is custom/otc)

Conditions:

• We simulate the outcome of a hedge, we don't facilitate traditional hedging procedure.

• Strike Price

• Underlying Value of tokens is the value of tokens * token price in pair currency

• Cost is premium and always in the paired currency of the underlying asset

• No Risk-Free Interest Rate charged

• No Implied Volatility imposed

• Tokens are lockedInUse when a trade is written, or when Taker takes trade.

Call Options

Scenario:

Trade Creation

• Writer, Capo, owns 1000 GPU tokens.

• He is unsure about the price going up further the next 30 days.

• Capo Deposits 1000 GPU to the Xeon Protocol Vault.

• Capo Writes a Call Option using 100 GPU tokens as underlying asset. Cost/premium 0.1 WETH. Duration 30 days. Strike price 2x from now, or strike value 2 WETH.

Trade Taking

• Taker, DegenX, wants exposure to GPU tokens and sees Capo's OTC trade on the Silkroad.

• DegenX is sure GPU will pump in the next 30 days.

• Current market value of 1000 GPU tokens is 1 WETH.

• Strike value of 1000 GPU tokens is 2 WETH.

• DegenX Deposits 0.1 WETH to Xeon Protocol Vault.

• DegenX Buys Capos GPU Call Option, his 0.1 WETH is credited to Capo instantly as Cost. Capo can immediately withdraw it as extra liquidity to buy more tokens.

Trade Running

• GPU soars in price 4X.

• Current market value of 1000 GPU tokens is now 4 WETH.

• Strike price or value is now half of the market value.

• Expiry or trade duration is up.

Trade Settlement

• Capo owes DegenX

Owed = Start Value - Strike Value.

Start Value = Token Price * Token Amount

Strike Value = Strike Price * Token Amount

• Equivalent in GPU

• Settlement function debits owed Profit equivalent in GPU tokens from Capo, credits it to DegenX. The difference is credited back to Capo.

• Trade is concluded.

Put Options

Scenario:

Trade Creation

• Writer, Capo, owns 1000 GPU tokens.

• He is concerned about the potential decrease in price over the next 30 days.

• Capo Deposits 1000 GPU to the Xeon Protocol Vault.

• Capo Writes a Put Option using 1000 GPU tokens as the underlying asset.

• Cost/premium 0.1 WETH. Duration 30 days. Strike price 0.5x from now, or strike value 0.5 WETH.

Trade Taking

• Taker, DegenX, wants to hedge against a potential decrease in GPU token price and sees Capo's OTC trade on the Silkroad.

• DegenX is concerned GPU might dip in the next 30 days.

• Current market value of 1000 GPU tokens is 1 WETH.

• Strike value of 1000 GPU tokens is 0.5 WETH.

• DegenX Deposits 0.1 WETH to the Xeon Protocol Vault.

• DegenX Buys Capo's GPU Put Option, his 0.1 WETH is credited to Capo instantly as the Cost. Capo can immediately withdraw it as extra liquidity to buy more tokens.

Trade Running

• GPU price drops to 0.25x.

• Current market value of 1000 GPU tokens is now 0.25 WETH.

• Strike price or value is now double the market value.

• Expiry or trade duration is up.

Trade Settlement

• DegenX owes Capo

Owed = Strike Value - Start Value.

Start Value = Token Price * Token Amount

Strike Value = Strike Price * Token Amount Equivalent in GPU

• Settlement function debits the owed Profit equivalent in GPU tokens from DegenX and credits it to Capo.

• The difference is credited back to DegenX. Trade is concluded.

Equity Swaps

Scenario:

Trade Creation

• Writer, Capo, owns 1000 GPU tokens.

• He is concerned about the potential decrease in price over the next 30 days.

• Capo Deposits 1000 GPU to the Xeon Protocol Vault.

• Capo Writes a Equity Swap using 1000 GPU tokens as the underlying asset.

• No cost is paid. Duration 30 days.

Trade Taking

• Taker, DegenX, wants exposure to GPU tokens but doesn't want to by them outright because of swap tax & ethereum gas fees. He sees Capo's OTC trade on the Silkroad.

• DegenX is very confident the price will go up in the next 30 days.

• Current market value of 1000 GPU tokens is 1 WETH.

• DegenX Deposits 1 WETH to the Xeon Protocol Vault to match the value and take the Swap.

• DegenX takes Capo's GPU EquitySwap for 1000 GPU tokens, his 1 WETH is locked in as collateral the same as Capo's GPU tokens.

Trade Running

• GPU price soars 10x.

• Current market value of 1000 GPU tokens is now 10 WETH.

• Expiry or trade duration is up.

Trade Settlement

• Capo owes DegenX

• The difference is taker payoff, calculated in GPU tokens and credited to DegenX's balance.

• DegenX 1 WETH collateral in the Swap is also unlocked and credited back to withdrawable balance.

• Capo receives the balance of the GPU tokens left after settlement to DegenX.

Note: If the price was to go down 10X, then DegenX would owe Capo

Xeon Protocol is written in Solidity to run on the blockchain as the database and processor of all transactions. The investors use the Dapp website front end to interact with the protocol at all times.

The entire protocol is custom built specifically for ERC20 hedging and lending, undergoing continued iterations and improvements. The Illustration above may not be the final.

Overview

A Put Option gives the taker or buyer of the option, the right, but not the obligation, to sell a specific amount of an underlying assets (ERC20 tokens) at a predetermined price (strike price) within a specified period.

A put option provides a form of insurance or hedging against potential price declines.

The ERC-20 Put Options tool enables users to write and take put options using two different tokens: a base token for the writer and a quote token for the taker. Specifically, the writer uses the base token as collateral, and the taker pays with the quote token. If the taker profits (the market price of the base token drops below the strike price), the payoff is deducted from the writer's collateral.

Read PL/ Calculations for a deeper understanding into settlement.

Put Option Features:

• Underlying assets or tokens to be used as collateral.

• Strike price quoted in pair/quote currency of the underlying token.

• Expiry date or duration.

• Cost or premium to buy hedge, is priced in quote currency of the underlying token.

• Hedge writer always has to provide collateral, thus the payoff (if any) to the taker is always in underlying assets, whereas for writer payoff is always in quote currency of the underlying tokens.

Screenshot

Example, scroll to Put Options.

Conditions of use:

• Writer supplies ERC-20 collateral when writing the Call Option.

• Writer dictates Cost to Takers.

• Taker pays cost directly to Writer when buying the Call Option.

• Both parties can initiate a request to topup collateral {Topup Requests}.

• Collateral is only moved from both parties balances when the party accepts a request.

• Taker only can exercise the option before the expiry date.

• After expiry date has passed, Taker has no right to exercise the option.

• Unexercised options are deleted by Miners or the Writer.

• If a miner deletes an expired hedge a fee is charged to Writer.

• If writer deletes an expired hedge no fee is charged to Writer.

• Both parties can also request to change the expiry from future to current date.

• No caps on deal terms: collateral amount, cost amount, duration and strike price.

Critical Dynamics of Collateral and Payoff:

• Collateral Depletion:

  • The writer's collateral continuously declines as market conditions favor the taker.

  • The collateral is used to cover the difference between the market price and the strike price, effectively paying the taker the profit.

• Profit Increase:

  • The taker's profit grows as the market price of the base token falls below the strike price.

  • This profit is realized when the taker exercises the put option.

Break-Even Threshold:

• Timing is Crucial:

  • Takers must be vigilant about the declining collateral value.

  • They must exercise their rights to the option before the writer's collateral drops below a certain break-even threshold. If the collateral value falls too low, there may not be sufficient funds to cover the payoff, leading to potential losses for the taker.

XEON Protocol harnesses its unique features to offer yield farming opportunities for our native token holders as well as for holders of other projects' native tokens. Check out to learn about how we maximize revenue generation by providing hedging services and pools to other projects.

We generate real yield through the following approaches:

Native Hedge Liquidity

This facility is available for both XEON token holders and other projects. This means investors of any ERC20 token can stake their tokens using our smart contracts and then assign them to a farming pool called Native Hedge Liquidity Pool or ERC20 Hedge Liquidity Pool, where ERC20 represents the project's token address.

In this pool, tokens are used as hedge liquidity by the project farmers or owners, to write native hedges on the OTC market using our hedging platform.

Native Loan Collateral

This facility will be available for both XEON protocol and other projects. This means that investors of any ERC20 token can stake their tokens using our smart contracts, and then assign them to a farming pool called Native Loan Collateral Pool or ERC20 Loan Collateral Pool, where ERC20 represents the project's token address.

In this pool, tokens are used as collateral by the project farmers or owners, to borrow money on the OTC market using our lending platform.

Visit the Testnet page.

Claim Testnet tokens of your choice.

Optional step - Browse through Testnet versions.

Optional step - Jump to testnet version page for full version information.

Go to Dapp

Go to Wallet page

Go to Cashier

Fill Cashier Deposit Form

Approve tokens

Deposit tokens to Vault

View new token balance

Go to Silkroad.

Fill trade form.

Write trade

View trade on deal page

Send Topup Requests or Zap Requests to other party to manage the deal during its lifespan.

Real Yield details how we designed the protocol to be self sufficient whilst also rewarding the investors who bring the volume to the protocol.

In this section we will cover the 4 areas where the protocol collects fees.

• Cashier

• Settlement

• Dex

XEON Protocol is made up of multiple smart contracts deployed on the blockchain. As such when hedges or loans are written, a call has to be initiated on the settlement function when the deal expires.

To fill this gap, the protocol employs miners to initiate deal settlement and earn a commission for it. This is called Hedge Mining.

Qualification

To qualify as a hedge miner, the following is required:

• Be a XEON investor

• Stake XEON tokens

• Assign the required minimum amount of XEON to the Mining Pool. Amount assigned buys mining rights in proportion the whole mining pool.

After meeting this criteria, a wallet is now considered an eligible miner. This means;

• Miner can earn a commission from each deal they settle

• Miner earns fees in underlying token or paired currency of underlying token

• Claim or withdraw commission accrued into their wallets

Mining Criteria

• Miners can choose which hedges or loans they want to mine based on personal preference to underlying tokens in the deal. Hedges of popular tokens can find themselves being settled faster than those with unpopular tokens.

• The amount of tokens assigned by miner to qualify, determines the sizes of hedges the miner get to settle. There are hierarchies, a wallet with the lowest amount of tokens assigned cannot be granted the same volume of deals as a wallet with the largest assignment.

• Deals are mined as soon as they expire, there are no reservations.

Miners earn a commission proportional to the pay-off or settlement value. As stated in How to Earn supposed the settlement fee charged by the protocol is 5% the payoff. Then 15% of that 5% will be awarded to the minder during a hedge settlement. Whilst the rest goes to the protocol as revenue earned.

Mining Example:

We generate real yield through the following approaches:

In addition to the farming pools mentioned in the previous chapter, investors in XEON can also earn additional income based on real yield, as follows;

As XEON investors

In addition to the farming pools and methods explained in Farming Pools, XEON investors can earn a share of the protocol revenue through:

• Staking XEON Tokens

• Mine or Settle Hedges and Loans

Staking XEON Tokens

We reward investors for simply holding our token and enabling us to operate. XEON investors should stake their tokens on our staking smart contract in order to be eligible for the monthly revenue sharing.

See Use Cases on how to stake and earn as a XEON investor.

Mining / Settling Hedges

Smart contracts do not self execute. This means for a protocol like ours whereby hedge or loan deals have a future expiry date, someone has to settle the deal in order to officially conclude it.

Settlement is the process of taking a hedge or loan deal, assessing its constants and then determining the outcome to execute for both parties.

Constants factored in during settlement are; start value, current value, expiry date and the pay-off or loss for each party.

Xeon Protocol taxes all hedge proceeds, in the base or paired currency. This tax is on the payoff only not the underlying value of the hedge or loan.

On maturity or expiry date, a hedge miner or settler takes the deal and executes it. The proceeds are moved from loser to winner and the protocol takes its cut in taxes. The hedge miner in turn also takes 15% of the protocol's cut, meaning that net gain to the protocol is 85% of the settlement fees.

Providing Native Hedge Liquidity

Stake your favorite tokens on our staking contract, and assign them to a liquidity pool of your choice. Xeon Protocol uses native liquidity pools to write fixed term or seasonal deals for the OTC market. Projects have to farm the native liquidity pools with their project tokens for extra income to the project.

As Project Partners

We invite projects to partner with Xeon Protocol and provide hedge and lending liquidity for their own token investors.

Projects that have native ERC20 tokens can farm yield for their own investors as stipulated in Farming Pools.

Using the paired currency of the underlying assets as stated in the previous chapter, we built an engine to allow us to get the value of any token holdings in their DEX pair. This is called the underlying value in our protocol.

This enables our protocol to put value on:

• Collateral

• Cost / Premium

• Payoff and Fees

This also enables the protocol to have support for:

• Custom LTV calculations

• Max loss calculations

• Custom Liquidation models

Max Loss Calculations

Collateral value is fed into the settlement function to determine the maximum loss a buyer or writer can incur in a deal.

Options - The max loss possible for Taker is the cost paid. To writer its capped by collateral value.

Swaps - The max loss is based on the value of the collateral provided.

Custom LTV Calculations

Our OTC lending platform allows parties to set or agree on custom LTVs when issuing loans.

Collateral value is fed into the Loan writing or taking functions, enabling parties to gauge the distance or gap in value between the loan and the collateral tokens provided.

Custom Liquidation Models

For all hedges, collateral value only comes into question when Taker chooses to exercise right. The protocol only checks payoff and collateral value upon settlement. This means collateral value can go below and back above the liquidation level during the lifetime of a deal.

In normal hedging, the pricing of options is typically done using various mathematical models. In the case of ERC20 tokens traded on DEXes, these tokens are capable of moving 100% in one day, the implied volatility can be quite high. Binomial or Monte Carlo are the best simulation methods. These models can handle variable volatility more effectively.

The Black-Scholes model assumes constant volatility, which might not be suitable for highly volatile tokens.

To calculate the call option cost using these models, you would typically consider the following inputs:

1. Underlying Token Price: The current price of the ERC-20 token.

2. Strike Price: The agreed-upon price at which the call option can be exercised.

3. Time to Expiration: The duration of the option, which is 5 days in this case.

4. Risk-Free Interest Rate: The risk-free interest rate during the option duration.

5. Implied Volatility: The expected volatility of the token's price over the option duration.

Using these inputs, we can run simulations or calculations based on the chosen pricing model to determine the call option cost or premium.

Comparison follows.

In this section we will do a round up on hedging and the types of hedges that exists and how we adopted it to our protocol. It's important to note that the terms "equity swap, call option and put option" in our context might not carry the same specific contractual implications as in traditional finance.

• Equity Swaps

• Call Options

• Put Options

Equity Swaps

In traditional finance, an equity swap is a financial derivative contract where two parties agree to exchange cash flows, often with one stream tied to the returns of an equity index or stock, and the other stream typically based on a fixed or floating interest rate. Equity swaps are used for various purposes, including gaining exposure to a particular equity market without directly owning the assets or for hedging purposes.

Example:

• Party A might agree to pay a fixed interest rate to Party B.

• Party B agrees to pay the return on a specified equity index to Party A.

The payments are based on the notional principal amount, and the parties exchange cash flows periodically.

in summary, Equity Swaps can be structured in different ways to meet the specific needs of the parties involved.

Call Options & Put Options

In options trading, call and put options are types of financial derivatives that give the holder the right, but not the obligation, to buy (call option) or sell (put option) an underlying asset at a predetermined price (strike price) within a specific time period (expiration date).

The main difference between call and put options lies in the direction of the underlying asset's price movement that benefits the option holder:

1. Call Options: A call option provides the holder with the right to buy the underlying asset at the strike price before the expiration date. Call options are typically used when the investor believes that the price of the underlying asset will rise. If the price of the underlying asset increases above the strike price, the call option holder can exercise the option, buying the asset at the lower strike price and potentially sell it at a higher market price, thus making a profit.

2. Put Options: A put option, on the other hand, grants the holder the right to sell the underlying asset at the strike price before the expiration date. Put options are generally used when the investor expects the price of the underlying asset to decline. If the price of the underlying asset drops below the strike price, the put option holder can exercise the option, selling the asset at the higher strike price and potentially avoiding losses or even profiting from the decline in value.

So, in summary, the distinction between call and put options is based on the direction of price movement that benefits the option holder. A call option benefits from a rise in the underlying asset's price, while a put option benefits from a decline in the underlying asset's price.

Simply staking tokens using the general staking, without assigning them to a farming pool, will only earn stakers general revenue share. These are available for any staker to claim from each month.

To increase rewards or revenue share for a staker, the staker needs to assign them to a farming pool. By assigning them to a pool, those tokens have been committed to yield farming, and proceeds collected will be shared between the stake assigners.

Assignment levels implemented by Xeon Protocol are as follows;

• General - Unassigned staked tokens

• Hedge Liquidity - see Native Hedge Liquidity

• Loan Collateral - see Native Loan Collateral

• Mining - Assigned to qualify as hedge or loan miner /settler

This model will be pivoted and used to create farming opportunities for other projects and their investors. Other projects can pool its investor's tokens together and use them to generate more revenue for their investors.

We are not reinventing the wheel in order to create a robust platform, we share some fundamental pillars with other blockchain hedging platforms.

Our blockchain hedging model is built on these four pillars:

Vault

This is our universal ERC-20 handling smart contract, inspired by Unicrypt, it can process deposits and withdrawals for any token. Token balances storage is mapped per token per wallet address, using userBalanceMap.

Collateral Locker

Using the userBalanceMap lockedInUse storage, when a hedge is written or taken, the collateral is locked using this mechanism until the deal is settled. This applies for all collateral in all deals.

Call and Put Options, Writer provides underlying asset or collateral, Taker pays cost only.

Equity Swaps, Both parties provide matching value collateral, in token and its pair respectively.

Hedge Premium Costing:

Instead of relying on the traditional premium calculations, users are able to price their own hedges using OTC rates or prevailing market rates.

Writers dictate the cost of taking their hedge, it is valued in the quote or pair currency of the underlying token in the deal.

For Options, collateral and cost don't need to be proportional, users can speculate.

For Equity Swaps, collateral and cost should be equal. The cost is not send to Writer but locked in use as collateral.

OTC P2P Market Making

Our smart contract does not need to pool premiums and collateral, nor does it need to match orders between buyers and sellers at certain price levels as traditional hedges do. We simply allow sellers to write hedges and list them on our open marketplace.

Terms are set by the Writer, the Buyer can only accept. Terms can also be adjusted after the deal has started, through deal requests.

Hedge Writers or sellers have their collateral, which is the underlying token being hedged, locked in the lockedInUse storage when they write a hedge.

Hedge Takers or buyers have their collateral, which is the hedge premium or cost to buy the hedge from the seller, locked in the lockedInUse storage when they buy a hedge.

Dynamic Pacts - Evolving Agreement

Parties in a hedge have the ability to adjust deal terms after the deal has started. Limited to the Neon Hedge platform only which houses Call Options, Put Options and Equity Swap tools. Neon Lending currently doesn't support these features.

Either of the parties in the deal have:

• Right to request increasing the collateral and cost.

• Right to request instant settlement, overwriting the initial expiry date agreed.

• Right to reject or accept the request and bring the terms to effect.

The type of deal is key in determining if the other party accepts or rejects any of those requests. For example:

• Call and Put Option Takers can always exercise their right when they want, a zap request from the Writer provides no advantage. Takers will only accept out of mercy.

• Writers always enjoy the full benefits of accepting requests when the terms are favorable.

Automated Settlement

Smart contracts can't self-execute, but users can validate and settle hedges once they expire. We use a validation approach for prompt hedge settlement. Both parties in the hedge can also trigger a settlement.

We incentivize users to settle hedges by offering a percentage of the profit or payoff to the winning party. A 5% settlement fee, subject to change, is charged for each hedge settled. This fee generates revenue for the protocol, with 10% of it awarded to the miner.

Capped Losses

When a hedge expires, the strike price of the underlying asset continues to fluctuate. This poses a risk if the hedge is settled using the market price at the time of settlement rather than the price at expiry. The longer the delay in settlement, the greater the risk of loss for both parties.

Liquidity Provision

The Neon Farming platform will incentivize liquidity providers to deposit their favorite ERC-20 tokens into a staking contract, then assign them to Liquidity Farming Pools. This is described in Native Hedge Liquidity. After these tokens are assigned to pools, they are used to write fixed term options and swaps. Farming is intended to be done by the owners of the ERC-20 project tokens pooled or strategy managers, not by Xeon Protocol.

Our protocol accepts deposits and withdrawals of any ERC20 token.

No Deposit Fees

There are no deposit fees charged when depositing to Xeon Protocol. All deposits reflect in balances mapping in full amount.

Withdrawal Fees

There is a 1% withdrawal fee charged for these tokens:

• WETH

• USDT

• USDC

Common pair tokens on exchanges are added to the protocol gradually to support more tokens. These are the cash tokens in our revenue model.

Premium is one of the factors in writing a hedge, along with:

• Premium or cost

• Risk-free interest rate

• Underlying asset value

• Strike price

• Time to expiration

Unlike other protocols, our hedging platform is built for OTC trading, so the premium is based on OTC market rates rather than the other listed factors.

Pricing Options

Call options and Put options typically carry a cost or premium set by the seller based on market trends, with no limitations on pricing in the OTC market—it's a willing buyer, willing seller arrangement. The cost is charged only in the paired currency of the underlying assets or tokens in the option. For instance, if VELA is paired with WETH, the option cost is always priced in WETH, the paired currency for VELA on DEX.

Cost is mandatory, In Options trading, Takers have to pay a cost directly to the Writer upon taking the deal and its not refundable no matter the outcome of the deal. This is the sellers minimum payoff no matter the outcome on settlement. To the Taker the cost is the maximum possible loss.

We also offer equity swaps, where the cost is treated as collateral. This is the only type of hedge where the cost is collateral and is locked in use during the deal.

Pricing Equity Swaps

Equity Swaps are the only type of hedges that have their own unique costing model.

For this tool, the cost is the money which the buyers has to pay to the seller in order to hold rights to exercise the hedge. The cost always have to be equal the collateral value put up by Writer, this is based on market prices using Uniswap TWAP oracles to value them in paired token.

The cost is locked in use together with the Writers collateral, and only released on settlement.

The two simulation methods I mentioned, namely Binomial and Monte Carlo simulations, are both widely used in options pricing. Here's a brief explanation of the differences between the two:

1. Binomial Simulation:

   • The binomial simulation method is based on the concept of a binomial tree, where the price of the underlying asset (in this case, the ERC20 token) is modeled as moving up or down at each time step.

   • The simulation divides the time to expiration into multiple discrete periods or steps.

   • At each step, the price can either move up or down based on specified probabilities.

   • By calculating the expected value at each step and working backward through the tree, the option price can be estimated.

   • The binomial model is relatively straightforward to implement and computationally less intensive compared to Monte Carlo simulation.

   • However, it can be less accurate than Monte Carlo simulation, especially for complex or highly volatile assets.

2. Monte Carlo Simulation:

   • Monte Carlo simulation uses random sampling to simulate a large number of possible price paths for the underlying asset.

   • The simulation involves generating random price movements based on specified statistical distributions, such as the log-normal distribution.

   • By simulating a large number of price paths, the option price is estimated based on the distribution of the final outcomes.

   • Monte Carlo simulation can handle complex and non-linear option pricing models more effectively than the binomial model.

   • It generally provides more accurate results, especially for assets with complex price dynamics or when considering multiple risk factors.

   • However, Monte Carlo simulation can be computationally more intensive and time-consuming compared to the binomial model.

In summary, the binomial simulation is simpler and computationally faster but may be less accurate for complex or highly volatile assets. On the other hand, Monte Carlo simulation is more flexible, accurate, and suitable for a wider range of option pricing scenarios but requires more computational resources.

The choice for the Beta Platform will be the Binamial Simulation Model.

Hedge structure factors:

• Underlying assets - ERC-20 tokens

• Strike Price

• Premium / Cost

• Expiry Date

• Underlying Value - Seller Collateral Value

• Strike Value

Factors Defined:

Underlying Assets - refers to the ERC20 tokens the seller or writer hedges.

Strike Price - refers to the price in paired currency the tokens being hedged have to cross

Premium - refers to the cost or price the buyers have to pay to buy the rights to the hedge

Expiry Date - refers to a future date to which the hedge expires and settlement follows.

Underlying Value - refers to the value in paired currency, of the underlying assets or ERC20 tokens in the hedge. These are the tokens being hedged by the seller or hedge writer.

Other Definitions:

Settlement Value - refers to the market value in paired currency of the underlying assets at the time of settlement.

Payoff - refers to the profit or proceeds credited to the winning party, taken from the losing party's collateral.

Writing a Hedge

You can write: Call Options, Put Options and Equity Swaps using your ERC-20 tokens as underlying assets or collateral.

In order to write a hedge on our protocol you need to specify these 4 parameters::

1. Hedge Type

2. ERC-20 Token Address - of the underlying assets being Hedged

3. Token Amount - amount of tokens to use as underlying assets or collateral

4. Premium or Cost - in paired currency to buy the hedge

5. Expiration Date - the day or timestamp at which the hedge expires for both parties

After filling those parameters on our Dapp, the Writer simply clicks "write" to submit the transaction to our protocol. Our protocol handles the rest, deducting the Writers deposit balances in the Vault, then locking them in the deal as collateral at market value, until settlement is triggered.

That's it!

Settlement can only be done under the following conditions:

• Taker exercising their right

• Upon expiry of the trade

• Upon both parties in the trade accepting Zap Requests

• By a miner

Process flow:

• Check settler wallet address

• Check if current timestamp > expiry timestamp

• Check hedge type and execute appropriate settlement calculations

• Execute settlement, crediting and debiting the parties

• Tax settlement value to profiteer only as settlement fee

• Credit the protocol wallet and miner wallet with fees collected

• Unlock collateral balances to both parties if any

Both parties will now have their collateral they used on the trade restored back into their withdraw-able balances.

They can proceed to withdraw or enter more trades with it.

This method is not ideal for pricing options considering the volatility is very high for ERC-20 tokens, thus rendering the cost insignificant compared to the potential profit.

Xeon Protocol resolved to instead allow users to use OTC prevailing rates to price a premium for a hedge they write, options demand and token trend will be factors.

In our case the goal of creating ERC-20 options is to:

• provide hedging tools for investors to manage risk

• provide speculative opportunities for traders and farmers

• leverage capital for more gains

• lock in profit on assets

This requires the premium on deals to be significant enough not negligible, it benefits no-one in a free market.

All tools in our ecosystem support the deletion of a deal. You can delete call options, put options, and equity swaps you wrote under specific conditions.

Conditions for Deleting a Hedge

• Untaken Deal Deletion:

  • You can delete a hedge before it is taken or bought (i.e., when the taker is address(0)).

• Taken Deal Deletion:

  • You can delete a hedge after it has expired and if the taker has lost the rights to exercise it.

• Equity Swaps:

  • Equity swaps cannot be deleted once taken; they can only be settled.

Deletion Fees

• Untaken Hedge:

  • Deleting an untaken hedge does not incur a fee for the writer.

• Expired and Unexercised Hedge:

  • Deleting a hedge that was taken but not exercised incurs a cancellation fee paid to the protocol.

  • The fee is charged in the underlying tokens to the writer.

  • The same fee calculation method used for settlement applies.

Deletion by Owner or Miner

• Owner Deletion:

  • The owner can delete an untaken hedge before it is taken (status = 1).

  • The owner can also delete the hedge after it expires and if it remains unexercised (status != 3).

• Miner Deletion:

  • A miner can delete an expired and unexercised hedge (status = 2) and receives a fee for doing so.

  • The fee is split between the miner and the protocol.

• Taker Deletion:

  • The taker is prohibited from deleting the hedge.

Balance Restoration

• Upon deletion, the remaining balance after fees is restored to the hedge owner.

As stated in our Real Yieldtopic,

Traditionally, hedges are priced in dollars. However in our approach we don't not rely on one currency to price our hedges or loans during writing, purchasing, and settlement.

More information on how Loans, Hedges, and Swaps are priced here:

Value is certain

We use the quote or paired currency of any ERC-20 token to value it. As detailed in the next chapter. Each trade carries a fixed premium or cost, determined by the trade writer to the taker. This amount is released immediately to the writer as soon as the taker buys the deal. This applies for only for Call Options, Put Options and Loans. The writer can withdraw the funds for use outside the protocol.

Referencing the Technology Topic below:

Hedges and Loans all have underlying assets/tokens as collateral in order to guarantee payoff outcomes to both parties.

Considering that DEX-es value tokens in quote/paired token, it is only logical to embrace this as the valuation standard for the underlying assets on our protocol.

This removes risk that may be associated with using other currencies, when price changes.

Consider the below scenario:

• Call Option Hedge with VELA tokens as underlying assets is created

• In the Hedge, VELA tokens are valued in XXX TOKENS an unofficial pair

• VELA tokens on DEX are paired with WETH officially

This creates a discrepancy in pricing or valuing. There is now need for a currency conversion.

Now supposed the price of XXX crushes by 50% overnight, or during the lifespan of the Call Option:

• The underlying value of the hedge is spoiled on the protocol, and is cut to half

• Yet on DEX-es, the value of the underlying tokens remains higher in WETH

• In turn, the collateral provided in the hedge is no-longer proportional to guarantee the parties.

• Twice the amount of XXX is now required to bring the Hedge value up to true Dex value

Conclusion

Third party currencies will not work to value hedges.

Our protocol supports all ERC-20 tokens on the blockchain it's deployed on.

This then enables for ease of costing, valuation and payoff when trading on our platforms. Value remains fair for both parties for the underlying tokens in question.

Let's go through the calculations step by step to determine the call option cost using the binomial method using the following example inputs:

1. Underlying Token Price: 10 cents

2. Strike Price: 13 cents

3. Time to Expiration: 3 days

4. Risk-Free Interest Rate: 0.5%

5. Implied Volatility: 100%

Let's calculate the call option cost using the binomial method:

1. Calculate Required Variables:

   • Number of Steps (numSteps): We'll use 100 steps for the binomial tree.

   • Delta T (deltaT): Time duration between each step (3 days / 100) = 0.03 days.

   • Up Factor (upFactor): exp(impliedVolatility * sqrt(deltaT)) = exp(100% * sqrt(0.03)) ≈ 1.478753756.

   • Down Factor (downFactor): 1 / upFactor ≈ 1 / 1.478753756 ≈ 0.675564409.

   • Discount Factor (discountFactor): exp(-riskFreeRate * timeToExpiration) = exp(-0.005 * 3/365) ≈ 0.99998633.

2. Build the Binomial Tree: Start with the initial price of the underlying token at time t=0, which is 10 cents. Use the up and down factors to calculate the prices at each step of the binomial tree.

   The binomial tree will look like this:

1. Calculate Option Values at Each Node: At the final time step (t=3 days), calculate the option value as the maximum of (price - strikePrice, 0) for each node.

   The option value tree will look like this:

1. Calculate Option Prices at Each Step: Starting from the second-to-last time step (t=2 days) and working backward, calculate the option prices at each step of the binomial tree.

   At t=2 days:

   • Option Value at Node 1: ((0 * 0.5) + (0 * 0.5)) * 0.99998633 ≈

0

• Option Value at Node 2: ((0 * 0.5) + (1.7875 * 0.5)) * 0.99998633 ≈ 0.0008936681

At t=1 day:

• Option Value at Node 1: ((0 * 0.5) + (0 * 0.5)) * 0.99998633 ≈ 0

• Option Value at Node 2: ((0 * 0.5) + (0.0008936681 * 0.5)) * 0.99998633 ≈ 0.0004468325

At t=0 days (initial time):

• Option Value at Node 1: ((0 * 0.5) + (0 * 0.5)) * 0.99998633 ≈ 0

• Option Value at Node 2: ((0 * 0.5) + (0.0004468325 * 0.5)) * 0.99998633 ≈ 0.0002234162

Therefore, the call option cost, based on the binomial method with the given inputs, is approximately 0.0008936681425369367 or 0.00089 cents.

We assumed the following factors:

Considering that the implied volatility was 100% which is pretty high but yet ideal for crypto, the resulting premium based on traditional pricing models is ridiculously low.

Inspired by Unicrypt's token lock smart contracts.

Xeon Protocol employs a central Vault smart contract to:

• accept deposits,

• lock balances into deals,

• transfer locked balances

• and process withdrawals.

This enables any ERC20 token to be used as collateral on our OTC hedging or lending markets.

The vault acts as a custodian of user tokens, this enables the core functions of the protocol to trustlessly execute transactions.

ERC20 holders can bundle together different tokens to create a basket of collateral.

The binomial method for option pricing is based on a discrete-time model where the price of the underlying asset is assumed to follow a binomial distribution. The method involves constructing a binomial tree, with each node representing the price of the underlying asset at a particular time step.

The equation used in the binomial method to calculate the option price at each node is as follows:

OptionValue = (p * OptionValue_Up + (1 - p) * OptionValue_Down) * DiscountFactor

Where:

• OptionValue is the estimated option value at a specific node in the tree.

• OptionValue_Up is the estimated option value at the next time step if the underlying asset price moves up.

• OptionValue_Down is the estimated option value at the next time step if the underlying asset price moves down.

• p is the probability of the underlying asset price moving up at each time step.

• DiscountFactor is the factor used to discount future cash flows back to the present value, considering the risk-free interest rate.

Here's a step-by-step explanation of the binomial method:

1. Calculate the parameters:

   • deltaT: Time duration between each step (timeToExpiration / numSteps).

   • upFactor: Factor by which the underlying asset price moves up at each step (exp(impliedVolatility * sqrt(deltaT))).

   • downFactor: Factor by which the underlying asset price moves down at each step (1 / upFactor).

   • discountFactor: Factor to discount future cash flows back to the present (exp(-riskFreeRate * timeToExpiration)).

2. Build the binomial tree:

   • Start with the initial price of the underlying asset at time t=0.

   • For each subsequent time step, calculate the price of the underlying asset by multiplying the previous price by the upFactor or downFactor.

   • Store the prices in an array (priceTree).

3. Calculate option values at each node:

   • Initialize an array (optionValueTree) to store the option values at each node.

   • At the final time step, calculate the option value as the maximum of (price - strikePrice, 0) for each node.

   • Backward iterate through the tree, calculating the option values at each node based on the probability-weighted average of the option values at the next time step.

   • Apply the discount factor to each option value to bring it back to the present value.

4. The estimated call option cost is the option value at the root node (optionValueTree[0]).

By iteratively calculating the option values backward through the tree, starting from the final time step, the binomial method allows for estimating the option price based on the assumed price movements and probabilities at each step.

It's worth noting that the binomial method assumes a risk-neutral world and requires the assumption of constant volatility during each time step. It provides an approximation of the option price and becomes more accurate as the number of steps (numSteps) in the tree increases.

The reason we chose the Binomial method is because our ERC20 hedging platform will price each contract in base currency i.e. some level of risk neutrality.

Our mission at Neon Protocol is to

Underlying asset is primary token in asset basket

Underlying value is calculated for each of the assets in basket and combined

Cost is charged in in primary token pair address

Before loan is taken it can be adjusted

Settlement is in primary token pair or in each underlying asset in basket based on equivalent tokens required to meet payoff in base pair.

In order to properly value all ERC20 tokens, we need to get the correct pair address and pair address decimal.

Neon Protocol developed a core helper function to the getUnderlyingValue function which assists in fetching the pair address of any ERC20 token from DEX-es.

getPairAddressZK function accepts any ERC20 address and relies on the following Uniswap Protocol functions:

• IUniswapV2Factory

• getPair

To get the pair address of the provided token address.

Support for pair addresses is limited to only:

• WETH

• USDT

• USDC

Providing any ERC20 token does not return a pair address matching the above pairs will result in the getPairAddressZK returning the error: "TokenValue: token is not paired with WETH, USDT, or USDC"

getPairAddressZK returns the pairAddress and pairedCurrency addresses, as a default redundant check.

Once a deal is taken, both parties can send requests to each other in the form of a Topup request.

This is a request to add to the currently existing collateral. You can only add not remove collateral.

This feature is meant to give traders more freedom and control over their deal.

This is meant to increase your risk or profit exposure based on changing market sentiment.

Conditions:

• Deal must be active and not expired or settled.

• Requests are not limited.

• One party sends a request first.

• The other party has to accept request for it to be binding.

• Collateral is then moved from both parties and locked in use.

• For Call and Put Options, collateral is moved direct from Taker to Writer.

• For Equity Swaps collateral is only locked in use, incrementing the value of the deal.

• Once added the collateral cant be removed.

topupHedge Function

This function is unified to handle requests by both parties. It only accepts requests from taker or writer. It uses msg.sender to determine if party wants to increment topup request or initiate it.

It actively transfers token balances to lockedInUse on acceptance or request.

If a request is not accepted, the requester can increment the active request amount.

All requests are stored under the hedge struct, under the array hedge.topupRequests. It works alongside topupMap[topupRequestID].state as the global mapping that keeps track of the status of each request outside the hedge struct.

Depending on the party, after all the above are updated and msg.sender has enough balance in vault to proceed, we update topupMap[topupRequestID].amountWriter and topupMap[topupRequestID].amountTaker.

Finally, hedge.cost and hedge.amount are updated for the hedgeMap to reflect the new collateral amounts for the deal.

rejectTopupRequest Function

Rejecting and cancelling are handled outside of the topupHedge function. Using the functions:

rejectTopupRequest

cancelTopupRequest

Both which point to the same mapping topupMap used in request above.

Topup mapping is then updated to rejected or falsetopupMap[_requestID].state = 2; so the request disappears from the deal page.

cancelTopupRequest Function

A separate function to cancel the requests stored in the topupMap by request Id.

Only the creator of the request can cancel, on condition the request was not accepted already by the other party.

Neon Protocol utilizes a Vault smart contract with the following functionality.

Deposit

The depositToken function allows msg.sender to:

• Transfer an amount > 0 to Vault Smart Contract

• Give allowance to the Vault to transfer the set amount of tokens on behalf of the msg.sender

• update userBalanceMap with the amount, under the userBalanceMap[msg.sender].deposited storage.

• update userERC20s mapping with new token address for first time deposits.

• onDeposit event is emitted with the token, amount and msg.sender upon a successful deposit.

User will now have deposited tokens into the Neon Protocol Vault.

The user can go on to write or buy or take hedges and loans.

Withdraw

msg.sender has to have withdrawable balance > amount requested in withdrawToken function.

The withdrawToken function allows msg.sender:

• Check token balance available for withdrawal using the getWithdrawableBalance function. Withdrawable balance is drived as: userBalanceMap[msg.sender].deposited - userBalanceMap[msg.sender].withdrawn - userBalanceMap[msg.sender].lockedInUse

• Transfer an amount < withdrawable balance from Vault Smart Contract.

• Pay cashier fees before withdrawal, debited from userBalanceMap[msg.sender].deposited and credited to the Vault balance.

• update userBalanceMap[msg.sender].withdrawn with the amount.

• onWithdraw event is emitted, with the token, amount and msg.sender upon a successful withdrawal.

User will now have succesfully withdrawn tokens from the Neon Protocol Vault.

Xeon Protocol is built from the ground out. All functions are custom made for the protocol.

Design Approach

There are two goals we sought to achieve with this design:

1. A simple functional universal token engine

2. A modern and aesthetic UI

Inspiration

Unicrypt simple approach to a universal ERC20 vault. Clean easy to understand.

Tech Stack

• Solidity

• Javascript

• Ether Js

• HTML5 & CSS5

Structure

• Backend - Blockchain deployed smart contracts.

• Frontend - Dapp interface and Web3 Infrastructure.

Settlement Overview

The settlement process involves triggering by an external caller to the smart contract and does not occur automatically upon trade expiry or when traders agree to initiate a Zap. Speed is crucial; trades should be settled as soon as possible or immediately upon the expiration of the rules binding the parties.

To facilitate swift settlement, the protocol incentivizes certain participants, called miners, who are XEON token stakers willing to earn passive income by settling trades upon expiry.

Key Criteria for Participation as a Miner:

1. Staking Requirements:

   • A wallet must stake XEON tokens.

   • Staked tokens are then assigned to a Mining Pool.

2. Mining Rights:

   • The proportion of staked tokens in the Mining Pool determines the mining rights available to a wallet.

   • Wallets with more staked tokens will have the ability to mine more trades, while those with fewer tokens will mine a smaller number of trades.

   • The exact formula for calculating mining rights is under development.

Settlement Process Overview:

Settlement involves calculating the payoff based on the underlying value, updating user balances, and distributing fees.

1. Value Calculation:

   • Measured in paired currency using the 'getUnderlyingValue' function.

   • Strike value set by the writer, start value determined when the hedge is initiated.

2. Payoffs and Losses:

   • Payoff is the difference between market value and strike value, paid in underlying or paired currency.

   • Losses are immediately debited; profits are credited to the deposited balance.

   • Initial amounts are restored by moving funds from locked to deposited status.

3. Fee Distribution:

   • Fees are collected based on the currency of the payoff.

   • Settlement fees are collected into the protocol's balance and distributed as dividends to a staking contract.

4. Miner Involvement:

   • Miners can settle expired trades, crucial for Equity Swaps but not for Options.

   • Miners can only delete unexercised options after expiry.

   • Miners choose which deals to settle based on the tokens and amounts they prefer.

5. Wallet Tracking:

   • Wallets must log interactions with each token for accurate net worth valuations.

6. Revenue Handling:

   • Protocol revenues are stored in a user balance map.

   • Revenue is withdrawn manually and sent to the staking wallet.

Specific Conditions and Rules:

• Call and Put Options:

  • Can be settled by miners or the taker.

  • Takers can settle before expiry; after expiry, options are deleted and taxed.

• Equity Swaps:

  • Can be settled by either party after expiry.

  • Expedited settlement via Zap is possible if both parties agree, updating the expiry date to the current time.

• Zap Feature:

  • Available for Equity Swaps.

  • Allows for expedited settlement before the original expiry date.

• Collateral Management:

  • If the loser lacks sufficient collateral, all available collateral is used to pay the winner.

  • For Put Options, takers must exercise while collateral still holds value.

  • Remaining balance after payoff deduction is returned to the loser.

By following this criteria, Xeon Protocol ensures a fair and efficient settlement process, leveraging the incentives for miners to maintain the speed and reliability of the system.

Settlement Process Overview:

The settlement process ensures fair resolution for all hedging options, including call options, put options, and swaps. It encompasses several key steps:

• Value Calculation: The value of the underlying asset is calculated using the getUnderlyingValue function, providing the asset's value in quote currency.

• Strike Value: The writer sets the strike value at the hedge initiation, determining the exercise price. The start value is recorded when the hedge begins.

• Premium: For call and put options, the premium is the cost paid in the quote currency. In swaps, the entire start value acts as collateral instead of a premium.

• Payoff Calculation: The payoff is the difference between the market value and the strike value, paid out in base tokens or quote currency.

• Immediate Impact: Losses are immediately debited from withdrawn funds, while profits are credited directly to the deposited balance.

• Collateral Restoration: Initial funds for both parties are restored by moving funds from locked-in use to deposit, reversing the creation or buying process.

• Fee Collection: Fees are collected in quote tokens if option and swap payoffs were done in quote tokens. Fees are collected in base tokens if option and swap payoffs were done in base tokens.

• Miner Settlement: Miners can settle deals after expiry by staking tokens, choosing deals and amounts to mine, avoiding unwanted tokens as rewards.

• Wallet Logging: Each wallet logs each token interacted with to allow for comprehensive balance valuations during settlement.

• Protocol Revenues: Protocol revenues are stored under userBalanceMap[address(this)], manually withdrawn, and sent to the staking wallet for financial sustainability.

• Option Handling: Takers can settle or exercise open call and put options before expiry. After expiry, options are deleted and taxed. Both parties can settle equity swaps, but only after expiry.

Conditions and Rules:

• Settlement Authority: Call and put options can only be settled by miners or the taker.

• Expiry Handling: Only the taker can settle before expiry; after expiry, the option is deleted.

• Swap Settlement: Swaps require fast settlement after expiry and can be settled by the miner or any involved party.

• Expedited Settlement: If a hedge has Zap request consensus on expedited settlement, the expiry date is updated to now.

• Collateral Shortfall: If the loser lacks collateral to pay the winner, all the loser's collateral is used for the payoff.

• Put Option Caution: Takers must exercise put options while the owner's collateral still covers the payoff.

• Remaining Value: After deducting the payoff from the loser's collateral, any remaining value is restored to the loser.

• Market Over Strike: For call options, if the market value is above the strike value plus cost, the taker profits.

• Below Strike: For put options, if the market value is below the strike value minus cost, the taker profits.

• Swap Gains: For swaps, if the market value exceeds the start value, the taker profits in base tokens.

• Swap Losses: If the market value is below the start value, the writer profits in quote tokens.

• Profit Logging: Profits are logged to track performance and ensure transparent reporting.

• Mining Flexibility: Miners select deals and tokens for rewards, optimizing their gains and avoiding unwanted tokens.

• Fee Distribution: Fees collected are distributed to staking contracts, rewarding protocol participants.

• Protocol Sustainability: Revenue management ensures long-term protocol sustainability and participant rewards.

This detailed yet concise overview provides a clear understanding of the settlement process, ensuring fairness and transparency for all parties involved.

Once a trade is running it can't be cancelled. Traders have to wait for expiry date or settlement date. Traders additionally have the option to expedite settlement provided both parties agree to it.

This is called zapping, and sending a request to the other party is a zapRequest.

Rules:

• One party has to send a zapRequest to the other party

• Either party in the trade can initiate request

• The other party, recipient of the request will see this appear on the deal page, and has option to accept or reject the request.

• Once rejected that request is archived, but the requester is not limited from sending more requests.

• If parties agree on settling as things stand, then the trade is marked as zap-consented making it available for settlement immediately.

• Settlement is still executed under the same rules as it would have if parties waited for expiration date (equity swaps) or chosen to exercise the option. It is just now settled based on current underlying values.

Implications of Zap Requests:

Once a Zap Request is accepted, it has full consent status, and the expiry date on the deal or hedge is updated to now. This applies for all hedges, with different consequences on each.

Zap Effect on Options

• Expiry date on the hedge is updated to now, meaning that Taker loses right to exercise the trade.

• Writer gains the right to delete or cancel the un-exercised option.

• Writer will incur a fee for deleting a hedge after, paid in underlying token.

Zap Effect on Equity Swaps

• Expiry date on the hedge is updated to now, meaning that both parties can now settle the trade now.

• A miner can also now settle it once expiry is passed, as speed of settlement matters in swaps.

zapRequest function

Shared by both parties, flags intent only.

This function checks is the requesting address matches either the hedge.owner or hedge.taker address. If its either party then they can update the request storage in the hedge struct.

hedge.zapWriter bool is set to true for the writer.

hedge.zapTaker bool is set to true for the taker.

Once flagged they cannot be unflagged. This is a once off event for every trade.

hedge.expiry is then updated to block.timestamp

If all conditions are met then zapRequested event is fired.

To write a hedge the msg.sender must have a sufficient balance of the tokens being hedged, under the userBalanceMap[msg.sender] storage.

All deals on our platform are collateralized fully by both parties, amounts and type of collateral to be put up for each deal depend on the parties involved.

Types of deals to write:

• Call Option

• Put Option

• Equity Swap

• Loan Request

Writing a deal (hedge or loan) utilizes the lockedinuse storage under userBalanceMap[msg.sender] as described in the below topic.

Writing conditions:

• Every deal has to have underlying assets, these are the tokens being hedged or loaned.

• Writer always has to provide collateral, thus the payoff (if any) to the taker is always in underlying assets.

• Taker collateral type is determined by the type of deal. Options taker collateral is asked in the form of underlying tokens paired currency. Swap taker collateral is asked in the form of underlying tokens being hedged.

• Premium or cost must be stipulated, depending on the type of deal the currency of the premium is determined automatically and fixed.

• A duration must be stipulated, which is the lifespan of the deal being written, and should be a value > block.timestamp.

• A deal will remain available on the OTC market as long as its not taken.

• Only writer can delete the deal before it is taken.

writeHedge Function

This function is unified to handle the writing of all hedge types (options and swaps) and will also handle loan request writing.

All deals written have an incrementing global ID counter to avoid same storage saving in the mapping hedgeMap.

Two helper functions are used in the process getWithdrawableBalance to check if writer has sufficient balance, and getUnderlyingValue to determine the startValue of the deal in its paired currency.

All inputs should meet requirement and if successful, a hedgeCreated event is emitted to signify the writing of the deal.

Currently the writeHedge function only supports a single token type as the underlying asset of collateral for a deal, in future equity swaps and loans will have the capability to bundle a group of tokens into a basket of underlying assets for a deal.

This process is crucial for our protocol and is the core mechanism behind all our OTC tools.

All tokens deposited into our protocol have a underlying value derived. This refers to the process of determining the equivalent value of a particular ERC20 token in the paired currency.

The utility of deriving the underlying value of tokens can be found here:

getUnderlyingValue

This is the primary function of our protocol engine / core mechanisms.

The function accepts input of token address and amount, then returns the value (in paired currency) and the paired currency address to the caller.

It only measure the value of the ERC20 tokens being hedged, i.e. the underlying assets. The cost or premium is excluded from this.

Its depended on the following helper functions:

• getPairAddressZK

• IUniswapV2Pair

• getReserves

• token0() and token1()

Functions that use this:

• writeHedge - used to derive createValue of the underlying tokens in the hedge.

• buyHedge - used to derive the startValue of the underlying tokens in the hedge.

• settleHedge - used to derive the endValue of the underlying tokens in the hedge, and to determine the payoff for each party in the hedge.

• depositToken, withdrawToken - used to derive the paired value equivalent of each transfer.

• getuserTokenBalances - used to retrieve the paired value for a specific balance of tokens held by a wallet on the protocol.

Conclusion

getUnderlyingValue function is the core function of our protocol engine. By embracing the fact that all ERC20 tokens have a measurable value in their paired currency, we open up the door to developing advanced OTC tools that are inclusive of all ERC20 tokens.

It enables Neon Protocol to build sound risk management and lending tools.

To buy a hedge the msg.sender must have a sufficient balance of the tokens being hedged, under the userBalanceMap[msg.sender] storage.

All deals on our platform are collateralized fully by both parties, amounts and type of collateral to be put up for each deal depend on the parties.

Types of deals to buy:

• Call Option

• Put Option

• Equity Swap

• Loan

Buying a deal (hedge or loan) utilizes the lockedinuse storage under userBalanceMap[msg.sender] as described in the below topic.

Buying conditions:

• A deal can be taken as long as its listed and available or unexpired.

• Only the paired currency of the underlying assets or tokens can be used to purchase a hedge.

• For loaning, the requested token is not strict but determined by the writer.

• Buyer must have enough sufficient balance of the required token deposited to Vault.

• Hedge writer always has to provide collateral, thus the payoff (if any) to the taker is always in underlying assets.

• Hedge taker collateral type is determined by the type of deal. Options taker collateral is asked in the form of underlying tokens paired currency. Swap taker collateral is asked in the form of underlying tokens being hedged.

buyHedge Function

This function is unified to handle the taking of all hedge types (options and swaps) and will also handle loans.

All deals taken will have their storage structs, under the mapping hedgeMap updated. hedge.status is updated from 0 (available) to 1 (taken), hedge.taker is wallet address of signer or msg.sender.

// For Call and Put Options cost is premium, lockedinuse here but paid out on settlement
// For Equity Swaps cost is equal to underlying value as 100% collateral is required. There is no premium

Two helper functions are used in the process getUserTokenBalances to check if taker has sufficient balance, and getUnderlyingValue to determine the startValue of the deal in its paired currency.

The global hedge taken arrays are updated with the ID of the hedge to help with filtering. myoptionsTaken stores wallet specific trades taken. We then update the protocol volume storage hedgesTakenVolume.

The takers collateral, or available balance is then added to lockedInUse. Depending on type of deal it can be credited to the writer immediately or only handled on settlement.

All inputs should meet requirement and if successful, a hedgePurchased event is emitted to signify the writing of the deal.

Deployment Addresses:

Xeon Protocol Testnet smart contracts are deployed on Sepolia at these addresses:

• oVELA 0x461eBee65e95F92db8bb9f0122B57E946D0245Bc

• oPEPE 0x02F992f8F110654869c719bE53a3202F6ab51B08

• oBCB 0x71F72c8A8F7e94F16EcD21cEc9f789bD5c50Af35

• oBITCOIN 0xf588aE424BD3D78f1172Cf37a5a6D604c1FD141c

• oBANANA 0x8f2936bEAc38d21c63B21D07E4CBee7E416C565D

• oXEON 0xDb90a9f7cEaA33a32Ec836Bbadeeaa8772Ad9797

• oUSDT 0x297b8d4b35294e730087adf0597a31a9bc1746af

• WETH/oUSDT 0x673a8ef506c61102f689A3f5533ddAc6c92c8D84

• Testnet Vault 0xa50E605f76661d4C0e36a78C588E084D779B05fE

• XEON Staking 0x535caE6FcD7E8536E8Ee14BfB22801a5e998e3c2

Smart Contract Interfaces:

ERC20

ERC20_ABI: [ { "inputs": [], "stateMutability": "nonpayable", "type": "constructor" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "owner", "type": "address" }, { "indexed": true, "internalType": "address", "name": "spender", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "value", "type": "uint256" } ], "name": "Approval", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": false, "internalType": "uint256", "name": "_maxTxAmount", "type": "uint256" } ], "name": "MaxTxAmountUpdated", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "previousOwner", "type": "address" }, { "indexed": true, "internalType": "address", "name": "newOwner", "type": "address" } ], "name": "OwnershipTransferred", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "from", "type": "address" }, { "indexed": true, "internalType": "address", "name": "to", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "value", "type": "uint256" } ], "name": "Transfer", "type": "event" }, { "inputs": [], "name": "_buyCount", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_ethRewardBasis", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_finalBuyTax", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_finalSellTax", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_initialBuyTax", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_initialSellTax", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_maxTaxSwap", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_maxTxAmount", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_maxWalletSize", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_preventSwapBefore", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_reduceSellTaxAt", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_taxSwapThreshold", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "_taxWallet", "outputs": [ { "internalType": "address payable", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address[]", "name": "bots_", "type": "address[]" } ], "name": "addBots", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "owner", "type": "address" }, { "internalType": "address", "name": "spender", "type": "address" } ], "name": "allowance", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "spender", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "approve", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "account", "type": "address" } ], "name": "balanceOf", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "cooldownTimerInterval", "outputs": [ { "internalType": "uint8", "name": "", "type": "uint8" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "decimals", "outputs": [ { "internalType": "uint8", "name": "", "type": "uint8" } ], "stateMutability": "pure", "type": "function" }, { "inputs": [ { "internalType": "address[]", "name": "notbot", "type": "address[]" } ], "name": "delBots", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "a", "type": "address" } ], "name": "isBot", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "manualSwap", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "name", "outputs": [ { "internalType": "string", "name": "", "type": "string" } ], "stateMutability": "pure", "type": "function" }, { "inputs": [], "name": "openTrading", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "owner", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_newFee", "type": "uint256" } ], "name": "reduceFee", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "removeLimits", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "renounceOwnership", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "symbol", "outputs": [ { "internalType": "string", "name": "", "type": "string" } ], "stateMutability": "pure", "type": "function" }, { "inputs": [], "name": "totalSupply", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "pure", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "recipient", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "transfer", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "transferDelayEnabled", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "sender", "type": "address" }, { "internalType": "address", "name": "recipient", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "transferFrom", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "nonpayable", "type": "function" }, { "stateMutability": "payable", "type": "receive" } ],

Vault, Engine

VAULT_ABI: [ { "anonymous": false, "inputs": [ { "indexed": true, internalType": "address", "name": "user", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "hedgeId", "type": "uint256" }, { "indexed": false, "internalType": "bool", "name": "bookmarked", "type": "bool" } ], "name": "bookmarkToggle", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "token", "type": "address" }, { "indexed": true, "internalType": "uint256", "name": "optionId", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "createValue", "type": "uint256" }, { "indexed": false, "internalType": "enum oXEONVAULT.HedgeType", "name": "hedgeType", "type": "uint8" }, { "indexed": true, "internalType": "address", "name": "writer", "type": "address" } ], "name": "hedgeCreated", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "token", "type": "address" }, { "indexed": true, "internalType": "uint256", "name": "optionId", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "startValue", "type": "uint256" }, { "indexed": false, "internalType": "enum oXEONVAULT.HedgeType", "name": "hedgeType", "type": "uint8" }, { "indexed": true, "internalType": "address", "name": "buyer", "type": "address" } ], "name": "hedgePurchased", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "token", "type": "address" }, { "indexed": true, "internalType": "uint256", "name": "optionId", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "endValue", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "payOff", "type": "uint256" }, { "indexed": true, "internalType": "address", "name": "miner", "type": "address" } ], "name": "hedgeSettled", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": false, "internalType": "uint256", "name": "optionId", "type": "uint256" }, { "indexed": true, "internalType": "address", "name": "miner", "type": "address" }, { "indexed": true, "internalType": "address", "name": "token", "type": "address" }, { "indexed": true, "internalType": "address", "name": "paired", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "tokenFee", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "pairFee", "type": "uint256" } ], "name": "minedHedge", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "token", "type": "address" }, { "indexed": true, "internalType": "uint256", "name": "amount", "type": "uint256" }, { "indexed": true, "internalType": "address", "name": "wallet", "type": "address" } ], "name": "onDeposit", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "token", "type": "address" }, { "indexed": true, "internalType": "uint256", "name": "amount", "type": "uint256" }, { "indexed": true, "internalType": "address", "name": "wallet", "type": "address" } ], "name": "onWithdraw", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": false, "internalType": "address", "name": "", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "received", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "party", "type": "address" }, { "indexed": true, "internalType": "uint256", "name": "hedgeId", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "topupAmount", "type": "uint256" }, { "indexed": false, "internalType": "bool", "name": "consent", "type": "bool" } ], "name": "topupRequested", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "uint256", "name": "hedgeId", "type": "uint256" }, { "indexed": true, "internalType": "address", "name": "party", "type": "address" } ], "name": "zapRequested", "type": "event" }, { "inputs": [ { "internalType": "uint256", "name": "_optionId", "type": "uint256" } ], "name": "bookmarkHedge", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_optionId", "type": "uint256" } ], "name": "buyHedge", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_optionId", "type": "uint256" }, { "internalType": "uint256", "name": "_requestID", "type": "uint256" } ], "name": "cancelTopupRequest", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "tool", "type": "uint256" }, { "internalType": "address", "name": "token", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "uint256", "name": "cost", "type": "uint256" }, { "internalType": "uint256", "name": "strikeprice", "type": "uint256" }, { "internalType": "uint256", "name": "deadline", "type": "uint256" } ], "name": "createHedge", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_token", "type": "address" }, { "internalType": "uint256", "name": "_amount", "type": "uint256" } ], "name": "depositToken", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_optionId", "type": "uint256" }, { "internalType": "uint256", "name": "_requestID", "type": "uint256" } ], "name": "rejectTopupRequest", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_optionId", "type": "uint256" } ], "name": "settleHedge", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_optionId", "type": "uint256" }, { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "bool", "name": "action", "type": "bool" } ], "name": "topupHedge", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "stateMutability": "payable", "type": "receive" }, { "inputs": [ { "internalType": "uint256", "name": "numerator", "type": "uint256" }, { "internalType": "uint256", "name": "denominator", "type": "uint256" } ], "name": "updateFee", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "token", "type": "address" }, { "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "withdrawToken", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_optionId", "type": "uint256" } ], "name": "zapRequest", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "stateMutability": "nonpayable", "type": "constructor" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "bookmarkedOptions", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "bookmarks", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "calculateFee", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "depositedTokensLength", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "equityswapsCreatedLength", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "equityswapsTakenLength", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "address", "name": "", "type": "address" } ], "name": "equivUserCosts", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "address", "name": "", "type": "address" } ], "name": "equivUserHedged", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "feeDenominator", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "feeNumerator", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getAllOptions", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getAllOptionsTaken", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getAllSwaps", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getAllSwapsTaken", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "user", "type": "address" }, { "internalType": "uint256", "name": "_optionId", "type": "uint256" } ], "name": "getBookmark", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_token", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getBoughtOptionsERC20", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_token", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getBoughtSwapsERC20", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "token", "type": "address" } ], "name": "getCountTokenOptions", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "token", "type": "address" } ], "name": "getCountTokenSwaps", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "user", "type": "address" }, { "internalType": "address", "name": "pairedCurrency", "type": "address" } ], "name": "getEquivUserPL", "outputs": [ { "internalType": "uint256", "name": "profits", "type": "uint256" }, { "internalType": "uint256", "name": "losses", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_optionId", "type": "uint256" } ], "name": "getHedgeDetails", "outputs": [ { "components": [ { "internalType": "bool", "name": "topupConsent", "type": "bool" }, { "internalType": "bool", "name": "zapTaker", "type": "bool" }, { "internalType": "bool", "name": "zapWriter", "type": "bool" }, { "internalType": "address", "name": "owner", "type": "address" }, { "internalType": "address", "name": "taker", "type": "address" }, { "internalType": "address", "name": "token", "type": "address" }, { "internalType": "address", "name": "paired", "type": "address" }, { "internalType": "uint256", "name": "status", "type": "uint256" }, { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "uint256", "name": "createValue", "type": "uint256" }, { "internalType": "uint256", "name": "startValue", "type": "uint256" }, { "internalType": "uint256", "name": "strikeValue", "type": "uint256" }, { "internalType": "uint256", "name": "endValue", "type": "uint256" }, { "internalType": "uint256", "name": "cost", "type": "uint256" }, { "internalType": "uint256", "name": "dt_created", "type": "uint256" }, { "internalType": "uint256", "name": "dt_started", "type": "uint256" }, { "internalType": "uint256", "name": "dt_expiry", "type": "uint256" }, { "internalType": "uint256", "name": "dt_settled", "type": "uint256" }, { "internalType": "enum oXEONVAULT.HedgeType", "name": "hedgeType", "type": "uint8" }, { "internalType": "uint256[]", "name": "topupRequests", "type": "uint256[]" } ], "internalType": "struct oXEONVAULT.hedgingOption", "name": "", "type": "tuple" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "startId", "type": "uint256" }, { "internalType": "uint256", "name": "endId", "type": "uint256" } ], "name": "getHedgeRange", "outputs": [ { "components": [ { "internalType": "bool", "name": "topupConsent", "type": "bool" }, { "internalType": "bool", "name": "zapTaker", "type": "bool" }, { "internalType": "bool", "name": "zapWriter", "type": "bool" }, { "internalType": "address", "name": "owner", "type": "address" }, { "internalType": "address", "name": "taker", "type": "address" }, { "internalType": "address", "name": "token", "type": "address" }, { "internalType": "address", "name": "paired", "type": "address" }, { "internalType": "uint256", "name": "status", "type": "uint256" }, { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "uint256", "name": "createValue", "type": "uint256" }, { "internalType": "uint256", "name": "startValue", "type": "uint256" }, { "internalType": "uint256", "name": "strikeValue", "type": "uint256" }, { "internalType": "uint256", "name": "endValue", "type": "uint256" }, { "internalType": "uint256", "name": "cost", "type": "uint256" }, { "internalType": "uint256", "name": "dt_created", "type": "uint256" }, { "internalType": "uint256", "name": "dt_started", "type": "uint256" }, { "internalType": "uint256", "name": "dt_expiry", "type": "uint256" }, { "internalType": "uint256", "name": "dt_settled", "type": "uint256" }, { "internalType": "enum oXEONVAULT.HedgeType", "name": "hedgeType", "type": "uint8" }, { "internalType": "uint256[]", "name": "topupRequests", "type": "uint256[]" } ], "internalType": "struct oXEONVAULT.hedgingOption[]", "name": "", "type": "tuple[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "user", "type": "address" } ], "name": "getmyBookmarks", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_token", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getOptionsForToken", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "tokenAddress", "type": "address" } ], "name": "getPairAddressZK", "outputs": [ { "internalType": "address", "name": "pairAddress", "type": "address" }, { "internalType": "address", "name": "pairedCurrency", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_token", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getSettledOptionsERC20", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_token", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getSettledSwapsERC20", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_token", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getSwapsForToken", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "_tokenAddress", "type": "address" }, { "internalType": "uint256", "name": "_tokenAmount", "type": "uint256" } ], "name": "getUnderlyingValue", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" }, { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "user", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getUserHistory", "outputs": [ { "internalType": "address[]", "name": "", "type": "address[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "user", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getUserOptionsCreated", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "user", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getUserOptionsTaken", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "user", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getUserSwapsCreated", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "user", "type": "address" }, { "internalType": "uint256", "name": "startIndex", "type": "uint256" }, { "internalType": "uint256", "name": "limit", "type": "uint256" } ], "name": "getUserSwapsTaken", "outputs": [ { "internalType": "uint256[]", "name": "", "type": "uint256[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "token", "type": "address" }, { "internalType": "address", "name": "user", "type": "address" } ], "name": "getUserTokenBalances", "outputs": [ { "internalType": "uint256", "name": "deposited", "type": "uint256" }, { "internalType": "uint256", "name": "withdrawn", "type": "uint256" }, { "internalType": "uint256", "name": "lockedinuse", "type": "uint256" }, { "internalType": "uint256", "name": "withdrawable", "type": "uint256" }, { "internalType": "uint256", "name": "withdrawableValue", "type": "uint256" }, { "internalType": "address", "name": "paired", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "hedgesCostVolume", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "hedgesCreatedVolume", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "hedgesTakenVolume", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "minerMap", "outputs": [ { "internalType": "bool", "name": "", "type": "bool" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "miners", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "myoptionsCreated", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "myoptionsTaken", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "myswapsCreated", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "myswapsTaken", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "optionID", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "optionsCreatedLength", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "optionsTakenLength", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "optionsVolume", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "owner", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "pairedERC20s", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "protocolBalanceMap", "outputs": [ { "internalType": "uint256", "name": "deposited", "type": "uint256" }, { "internalType": "uint256", "name": "withdrawn", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "protocolCashierFees", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "protocolFeesTokens", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "protocolPairedFees", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "protocolPairProfits", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "protocolProfitsTokens", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "settledTradesCount", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "settledVolume", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "swapsVolume", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "topupMap", "outputs": [ { "internalType": "uint256", "name": "amountWriter", "type": "uint256" }, { "internalType": "uint256", "name": "amountTaker", "type": "uint256" }, { "internalType": "uint256", "name": "requestTime", "type": "uint256" }, { "internalType": "uint256", "name": "acceptTime", "type": "uint256" }, { "internalType": "uint256", "name": "rejectTime", "type": "uint256" }, { "internalType": "uint256", "name": "state", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "topupRequestID", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "usdcAddress", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "usdcEquivDeposits", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "usdcEquivWithdrawals", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "usdtAddress", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "usdtEquivDeposits", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "usdtEquivWithdrawals", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "address", "name": "", "type": "address" } ], "name": "userBalanceMap", "outputs": [ { "internalType": "uint256", "name": "deposited", "type": "uint256" }, { "internalType": "uint256", "name": "withdrawn", "type": "uint256" }, { "internalType": "uint256", "name": "lockedinuse", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" }, { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "userERC20s", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "wethAddress", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "wethEquivDeposits", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "wethEquivWithdrawals", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "XeonAddress", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" } ],

Staking

stakingContractABI: [ { "inputs": [ { "internalType": "address", "name": "XeonToken", "type": "address" } ], "stateMutability": "nonpayable", "type": "constructor" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "previousOwner", "type": "address" }, { "indexed": true, "internalType": "address", "name": "newOwner", "type": "address" } ], "name": "OwnershipTransferred", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "staker", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "amount", "type": "uint256" }, { "indexed": true, "internalType": "uint256", "name": "poolID", "type": "uint256" } ], "name": "RewardClaimed", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": false, "internalType": "uint256", "name": "amount", "type": "uint256" }, { "indexed": true, "internalType": "uint256", "name": "poolID", "type": "uint256" } ], "name": "RewardsDistributed", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "staker", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "Staked", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "staker", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "amountForMining", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "amountForLiquidity", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "amountForCollateral", "type": "uint256" } ], "name": "TokensAssigned", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "staker", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "amountFromMining", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "amountFromLiquidity", "type": "uint256" }, { "indexed": false, "internalType": "uint256", "name": "amountFromCollateral", "type": "uint256" } ], "name": "TokensUnassigned", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "internalType": "address", "name": "staker", "type": "address" }, { "indexed": false, "internalType": "uint256", "name": "amount", "type": "uint256" } ], "name": "Unstaked", "type": "event" }, { "inputs": [ { "internalType": "uint256", "name": "_percentForMining", "type": "uint256" }, { "internalType": "uint256", "name": "_percentForLiquidity", "type": "uint256" }, { "internalType": "uint256", "name": "_percentForCollateral", "type": "uint256" } ], "name": "assignTokens", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "claimCollateralRewards", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "claimLiquidityRewards", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "claimRewards", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "claimedRewards", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "claimedRewardsCol", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "claimedRewardsCollateral", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "claimedRewardsLiq", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "claimedRewardsLiquidity", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "claimedRewardsStaking", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "depositCollateralRewards", "outputs": [], "stateMutability": "payable", "type": "function" }, { "inputs": [], "name": "depositLiquidityRewards", "outputs": [], "stateMutability": "payable", "type": "function" }, { "inputs": [], "name": "depositRewards", "outputs": [], "stateMutability": "payable", "type": "function" }, { "inputs": [], "name": "ethCollateralRewardBasis", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "ethLiquidityRewardBasis", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "ethRewardBasis", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "stakerAddress", "type": "address" } ], "name": "getAssignedAndUnassignedAmounts", "outputs": [ { "internalType": "uint256", "name": "assignedForMining", "type": "uint256" }, { "internalType": "uint256", "name": "assignedForLiquidity", "type": "uint256" }, { "internalType": "uint256", "name": "assignedForCollateral", "type": "uint256" }, { "internalType": "uint256", "name": "unassigned", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "getCollateralRewardsDue", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "getLiquidityRewardsDue", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "getRewardsDue", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "stakerAddress", "type": "address" } ], "name": "getStakedBalance", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "getStakers", "outputs": [ { "internalType": "address[]", "name": "", "type": "address[]" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "getTotalAssigned", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "getTotalStaked", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "getTotalUnassigned", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "lastCollateralRewardBasis", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "lastLiquidityRewardBasis", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "lastRewardBasis", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "nextUnstakeDay", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "owner", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "poolExpiry", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "renounceOwnership", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "restartPool", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_amount", "type": "uint256" } ], "name": "stake", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "name": "stakerAddresses", "outputs": [ { "internalType": "address", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "", "type": "address" } ], "name": "stakers", "outputs": [ { "internalType": "uint256", "name": "amount", "type": "uint256" }, { "internalType": "uint256", "name": "stakingTime", "type": "uint256" }, { "internalType": "uint256", "name": "lastClaimedDay", "type": "uint256" }, { "internalType": "uint256", "name": "assignedForMining", "type": "uint256" }, { "internalType": "uint256", "name": "assignedForLiquidity", "type": "uint256" }, { "internalType": "uint256", "name": "assignedForCollateral", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "stakingToken", "outputs": [ { "internalType": "contract IERC20", "name": "", "type": "address" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "startContract", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "totalAssignedForCollateral", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "totalAssignedForLiquidity", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "totalAssignedForMining", "outputs": [ { "internalType": "uint256", "name": "", "type": "uint256" } ], "stateMutability": "view", "type": "function" }, { "inputs": [ { "internalType": "address", "name": "newOwner", "type": "address" } ], "name": "transferOwnership", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [ { "internalType": "uint256", "name": "_amountFromMining", "type": "uint256" }, { "internalType": "uint256", "name": "_amountFromLiquidity", "type": "uint256" }, { "internalType": "uint256", "name": "_amountFromCollateral", "type": "uint256" } ], "name": "unassignTokens", "outputs": [], "stateMutability": "nonpayable", "type": "function" }, { "inputs": [], "name": "unstake", "outputs": [], "stateMutability": "nonpayable", "type": "function" } ]

The current smart contracts are pending modularization and have hit smart contract size limits. Modularization will open the path towards building the Lending Ecosystem.

Official closed door testing began in December 2023, a few months behind schedule.

12 testnet versions have been released prior to making the project public. Most of the work on the protocol is complete, the current testnet version is ready for the initial public testing phase.

Our testnet application delivers both the latest, fully functional backend and frontends at any given stage during the build iterations.

Xeon Protocol keeps a repository of all its code iterations on GitHub, both frontend and backend.

You can view our repository here:

https://github.com/neonhedge

Development started in April of 2023. The repository has gone through multiple code iterations ever since and continues to evolve as we aim to create the best version.

May 2024 Update

Codebase moved to new organization private repo on GitHub.

An Audit is pending and will only be done after the Testnet phase is complete. All audits will be posted here.

Our Brand

Xeon Protocol is a pioneering DeFi platform founded with the vision of revolutionizing the financial landscape through decentralized finance.

"Xeon Protocol" combines innovation and technology, encapsulated in the capitalization of the first letter of each word. Our brand can also be abbreviated as "XP" to represent our cutting-edge solutions.

"DynamicPacts" and "Neon" are two of our flagship features, each capitalized to signify their importance within the Xeon Protocol ecosystem. "DynamicPacts" and "Neon" are integral trademarks of Xeon Protocol Inc.

Branding Guidelines

To maintain the integrity and consistency of the Xeon Protocol brand, the following guidelines must be adhered to when using our name and logo in any materials or platforms:

1. Logo Usage

   • Always use the Xeon Protocol logo as provided without any alterations.

   • Do not combine the Xeon Protocol logo with other images or logos without prior consent.

2. Brand Representation

   • Do not imply any relationship, affiliation, or endorsement with Xeon Protocol unless explicitly agreed upon in writing. For example, avoid phrases like "we partner with Xeon Protocol" without written authorization.

   • The Xeon Protocol brand should not be used in any context that associates it with illegal or unlawful activities, promotions, or products.

3. Permissible Usage

   • The Xeon Protocol name and marks may be used only in relation to services provided by our firm. They must not be used alongside any illegal or unlawful activities, promotions, or products.

   • Ensure that any representation of the Xeon Protocol brand aligns with our values and mission to foster a secure, scalable, and user-centric DeFi ecosystem.

Adherence to these guidelines is crucial in preserving the reputation and identity of Xeon Protocol as a leader in decentralized finance.

Brand Links:

Brand Book https://drive.google.com/drive/folders/1nRCVQMr0UoDvFYIlOsQy-tU69VLrd2Bg?usp=drive_link

Corporate Material https://drive.google.com/drive/folders/1nRCVQMr0UoDvFYIlOsQy-tU69VLrd2Bg?usp=drive_link

After a user or wallet deposits tokens into our protocol, the tokens are now ready for use in writing or buying OTC deals.

Our protocol is designed for OTC marketplaces and acts as the custodian or escrow when parties engage in a deal.

The following actions require that collateral be locked by the protocol as the custodian during a deal.

• writing a hedge

• buying a hedge

• issuing a loan

• taking a loan

Tokens are held as collateral for the above actions. This is done by incrementing the userBalanceMap[msg.sender].lockedinuse storage for the msg.sender whilst performing these actions.

Note, the getWithdrawableBalance function mentioned in ERC20 withdrawals below, enforces the collateral or token locking mechanism by deducting lockedinuse balance whilst determining the withdrawable balance for a user / msg.sender.

Implications:

• tokens as held as collateral until the hedge deal is settled.

• tokens cannot be withdrawn or assigned for any other deal

Settlement Usage

For each party, token balances in userBalanceMap[msg.sender].lockedinuse are used as payoff collateral. Deducting payoff equivalent in underlying assets or paired currency, then crediting to the due party's userBalanceMap[msg.sender].deposited balance.

lockedinuse Restoration

During the settlement process, the settlement function first calculates the payoff required and then debits it from the userBalanceMap[msg.sender].lockedinuse of the losing party and then credits it to the userBalanceMap[msg.sender].deposited balance of winning party in the deal.