Polkastarter

Injective Protocol is a fully decentralized layer-2 DEX protocol built for the next generation of decentralized derivatives exchange.
The Injective Chain is a Tendermint-based IBC-compatible blockchain which supports a decentralized orderbook-based DEX protocol and a trustless ERC-20 token bridge to the Ethereum blockchain.
It is the first layer-2 fully decentralized exchange protocol for decentralized perpetual swaps, futures, and spot trading that unlocks the full potential of decentralized derivatives and borderless DeFi. Every component of the protocol has been built to be fully trustless, censorship-resistant, publicly verifiable, and front-running resistant.
By providing the unrestricted and unprecedented ability to express diverse views in the decentralized financial markets, we are striving to empower individuals with the ability to more efficiently allocate capital in our society.
Injective Protocol’s infrastructure is comprised of three principal components:
The Injective Chain is a layer-2 sidechain and Cosmos Zone connected to Ethereum.
The chain itself is built on top of Tendermint and allows for the transferring and trading of Ethereum-based assets on the Injective Chain.
The Injective Chain’s primary purpose is to power the Injective Exchange protocol, which is a decentralized peer-to-peer spot and derivatives exchange protocol. The protocol allows individuals to create and trade on arbitrary derivative markets.
Unlike traditional exchanges which serve as gatekeepers to the crypto industry, Injective transforms an exchange into a decentralized public utility. What truly differentiates Injective is that we bring every component of a decentralized exchange to the public. Everything — from the front-end exchange interface to back-end infrastructure to orderbook liquidity — is provided openly and for free.
This transforms the traditional business model of exchanges as we eliminate the technical barrier to entry for individuals to freely run a highly performative exchange.
Injective’s model rewards relayers in the Injective network for sourcing liquidity. By doing so, exchange providers are incentivized to better serve users as they compete amongst each other to provide better user experiences. Thus, this allows users from all around the world to access decentralized financial markets.
The Injective Chain is the core backbone for Injective’s layer-2 derivatives platform.
Beyond the standard imported modules from the Cosmos-SDK, the Injective chain itself is comprised of 5 unique modules:
Injective defines its own custom Account
type that uses Ethereum’s ECDSA secp256k1 curve for keys. This satisfies the EIP84 for full BIP44 paths. The root HD path for Injective-based accounts is m/44'/60'/0'/0
.
There are 3 main types of Addresses
/PubKeys
available by default on Injective:
message
). They are derived using the eth_secp256k1
curve.eth_secp256k1
curve.ed25519
curve.Address bech32 Prefix | Pubkey bech32 Prefix | Curve | Address byte length | Pubkey byte length | |
---|---|---|---|---|---|
Accounts | inj |
injpub |
eth_secp256k1 |
20 |
33 (compressed) |
Validator Operator | injvaloper |
injvaloperpub |
eth_secp256k1 |
20 |
33 (compressed) |
Consensus Nodes | injvalcons |
injvalconspub |
ed25519 |
20 |
32 |
EthAccount
s can be represented in both Bech32 and hex format for Ethereum’s Web3 tooling compatibility.
The Bech32 format is the default format for Cosmos-SDK queries and transactions through CLI and REST clients. The hex format on the other hand, is the Ethereum common.Address
representation of a Cosmos sdk.AccAddress
.
inj14au322k9munkmx5wrchz9q30juf5wjgz2cfqku
0xAF79152AC5dF276D9A8e1E2E22822f9713474902
{"@type":"/injective.crypto.v1beta1.ethsecp256k1.PubKey","key":"ApNNebT58zlZxO2yjHiRTJ7a7ufjIzeq5HhLrbmtg9Y/"}
Avalanche is an open-source platform for launching decentralized applications and enterprise blockchain deployments in one interoperable, highly scalable ecosystem. Avalanche is the first decentralized smart contracts platform built for the scale of global finance, with near-instant transaction finality. Ethereum developers can quickly build on Avalanche as Solidity works out-of-the-box.
A key difference between Avalanche and other decentralized networks is the consensus protocol. Over time, people have come to a false understanding that blockchains have to be slow and not scalable. The Avalanche protocol employs a novel approach to consensus to achieve its strong safety guarantees, quick finality, and high-throughput without compromising decentralization.
AVAX is the native token of Avalanche. It’s a hard-capped, scarce asset that is used to pay for fees, secure the platform through staking, and provide a basic unit of account between the multiple subnets created on Avalanche. 1 nAVAX
is equal to 0.000000001 AVAX
.
Protocols in the Avalanche family operate through repeated sub-sampled voting. When a validator is determining whether a transaction should be accepted or rejected, it asks a small, random subset of validators whether they think the transaction should be accepted or rejected. If the queried validator thinks the transaction is invalid, has already rejected the transaction, or prefers a conflicting transaction, it replies that it thinks the transaction should be rejected. Otherwise, it replies that it thinks the transaction should be accepted.
If a sufficiently large portion (alpha α) of the validators sampled reply that they think the transaction should be accepted, the validator prefers to accept the transaction. That is, when it is queried about the transaction in the future, it will reply that it thinks the transaction should be accepted. Similarly, the validator will prefer to reject the transaction if a sufficiently large portion of the validators replies that they think the transaction should be rejected.
The validator repeats this sampling process until alpha of the validators queried reply the same way (accept or reject) for beta β consecutive rounds.
In the common case when a transaction has no conflicts, finalization happens very quickly. When conflicts exist, honest validators quickly cluster around conflicting transactions, entering a positive feedback loop until all correct validators prefer that transaction. This leads to the acceptance of non-conflicting transactions and the rejection of conflicting transactions.
It is guaranteed (with high probability based on system parameters) that if any honest validator accepts or rejects a transaction, all honest validators will accept or reject that transaction.
Learn more technical components of the Avalanche consensus protocol by reading the whitepaper.
Snowman is a chain-optimized consensus protocol–high-throughput, totally-ordered, and great for smart contracts. Snowman is powered by the Avalanche consensus protocol. Both P-Chain and C-Chain implement the Snowman consensus protocol.
Uses a novel consensus protocol, developed by a team of Cornell computer scientists, and is able to permanently confirm transactions in under 1 second.
Capable of 4,500 transactions per second–an order of magnitude greater than existing blockchains.
Ensures stronger security guarantees well-above the 51% standard of other networks.
Easily create custom blockchains and decentralized apps that contain almost any arbitrary logic.
Uses energy-efficient proof-of-stake consensus algorithm rather than proof-of-work.
Supports the creation of Solidity smart contracts and your favorite Ethereum tools like Remix, Metamask, Truffle, and more.
Create your own public or private blockchains.
Native support for easily creating and trading digital smart assets with complex, custom rulesets.
Avalanche features 3 built-in blockchains: Exchange Chain (X-Chain), Platform Chain (P-Chain), and Contract Chain (C-Chain). All 3 blockchains are validated and secured by the Primary Network. The Primary Network is a special subnet, and all members of all custom subnets must also be a member of the Primary Network by staking at least 2,000 AVAX.
Here are tutorials on creating a subnet and adding validators to a subnet.
A subnet, or subnetwork, is a dynamic set of validators working together to achieve consensus on the state of a set of blockchains. Each blockchain is validated by exactly one subnet. A subnet can validate many blockchains. A node may be a member of many subnets.
A subnet manages its own membership, and it may require that its constituent validators have certain properties. This is very useful, and we explore its ramifications in more depth below:
Avalanche’s subnet architecture makes regulatory compliance manageable. As mentioned above, a subnet may require validators to meet a set of requirements.
Some examples of requirements include:
(To be abundantly clear, the above examples are just that: examples. These requirements do not apply to the Avalanche Primary Network.)
You can create a subnet where only certain pre-defined validators may join and create a private subnet where the contents of the blockchains would be visible only to those validators. This is ideal for organizations interested in keeping their information private.
In a heterogeneous network of blockchains, some validators will not want to validate certain blockchains because they simply have no interest in those blockchains. The subnet model allows validators to only concern themselves with blockchains that they care about. This reduces the burden on validators.
Different blockchain-based applications may require validators to have certain properties. Suppose there is an application that requires large amounts of RAM or CPU power. A Subnet could require that validators meet certain hardware requirements so that the application doesn’t suffer from low performance due to slow validators.
A Virtual Machine (VM) defines the application-level logic of a blockchain. In technical terms, it specifies the blockchain’s state, state transition function, transactions, and the API through which users can interact with the blockchain. Every blockchain on Avalanche is an instance of a VM.
When you write a VM, you don’t need to concern yourself with lower-level logic like networking, consensus, and the structure of the blockchain. Avalanche does this behind the scenes so you can focus on the thing you would like to build.
Think of a VM as a blueprint for a blockchain; you can use the same VM to create many blockchains, each of which follows the same ruleset but is logically independent of other blockchains.
At first, blockchain networks had one Virtual Machine (VM) with a pre-defined, static set of functionality. This rigid, monolithic design limited what blockchain-based applications one could run on such networks.
People who wanted custom decentralized applications had to create their own, entirely new blockchain network from scratch. Doing so required a great deal of time and effort, offered limited security, and generally resulted in a bespoke, fragile blockchain that never got off the ground.
Ethereum made a step toward solving this problem with smart contracts. Developers didn’t need to worry about networking and consensus, but creating decentralized applications was still hard. The Ethereum VM has low performance and imposes restrictions on smart contract developers. Solidity and the other few languages for writing Ethereum smart contracts are unfamiliar to most programmers.
Avalanche VMs (AVMs) make it easy to define a blockchain-based decentralized application. Rather than new, limited languages like Solidity, developers can write VMs in Go (other languages will be supported in the future).
Avalanche supports the creation of new instances of the Avalanche VM.
Avalanche also supports creating custom blockchains with virtual machines.
The X-Chain acts as a decentralized platform for creating and trading digital smart assets, a representation of a real-world resource (e.g., equity, bonds) with a set of rules that govern its behavior, like “can’t be traded until tomorrow” or “can only be sent to US citizens.”
One asset traded on the X-Chain is AVAX. When you issue a transaction to a blockchain on Avalanche, you pay a fee denominated in AVAX.
The X-Chain is an instance of the Avalanche Virtual Machine (AVM). The X-Chain API allows clients to create and trade assets on the X-Chain and other instances of the AVM. See this for more details.
The P-Chain is the metadata blockchain on Avalanche and coordinates validators, keeps track of active subnets, and enables the creation of new subnets. The P-Chain implements the Snowman consensus protocol.
The P-Chain API allows clients to create subnets, add validators to subnets, and create blockchains.
The C-Chain allows for the creation smart contracts using the C-Chain’s API.
The C-Chain is an instance of the Ethereum Virtual Machine powered by Avalanche.