Today we have another interesting project named as Injective Protocol. It’s claimed to be the first layer-2 DEX that unlocks the full potential of decentralised derivatives and borderless DeFi.
Architecture of the Protocol
Injective protocol is composed of five principal components as stated on their website here.
- Injective Chain
- Injective Exchange Client
- Injective API Provider
- Injective EVM RPC provider
- Injective Bridge Contracts on Ethereum
It’s the core backbone for Injective’s layer-2 derivatives platform and hosts a fully decentralized order-book, trade execution coordinator, EVM execution environment, and bi-directional token bridge to Ethereum.
Layer-2 EVM Execution Environment
It supports smart contract execution through a modular implementation of the Ethereum Virtual Machine (EVM) on top of the Cosmos-SDK. By implementing the EVM on top of Tendermint, users enjoy a scalable and interoperable implementation of Ethereum built on Proof-of-Stake with 1-Block finality.
Developers can also enjoy a similar thing for creating dApps on Injective EVM, with additional benefits including native support for transaction fee delegation and an increased contract byte-code size limit of 100KB.
You can read more about it here.
Injective Exchange Client
Injective provides a powerful, full-fledged decentralized exchange open-source front-end implementation allowing anyone to easily participate in the decentralized exchange protocol in a fully permission-less manner.
The Injective Client is a comprehensive yet friendly graphical user interface catered towards the general public as well as more advanced users. Relayers can host the client on a server to allow users to interact with the protocol. Individuals can also run the client from their locally to directly interact with the protocol. The exchange client interface will also be deployed on IPFS.Injective Protocol
Injective API Provider
Injective’s model rewards relayers in the Injective network for sourcing liquidity. By doing so, exchange providers are incentivized to better serve users, competing amongst each other to provide better user experience, thus broadening access to DeFi for users all around the world.
Injective API nodes have two purposes:
1) providing transaction relay services and 2) serving as a data layer for the protocol.
Transaction Relay Service
Although users can directly interact with the Injective Chain by broadcasting a compatible Tendermint transaction encoding a compatible message type, doing so would be cumbersome for most users. To this end, API nodes provide users a simple HTTP, gRPC and Websocket API to interact with the protocol. The API nodes then formulate the appropriate transactions and relay them to the Injective Chain.
Injective Exchange API nodes also serve as a data layer for external clients. Injective provides a data and analytics API which is out-of-the-box compatible with Injective’s sample frontend interface.
The Injective API supports the Injective Derivatives and Spot Exchange APIs for the Injective Client, the 0x Standard Coordinator API, the Injective Derivatives Protocol Graph Node GraphQL API and other API services required by the Injective Exchange Client. A partial specification for this API can be found at api.injective.dev.
Injective ⮂ Ethereum Bridge
Users can transfer ERC-20 tokens from Ethereum through the bi-directional Injective Token Bridge, which serves as a two-way Ethereum peg-zone for ERC-20 tokens to be transferred to the Injective Chain EVM. The peg-zone is based off Peggy and is secured by the Proof-of-Stake security of the Injective Chain. ERC-20 tokens can be transferred to and from Ethereum to the Injective Chain through the Injective Bridge . The process to do so is inspired by the standard flow as defined by Peggy.
Ethereum → Injective Chain
The following is the underlying process involved in transferring ERC-20 tokens from Ethereum to the Injective Chain. Validators witness the locking of ERC20 assets and sign a data package containing information about the lock, which is then relayed to the Injective chain and witnessed by the EthBridge module. Once a quorum of 2/3 of the validators by signing power have confirmed that the transaction’s information is valid, the funds are released by the Oracle module and are transferred to the intended recipient’s Cosmos address if a Cosmos address was specified in the lock event. The user can also choose to transfer the ERC-20 token to the corresponding child ERC-20 token on the Injective EVM chain.
This process is abstracted away from the end user, who simply needs to transfer their ERC-20 to the Injective Peg Zone contract and specify whether they desire to have their funds sent to their Cosmos address (represented in the Cosmos bank module) or on the child ERC-20 contract on the Injective EVM.
On a high level, the transfer flow for transferring a token to the is as follows:
- User sends the ERC-20 to the Injective Bridge Contract, emitting a LogLock event.
- An Injective relayer listening to the event creates and signs a Tendermint transaction encoding this information which is then broadcasted to the Injective Chain.
- The nodes of the Injective Chain verify the validity of the transaction.
- New tokens representing the ERC-20 are minted in the bank module.
Thereafter, the ERC-20 can be used on Injective Chain’s EVM as well as in the Cosmos-SDK based application logic of the Injective Chain. In the future, the Injective chain will support cross-chain transfers using Cosmos IBC.
Injective Chain → Ethereum
The following is the underlying process involved in transferring ETH/ERC-20 tokens from the Injective Chain to Ethereum.
Validators witness transactions on the Injective Chain and sign a data package containing the information. The user’s ETH/ERC-20 on the Injective Chain is burned, resulting in unlocking the ERC-20 on Ethereum. The data package containing the validator’s signature is then relayed to the Injective Bridge contracts deployed on the Ethereum blockchain. Once enough other validators have confirmed that the transaction’s information is valid, the funds are released/minted to the intended recipient’s Ethereum address.
Now let’s discuss about the Token Itself
1. Proof of Stake Security
To ensure the security of our sidechain, we inflate the supply of our token to incentivize nodes to stake INJ and participate in the Injective network.
The tentative initial supply of INJ will be set to 100,000,000 tokens and shall increase for a finite amount of time through block rewards.
The target INJ inflation will tentatively be 7% at genesis and decrease over time to 2%. Over time, the total supply of INJ may be lower than the initial supply due to our deflationary mechanism detailed in the Exchange Fee Value Accrual section above.
The INJ token can be used to govern various components of our sidechain including the futures protocol, exchange parameters and protocol upgrades.
The governance process for the Injective Chain core node is divided in a few steps that are outlined below:
- Proposal submission: Proposal is submitted to the blockchain with a deposit.
- Vote: Once deposit reaches a certain value (
MinDeposit), proposal is confirmed and vote opens. Bonded INJ holders can then send
TxGovVotetransactions to vote on the proposal.
- If the proposal involves a software upgrade (as opposed to a Plain Text proposal):
- Signal: Validators start signaling that they are ready to switch to the new version.
- Switch: Once more than 75% of validators have signaled that they are ready to switch, their software automatically flips to the new version.
For any governance decision, INJ holders can initiate a referendum by submitting a signed on-chain proposal. Once at least 1% of the total supply of INJ token holders support the proposal, a 14-day referendum period will commence. During this time, INJ holders do not need to lock their tokens and can simply submit their vote on-chain. Their voting power, which is proportional to their token balance, will be calculated at the end of the 14-day period. After the voting window elapses, the proposal will only be accepted if a majority of voting power approve the proposal and if more than a predetermined percentage of the total token supply has participated in the election.
3. Market Maker Incentives
Make orders will receive a net positive fee rebate to incentivize liquidity. Distribution will happen periodically based on snapshots.
Our decentralized exchange will initially implement a global minimum exchange fee ofrm=0.1%rm=0.1%for makers andrt=0.2%rt=0.2%for takers.
As one mechanism of bootstrapping liquidity in the two-sided market of our decentralized exchange, we incentivize market makers to provide liquidity through exchange fee rebates in our INJ token. Traders who place make orders that are filled are proportionally rewarded (byαfilledαfilled) with a filled make order rebate reward equal to:Filled Make Order Rebate=αfilled(δ⋅rm)Filled Make Order Rebate=αfilled(δ⋅rm)
Whereδδis the ratio between the market value of the reward and the exchange fee. The distribution of the INJ token will be done off-chain and a minimum threshold of the aggregate make order notional value for each address will be in place to qualify for the market maker incentive. At genesis,δδwill be greater than 1 and slowly decrease to 0.5 in linear time over 4 years.
4. Relayer Incentives
Nodes and validators of the Injective sidechain also have the capability to act as relayers who can cater to traders in their desired ways (e.g. a relayer can provide an improved interface/API catering to a specialized group of traders). As an incentive mechanism for relayers to provide the best experience for traders, we reward relayers who originate orders into the shared orderbook. The node that first discovers a make order (by relaying to the shared order-book) will receive a ratio of the exchange fee of each make order discovered by them.
Similarly, the node that first relays a take order will receive a ratio of the exchange fee of each make order discovered by them.
At genesis, δδ will be set at 40% and subject to change by governance.
5. Exchange Fee Value Accrual
After the relayer reward distribution, the rest of the exchange fee will undergo an on-chain buy-back-and-burn event to accrue value for INJ. Since it’s not necessary for users to utilize INJ for the exchange fee, exchange fees collected from all trading pairs are aggregated over a set period of time and sold in batch to market makers who bid with INJ tokens. To achieve this, we utilize an absolute auction mechanism that repeats every month. A derivatives protocol contract will continuously aggregate all exchange fees collected during the monthly period into a pool and then conduct a week-long blind auction at the end of the period. The smart contract will simply verify and select the highest bid to conduct the exchange. All proceeds from the auction will be burnt.
6. Collateral Backing for Derivatives
INJ will be utilized as an alternative to stablecoins as margin and collateral for Injective’s derivatives markets. In some futures markets, INJ can also be used as collateral backing or insurance pool staking where stakers can earn interest on their locked tokens.
7. Exchange participation incentives
We plan to distribute a fixed number of INJ tokens daily over a predetermined period of time. Each day, a snapshot of all account profit-and-loss in selected markets will be taken. An aggregate profit-and-loss for the address will be calculated and used as the weight for token distribution. In practice, an avid Injective participant with high notional profit will receive more INJ than another participant with lower notional profit, even if he or she has a higher profit-and-loss percentage.
How to buy Injective Protocol !
- Sign up on WazirX Exchange.
- Complete your KYC.
- Deposit INR to your account.
- Trade !
That was easy right !
Here’s the link to make it even easier. Click Here.
Summary of the project
With the use cases of this project in field of Governance, Exchange Fee Value Capture, derivatives collateralization, liquidity mining, and staking, I feel that it’s a great project which one should look at.