Table of Contents

○ Copy Trading
○ Prediction Markets
○ Fixed Rate Lending
○ Interest Rate Swaps
○ Generic Ethereum Oracle
○ Ethereum AMM LP Hedging
○ Peer-to-Peer (P2P) Payment App
○ Margined Trading Product
○ DeFi Management Dashboard
○ NFT Dump-to-Earn

Copy Trading

Overview

Copy trading on DEXs is a less common feature compared to CEXs due to latency and gas constraints. Injective’s sub-second block times and low gas fees can enable automated copy trading through smart contracts.

Warp has integrated with Injective and can automate smart contract executions through a decentralized network of agents. Essentially, the user specifies the criteria under which the smart contract should execute and the agents will execute the contract accordingly.

In this case, the agents can observe the block events through dynamic logic queries to determine when a given address has executed a trade. As soon as this happens, the agents will automatically execute the same trade on behalf of the user in the next block.

In order to reduce complexity and risk, the user can delegate permissions to execute trades to the smart contract through authz. This negates the need for the smart contract to hold the capital which is more appealing to users.

Hackathon MVP


  • Create a website that allows the user to input the address they want to copy. The website should also show active INJ balance for the contract so the user can fund it accordingly. It should also redirect users to helixapp.com so they can track performance of their trades and balances.
  • Develop the dynamic query as per the Warp docs. The block events for spot and derivative order creation and cancellation are: EventCancelSpotOrder, EventCancelDerivativeOrder, EventNewSpotOrders & EventNewDerivativeOrders. Keep in mind that the contract should open exposure relative to the active wallet balance. If the address we’re copying, executes a trade of 3% relative to its balance, the contract should open a trade of 3% relative to the user’s balance.
  • Develop the smart contract to execute the trades on behalf of the user through authz.

Resources



Mentor


  • Achilleas Kalantzis, Integrations Engineer

  • Discord Username: achilleaskalantzis

Prediction Markets

Overview

Injective’s fully on-chain orderbook allows users to launch various financial instruments such as spot, perpetuals, expiry futures and binary options. Prediction markets have lately attracted a vast interest across the industry but none of the key players have achieved meaningful traction due to capital inefficiency present in AMM designs and high gas fees.

Frontrunner is a protocol focusing on sports-betting set to launch on Injective’s orderbook in the coming weeks.

We propose a more generic implementation of the binary options primitive akin to Augur and Polymarket which don’t focus on a specific niche (i.e. sports betting). Injective’s orderbook and extremely low gas fees would enable high retail engagement and capital efficiency. Even though bootstrapping liquidity on an orderbook is a major problem, Mito set to launch in the upcoming months will allow users to bootstrap liquidity through vaults. Users can pull their capital into a vault which is going to be controlled by a sophisticated market-maker and provide liquidity to these markets.

Revenue Model & Incentives

Injective incentivizes vault LPs, exchange dApps and market makers through a unique design. Protocol fees are split in two portions: the auction and the fee recipient. 60% of the fees go to the auction pool whereby users can bid for a basket of tokens (mostly stablecoins) with INJ tokens. The winner receives the basket with all generated fees and the INJ used to bid, are burned.

The rest of the 40% can be set to a unique address which can be modified accordingly from the sender.

Vault LPs

Users who LP into Mito vaults will generate APY through Injective’s incentives programs, namely Trade & Earn and OLP as well as the strategy’s performance. Market makers will make money off the bid-ask spread, thus utilizing the capital more efficiently and distribute it back to the LPs.

Exchange dApp

The exchange dApp (the deliverable in this project), will set the fee recipient to an address of its choosing on the frontend page. Thus, all retail users who trade on the dApp will pay the full market fee but you will effectively receive 40% of those fees immediately to you wallet.

Market Makers

Market makers who faciliate the trading activity of the vault, will set fee recipient to an address of their choosing. All LPs will pay the full protocol fees for each trade that will be faciliated by the market maker but 40% of the fees will go back to an address the market maker owns.

Hackathon MVP


  • Develop an exchange dApp akin to Helix and Frontrunner for generalized prediction markets.

Resources


  • Protocol docs on Injective’s binary options primitive

  • API docs on Injective’s binary options

  • Polymarket’s docs and UI

  • Augur’s docs and UI

  • Helix (flagship DEX on Injective) repository. You may choose to fork the project and modify the front-end accordingly.

  • Typescript SDK & docs


Mentor


  • Bojan Angjelkoski, Technical Lead

  • Discord Username: bangjelkoski

Fixed Rate Lending

Overview

The vast majority of lending protocols follow a peer-to-pool approach that consist of variable rate models and governance. Risk-related factors and parameters such as interest rates are determined by governance in a reactive fashion as market conditions change. Even though this approach has been an innovation in DeFi and offers utility, fixed-rate lending is an untapped area.

Fixed-rate lending would allow borrowers to predict the costs of a given loan in contrast to the existing approach where costs change over time, degrading UX.

The primary parameters can be set by governance but some parameters can be set freely by participants. This would be achieved by an overcollateralized zero coupon bond-based P2P lending protocol.

Zero coupon bonds are a debt instrument that pay no interest, they rather trade at a discount and thus generate profit for the holder at maturity when redemeed.

Borrowers would set collateral in ratios pre-set by governance. Upon minting these bonds, users would be able to sell them on the market in return for the token they were looking to borrow.

Lenders would receive these bonds and exercise them for face-value at maturity.

Here is a concrete example on the flow:

  • Alice wants to borrow 1,000 USDC for 1 year.
  • The current market price for 1,000 USDC is 1,100 1-year USDC bonds.
  • Alice provides enough INJ collateral to mint 1,100 1-year USDC bonds.
  • She then proceeds to sell them in the market* for 1,000 USDC.
  • Bob, who wanted to lend 1,000 USDC, had previously placed a limit order on the market to buy 1,100 1-year USDC bonds for 1,000 USDC.
  • When Alice sells the bonds, Bob receives the 1,100 1-year USDC bonds which, at maturity, would be redeemable for their face value: 1,100 USDC. If we assume this transaction happened at the start of the 1-year period, then the implied interest rate for this loan would be 10%.

Upon maturity, borrowers have the ability to repay the loan or the system will automatically roll the maturity one additional period. This ensures that there’s always principal for lenders to redeem. This system is overcollateralized and borrowers are subject to liquidations when the ratio drops below governance-defined thresholds.

We believe an orderbook design is more expressive as lenders can quote based on their views about interest rates. As bonds reach maturity or liquidation, the system requires sophisticated market makers to supply liquidity.

Hackathon MVP


  • A bond minting mechanism that accepts collateral and handles liquidations directly on Injective’s orderbook when it falls below a threshold.
  • Create a website to incorporate the above design. The front-end should reflect on open positions and liquidation thresholds.
  • The rollover mechanism does not need to be part of the MVP.

Resources



Mentor


  • Eric Chen, CEO

  • Discord Username: ericinjective

Interest Rate Swaps

Overview

Interest rate swaps are financial derivatives commonly used in Traditional Finance (TradFi) to manage and mitigate interest rate risk. They are agreements between two parties to exchange interest rate payments over a set period of time. These contracts allow entities to transform the terms of their debt or investments to better suit their specific needs and risk profiles.

In a typical interest rate swap, there are two legs:

1. Fixed leg: One party agrees to pay a fixed interest rate on a notional amount throughout the life of the swap. The fixed rate is predetermined at the inception of the swap.

2. Floating leg: The other party agrees to pay a variable interest rate, typically tied to a reference rate such as LIBOR (London Interbank Offered Rate) or an interbank lending rate, on the same notional amount. The variable rate is reset periodically, often every three or six months, to reflect changes in the reference rate.

The key objective of interest rate swaps is to allow participants to manage interest rate exposure and cash flow uncertainties. Some common reasons for using interest rate swaps include:

1. Hedging: Businesses can use interest rate swaps to protect themselves against adverse interest rate movements. For example, a company with a variable-rate loan might swap it for a fixed-rate obligation if they expect interest rates to rise, thereby locking in a predictable interest expense.

2. Yield enhancement: Institutional investors may use interest rate swaps to increase their overall investment yield by exchanging a fixed income stream for a potentially higher variable income stream.

3. Asset-liability management: Financial institutions can use interest rate swaps to better match the duration and interest rate characteristics of their assets and liabilities, reducing potential mismatches and risk.

4. Speculation: Some market participants may use interest rate swaps as a speculative tool, taking positions on future interest rate movements.

DeFi Landscape

There are mainly two mechanisms to implement interest rate swaps on-chain.

1. Utilize CDPs to mint expiring derivatives known as “fyTokens” implemented by Yield Protocol.

2. Mint two tokens to represent the principal and yield, “pTokens” and yTokens” , effectively splitting the yield-bearing assets as implemented by Pendle.

Purpose and Functionality

  • Yield Protocol: Yield Protocol is a platform that enables users to create and trade interest rate derivatives. It allows users to mint fixed-term, fixed-rate debt tokens called fyTokens by depositing collateral (usually stablecoins). These fyTokens represent claims on the underlying collateral plus interest. Users can trade these fyTokens, enabling them to manage and speculate on interest rate exposure.
  • Pendle: Pendle is a protocol that facilitates the creation and trading of tokenized future yield streams. It allows liquidity providers (LPs) to lock their tokens, such as those obtained from providing liquidity on Automated Market Makers (AMMs), into smart contracts called Yield Tokens (yTokens). These yTokens represent future yield generated by the locked assets. Users can trade these yTokens, allowing for more efficient capital utilization and yield optimization.

Assets Supported

  • Yield Protocol primarily supports stablecoins or other assets that can be used as collateral for creating fixed-term, fixed-rate debt tokens.
  • Pendle: Pendle supports a broader range of assets, allowing users to tokenize the yield of various assets locked in different protocols, including assets from AMMs and lending protocols.

Use Cases

  • Yield Protocol: Its primary use case is interest rate management and speculation. Users can use fyTokens to hedge against interest rate volatility or speculate on interest rate movements.
  • Pendle: Pendle's main use case is yield optimization and trading. It enables LPs to tokenize their future yield streams and trade them to unlock additional capital or optimize their investment strategies.

References


Hackathon MVP


  • Create a fixed-yield primitive using the fyToken model where liquidity for fyTokens uses an on-chain order book. Choosing a single collateral token (e.g. ATOM), a single borrow token (e.g. USDC), and a single expiration date will simplify implementation. Scope can be further reduced by focusing on one side of the market (borrowing or lending).
  • Users should be able to either mint fyTokens with collateral (to borrow at a fixed rate) or purchase fyTokens from a market (to lend at a fixed rate). The user interface should simplify calculations about achieved fixed rates, and allow borrowers to monitor the health of any open positions.
  • To ensure healthy order book depth for the fyToken derivatives, design a mechanism to incentivize makers (e.g. emit tokens to makers that have orders at the top of the book multiple blocks in a row).

Resources



Mentor


  • Eric Chen, CEO

  • Discord Username: ericinjective

Generic Ethereum Oracle

Overview

We propose the integration of a generic Ethereum oracle on Injective. Oracle providers such as Pyth and Band provide a limited set of feeds that have been vetted. These feeds are usually crypto assets or hard assets such as gold or silver.

A generic Ethereum oracle would allow users to pass contract state from Ethereum to Injective and enable new use-cases. One example is Uniswap v3, uniswap pools can serve as oracles and would allow users to launch perpetual markets on Injective with arbitrary Uniswap pools as oracles.

Additionally, pool information on LPs and token ratios could enable a new product whereby users can hedge and reduce incurred IL (Impermanent Loss). A smart contract on Injective could place trades in a perpetual market for the same asset the user has incurred IL on AMMs like Uniswap.

Hackathon MVP


  • Implement a generic query-response interface for requesting and relaying Ethereum state data along with a modular proof verification layer. This should include a production-ready centralized proof of concept. The Ethereum state data will be stored on an Injective smart contract which should be structured with data storage considerations in mind in order to scale.
  • The project can then expand in a decentralized implementation of such interface via bridging infrastructure such as Wormhole or Axiom. This should not necessarily be part of the MVP.

Resources



Mentor


  • Albert Chon, CTO

  • Discord Username: albertchon

Ethereum AMM LP Hedging

Overview

This document proposes a simple, Ethereum-centric application that enables Ethereum users to hedge their LP (liquidity provider) positions on CPMMs or AMMs such as Uniswap or Curve to avoid IL (impermanent loss) and maximize LP yields. Through a simple front-end, users can bridge stable assets such as USDT and hedge their qualifying LP positions on corresponding perpetual markets on Injective. The process of hedging is fully automated with a smart contract approach.

Leveraging Injective’s infrastructure, a highly intuitive Ethereum-user facing application can be implemented with Injective interactions completely abstracted from the front-end. The application will suggest optimal amount of stable assets to hedge their existing qualifying LP positions, guide users through the bridging and Injective gas-free transactions through EIP712 signing, and begin helping users hedge their LP positions against IL (Impermanent Loss) in 1-click.

Refer to Logarithm for inspiration which is a project currently developing a similar product.

Hackathon MVP


  • Implement a Cosmwasm smart contract that ingests hedging parameters upon user subscription and executes with user deposited funds when trigger conditions are met. The user should provide permissions to the smart contract through authz, this will negate the need for the contract to hold any funds.
  • On the front-end, implement a web application that queries user’s existing Ethereum LP position balance and derive the optimal hedging parameters to suggest to the user. Additionally, leverage Injective SDKs to guide users through the bridging and transaction signing process utilizing Ethereum native wallets for hedging and withdrawal. Applicants will receive bonus points if Injective is completely abstracted from the user experience.

Resources



Mentor


  • Bojan Angjelkoski, Technical Lead

  • Discord Username: bangjelkoski

Peer-to-Peer (P2P) Payment App

Overview

This document proposes a simple payment app on Injective. Users should be able to tokens on Injective to a specified address or .inj name service (provided by SpaceID) from their mobile. The product should have an integration with all wallets available on Injective dApps.

Users should also be able to transfer any token on Injective beyond INJ.

Hackathon MVP


  • Develop a mobile application (iOS & Android) with support only for MetaMask or Keplr. The application can support only specified addresses and INJ as a token in the beginning.
  • The product can be further improved to include support for all wallets, .inj domains as well as custom tokens on Injective.

Resources



Mentor


  • Bojan Angjelkoski, Technical Lead

  • Discord Username: bangjelkoski

Margined Trading Product

Overview

This document proposes a platform that combines trading in a model akin to Rollbit. These platforms have attracted vast interest from the crypto community in the past few months. They allow traders to deploy capital in assets with extremely high leverage and potentially attain huge rewards.

Even though the design of these platforms is not sound and might be prone to insolvency, aggressive liquidation framework and fees’ distribution can bootstrap liquidity in the early phases. The majority of the fees can be distributed back to the protocol to increase the pool size and potential losses when users make sizeable successful trades.

The product can expand to Sports, NFTs and more but the scope should be kept to trading and perpetual markets in the beginning for the MVP. The entire product should be fully decentralized with on-chain execution through CosmWasm smart contracts.

Hackathon MVP


  • Develop a web application focused on perpetual markets with a peer-to-pool design. There should be a single pool for all markets and only launch top 20 tokens that are relatively non-volatile to ensure there’s a low risk of insolvency.
  • The product should also have relatively low leverage in the beginning (30-40x) with fee distribution back to the pool and LPs until the ecosystem grows. Tokenomics can be further improved with a token buy-back mechanism or fee discounts.
  • Pyth oracle prices from Injective’s oracle module should be utilized in the formula designs.

Resources



Mentor


  • Achilleas Kalantzis, Integrations Engineer

  • Discord Username: achilleaskalantzis

DeFi Management Dashboard

Overview

This document proposes a DeFi management dashboard akin to DeFi Saver. The Injective ecosystem has seen a surge in ecosystem growth with DeFi dApps such as Mito, Helix, Elixir, Black Panther, Neptune and many more. The DeFi dashboard would allow users to view exposure and interact with DeFi applications on Injective from a single page.

Effectively, they would be able to see and close LP positions in dApps such as Mito and Elixir. Additionally, users could add also view positions on dApps such as Helix and Neptune as well as interact with these protocols (i.e. add margin to avoid liquidation).

Hackathon MVP


  • Create a web application that shows open positions across the aforementioned dApps on Injective.
  • Add CTA buttons to close positions and increase margin for the respective dApps. For the MVP, these buttons should redirect the user to the respective dApp for the interaction.
  • The product can be further improved by adding functionality to interact with these protocols from the web application and remove redirection which degrades UX.

Resources



Mentor


  • Bojan Angjelkoski, Technical Lead

  • Discord Username: bangjelkoski

NFT Dump-to-Earn

Overview

NFTs on Injective have seen massive growth with more and more marketplaces and collections go live. We propose an NFT dump-to-earn protocol whereby users can dispose their NFTs in return for a token or “fish” NFTs disposed by others akin to JunkYard.

Users might want to dispose NFTs they consider as useless and can’t be sold in a marketplace. In return they receive “JunkCoin”.

Users can also “fish” for NFTs disposed by others by paying a small fee.

Hackathon MVP


  • Develop a FE site and smart contracts for the NFT disposal. The “fish” functionality can be added at a later stage and should not necessarily be part of the MVP.

Resources



Mentor


  • Achilleas Kalantzis, Integrations Engineer

  • Discord Username: achilleaskalantzis