{
match msg {
// ... other message handling ...
ExecuteMsg::SendTokens { recipient, amount } => try_send(info, recipient, amount),
}
}
```
## Testing
As with other smart contract functions, you should add unit tests to ensure your bank send functionality works as expected. This includes testing different scenarios, such as sending various token amounts and handling errors correctly.
You may use [test-tube](https://github.com/InjectiveLabs/test-tube) for running integration tests that include a local Injective chain.
Congratulations! You've created and interacted with your first Injective smart contract and now know how to get started with CosmWasm development on Injective. Continue to Creating a Frontend for Your Contract for a guide on creating a web UI.
# Whitelisting deployment address
Source: https://docs.injective.network/developers-cosmwasm/whitelisting-deployment-address-guide
Contract upload on Injective mainnet requires governance approval. You can read through the guide to do so in the [mainnet-deployment.md](/developers-cosmwasm/mainnet-deployment-guide/ "mention") guide.
This structure has been put in place for multiple reasons:
1. Historically, the community has discovered vulnerabilities in CosmWasm whereby certain contracts could cause a chain halt. Thus, requiring approval will be inherently more secure until the language matures and stabilizes over time.
2. Governance prevents unaudited and bogus contracts from being deployed into the network, ensuring that hacks and scams will occur at a lesser degree.
3. This results in a more curated experience for ecosystem users, since the blockchain does not fill up with unwanted transactions and contracts.
This governance process is time-consuming for validators and the community. Injective builders additionally face a 4-day wait to roll out features, affecting developer experience and user growth.
As of the Altaris chain upgrade, it is now possible to request whitelisting your address for contract uploads.
## Submission Guidelines
To be considered for a whitelist approval, it is strongly recommended to include all the following information in the governance proposal. Validators are recommended to contact the Foundation in Discord to verify the information submitted for each proposal before voting.
1. Are the identities of the team members known to the community?
2. Has the team completed KYC/KYB with the Injective Foundation?
3. How long has the protocol been live on Injective mainnet?
4. Has the team developed applications in other ecosystems? (provide the details)
## Voting Guidelines
Users that meet these criteria will have a greater chance at receiving whitelist permissions:
1. The project has completed Injective Foundation KYC/KYB and the team members' identities are known to the community. *Exception: Anonymous developers with proven credibility and successful apps in other ecosystems.*
2. The project has been live on mainnet for at least 1 month and has achieved significant TVL/usage.
## Operational Guidelines
It is strongly recommended to use a multisig or Ledger wallet for the whitelisted uploads.
# Min Price Tick Size
Source: https://docs.injective.network/developers-defi/calculate-min-price-tick-size
## Minimum Market Price Tick Size
The minimum market price tick size dictates the smallest increment by which an order price can increase or decrease. For instance, if a market has a minimum price tick size of **0.001**, an order submitted with a price of **0.0011** would be rejected because it does not align with the allowed increments.
**Note:** The formulas for calculating the price tick size differ between spot and derivative markets.
### Spot Market
#### Conversion from Human-Readable Format to Chain Format
Using the INJ/USDT market as an example, which has **18 base decimals** and **6 quote decimals**, the conversion to chain format is as follows:
$\text{chainFormat} = \text{value} \times 10^{(\text{quoteDecimals} - \text{baseDecimals})}$
#### Conversion from Chain Format to Human-Readable Format
To convert back to a human-readable format:
$\text{humanReadableFormat} = \text{value} \times 10^{(\text{baseDecimals} - \text{quoteDecimals})}$
### Derivative Market
#### Conversion from Human-Readable Format to Chain Format
Using the INJ/USDT perpetual market with **6 quote decimals** as an example, the conversion to chain format is:
$\text{chainFormat} = \text{value} \times 10^{-\text{quoteDecimals}}$
#### Conversion from Chain Format to Human-Readable Format
To convert back to a human-readable format:
$\text{humanReadableFormat} = \text{value} \times 10^{-\text{quoteDecimals}}$
Also, be sure to check out our [concepts](../developers/concepts/calculation-min-price-tick-size/).
# Denom Metadata
Source: https://docs.injective.network/developers-defi/denom-and-bank
A `denom` is how tokens are represented within the `Bank` module of Injective. These assets can be used for trading, creating new markets on the exchange module, participating in auctions, transferring to another address, etc.
One of the biggest pain points for developers and traders is getting the metadata of these `denoms`. This metadata includes `decimals`, `symbol`, `name`, etc.
This guide shows how to fetch `denom` metadata directly from the `injective-lists` repository and map it to your `denom`. You can also use this approach to map `denoms`'s metadata for Spot and Derivative Markets.
## Injective Lists
`injective-lists` is a public repository that holds metadata information for all tokens on Injective. It's the most up-to-date and reliable source of this particular information. You can submit your token information by creating a PR for this repo. Be sure to correctly specify the fields. In particular, `"denom"` field (read about [token standards](/defi/tokens/)) should have respective `ibc`, `peggy` and `factory` prefixes depending on the token standard.
The metadata is fetched automatically for new `denoms` on chain every 30 minutes and the `json` files are regenerated.
You can head to the [https://github.com/InjectiveLabs/injective-lists/tree/master/json/tokens](https://github.com/InjectiveLabs/injective-lists/tree/master/json/tokens) folder and download the metadata based on the environment:
1. [Mainnet Raw JSON](https://raw.githubusercontent.com/InjectiveLabs/injective-lists/refs/heads/master/json/tokens/mainnet.json)
2. [Testnet Raw JSON](https://github.com/InjectiveLabs/injective-lists/blob/master/json/tokens/testnet.json)
Once you have the JSON, you have to map the metadata with the particular `denom`.
The interface that this metadata information has is
```typescript theme={null}
export interface Token {
name: string;
logo: string;
symbol: string;
decimals: number;
coinGeckoId: string;
denom: string;
address: string;
tokenType: string;
tokenVerification: string;
}
```
### Bank Balance
Let's say you fetch the bank balance of a particular address (as shown on the example below using TypeScript), you can easily map it to the metadata information from the JSON files above
```typescript theme={null}
import { config } from "dotenv";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { ChainGrpcBankApi } from "@injectivelabs/sdk-ts/client/chain";
import { IndexerGrpcPortfolioApi } from "@injectivelabs/sdk-ts/client/indexer";
config();
/** Querying Example */
(async () => {
const endpoints = getNetworkEndpoints(Network.MainnetSentry);
const chainGrpcBankApi = new ChainGrpcBankApi(endpoints.grpc);
const injectiveAddress = "inj...";
const { balances } = chainGrpcBankApi.fetchBalances(injectiveAddress);
console.log(bankBalances);
const metadata = JSON.parse(await readFile("./mainnet.json", "utf8")) as {
denom: string;
address: string;
decimals: string;
logo: string;
name: string;
tokenType: string;
coinGeckoId: string
}[];
const balances = bankBalances.map((balance) => {
const meta = metadata.find((m) => m.denom === balance.denom);
return {
...balance,
...meta,
};
}
console.log(balances)
})();
```
Now, your bank balance has all of the metadata information that you need (including `decimals`, `symbol`, `name`, `logo`, etc).
### Spot Market
Similar to the Bank balances, you can use the same approach to map the `denoms` within a Spot market with it's metadata.
```typescript theme={null}
import { config } from "dotenv";
import { readFile } from "fs/promises";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcSpotApi } from "@injectivelabs/sdk-ts/client/indexer";
config();
/** Querying Example */
(async () => {
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer);
const markets = await indexerGrpcSpotApi.fetchMarkets();
console.log(markets);
const metadata = JSON.parse(await readFile("./mainnet.json", "utf8")) as {
denom: string;
address: string;
decimals: string;
logo: string;
name: string;
tokenType: string;
coinGeckoId: string;
}[];
const marketsWithMetadata = markets.map((market) => {
const baseTokenMetadata = metadata.find(
(m) => m.denom === market.baseDenom
);
const quoteTokenMetadata = metadata.find(
(m) => m.denom === market.quoteDenom
);
return {
...market,
baseTokenMetadata,
quoteTokenMetadata,
};
});
console.log(marketsWithMetadata);
})();
```
### Derivative Market
Similar to the Bank balances, you can use the same approach to map the `denom` within a Derivative market with it's metadata.
```typescript theme={null}
import { config } from "dotenv";
import { readFile } from "fs/promises";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcDerivativesApi } from "@injectivelabs/sdk-ts/client/indexer";
config();
/** Querying Example */
(async () => {
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativeApi = new IndexerGrpcDerivativesApi(
endpoints.indexer
);
const markets = await indexerGrpcDerivativeApi.fetchMarkets();
console.log(markets);
const metadata = JSON.parse(await readFile("./mainnet.json", "utf8")) as {
denom: string;
address: string;
decimals: string;
logo: string;
name: string;
tokenType: string;
coinGeckoId: string;
}[];
const marketsWithMetadata = markets.map((market) => {
const baseTokenMetadata = metadata.find(
(m) => m.denom === market.baseDenom
);
return {
...market,
quoteTokenMetadata,
};
});
console.log(marketsWithMetadata);
})();
```
# Overview
Source: https://docs.injective.network/developers-defi/index
Injective marks the forefront of exchange-focused layer-1 blockchains offering decentralized perpetual swaps, futures, and spot trading. It fully taps into the possibilities of decentralized derivatives and borderless DeFi. Every component is designed to embody complete trustlessness, resistance to censorship, public verifiability, and resilience against front-running.
Injective enables traders to create and trade arbitrary spot and derivatives markets. Injective also enables on-chain limit orderbook management, on-chain trade execution, on-chain order matching, on-chain transaction settlement, and on-chain trading incentive distribution through the logic codified by the Injective Chain's [Exchange Module](/developers-native/injective/exchange).
## Build an Orderbook DEX on Injective
As an incentive mechanism to encourage exchanges to build on Injective and source trading activity, exchanges that originate orders into the shared orderbook of Injective's exchange protocol ([read more](/developers-native/injective/exchange)) are rewarded with $β=40%β=40%$ of the trading fee from orders that they source. The exchange protocol implements a global minimum trading fee of $rm=0.1%rm=0.1%$ for makers and $rt=0.2%rt=0.2%$ for takers.
The goal of Injective's incentive mechanism is to allow exchanges competing amongst each other to provide a better user experience and to better serve users, broadening access to DeFi for users all around the world.
An exchange can easily set up a client (such as a UI on web or mobile) and an API provider.
Head to our [DEX tutorial](/developers/dapps/example-dex) to bootstrap your DEX with a few clicks!
# Injective Trader
Source: https://docs.injective.network/developers-defi/injective-trader/index
# Injective Trader
Injective Trader is a professional-grade framework that provides a high-performance, reliable foundation for developing and deploying algorithmic trading strategies on the Injective blockchain. It bridges the gap between algorithmic trading strategies and blockchain execution, eliminating technical barriers. The framework takes care of the heavy lifting - real-time data streaming, order execution, reconnection/recovery, transaction batching, and analytics This frees up traders to focus solely on strategy development rather than blockchain complexities.
You can use it to import existing strategies or create new ones that:
* **Place orders automatically** based on your logic
* **Monitor markets 24/7** and react to price changes
* **Manage risk** with built-in limits and safety features
* **Handle multiple markets** simultaneously
* **Provide detailed logs** of all trading activity
### Core Capabilities
**Simplified Strategy Development**
* No SDK expertise required - focus purely on trading logic
* Rapid strategy deployment with minimal technical overhead
* Event-driven architecture enabling intuitive strategy implementation
**Built-in Reliability**
* Automated reconnection and recovery mechanisms
* Transaction validation before execution
* Comprehensive error handling and retry logic
**Performance Optimization**
* Intelligent transaction batching for cost reduction
* Automatic fee management and optimization
* Multi-account support for scale
**Enterprise-Ready Features**
* Complete position and PnL tracking
* Risk management capabilities
* Detailed performance analytics
Injective trader transacts assets with real value, as such security is paramount. Be sure to use the following as a security baseline, and also take further measures to protect your assets.
* **Never share private keys** or commit them to Git.
* Store secrets in a local **`.env` file** and load via environment variables.
* For extra safety, consider using
[**AuthZ**](https://github.com/InjectiveLabs/injective-trader/tree/master?tab=readme-ov-file#authorization-trading-authz)
to grant trading rights without exposing your main account.
## Quick Start (5 minutes)
### 1. Get Your Injective Account Ready (and Funded)
1. **Create an account** on Injective using Keplr or `injectived`.
2. If using Keplr, **export your private key** for the `.env` file.
* *Tip: With AuthZ, you can grant limited permissions to a trading account for better security.*
3. **Fund your account** with USDT by sending from another Injective address, or via [bridge.injective.network](http://bridge.injective.network/).
* *EVM tip: You can derive your `inj` address with the TS SDK and bridge USDT from Ethereum to Injective without even setting up an Injective account.*
### 2. Download and Setup
```bash theme={null}
git clone https://github.com/InjectiveLabs/injective-trader.git
cd injective-trader
# Create a virtual environment (recommended)
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\Activate.ps1
pip install -r requirements.txt
pip install "injective-py==1.9"
```
*Note: `injective-trader` is not yet compatible with `injective-py` v1.11.*
### 3. Configure Your Strategy
Edit the preexisting `config.yaml`:
```yaml theme={null}
Exchange: Helix
ConsoleLevel: INFO
FileLevel: DEBUG
Components:
Initializer:
Network: mainnet
BotName: MyBot
MarketTickers:
- INJ/USDT PERP
- BTC/USDT PERP
- ETH/USDT PERP
Strategies:
MyMarketMaker:
Name: "MyMarketMaker"
Class: "SimpleStrategy"
MarketIds:
- "0x17ef48032..." # INJ/USDT PERP
- "0x4ca0f92f..." # BTC/USDT PERP
- "0x9b998016..." # ETH/USDT PERP
AccountAddresses:
- "inj1your_account_address_here"
TradingAccount: "inj1your_account_address_here"
CIDPrefix: "my_mm"
Parameters:
OrderSize: 0.1
MaxPosition: 1.0
SpreadThreshold: 0.005
```
### 4. Set Your Private Key
Instead of a single `INJECTIVE_PRIVATE_KEY`, use **bot-scoped environment variables** in `.env` (matches the framework defaults):
```
# For bot named "MyBot"
MyBot_GRANTER_INJECTIVE_PRIVATE_KEY=your_granter_private_key_here
MyBot_GRANTEE_0_INJECTIVE_PRIVATE_KEY=your_first_grantee_private_key_here
```
Load them into your session:
```bash theme={null}
export $(grep -v '^#' .env | xargs)
```
### 5. Run Your Strategy
```bash theme={null}
python main.py MyBot config.yaml --log_path logs/my_bot.log --network mainnet
```
That's it - your bot is now live!
## IDE set up
If you are using VS code or compatible IDEs (such as Cursor), consider adding the following configuration for easy debugging.
`.vscode/launch.json`:
```json theme={null}
{
"version": "0.2.0",
"configurations": [
{
"name": "Run MyBot (mainnet)",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}/main.py",
"console": "integratedTerminal",
"args": ["MyBot", "config.yaml", "--log_path", "logs/strategy.log", "--network", "mainnet"],
"envFile": "${workspaceFolder}/.env"
},
{
"name": "Run MyBot (testnet, debug)",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}/main.py",
"console": "integratedTerminal",
"args": ["MyBot", "config.yaml", "--log_path", "logs/debug.log", "--network", "testnet", "--debug"],
"envFile": "${workspaceFolder}/.env"
}
]
}
```
You should now be able to do **Run → Start Debugging** in your IDE.
## Architecture
### System Architecture Diagram
Injective Trader Network Architecture Diagram
### Core Design Patterns
* **Mediator Pattern**: Centralizes communication between components, enabling a decoupled architecture where components interact without direct dependencies.
* **Component Pattern**: Standardizes lifecycle management (initialize, run, terminate) for all system components, ensuring consistent behavior.
* **State Pattern**: Manages component lifecycle through well-defined states (Idle, Running, Terminated), providing predictable transitions and error handling.
* **Task Management Pattern**: Coordinates asynchronous tasks with automated monitoring and recovery, ensuring reliable execution in an event-driven environment.
* **Observer Pattern**: Enables strategies to react to specific update events through specialized event handlers, creating a flexible strategy development approach.
### Key Components
**Exchange-Specific Agents**
* **Initializer**: Sets up exchange connections, accounts, and markets
* **ChainListener**: Streams real-time blockchain data with automatic reconnection
* **MessageBroadcaster**: Handles transaction creation and broadcasting with retry logic
* **Liquidator**: Monitors and executes liquidations for undercollateralized positions
**Managers**
* **MarketManager**: Processes market data and maintains orderbook integrity
* **AccountManager**: Tracks balances, positions, and order state
* **StrategyManager**: Routes market events to appropriate strategy implementations
* **RiskManager**: Enforces position limits and risk controls
* **TaskManager**: Orchestrates and monitors asynchronous task execution
**Data-Level Domains**
* **Market**: Represents trading pairs with orderbooks and metadata
* **Account**: Manages account balances, deposits, and subaccounts
* **Positions**: Tracks derivative positions with P\&L calculations
* **Order**: Order state tracking with execution history
* **Oracle Prices**: Real-time price feeds with timestamp tracking
**Strategy-Level Plugins**
* **Strategy Base**: Template for implementing custom strategies
* **Update Handlers**: Event-specific processors for market data events
* **Performance Metrics**: Statistics and P\&L tracking
* **Risk Models**: Customizable risk management rules
## Next
Learn more about the [simple strategy](/developers-defi/injective-trader/simple-strategy) that ships with Injective Trader, to get yourself comfortable with the codebase before diving in.
# Getting Started
Source: https://docs.injective.network/developers-defi/injective-trader/simple-strategy
# Getting Started
Injective Trader comes built in with a "Simple Strategy" to aid with rapid prototyping and familiarizing yourself with the codebase.
**What it does:**
* Monitors orderbooks for INJ, BTC, ETH
* Places buy orders slightly below market price
* Places sell orders slightly above market price
* Maintains a spread for profitability
* Respects position limits for risk control
**Best for:** predictable and steady trading while familiarizing yourself with Injective Trader. **Not recommended for production use.**
**Example Logs:**
```
[INFO] Placing BUY order: 0.1 INJ at $3.45 (spread: 0.5%)
[INFO] Placing SELL order: 0.1 INJ at $3.47 (spread: 0.5%)
[INFO] Order filled: BUY 0.1 INJ at $3.45
```
## Customizing Your Strategy
### Order size
```yaml theme={null}
OrderSize: 0.5
MaxPosition: 2.0
```
### More markets
```yaml theme={null}
MarketTickers:
- INJ/USDT PERP
- BTC/USDT PERP
- ETH/USDT PERP
- APT/USDT PERP
- AVAX/USDT PERP
- SOL/USDT PERP
```
### Spreads
```yaml theme={null}
SpreadThreshold: 0.01 # conservative
SpreadThreshold: 0.002 # aggressive
```
## Common Configurations
### Conservative Maker
```yaml theme={null}
OrderSize: 0.05
MaxPosition: 0.5
SpreadThreshold: 0.01
```
### Aggressive Maker
```yaml theme={null}
OrderSize: 0.5
MaxPosition: 5.0
SpreadThreshold: 0.002
```
### Multi-Market Strategy
```yaml theme={null}
MarketTickers:
- INJ/USDT PERP
- BTC/USDT PERP
- ETH/USDT PERP
- APT/USDT PERP
- AVAX/USDT PERP
- SOL/USDT PERP
- TON/USDT PERP
- ATOM/USDT PERP
```
## Monitoring Your Bot
```bash theme={null}
tail -f logs/my_bot.log
grep "Order filled" logs/my_bot.log
grep "ERROR" logs/my_bot.log
```
### Key Messages
* ✅ Order placed successfully
* 💰 Order filled
* ⚠️ Position limit reached
* ❌ Insufficient balance
### Performance Metrics
* Total PnL
* Win rate
* Fill rate
* Average spread
## Risk Management
* Set position limits (`MaxPosition`)
* Monitor positions and stop out manually if needed
* Maintain enough USDT for margin, fees, and buffer
## Troubleshooting
**No private keys found**
```bash theme={null}
echo $MyBot_GRANTER_INJECTIVE_PRIVATE_KEY
```
* **Insufficient balance** → Add USDT / reduce `OrderSize`
* **Market not found** → Double-check tickers/IDs
* **Bot stops working**
```bash theme={null}
grep "ERROR" logs/my_bot.log | tail -10
python main.py MyBot config.yaml --log_path logs/my_bot.log --network mainnet
```
## Advanced Features
* **Multiple accounts** via `AccountAddresses`
* **Custom order types** (limit, market, reduce-only)
* **External signals** with Redis/Valkey
## Next
Learn how to develop your own [custom strategy](/developers-defi/injective-trader/strategy-development-guide) for Injective Trader.
# Strategy Development Guide
Source: https://docs.injective.network/developers-defi/injective-trader/strategy-development-guide
# Strategy Development Guide
## Configuration Guide
The Injective Trader uses a YAML configuration file to define behavior, components, and strategy parameters.
The most important configuration sections to focus on are:
* `LogLevel`
* `Network` and `MarketTickers` in the `Initializer` under the `Components` section
* `Strategies` section
Here's a detailed breakdown of the configuration structure:
### Top-Level Parameters
```yaml theme={null}
Exchange: Helix # Trading exchange to use
LogLevel: INFO # Logging level (DEBUG, INFO, WARNING, ERROR)
```
### Components Section
The `Components` section configures framework components:
```yaml theme={null}
Components:
# Chain initialization and market setup
Initializer:
Network: mainnet # Network to connect to (mainnet or testnet)
MarketTickers: # Market tickers to track (will be converted to IDs)
- INJ/USDT PERP
- ETH/USDT
BotName: MyBot
# Chain listening configuration
ChainListener:
ReconnectionDelay: 5 # Seconds to wait before reconnection attempts
LargeGapThreshold: 50 # Sequence gap threshold for orderbook snapshot requests
# Transaction broadcasting configuration
MessageBroadcaster:
ErrorCodesJson: config/error_codes.json # Error code lookup for tx validation
GranteePool: # For authz transaction mode
MaxPendingTxs: 5 # Maximum pending transactions per grantee
ErrorThreshold: 3 # Consecutive errors before blocking a grantee
BlockDuration: 300 # Seconds to block a grantee after errors
RotationInterval: 1 # Seconds between grantee rotations
RefreshInterval: 300 # Seconds between grant refresh checks
Batch: # Transaction batching settings
MaxBatchSize: 15 # Maximum messages per batch
MinBatchSize: 3 # Minimum messages to trigger immediate send
MaxGasLimit: 5000000 # Maximum gas per batch
MaxBatchDelay: 0.5 # Maximum seconds to wait for batch completion
```
**Note**: Most users only need to take care of `Network` and include all the markets that they want to listen to in `MarketTickers`.
They won't need to modify these advanced component settings. The default values work well for most use cases.
### Strategies Section
The `Strategies` section defines each trading strategy:
```yaml theme={null}
Strategies:
SimpleStrategy: # Strategy identifier (your choice)
# Required parameters
Name: "SimpleStrategy" # Strategy name (used in logs)
Class: "SimpleStrategy" # [REQUIRED] Python class name to instantiate
MarketIds: # [REQUIRED] Markets to trade on
- "0x9b9980167ecc3645ff1a5517886652d94a0825e54a77d2057cbbe3ebee015963" # INJ/USDT PERP
AccountAddresses: # [REQUIRED] Accounts to use
- "inj1youractualaccount..." # (Must match private key in env)
TradingAccount: "inj1youractualaccount..." # [REQUIRED] Account for placing orders (Must match private key in env)
# Optional parameters
FeeRecipient: "inj1feerecipient..." # Address to receive trading fees (if applicable)
CIDPrefix: "simple_strat" # Prefix for client order IDs
SubaccountIds: ["0x123..."] # Specific subaccounts to use (otherwise all available)
# Risk management configuration [Optional]
# You don't have to include them if you don't have your specific risk model
Risk: "BasicRiskModel" # Risk model to apply (if using risk management)
RiskConfig: # Risk thresholds
DrawdownWarning: 0.1 # 10% drawdown warning threshold
DrawdownCritical: 0.2 # 20% drawdown critical threshold
MarginWarning: 0.7 # 70% margin usage warning
MarginCritical: 0.8 # 80% margin usage critical
```
**Required Strategy Parameters:**
* `Class`: Must exactly match your Python class name
* `MarketIds`: List of market IDs to trade on in this strategy (use hex format)
* `AccountAddresses`: List of accounts to use for trading in this strategy
* `TradingAccount`: Account used for order execution (must be in `AccountAddresses`) \[See more details on [Trading Mode Configuration](https://www.notion.so/Trading-Mode-Configuration-1bb7a004ab758056affdefc2c99aca08?pvs=21) ]
**Recommended Parameters:**
* `CIDPrefix`: Prefix for client order IDs (helps identify your orders)
* `Name`: Human-readable name for logs and monitoring
**Custom Parameters:**
* You can add any custom parameters your strategy needs
* All parameters under your strategy name will be available in `self.config`
* Group related parameters under the `Parameters` section for clarity
### Trading Mode Configuration
The framework supports two trading modes:
#### Direct Execution Mode
```yaml theme={null}
Strategies:
SimpleStrategy:
# Other parameters...
TradingAccount: "inj1youraccount..." # Account that will sign and broadcast transactions
```
#### Authorization (Authz) Mode
```yaml theme={null}
Strategies:
SimpleStrategy:
# Other parameters...
Granter: "inj1granteraccount..." # Account granting permission to execute trades
Grantees: # Accounts that can execute trades on behalf of granter
- "inj1grantee1..."
- "inj1grantee2..."
```
**Note**: You must specify either `TradingAccount` for direct execution OR `Granter` and `Grantees` for authorization mode.
The framework enforces this requirement during initialization.
### RetryConfig Section
The `RetryConfig` section controls retry behavior for network operations:
```yaml theme={null}
RetryConfig:
# Global retry settings
DefaultRetry:
max_attempts: 3 # Maximum retry attempts
base_delay: 1.0 # Base delay between retries (seconds)
max_delay: 32.0 # Maximum delay cap (seconds)
jitter: true # Add randomness to delay
timeout: 30.0 # Operation timeout (seconds)
error_threshold: 10 # Errors before circuit breaking
error_window: 60 # Error counting window (seconds)
# Component-specific retry settings (override defaults)
ChainListener:
max_attempts: 5 # More retries for chain listener
base_delay: 2.0
max_delay: 45.0
MessageBroadcaster:
max_attempts: 3
base_delay: 1.0
max_delay: 30.0
```
**Note**: RetryConfig has sensible defaults and typically doesn't need customization unless you're experiencing specific connectivity issues.
***
Now that we understand the overall structure, we are ready to develop custom ones!
## Strategy Development Guide
Strategies in the Injective Trader follow a consistent structure based on the `Strategy` base class. This section explains how to build effective strategies.
### Strategy Class Structure
Your strategy class inherits from the base `Strategy` class:
```python theme={null}
from src.core.strategy import Strategy, StrategyResult
from src.utils.enums import UpdateType, Side
class SimpleStrategy(Strategy):
def __init__(self, logger, config):
"""
Initialize strategy with logger and configuration.
Args:
logger: Logger instance for strategy logging
config: Strategy configuration dictionary
Required keys:
- MarketIds: List of market IDs to trade
- AccountAddresses: List of account addresses to use
Optional keys:
- Name: Strategy name
- Parameters: Strategy-specific parameters
- RiskConfig: Risk management parameters
"""
super().__init__(logger, config)
def on_initialize(self, accounts, markets):
"""
Initialize strategy-specific state and parameters.
Called once before strategy starts processing updates.
Args:
accounts: Dictionary of account_address -> Account
markets: Dictionary of market_id -> Market
"""
pass
async def _execute_strategy(self, update_type, processed_data):
"""
Strategy-specific execution logic.
Args:
update_type: Type of update being processed
processed_data: Update-specific data dictionary after handler processing
Common fields:
- market_id: Market identifier
- account_address: Account address (for account updates)
- subaccount_id: Subaccount identifier (for position/trade updates)
Returns:
StrategyResult:
- orders
- cancellations
- margin updates
"""
pass
```
#### Strategy Constructor (`__init__`)
Your strategy class can include a constructor that calls the parent class constructor:
```python theme={null}
def __init__(self, logger, config):
super().__init__(logger, config)
# Custom initialization that doesn't require markets or accounts
self.custom_parameter = 42
# Optional: Custom handler overrides
self.handlers[UpdateType.OnOrderbook] = MyCustomOrderbookHandler(
self.logger, self.config, self.metrics
)
# Optional: Custom performance metrics overrides
self.my_metrics = MyCustomPerformanceMetrics(self.logger)
```
The base class constructor handles:
1. Parameter validation and extraction
2. Setting up standard metrics and handlers (See \[block link] for more information on writing your own handlers)
3. Initializing state tracking containers
4. Setting up trading mode (direct or authz)
**Important**: The `__init__` method cannot access market data or account information.
Use `on_initialize` for operations requiring those resources.
Available properties provided by base `__init__` are:
| **Property** | **Description** | **Source** | **Required** |
| ------------------------ | ----------------------------------------------------- | ---------------------------------------------------------------------- | -------------- |
| `self.name` | Strategy name used in log | From config `Name` | YES |
| `self.logger` | Logger instance | For strategy-specific logging | YES |
| `self.config` | Complete strategy configuration | Corresponding strategy subsection under `Strategies` section in config | YES |
| `self.market_ids` | List of market IDs interested in this strategy | From config `MarketIds` | YES |
| `self.account_addresses` | List of account addresses interested in this strategy | From config `AccountAddresses` | YES |
| `self.subaccount_ids` | List of subaccount IDs | From config `SubaccountIds` | NO |
| `self.markets` | Dictionary of market\_id → `Market` objects | Populated during initialization | NO |
| `self.accounts` | Dictionary of account\_address → `Account` objects | Populated during initialization | NO |
| `self.trading_mode` | "direct" or "authz” | Based on config | YES |
| `self.fee_recipient` | Fee recipient address | From config `FeeRecipient` | NO |
| `self.cid_prefix` | Client order ID prefix | From config `CIDPrefix` | NO |
| `self.metrics` | Performance tracking | For recording metrics and alerts | YES \[DEFAULT] |
| `self.handlers` | Event handlers dictionary | UpdateType → Handler objects | YES \[DEFAULT] |
#### Initialization Method (`on_initialize`)
The `on_initialize` method is called once during framework startup, after markets and accounts are loaded.
**Purpose**: Initialize strategy state and parameters **Parameters**:
* `accounts`: Dictionary of account\_address → `Account` objects
* `markets`: Dictionary of market\_id → `Market` objects
**Returns**: \[Optional] `StrategyResult` with initial orders (if any)
```python theme={null}
def on_initialize(self, accounts, markets):
# Now you have access to all market and account data
# Example: Access market metadata
for market_id in self.market_ids:
market = markets[market_id]
self.logger.info(f"Market {market_id} tick sizes: "
f"price={market.min_price_tick}, "
f"quantity={market.min_quantity_tick}")
# Example: Initialize parameters that need market info
self.avg_prices = {
market_id: markets[market_id].orderbook.tob()[0]
for market_id in self.market_ids
if markets[market_id].orderbook.tob()[0]
}
# Example: Place initial orders
if self.config.get("PlaceInitialOrders", False):
result = StrategyResult()
# Add initial orders...
return result
return None # No initial orders
```
This method is part of the strategy initialization sequence:
1. Framework loads markets and accounts required by this strategy
2. Your `on_initialize` method is called with loaded data
3. Any returned orders are immediately submitted
4. The strategy moves to running state
**Tip**: Use `on_initialize` for parameter initialization that requires market or account data, and to place any initial orders needed for your strategy.
For data structure information on `Account` and `Market`, see below.
#### Strategy Logic (`_execute_strategy` ) Method
The `_execute_strategy` method is a part of “Strategy Execution (`execute`) Method”. The base class `execute` method handles the complete execution flow:
1. **Initialization check**: Initializes the strategy if needed
2. **State update**: Updates the strategy's account and market references
3. **Data processing**: Processes raw update data through the appropriate handler
4. **Strategy execution**: Calls your `_execute_strategy` method with processed data
5. **Order enrichment**: Adds default values to orders (fee recipient, client ID)
You rarely need to override this method. Instead, focus on implementing `_execute_strategy` where your custom trading logic goes:
**Purpose**: Analyze market data and generate trading signals **Parameters**:
* `update_type`: Type of update being processed \[See [Update Types and Corresponding Data Fields](https://www.notion.so/Update-Types-and-Corresponding-Data-Fields-1bb7a004ab7580c1a32ed133b770937a?pvs=21) for more information]
* `processed_data`: Handler-processed data dictionary with relevant fields
**Returns**: `StrategyResult` with orders/cancellations or `None`
```python theme={null}
async def _execute_strategy(self, update_type, processed_data):
# Only respond to orderbook updates
if update_type != UpdateType.OnOrderbook:
return None
# Get market data
market_id = processed_data["market_id"]
market = self.markets[market_id]
# Get current prices
bid, ask = market.orderbook.tob()
if not bid or not ask:
self.logger.warning(f"Incomplete orderbook for {market_id}")
return None
# Implement your strategy logic
spread = (ask - bid) / bid
if spread < self.min_spread_threshold:
self.logger.info(f"Spread too narrow: {spread:.2%}")
return None
# Get subaccount for orders
subaccount_id = self.config.get("SubaccountIds", [""])[0]
if not subaccount_id:
return None
# Check current position to avoid exceeding limits
position = self.get_position(subaccount_id, market_id)
current_size = Decimal("0")
if position:
current_size = position.get("quantity", Decimal("0"))
# Determine order parameters
result = StrategyResult()
# Create a new order
if current_size < self.max_position:
buy_order = Order(
market_id=market_id,
subaccount_id=subaccount_id,
order_side=Side.BUY,
price=bid,
quantity=self.order_size,
market_type=market.market_type # Required field as of v0.5.1
)
result.orders.append(buy_order)
self.logger.info(f"Creating BUY order at {bid}: {self.order_size}")
# Cancel existing orders if needed
for order_hash in self.active_orders:
result.cancellations.append({
"market_id": market_id,
"subaccount_id": subaccount_id,
"order_hash": order_hash
})
return result
```
In `_execute_strategy` you can:
* Filter by update type to handle specific events
* Access current market data and account state
* Check existing positions before placing orders
* Implement custom trading logic based on market conditions
* Create new orders and cancel existing ones
* Update position margins for derivative markets
* Log strategy decisions for monitoring and debugging
The framework will handle the execution details like transaction creation, simulation, and broadcasting based on your returned `StrategyResult`.
#### Best Practices
1. **Initialize all parameters in `on_initialize`**
* Get parameters from `self.config`
* Set default values for missing parameters
* Initialize internal state variables
2. **Filter update types**
* Only process update types your strategy cares about
* Always check for required fields in processed\_data
3. **Validate market data**
* Check if bid/ask exists before using
* Verify position exists before making decisions based on it
4. **Respect market constraints**
* Round prices and quantities to market tick sizes
* Check minimum order size and notional requirements
5. **Handle trading account properly**
* Ensure trading account is in AccountAddresses
* Specify correct subaccount\_id for orders
6. **Implement proper logging**
* Log strategy decisions and important events
* Use appropriate log levels (info, warning, error)
7. **Set custom parameters**
* Use the `Parameters` section for strategy-specific values
* Document expected parameters
This guide should give you a solid foundation for creating and configuring effective trading strategies with the framework.
### Custom Handlers
The framework processes updates through specialized handlers before passing the data to your strategy. You can create custom handlers for more control over data processing.
#### Handler Base Class
All handlers inherit from the `UpdateHandler` base class:
```python theme={null}
class UpdateHandler(ABC):
def __init__(self, logger, config, metrics):
self.logger = logger
self.config = config
self.metrics = metrics
async def process(self, **update_data) -> Dict:
"""Process update data and return processed result"""
try:
return await self._process_update(**update_data)
except Exception as e:
self.logger.error(f"Error processing update: {e}")
return None
@abstractmethod
async def _process_update(self, **kwargs) -> Dict:
"""Process specific update type. To be implemented by subclasses."""
pass
```
#### Creating a Custom Handler
To create a custom handler:
1. Inherit from the appropriate handler base class
2. Override the `_process_update` method
3. Register your handler in your strategy's constructor
```python theme={null}
from src.core.handlers import OrderbookHandler
class MyCustomOrderbookHandler(OrderbookHandler):
async def _process_update(self, **update_data):
# Get basic processed data
processed_data = await super()._process_update(**update_data)
if not processed_data:
return None
# Add custom metrics
market = update_data.get("market")
bid, ask = market.orderbook.tob()
if bid and ask:
# Calculate custom metrics
spread = ask - bid
spread_pct = (ask - bid) / bid
# Add to processed data
processed_data["spread"] = spread
processed_data["spread_pct"] = spread_pct
# Record in metrics system
self.metrics.add_custom_metric(f"{market.market_id}_spread", spread_pct)
return processed_data
```
#### Registering Custom Handlers
Register your custom handlers in your strategy constructor:
```python theme={null}
def __init__(self, logger, config):
super().__init__(logger, config)
# Replace default handlers with custom implementations
self.handlers[UpdateType.OnOrderbook] = MyCustomOrderbookHandler(
self.logger, self.config, self.metrics
)
self.handlers[UpdateType.OnPosition] = MyCustomPositionHandler(
self.logger, self.config, self.metrics
)
```
#### Available Handler Types
The framework provides these handler types that you can extend:
| **Handler Class** | **Update Type** | **Purpose** |
| ------------------ | -------------------------- | ---------------------------- |
| `OrderbookHandler` | `UpdateType.OnOrderbook` | Process orderbook updates |
| `OracleHandler` | `UpdateType.OnOraclePrice` | Process oracle price updates |
| `PositionHandler` | `UpdateType.OnPosition` | Process position updates |
| `BalanceHandler` | `UpdateType.OnBankBalance` | Process balance updates |
| `DepositHandler` | `UpdateType.OnDeposit` | Process deposit updates |
| `TradeHandler` | `UpdateType.OnSpotTrade` | Process trade execution |
| `OrderHandler` | `UpdateType.OnSpotOrder` | Process order updates |
## Key Data Structure
### Update Types and Corresponding Data Fields
The framework processes these main event types that your strategy can react to:
| **Update Type** | **Description** | **Key Data Fields** |
| ------------------------------ | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `UpdateType.OnOrderbook` | Orderbook updates | - market\_id: str
|
| `UpdateType.OnOraclePrice` | Oracle price updates | - market\_id: str
|
| `UpdateType.OnBankBalance` | Account balance updates | - account\_address: str
|
| `UpdateType.OnDeposit` | Subaccount deposit updates | - account\_address: str
|
| `UpdateType.OnPosition` | Position changes | - market\_id: str
|
| `UpdateType.OnSpotTrade` | Spot trade execution | - market\_id: str
|
| `UpdateType.OnDerivativeTrade` | Derivative trade execution | - market\_id: str
|
| `UpdateType.OnSpotOrder` | Spot order updates | - market\_id: str
|
| `UpdateType.OnDerivativeOrder` | Derivative order updates | - market\_id: str
|
### Strategy Result
When your strategy decides to take action, return a `StrategyResult` object with:
| **Field** | **Description** | **Content** |
| ---------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `orders` | List of new orders to create | `[Order(...), Order(...)]` |
| `cancellations` | List of orders to cancel | `[{"market_id": "0x123...", "subaccount_id": "0x456...", "order_hash": "0x789..."}]` |
| `margin_updates` | List of margin adjustments | `[{"action": "increase", "market_id": "0x123...", "source_subaccount_id": "0x456...", "destination_subaccount_id": "0x456...", "amount": Decimal("50.0")}]` |
| `liquidations` | List of positions to be liquidated due to insufficient margin | `[{"market_id": "0x123...", "subaccount_id": "0x456...", "executor_subaccount_id": "0x789...", "price": price, "quantity": quantity, "margin": margin}]` |
### Market
| **Property** | **Type** | **Description** | **Note** |
| -------------------- | ------------------------------------------------------ | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `market_id` | `str` | Unique market identifier | |
| `market_type` | `MarketType` object | Market type (SPOT, DERIVATIVE or BINARY) | Required as of v0.5.1 |
| `market` | `BinaryOptionMarket \| DerivativeMarket \| SpotMarket` | Market object from `pyinjective` | SpotMarket: [https://api.injective.exchange/#chain-exchange-for-spot-spotmarkets](https://api.injective.exchange/#chain-exchange-for-spot-spotmarkets) [https://api.injective.exchange/#chain-exchange-for-derivatives-derivativemarkets](https://api.injective.exchange/#chain-exchange-for-derivatives-derivativemarkets) [https://api.injective.exchange/#chain-exchange-for-binary-options-binaryoptionsmarkets](https://api.injective.exchange/#chain-exchange-for-binary-options-binaryoptionsmarkets)
|
| `orderbook` | `Orderbook` object | Current market orderbook | |
| `oracle_price` | `Decimal` | Current market oracle price | |
| `min_price_tick` | `Decimal` | Minimum price increment | |
| `min_quantity_tick` | `Decimal` | Minimum quantity increment | |
| `base_oracle_price` | `Decimal` | Base token oracle price | Optional |
| `quote_oracle_price` | `Decimal` | Quote token oracle price | Optional |
| `oracle_timestamp` | `int` | Oracle price timestamp | Optional |
| `mark_price` | `Decimal` | Mark price for derivative | Optional |
### Orderbook
| **Property** | **Type** | **Description** | **Note** |
| ------------ | -------------------- | ------------------------------------------ | --------------------------------------- |
| `sequence` | `str` | Orderbook sequence number | |
| `bids` | `List[L2PriceLevel]` | List of bid price levels | `L2PriceLevel` : `price` and `quantity` |
| `asks` | `List[L2PriceLevel]` | List of ask price levels | `L2PriceLevel` : `price` and `quantity` |
| `tob` | `Tuple` | Top of book (bid, ask) prices | |
| `is_health` | `bool` | Indicates if orderbook is in healthy state | `False` when sequence is 0 |
### Account
| **Property** | **Type** | **Description** | **Note** |
| ----------------- | ------------------------ | ---------------------------------- | --------------------------------------- |
| `private_key` | `PrivateKey` | Injective private key | Not directly accessible |
| `public_key` | `PublicKey` | Corresponding public key | |
| `address` | `Address` | Account address object | Contains sequence information |
| `account_address` | `str` | Bech32 address string | Format: "inj1..." |
| `bank_balances` | `Dict[str, BankBalance]` | Token balances in account | Key: denom |
| `balances` | `Dict[str, Balance]` | Alternative balance representation | Key: denom |
| `subaccounts` | `Dict[str, SubAccount]` | Subaccounts owned by this account | Key: subaccount\_id |
| `sequence` | `int` | Transaction sequence number | Property that accesses address.sequence |
### BankBalance
| **Property** | **Type** | **Description** | **Note** |
| ------------ | --------- | ------------------ | ------------------------- |
| `denom` | `str` | Token denomination | e.g., "inj", "peggy0x..." |
| `amount` | `Decimal` | Token amount | Human-readable format |
### Balance
| **Property** | **Type** | **Description** | **Note** |
| ------------ | --------- | ------------------ | -------------------------- |
| `denom` | `str` | Token denomination | e.g., "inj", "peggy0x..." |
| `total` | `Decimal` | Total balance | |
| `available` | `Decimal` | Available balance | Total minus locked amounts |
### SubAccount
| **Property** | **Type** | **Description** | **Note** |
| ------------------- | ----------------------------- | ---------------------------- | ---------------------------------- |
| `subaccount_id` | `str` | Unique subaccount identifier | Format: "0x..." |
| `portfolio` | `Dict[str, Deposit]` | Token deposits in subaccount | Key: denom |
| `positions` | `Dict[str, Position]` | Trading positions | Key: market\_id |
| `open_bid_orders` | `Dict[str, Dict[str, Order]]` | Open buy orders | `market_id -> {order_hash: Order}` |
| `open_ask_orders` | `Dict[str, Dict[str, Order]]` | Open sell orders | `market_id -> {order_hash: Order}` |
| `traded_bid_orders` | `Dict[str, Dict[str, Order]]` | Filled buy orders | `market_id -> {order_hash: Order}` |
| `traded_ask_orders` | `Dict[str, Dict[str, Order]]` | Filled sell orders | `market_id -> {order_hash: Order}` |
### Deposit
| **Property** | **Type** | **Description** | **Note** |
| ------------------- | --------- | ------------------------ | ------------------------------ |
| `denom` | `str` | Token denomination | e.g., "inj", "peggy0x..." |
| `total_balance` | `Decimal` | Total deposit amount | |
| `available_balance` | `Decimal` | Available deposit amount | Total minus margins and locked |
### Position
| **Property** | **Type** | **Description** | **Note** |
| -------------------------- | --------- | ---------------------------- | ---------- |
| `subaccount_id` | `str` | Owner subaccount ID | |
| `market_id` | `str` | Market identifier | |
| `quantity` | `Decimal` | Position size | |
| `entry_price` | `Decimal` | Average entry price | |
| `margin` | `Decimal` | Total margin amount | |
| `cumulative_funding_entry` | `Decimal` | Cumulative funding at entry | |
| `is_long` | `bool` | Long (true) or short (false) | |
| `unrealized_pnl` | `Decimal` | Unrealized profit/loss | Default: 0 |
| `total_volume` | `Decimal` | Total trading volume | Default: 0 |
| `trades_count` | `int` | Number of trades | Default: 0 |
| `mark_price` | `Decimal` | Current market price | Optional |
| `liquidation_price` | `Decimal` | Liquidation threshold | Optional |
| `margin_ratio` | `Decimal` | Current margin ratio | Optional |
### Order
| **Property** | **Type** | **Description** | **Note** |
| ---------------- | ------------- | --------------------------- | ----------------------------- |
| `market_id` | `str` | Market identifier | |
| `subaccount_id` | `str` | Subaccount identifier | |
| `order_side` | `Side` | Buy or sell | Side.BUY or Side.SELL |
| `price` | `Decimal` | Order price | |
| `quantity` | `Decimal` | Order quantity | |
| `order_hash` | `str` | Unique order identifier | Optional, set by chain |
| `fillable` | `Decimal` | Remaining unfilled quantity | Optional |
| `filled` | `Decimal` | Filled quantity | Optional |
| `status` | `OrderStatus` | Order status | BOOKED, PARTIAL\_FILLED, etc. |
| `order_type` | `str` | Order type | Default: "LIMIT" |
| `margin` | `Decimal` | Margin amount (derivatives) | Optional |
| `leverage` | `Decimal` | Leverage multiple | Optional |
| `trigger_price` | `Decimal` | For conditional orders | Optional |
| `market_type` | `MarketType` | SPOT, DERIVATIVE, BINARY | Optional |
| `fee_recipient` | `str` | Fee recipient address | Default: "" |
| `cid` | `str` | Client order ID | Optional |
| `created_at` | `datetime` | Creation timestamp | Optional |
| `updated_at` | `datetime` | Last update timestamp | Optional |
| `position_delta` | `Dict` | Position change data | Optional for derivatives |
| `payout` | `Decimal` | Expected payout | Optional for derivatives |
| `tx_hash` | `str` | Transaction hash | Optional |
| `error_code` | `str` | Error code if failed | Optional |
| `error_message` | `str` | Error details | Optional |
### OrderStatus (Enum)
| **Value** | **Description** |
| ---------------- | ------------------------- |
| `BOOKED` | Order accepted and active |
| `PARTIAL_FILLED` | Partially filled |
| `FILLED` | Completely filled |
| `CANCELLED` | Cancelled by user |
| `EXPIRED` | Expired (time-based) |
### Side (Enum)
| **Value** | **Description** |
| --------- | --------------- |
| `BUY` | Buy order |
| `SELL` | Sell order |
### MarketType (Enum)
| **Value** | **Description** |
| ------------ | --------------------- |
| `SPOT` | Spot market |
| `DERIVATIVE` | Derivatives market |
| `BINARY` | Binary options market |
# Launch a Market
Source: https://docs.injective.network/developers-defi/market-launch
The prerequisite for launching a market is to [launch a token](/developers-defi/token-launch/).
Launching a trading pair on Injective is quick, easy, and best of all, permissionless!
The following tutorial assumes the pair is listed with an ERC-20 token bridged from Ethereum as the base asset, paired with INJ as the quote asset.
For an Injective-native token, skip the bridging portion and head straight to step 6.
1. Navigate to the [Injective Bridge](http://bridge.injective.network/) to begin the process of bridging your chosen ERC-20 token from Ethereum to Injective using the Peggy bridge.
**Note:** Derivative markets share the same format for `minQuantityTickSize` between the user interface and the chain, so no formatting is required.
### Spot Market
#### Conversion from Human-Readable Format to Chain Format
Using the INJ/USDT market as an example, which has **18 base decimals** and **6 quote decimals**, the conversion to chain format is as follows:
$\text{chainFormat} = \text{value} \times 10^{\text{baseDecimals}}$
#### Conversion from Chain Format to Human-Readable Format
To convert back to a human-readable format:
$\text{humanReadableFormat} = \text{value} \times 10^{-\text{baseDecimals}}$
Also, be sure to check out our [concepts](../developers/concepts/calculation-min-price-tick-size/).
# Provider Oracle
Source: https://docs.injective.network/developers-defi/provider-oracle
Prerequisite reading [Injective Oracle Module](/developers-native/injective/oracle/)
The goal of this section is to provide users a guide on how to launch and maintain an oracle provider on Injective. These oracles can be used for various purposes, like Perpetual Markets, Expiry Futures Markets, [Binary Options markets](/developers-native/injective/exchange/02_binary_options_markets/), etc.
First, what is an oracle provider? It's an oracle **TYPE** that allows external parties to relay price feeds to the Injective chain. These external parties are called providers. A provider identifies each external party, and all the price feeds provided on the chain are stored under that particular provider. This allows custom price feeds to be created on Injective, which can power creative and advanced markets like [Binary Options markets](/developers-native/injective/exchange/02_binary_options_markets/) being launched on Injective.
The first thing developers need to do is register their provider under the Oracle Provider type. You can do that by submitting a `GrantProviderPrivilegeProposal` governance proposal. Once the proposal passes, your provider will be registered, and you can relay price feeds. You can do it in a CLI environment using `injectived` (`grant-provider-privilege-proposal [providerName] [relayers] --title [title] --description [desc] [flags]`) or using any of our SDKs to create the message and broadcast it to the chain.
You can see an example on how to submit this proposal in the Oracle Module Proposals Section
*Note: the `relayers` of the `GrantProviderPrivilegeProposal` are addresses that will be whitelisted to submit the price feeds to Injective.*
Once the proposal passes, the `relayers` can use the `MsgRelayProviderPrices` to submit prices for a base/quote pair within their provider namespace of the Oracle Provider Type oracle on Injective. You can do it in a CLI environment using `injectived` (`relay-provider-prices [providerName] [symbol:prices] [flags]`) or using any of our SDKs to create the message and broadcast it to the chain.
Finally, you can use these price feeds to create your Derivative Markets.
# Testnet Faucet Integration
Source: https://docs.injective.network/developers-defi/testnet-faucet-integration
If you want to have a testnet faucet integration within your dApp, the only thing you need to do is do a `POST` request to `` `https://jsbqfdd4yk.execute-api.us-east-1.amazonaws.com/v1/faucet` `` and pass an `{ address: inj1...}` as the body of the `POST` request. The address is then stored within the queue ,which is processed every 5 to 10 minutes.
Here is an example code snippet:\\
```typescript theme={null}
import { HttpClient } from "@injectivelabs/utils"
const LAMBDA_API = "https://jsbqfdd4yk.execute-api.us-east-1.amazonaws.com/v1"
const client = new HttpClient(LAMBDA_API);
client
.post("faucet", { address: "inj1...." })
.then((response: any) => {
alert("success, your address is in the queue");
})
.catch((e: any) => {
alert("Something happened - " + e.message);
})
.finally(() => {
//
});
```
# Launch a Token
Source: https://docs.injective.network/developers-defi/token-launch
Within this document, we'll explain how to launch a token on Injective.
There are two options for launching a token on Injective: bridging an existing token or creating a new token.
## Bridging
You have to have `injectived` installed locally before proceeding with this tutorial. You can learn more about it on the [injectived](/developers/injectived/ "mention")page.
Once you have `injectived` installed and a key added, you can use the CLI to launch your token:
1. **Create a `TokenFactory` denom**
The fee for creating a factory denom is `0.1 INJ`.
```bash theme={null}
injectived tx tokenfactory create-denom [subdenom] [name] [symbol] [decimals] --from=YOUR_KEY --chain-id=injective-888 --node=https://testnet.tm.injective.network:443 --gas-prices=500000000inj --gas 1000000
```
Tokens are namespaced by the creator address to be permissionless and avoid name collision. In the example above, the subdenom is `ak` but the denom naming will be `factory/{creator address}/{subdenom}`.
2. **Submit token metadata**
To get your token visible on Injective dApps, you have to submit its metadata.
```bash theme={null}
injectived tx tokenfactory set-denom-metadata "My Token Description" 'factory/inj17vytdwqczqz72j65saukplrktd4gyfme5agf6c/ak' AKK AKCoin AK '' '' '[
{"denom":"factory/inj17vytdwqczqz72j65saukplrktd4gyfme5agf6c/ak","exponent":0,"aliases":[]},
{"denom":"AKK","exponent":6,"aliases":[]}
]' 6 --from=YOUR_KEY --chain-id=injective-888 --node=https://testnet.sentry.tm.injective.network:443 --gas-prices=500000000inj --gas 1000000
```
This command expects the following arguments:
```bash theme={null}
injectived tx tokenfactory set-denom-metadata [description] [base] [display] [name] [symbol] [uri] [uri-hash] [denom-unit (json)] [decimals]
```
3. **Mint tokens**
Once you have created your token and submitted the token metadata, it's time to mint your tokens.
```bash theme={null}
injectived tx tokenfactory mint 1000000factory/inj17vytdwqczqz72j65saukplrktd4gyfme5agf6c/ak --from=gov --chain-id=injective-888 --node=https://testnet.sentry.tm.injective.network:443 --gas-prices=500000000inj --gas 1000000
```
This command will mint 1 token, assuming your token has 6 decimals.
4. **Burn tokens**
The admin of the token, can also burn the tokens.
```bash theme={null}
injectived tx tokenfactory burn 1000000factory/inj17vytdwqczqz72j65saukplrktd4gyfme5agf6c/ak --from=gov --chain-id=injective-888 --node=https://testnet.sentry.tm.injective.network:443 --gas-prices=500000000inj --gas 1000000
```
5. **Change admin**
It's recommended once you have minted the initial supply to change admin to the `null` address to make sure that the supply of the token cannot be manipulated. Once again, the admin of the token can mint and burn supply anytime. The `NEW_ADDRESS`, as explained above in most of the cases should be set to `inj1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqe2hm49`.
```bash theme={null}
injectived tx tokenfactory change-admin factory/inj17vytdwqczqz72j65saukplrktd4gyfme5agf6c/ak NEW_ADDRESS --from=gov --chain-id=injective-888 --node=https://testnet.sentry.tm.injective.network:443 --gas-prices=500000000inj --gas 1000000
```
The examples above are for testnet. If you want to run them on mainnet, do the following changes:
`injective-888` > `injective-1`
`https://testnet.sentry.tm.injective.network:443` > `http://sentry.tm.injective.network:443`
#### Using Cosmwasm
To create and manage a bank token programmatically via a smart contract, one can use the following messages found in the [`injective-cosmwasm`](https://github.com/InjectiveLabs/cw-injective/blob/6b2d549ff99912b9b16dbf91a06c83db99b5dace/packages/injective-cosmwasm/src/msg.rs#L399-L434) package:
\
`create_new_denom_msg`
```rust theme={null}
pub fn create_new_denom_msg(sender: String, subdenom: String) -> CosmosMsg {
InjectiveMsgWrapper {
route: InjectiveRoute::Tokenfactory,
msg_data: InjectiveMsg::CreateDenom { sender, subdenom },
}
.into()
}
```
Purpose: Creates a message to create a new token denomination using the tokenfactory module.
Parameters:
* `sender`: The address of the account initiating the creation.
* `subdenom`: The sub-denomination identifier for the new token.
Returns: A `CosmosMsg` wrapped in an `InjectiveMsgWrapper`, ready to be sent to the Injective blockchain.
Example:
```rust theme={null}
let new_denom_message = create_new_denom_msg(
env.contract.address, // Sender's address
"mytoken".to_string(), // Sub-denomination identifier
);
```
#### `create_set_token_metadata_msg`
```rust theme={null}
pub fn create_set_token_metadata_msg(denom: String, name: String, symbol: String, decimals: u8) -> CosmosMsg {
InjectiveMsgWrapper {
route: InjectiveRoute::Tokenfactory,
msg_data: InjectiveMsg::SetTokenMetadata {
denom,
name,
symbol,
decimals,
},
}
.into()
}
```
Purpose: Creates a message to set or update metadata for a token.
Parameters:
* `denom`: The denomination identifier of the token.
* `name`: The full name of the token.
* `symbol`: The symbol of the token.
* `decimals`: The number of decimal places the token uses.
Returns: A `CosmosMsg` wrapped in an `InjectiveMsgWrapper`, ready to be sent to the Injective blockchain.
Example:
```rust theme={null}
let metadata_message = create_set_token_metadata_msg(
"mytoken".to_string(), // Denomination identifier
"My Custom Token".to_string(), // Full name
"MYT".to_string(), // Symbol
18, // Number of decimals
);
```
#### `create_mint_tokens_msg`
```rust theme={null}
pub fn create_mint_tokens_msg(sender: Addr, amount: Coin, mint_to: String) -> CosmosMsg {
InjectiveMsgWrapper {
route: InjectiveRoute::Tokenfactory,
msg_data: InjectiveMsg::Mint { sender, amount, mint_to },
}
.into()
}
```
Purpose: Creates a message to mint new tokens. The token must be a tokenfactory token and the sender must be the token admin.
Parameters:
* `sender`: The address of the account initiating the mint operation.
* `amount`: The amount of tokens to mint.
* `mint_to`: The recipient address where the newly minted tokens should be sent.
Returns: A `CosmosMsg` wrapped in an `InjectiveMsgWrapper`, ready to be sent to the Injective blockchain.
Example:
```rust theme={null}
let mint_message = create_mint_tokens_msg(
env.contract.address, // Sender's address
Coin::new(1000, "factory//mytoken"), // Amount to mint
"inj1...".to_string(), // Recipient's address
);
```
#### `create_burn_tokens_msg`
```rust theme={null}
pub fn create_burn_tokens_msg(sender: Addr, amount: Coin) -> CosmosMsg {
InjectiveMsgWrapper {
route: InjectiveRoute::Tokenfactory,
msg_data: InjectiveMsg::Burn { sender, amount },
}
.into()
}
```
Purpose: Creates a message to burn tokens. The token must be a tokenfactory token and the sender must be the token admin.
Parameters:
* `sender`: The address of the account initiating the burn operation.
* `amount`: The amount of tokens to burn.
Returns: A `CosmosMsg` wrapped in an `InjectiveMsgWrapper`, ready to be sent to the Injective blockchain.
Example:
```rust theme={null}
let burn_message = create_burn_tokens_msg(
env.contract.address, // Sender's address
Coin::new(500, "factory//mytoken"), // Amount to burn
);
```
# Add Injective to Your dApp
Source: https://docs.injective.network/developers-evm/add-injective-to-your-dapp
# Add Injective to Your dApp
Enable your users to connect to the Injective network with a single click.
Use the code snippet below to add an “Add Injective Network” button to your dApp, making it easy for users to add Injective to MetaMask or any EVM-compatible wallet.
1. Copy and paste the snippet into your frontend codebase.
2. Connect the `addInjectiveNetwork` function to your preferred UI button.
3. That’s it—your users can now add Injective to their wallet in seconds
```tsx theme={null}
// Network configuration
const INJECTIVE_MAINNET_CONFIG = {
chainId: '0x6f0', // 1776 in decimal
chainName: 'Injective',
rpcUrls: ['https://evm-rpc.injective.network'],
nativeCurrency: {
name: 'Injective',
symbol: 'INJ',
decimals: 18
},
blockExplorerUrls: ['https://explorer.injective.network']
};
async function addInjectiveNetwork() {
// Check if MetaMask or another Web3 wallet is installed
if (!window.ethereum) {
alert('Please install MetaMask or another Web3 wallet!');
return;
}
try {
// First, try to switch to the Injective network
await window.ethereum.request({
method: 'wallet_switchEthereumChain',
params: [{ chainId: INJECTIVE_MAINNET_CONFIG.chainId }],
});
console.log('Switched to Injective network successfully!');
} catch (switchError) {
// Error code 4902 means the network hasn't been added yet
if (switchError.code === 4902) {
try {
// Add the Injective network
await window.ethereum.request({
method: 'wallet_addEthereumChain',
params: [INJECTIVE_MAINNET_CONFIG],
});
console.log('Injective network added successfully!');
} catch (addError) {
console.error('Failed to add Injective network:', addError);
alert('Failed to add Injective network. Please try again.');
}
} else {
console.error('Failed to switch network:', switchError);
alert('Failed to switch to Injective network.');
}
}
}
```
# Bank Precompile
Source: https://docs.injective.network/developers-evm/bank-precompile
# Bank Precompile
The Bank Precompile is a system smart contract residing at the fixed address `0x0000000000000000000000000000000000000064`.
It offers EVM developers a gas-efficient and native pathway to interact directly with the Injective's **bank module** (`x/bank`). This effectively bringing ERC-20 tokens on-chain. Any ERC-20 contract using the Bank precompile will be represented as `erc20:0x...` denom on-chain. Technically, this means that tokens reside only on-chain, with the EVM providing a view to the chain state rather than maintaining a separate copy. Unlike traditional bridging, where two token versions require user actions to switch, the Bank precompile offers real-time, dual-environment reflection for any transfer using either the on-chain bank denom or the ERC-20 `transfer()` method.
A range of ERC-20 implementations backed by the Bank precompile, alongside precompile interfaces and abstract contracts, are available at [Injective’s Solidity Contracts Repository](https://github.com/InjectiveLabs/solidity-contracts). Key contracts include:
* **Bank.sol** – precompile interface
* **BankERC20.sol** – abstract ERC20 implementation backed by the Bank precompile
* **FixedSupplyBankERC20.sol** – decentralized ERC20 with fixed supply (no owner, no minting or burning)
* **MintBurnBankERC20.sol** – ERC20 with an owner authorized to mint and burn tokens
These implementations are based on OpenZeppelin’s ERC20 contracts. Developers can freely create custom ERC20 contracts utilizing the Bank precompile.
## ERC20 Contract Deployment
**ℹ️ Note:**
To prevent denom spam, deploying an ERC20 contract via the ERC20 module is a **payable operation** and requires a deployment fee of **1 INJ**. Make sure your ERC20 contract deployment transaction includes this amount, or the operation will be rejected.
## Bank Precompile Interface
```solidity theme={null}
interface IBankModule {
function mint(address,uint256) external payable returns (bool);
function balanceOf(address,address) external view returns (uint256);
function burn(address,uint256) external payable returns (bool);
function transfer(address,address,uint256) external payable returns (bool);
function totalSupply(address) external view returns (uint256);
function metadata(address) external view returns (string memory,string memory,uint8);
function setMetadata(string memory,string memory,uint8) external payable returns (bool);
}
```
## Example
[Wrapped INJ (wINJ)](/developers-evm/wrapped-inj#is-winj-the-same-as-weth "Is wINJ the same as wETH?")
makes use of the Bank EVM precompile in order to implement the
[MultiVM Token Standard (MTS)](/developers-evm/multivm-token-standard).
## Start building
We've prepared a handful of demos that show how to build contracts using the Bank, Exchange, and Staking precompiles. These examples also demonstrate how to interact with the Injective EVM using the most common Ethereum development framework—**Foundry**.
See the bank precompile demo [here](https://github.com/InjectiveLabs/solidity-contracts/tree/master/demos/erc20) and follow the corresponding README.
# Connect with MetaMask
Source: https://docs.injective.network/developers-evm/dapps/connect-with-metamask
## Connect MetaMask to Injective EVM Testnet
MetaMask is a browser wallet extension that lets you connect to any EVM-compatible network, including **Injective EVM**.
### How to Install MetaMask
Install the official MetaMask extension from the [MetaMask download page](https://metamask.io/download).
### Add Injective EVM Testnet to MetaMask
1. Click the **MetaMask icon** in your browser and unlock your wallet.
2. Click the **network selector** at the top (the default is *"Ethereum Mainnet"*).
3. Select **“Add Network”** or **“Add a network manually”** to open the custom network form.
#### Injective EVM Testnet Parameters
Fill in the following details:
```json theme={null}
Network Name: Injective EVM Testnet
Chain ID: 1439
RPC URL: https://k8s.testnet.json-rpc.injective.network/
Currency Symbol: INJ
Block Explorer URL: https://testnet.blockscout.injective.network/blocks
```
> *Note: Block Explorer URL is optional, powered by BlockScout.*
### Switch to Injective EVM Testnet
Once the network is added, use the network selector to switch to **Injective EVM Testnet**.
### Fund Your Wallet (Optional)
Need Testnet INJ? Visit the [Injective Testnet faucet](https://testnet.faucet.injective.network).
Funds will appear once included in a Testnet block.
***
### You're All Set!
MetaMask is now connected to the **Injective EVM Testnet**. You can:
* Deploy smart contracts using tools like **Foundry**, **Hardhat**, or **Remix**.
* Interact with Testnet dApps and contracts.
* Inspect transactions via the Blockscout explorer.
> **Tip:** Always double-check RPC URLs and Chain IDs - accuracy is crucial to avoid misconfiguration.
***
### Connect MetaMask via `ethers.js`
You can also connect MetaMask programmatically using [`ethers`](https://docs.ethers.org/).
#### Sample Code
```ts theme={null}
import { ethers } from 'ethers';
export const INJECTIVE_EVM_PARAMS = {
chainId: '0x59f', // 1439 in hexadecimal
chainName: 'Injective EVM',
rpcUrls: ['https://k8s.testnet.json-rpc.injective.network/'],
nativeCurrency: {
name: 'Injective',
symbol: 'INJ',
decimals: 18,
},
blockExplorerUrls: ['https://testnet.blockscout.injective.network/blocks'],
};
export async function connectMetaMask() {
if (typeof window.ethereum === 'undefined') {
alert('MetaMask not installed!');
return;
}
const provider = new ethers.providers.Web3Provider(window.ethereum);
try {
await window.ethereum.request({
method: 'wallet_addEthereumChain',
params: [INJECTIVE_EVM_PARAMS],
});
await provider.send('eth_requestAccounts', []);
const signer = provider.getSigner();
const address = await signer.getAddress();
console.log('Connected address:', address);
return { provider, signer, address };
} catch (err) {
console.error('MetaMask connection failed:', err);
}
}
```
### Using `ethers.js` to interact with your smart contract
Sample code for counter contract ABI:
```tsx theme={null}
// abi/counterAbi.ts
[
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "sender",
"type": "address"
},
{
"indexed": false,
"internalType": "string",
"name": "reason",
"type": "string"
}
],
"name": "UserRevert",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "sender",
"type": "address"
},
{
"indexed": false,
"internalType": "uint256",
"name": "newValue",
"type": "uint256"
}
],
"name": "ValueSet",
"type": "event"
},
{
"inputs": [],
"name": "increment",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [],
"name": "number",
"outputs": [
{
"internalType": "uint256",
"name": "",
"type": "uint256"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [
{
"internalType": "uint256",
"name": "newNumber",
"type": "uint256"
}
],
"name": "setNumber",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "string",
"name": "reason",
"type": "string"
}
],
"name": "userRevert",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
}
]
```
```javascript theme={null}
import { ethers } from 'ethers'
import { counterAbi } from './abi/counterAbi'
import { INJECTIVE_EVM_PARAMS } from './config' // From separate file
// Replace with your deployed contract address
const contractAddress = '0xYourContractAddressHere'
async function connectAndInteract() {
if (!window.ethereum) {
alert('MetaMask is not installed!')
return
}
// Request Injective EVM Network be added to MetaMask
await window.ethereum.request({
method: 'wallet_addEthereumChain',
params: [
{
chainId: INJECTIVE_EVM_PARAMS.chainHex,
chainName: INJECTIVE_EVM_PARAMS.chainName,
rpcUrls: [INJECTIVE_EVM_PARAMS.rpcUrl],
nativeCurrency: INJECTIVE_EVM_PARAMS.nativeCurrency,
blockExplorerUrls: [INJECTIVE_EVM_PARAMS.blockExplorer],
},
],
})
const provider = new ethers.providers.Web3Provider(window.ethereum)
await provider.send('eth_requestAccounts', [])
const signer = provider.getSigner()
const userAddress = await signer.getAddress()
console.log('Connected as:', userAddress)
// Contract instance
const contract = new ethers.Contract(contractAddress, counterAbi, signer)
// Send transaction to increment
const tx = await contract.increment()
console.log('Transaction sent:', tx.hash)
const receipt = await tx.wait()
console.log('Transaction mined in block:', receipt.blockNumber)
}
connectAndInteract().catch(console.error)
```
### Using `viem` to interact with your smart contract
Sample code
```javascript theme={null}
import { counterAbi } from './abi/counterAbi'
import { INJECTIVE_EVM_PARAMS } from './config'
import { createPublicClient, http } from 'viem'
import { createWalletClient, custom, defineChain, formatEther } from 'viem'
// Replace with your deployed contract address
const contractAddress = '0xYourContractAddressHere'
async function connectAndInteract() {
if (typeof window === 'undefined' || typeof window.ethereum === 'undefined') {
alert('MetaMask is not installed!')
return
}
const client = createWalletClient({
chain: INJECTIVE_EVM_PARAMS,
transport: custom(window.ethereum),
})
// Create a PublicClient for reading contract state
const publicClient = createPublicClient({
chain: injectiveEvm,
transport: http(),
})
const [account] = await client.requestAddresses()
console.log('Connected account:', account)
// Send transaction to increment using wallet client
const hash = await client.writeContract({
address: contractAddress,
abi: counterAbi,
functionName: 'increment',
account,
})
console.log('Transaction sent with hash:', hash)
}
connectAndInteract().catch(console.error)
```
# Connect with WalletConnect
Source: https://docs.injective.network/developers-evm/dapps/connect-with-walletconnect
WalletConnect is an open-source, chain-agnostic protocol that securely links wallets and Web3 applications. It uses a bridge server to relay encrypted messages, allowing users to connect by scanning a QR code or via deep-linking, without exposing private keys.
### Integration Steps for WalletConnect
#### Prerequisites
Register at [WalletConnect Cloud](https://cloud.walletconnect.com) and obtain the **project ID**.
***
#### Install Dependency
```bash theme={null}
npm install ethers wagmi viem @walletconnect/ethereum-provider
```
Set up Injective EVM network configuration
```javascript theme={null}
// lib/injectiveChain.ts
import { defineChain } from 'viem'
export const injectiveEvm = defineChain({
id: 1439,
name: 'Injective EVM',
nativeCurrency: {
name: 'INJ',
symbol: 'INJ',
decimals: 18,
},
rpcUrls: {
default: { http: ['https://k8s.testnet.json-rpc.injective.network'] },
},
blockExplorers: {
default: { name: 'InjectiveScan', url: 'https://testnet.blockscout.injective.network/blocks' },
},
})
```
Set up Wagmi + WalletConnect
```javascript theme={null}
// lib/wagmi.ts
import { walletConnect } from '@wagmi/connectors'
import { createConfig, http } from '@wagmi/core'
import { injectiveEvm } from './injectiveChain'
export const wagmiConfig = createConfig({
chains: [injectiveEvm],
connectors: [
walletConnect({
projectId: 'your-walletconnect-project-id', // From WalletConnect Cloud
showQrModal: true,
}),
],
transports: {
[injectiveEvm.id]: http(injectiveEvm.rpcUrls.default.http[0]),
},
})
```
Integrate into your project
```javascript theme={null}
'use client'
import Image from 'next/image'
import { wagmiConfig } from './providers'
import { useConnect, useAccount, WagmiProvider } from 'wagmi'
import { QueryClientProvider, QueryClient } from '@tanstack/react-query'
export const queryClient = new QueryClient()
function WalletConnector() {
const { connectors, connect, isPending } = useConnect()
const { address, isConnected } = useAccount()
const wcConnector = connectors.find(c => c.id === 'walletConnect')
return (
{isConnected ? (
Connected to {address}
) : (
wcConnector && connect({ connector: wcConnector })}
disabled={isPending || !wcConnector}
style={{ padding: '12px 24px', fontSize: '16px' }}
>
Connect Wallet (WalletConnect)
)}
)
}
```
***
More Info
* WalletConnect docs: [https://docs.walletconnect.com](https://docs.walletconnect.com)
* WalletConnect official examples: [https://github.com/WalletConnect/web-examples](https://github.com/WalletConnect/web-examples)
# Your First EVM dApp
Source: https://docs.injective.network/developers-evm/dapps/index
Connect your wallet with MetaMask or WalletConnect
dApps are front end applications that interact with a blockchain,
typically with smart contracts.
Do check out [your first EVM smart contract](/developers-evm/smart-contracts/) first!
These guides show you how to connect uisng different EVM wallets and libraries.
## Guides
* [Connect with MetaMask](/developers-evm/dapps/connect-with-metamask/)
* [Connect with WalletConnect](/developers-evm/dapps/connect-with-walletconnect/)
# ERC20 Module
Source: https://docs.injective.network/developers-evm/erc20-module
### ERC20 Module
The ERC20 module enables **existing** bank denoms (e.g., IBC-bridged tokens, USDC, tokenfactory, and Peggy) to integrate with the Injective EVM. It maintains a mapping between token pairs within its storage, creating an association between ERC20 tokens and their corresponding bank denoms. When a new token pair is generated for an existing bank denom, the module deploys an ERC20 contract that interacts with the Bank precompile, which then references the storage mapping to align the ERC20 address with the respective bank denom. This module serves several essential purposes:
1. **Storage**: Maps between bank denom ↔ ERC20 address
2. **New Message Type**: Enables users to establish new token pair mappings by issuing a chain message
#### Creating a New Token Pair
Currently, three types of bank denoms can have associated token pairs, each with specific rules:
* **Tokenfactory (`factory/...`)**\
Only the denom admin or governance can create a token pair. The sender can specify an existing ERC20 contract address as a custom implementation. If omitted, a new instance of `MintBurnBankERC20.sol` is deployed, with `msg.sender` as the owner, allowing minting and burning through the contract.
* **IBC (`ibc/...`)**\
IBC denoms can be integrated into the EVM by any user through token pair creation, though without the option for custom ERC20 addresses. These will always deploy a new, ownerless instance of `FixedSupplyBankERC20.sol`.
* **Peggy (`peggy0x...`)**\
Peggy denoms can be integrated into the EVM by any user through token pair creation, though without the option for custom ERC20 addresses. These will always deploy a new, ownerless instance of `FixedSupplyBankERC20.sol`.
# EVM Equivalence
Source: https://docs.injective.network/developers-evm/evm-equivalence
Understanding EVM equivalence on Injective
## Injective EVM vs. Ethereum Mainnet
Injective's native EVM us a fully embedded execution environment that has been integrated into the core architecture of the chain. It is designed to be a 1:1 equivalent to Ethereum in terms of development experience.
Native EVM on Injective supports the latest version of `geth`, ensuring that developers have access to the latest features, tooling, security patches, and improvements. In addition, Injective’s EVM enhances performance and expands capabilities, granting access to Injective's sophisticated financial infrastructure that extends beyond what’s available on Ethereum.
## Gas Fee Estimates for Transactions
| Chain | Gas Price Range | Token Price | Create ERC-4337 Account | Simple Transfer | ERC-20 Transfer |
| ---------------- | ---------------- | ----------- | ----------------------- | ----------------- | ----------------- |
| Ethereum¹ | 30.5 ± 10.6 gwei | \$3000 | $35.25 ± $12.25 | $1.9215 ± $0.6678 | $5.9475 ± $2.067 |
| Polygon² | 224 ± 108 gwei | \$0.4 | $0.0345 ± $0.0166 | $0.0018 ± $0.0009 | $0.0058 ± $0.0028 |
| Optimism³ | 0.30 ± 0.15 gwei | \$3000 | $0.3467 ± $0.1733 | $0.0189 ± $0.0094 | $0.0585 ± $0.0292 |
| Avalanche⁴ | 36.4 ± 4.5 nAVAX | \$28 | $0.3926 ± $0.0485 | $0.0214 ± $0.0026 | $0.0662 ± $0.0081 |
| BnB Smart Chain⁵ | 7.05 ± 0.53 gwei | \$600 | $1.6296 ± $0.1225 | $0.0888 ± $0.0066 | $0.2749 ± $0.0206 |
| Sei⁶ | 0.02 usei | \$0.40 | \$0.0030 | \$0.00017 | \$0.0005 |
| Injective⁷ | 0.16 nINJ | \$23 | \$0.0014 | \$0.00008 | \$0.0002 |
### Note: Gas per Action
Do **not** use inEVM, as that has been **deprecated**.
# Explorers
* [https://blockscout.injective.network/](https://blockscout.injective.network/) → Can only see EVM transactions
* [https://injscan.com/](https://injscan.com/) → Can see both EVM and Cosmos transactions
Reference: [EVM Network Information | Injective | Docs](/developers-evm/network-information#injective-evm-mainnet)
# RPC Endpoints
* Recommended for integrations partners
* Customizable for needs of applications
* Customizable rate limits, and no cut off for historical data queries
* Freemium/ paid options
* How to connect:
* QuickNode: [Injective RPC Node Endpoints, APIs & Tools | QuickNode](https://www.quicknode.com/chains/inj)
* Thirdweb: [Injective EVM](https://thirdweb.com/injective)
* Not recommended for integrations partners
* Not customizable for needs of applications
* Heavy rate limiting, and cut off for historical data queries
* Free option
* How to connect:
* JSON-RPC Endpoint: `https://sentry.evm-rpc.injective.network/`
* WS Endpoint: `wss://sentry.evm-ws.injective.network`
Reference: [EVM Network Information | Injective | Docs](/developers-evm/network-information#injective-evm-mainnet)
Do **not** use inEVM, as that has been **deprecated**.
# Contract Addresses
| | | |
| --------- | ----------- | -------------------------------------------- |
| USDT | MTS USDT | `0x88f7F2b685F9692caf8c478f5BADF09eE9B1Cc13` |
| wETH | wrapped ETH | `0x83A15000b753AC0EeE06D2Cb41a69e76D0D5c7F7` |
| wINJ | wrapped INJ | `0x0000000088827d2d103ee2d9A6b781773AE03FfB` |
| USDC | | `0x2a25fbD67b3aE485e461fe55d9DbeF302B7D3989` |
| MultiCall | | `0xcA11bde05977b3631167028862bE2a173976CA11` |
Please use the reference page below as the canonical source.
Reference: [EVM Network Information | Injective | Docs](/developers-evm/network-information#injective-evm-mainnet)
# Bridges
[Injective Bridge](https://bridge.injective.network)
Guides:
* [How To Bridge From Ethereum To Injective Using Metamask](https://injective.com/blog/how-to-bridge-from-ethereum-to-injective-using-metamask/)
* [How To Bridge From Solana To Injective Using Phantom](https://injective.com/blog/how-to-bridge-from-solana-to-injective-using-phantom/)
* [How to Bridge To Injective Using Wormhole](https://injective.com/blog/how-to-bridge-to-injective-using-wormhole/)
* [How To Bridge From Cosmos To Injective Using Keplr](https://injective.com/blog/how-to-bridge-from-cosmos-to-injective-using-keplr/)
# Data
## Explorers
* Explorer: [`blockscout.injective.network`](https://blockscout.injective.network/)
* Explorer API: [`blockscout-api.injective.network/api`](https://blockscout-api.injective.network/api)
## Oracles
* API3:
* Price feeds: [Api3 Market | Injective EVM](https://market.api3.org/injective)
* Pyth:
* Documentation: [Pyth EVM Real Time Data Pull Integration](https://docs.pyth.network/price-feeds/core/use-real-time-data/pull-integration/evm)
* Reference documentation: [Pyth EVM Smart Contract Addresses](https://docs.pyth.network/price-feeds/core/contract-addresses/evm)
* Chainlink:
* Documentation: [Chainlink Data Streams](https://docs.chain.link/data-streams)
# Wallets
## `injectived`
Suitable for programmatic control, e.g. application/ dApp operated accounts.
Installation quickstart:
```shell theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.17.2-1765930431/linux-amd64.zip # replace with latest version of injective
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
In the command above, the URL for the `wget` download should be replaced with one for the latest release.
You can find the exact commands (including the URL) under the [Mainnet Validator](/infra/validator-mainnet) section.
More options, including installation via Docker, or compiling from source,
available in the reference page below.
Reference: [injectived | Injective | Docs](/developers/injectived)
## MetaMask
Suitable for retail users who need to interact with EVM DApps.
Installation:
* Get browser extension from [https://metamask.io/en-GB](https://metamask.io/en-GB) for your specific browser.
* Visit [https://blockscout.injective.network/](https://blockscout.injective.network/), scroll to the bottom of the page
* Click on the “Add Injective” button
* Follow the prompts in MetaMask’s user interface
Reference: [How to Create an Injective Wallet (MetaMask)](https://injective.com/blog/how-to-create-an-injective-wallet-2/#to-connect-to-injective-with-metamask)
## Keplr
* Keplr : [https://www.keplr.app](https://www.keplr.app)
* Keplr API Docs for Integration: [https://docs.keplr.app/api/intro](https://docs.keplr.app/api/intro)
Reference: [How to Create an Injective Wallet (Keplr)](https://injective.com/blog/how-to-create-an-injective-wallet-2#to-connect-to-injective-with-keplr)
# EVM Integrations FAQ
Source: https://docs.injective.network/developers-evm/evm-integrations-faq
Frequently asked questions about integrating with Injective's EVM.
## Does Injective EVM Support ...?
**Does Injective EVM Support (EVM feature)?**
A: Generally, the answer is "yes".
See below for more specific questions.
**Does Injective EVM Support these specific opcodes?**
A: Yes. We have parity with opcode implementation.
More precisely: We have not added any custom opcodes,
neither have we modified the behaviour of any opcodes.
**Does Injective EVM Support ERC20, ERC721, ERC1155?**
A: Yes, any Solidity based smart contract standards should work,
as these *do not* require any special features beyond the standard EVM.
Corollary: When implementing fungible tokens,
ERC20 and any others that are extensions of it,
we strongly recommend that you implement them as a MultiVM Token Standard (MTS) token.
This allows the same token to act as a fungible token not only on Injective's EVM,
but also on Injective native (specifically as Cosmos Denoms).
Should Injective add other VMs in the future, MTS tokens will also work on those.
Read more about MTS:
[General article](https://injective.com/blog/multivm-token-standard-wrapped-inj), and
[technical reference](/developers-evm/multivm-token-standard).
**Does Injective EVM Support EIP-1559?**
A: Yes.
## Can I use ... on Injective EVM?
A: Generally, the answer is "yes".
See below for more specific questions.
**Can I use (EVM tool/ library) on Injective EVM?**
A:
* viem - yes
* ethers.js - yes
* hardhat - yes
* foundry - yes
**Can I use Foundry on Injective EVM with Injective's EVM precompiles?**
A: Injective's [EVM precompiles](/developers-evm/precompiles)
access Injective native functions that are not available in generic EVMs.
This means that if you use, for example Foundry and connect it to:
* Injective EVM Testnet, it will work
* `localhost` simulated EVM network, it will not work
To address the latter issue, we've forked the Foundry tools to support
Injective precompiles (starting with Bank precompile needed for `BankERC20.sol` and MTS),
if you are using Solidity tests or deployment scripts as a Foundry project,
you will need this so `forge`/ `cast` can do local simulations.
Latest releases, with pre-built binaries for x86\_64 Linux and macOS ARM64,
can be found at [github.com/InjectiveLabs/foundry/releases](https://github.com/InjectiveLabs/foundry/releases).
In order to enable support for Injective precompiles on this forked version of Foundry, you must set `injective = true` inside config file `foundry.toml` or use an environment variable `FOUNDRY_INJECTIVE=true`.
## Which EVM development infrastructure is available on Injective?
Refer to the [EVM Integrations Cheat Sheet](/developers-evm/evm-integrations-cheat-sheet)
for the answers.
## How can I resolve JSON-RPC dropped responses?
A: If you are using the public endpoint for RPCs,
this is likely to happen to you due to rate limiting.
These endpoints are designed for very light usage.
If you have deployed a complex application,
you should consider using a commercial grade RPC endpoint instead.
You may find recommended RPC providers in the
[EVM Integrations Cheat Sheet](/developers-evm/evm-integrations-cheat-sheet).
## Are `inj...` addresses and `0x...` addresses comaptible?
A: Yes. In fact they are the same, simply rendered in different formats.
Refer to [Convert addresses](https://docs.injective.network/developers/convert-addresses)
for example code to convert between these two formats.
## Which EVM hardfork does Injective support?
A: Here's the live configuration data for the EVM:
[sentry.lcd.injective.network/injective/evm/v1/params](https://sentry.lcd.injective.network/injective/evm/v1/params)
Under `chain_config`, there are keys that correspond to EVM hard fork names (with suffixes).
These indicate which ones are enabled.
The value for these keys are the block numbers at which they are enabled.
As of the Mainnet launch, all of them are set to `0`,
i.e. they are enabled from the "genesis" EVM block.
For future EVM hardforks, new keys will be added that will have a non-zero block number
at which they will be (or were) enabled.
Do you have more questions about EVM integrations?
Join the [Injective discord](https://discord.com/invite/injective)
community and ask them there!
# Exchange Precompile
Source: https://docs.injective.network/developers-evm/exchange-precompile
The Exchange Precompile is a system smart contract residing at the fixed address `0x0000000000000000000000000000000000000065`. It offers Solidity developers a gas-efficient and native pathway to interact directly with the Injective chain's exchange module. By leveraging this precompile, your smart contracts can seamlessly perform a variety of exchange-related actions, including:
* Depositing and withdrawing funds to/from subaccounts.
* Placing or cancelling spot and derivative orders.
* Querying subaccount balances and open positions.
* Managing authorization grants for other accounts or contracts.
#### Calling the Precompile: Direct vs. Proxy Access
Interacting with the Exchange Precompile can be approached in two primary ways:
**1. Direct Access (Self-Calling Contracts)**
In this mode, your smart contract interacts with the precompile on its own behalf. The contract itself is the actor performing operations on the exchange module, using its own funds and managing its own positions.
*Example:*
```
exchange.deposit(address(this), subaccountID, denom, amount);
```
This method is straightforward and **requires no explicit authorization grant**, as the contract is inherently permissioned to manage its own resources.
**2. Proxy Access (Calling on Behalf of Another User)**
Smart contracts can also be designed to act as intermediaries, performing exchange operations on behalf of external user accounts. In this scenario, the contract calls the precompile, specifying a third-party's address as the sender or the account to be acted upon.
*Example:*
```
exchange.deposit(userAddress, subaccountID, denom, amount);
```
For this to succeed, the smart contract (`grantee`) **must be explicitly authorized** by the user (`userAddress`, the `granter`) to perform the specified action. This authorization is managed using the `approve` and `revoke` methods provided by the precompile. **It's crucial to handle these authorizations with care to ensure user funds are secure.**
To authorize a contract to perform specific actions on your behalf:
```
exchange.approve(grantee, msgTypes, spendLimit, duration);
```
* `grantee`: The address of the contract being authorized.
* `msgTypes`: An array of message types (e.g., `MsgCreateDerivativeLimitOrder`, `MsgDeposit`) the `grantee` is authorized to execute. Refer to `ExchangeTypes.sol` or the Injective Protocol protobuf definitions for a complete list.
* `spendLimit`: An array of `Cosmos.Coin` structs defining the maximum amount of specified tokens the `grantee` can utilize per message type or overall for the grant.
* `duration`: The time period, in seconds, for which the authorization remains valid.
To revoke a previously granted authorization:
```
exchange.revoke(grantee, msgTypes);
```
To check if an authorization currently exists:
```
exchange.allowance(grantee, granter, msgType);
```
#### Example: Direct Method
The `ExchangeDemo` contract below illustrates how a smart contract can use the direct access method. It performs basic exchange actions like depositing funds, withdrawing funds, creating a derivative limit order, and querying subaccount positions, all using its own subaccount and funds.
The `Exchange.sol` and `ExchangeTypes.sol` files contain the necessary interface definitions and data structures for interacting with the precompile. These are typically available in the official Injective Solidity contracts repository or can be included as dependencies in your project.
```solidity theme={null}
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
import "../src/Exchange.sol"; // Contains IExchangeModule interface
import "../src/ExchangeTypes.sol"; // Contains necessary structs like DerivativeOrder
contract ExchangeDemo {
address constant exchangeContract = 0x0000000000000000000000000000000000000065;
IExchangeModule exchange = IExchangeModule(exchangeContract);
/***************************************************************************
* Calling the precompile directly (contract acts on its own behalf)
****************************************************************************/
/**
* @notice Deposits funds from the contract's balance into one of its exchange subaccounts.
* @param subaccountID The target subaccount ID (derived from the contract's address).
* @param denom The denomination of the asset to deposit (e.g., "inj").
* @param amount The quantity of the asset to deposit.
* @return success Boolean indicating if the deposit was successful.
*/
function deposit(
string calldata subaccountID,
string calldata denom,
uint256 amount
) external returns (bool) {
try exchange.deposit(address(this), subaccountID, denom, amount) returns (bool success) {
return success;
} catch Error(string memory reason) {
revert(string(abi.encodePacked("Deposit error: ", reason)));
} catch {
revert("Unknown error during deposit");
}
}
/**
* @notice Withdraws funds from one of the contract's exchange subaccounts to its main balance.
* @param subaccountID The source subaccount ID.
* @param denom The denomination of the asset to withdraw.
* @param amount The quantity of the asset to withdraw.
* @return success Boolean indicating if the withdrawal was successful.
*/
function withdraw(
string calldata subaccountID,
string calldata denom,
uint256 amount
) external returns (bool) {
try exchange.withdraw(address(this), subaccountID, denom, amount) returns (bool success) {
return success;
} catch Error(string memory reason) {
revert(string(abi.encodePacked("Withdraw error: ", reason)));
} catch {
revert("Unknown error during withdraw");
}
}
/**
* @notice Queries the derivative positions for a given subaccount of this contract.
* @param subaccountID The subaccount ID to query.
* @return positions An array of DerivativePosition structs.
*/
function subaccountPositions(
string calldata subaccountID
) external view returns (IExchangeModule.DerivativePosition[] memory positions) {
// Note: View functions calling precompiles might behave differently based on node configuration
// For on-chain state, this is fine. For off-chain queries, direct gRPC/API queries are often preferred.
return exchange.subaccountPositions(subaccountID);
}
/**
* @notice Creates a new derivative limit order from the contract's subaccount.
* @param order The DerivativeOrder struct containing order details.
* @return response The response struct containing details like order hash.
*/
function createDerivativeLimitOrder(
IExchangeModule.DerivativeOrder calldata order
) external returns (IExchangeModule.CreateDerivativeLimitOrderResponse memory response) {
try exchange.createDerivativeLimitOrder(address(this), order) returns (IExchangeModule.CreateDerivativeLimitOrderResponse memory resp) {
return resp;
} catch Error(string memory reason) {
revert(string(abi.encodePacked("CreateDerivativeLimitOrder error: ", reason)));
} catch {
revert("Unknown error during createDerivativeLimitOrder");
}
}
}
```
#### Start building
For detailed instructions on how to build, deploy, and interact with this `ExchangeDemo` smart contract, including setting up subaccounts and funding, please refer to the comprehensive demo available in our [solidity-contracts](https://github.com/InjectiveLabs/solidity-contracts/tree/master/demos/exchange) repository.
#### Conclusion
The Exchange Precompile is a powerful tool, enabling sophisticated, protocol-integrated trading logic to be embedded directly within your smart contracts on Injective. Whether your contract is managing its own portfolio or acting as a versatile trading interface for other users (via the proxy pattern with `approve` and `revoke`), this precompile offers a clean, secure, and efficient method to interact with the core exchange module using Solidity.
Remember to prioritize direct calls for self-contained contract logic and to carefully implement the proxy pattern with robust authorization when building reusable contract interfaces for the broader Injective ecosystem.
\\
# Overview
Source: https://docs.injective.network/developers-evm/index
Welcome, EVM developers! Native EVM support on Injective lets you deploy Solidity smart contracts. It also opens up possibilities such as interacting with the exchange module, building dApps, and much more. You can now build in Injective with familiar tools, libraries, and workflows!
## Start Building on EVM
Set up your connection to Injective's EVM
Write **Solidity**. Then compile, test, deploy, verify, and interact with **smart contracts**.
EVM interface that allows smart contracts to interact with native functions of the Injective chain
INJ Faucet
# Infrastructure & Tooling
Source: https://docs.injective.network/developers-evm/infrastructure-and-tooling
Build on Injective with World-Class Infrastructure
BlockScoutInjective is supported by a rich ecosystem of industry-leading infrastructure providers. Access reliable RPCs, powerful data indexers, and all the tools you need to build and scale your dApp on the fastest L1 for finance.
### RPC & Node Providers
Tenderly Tenderly is a platform that offers advanced transaction simulation, enabling users to preview and analyze Ethereum and EVM-compatible transactions without broadcasting them on-chain. It also provides powerful debugging tools, including step-by-step execution tracing and error reporting, to help developers identify and fix issues in smart contracts efficiently. QuickNode Build on Injective with the fastest RPC Nodes, a comprehensive library of web3 APIs, and the most performant blockchain ETL tools.
### **Data Indexing & Querying**
The Graph
The Graph’s state-of-the-art Substreams and Substreams-powered subgraph solution, developed by StreamingFast for Injective, provides developers seamless access to on-chain data.
### Block Explorers
# MultiVM Token Standard
Source: https://docs.injective.network/developers-evm/multivm-token-standard
Understanding token representation in Injective's multi-VM architecture
## What is MultiVM Token Standard (MTS)?
MTS (MultiVM Token Standard) ensures that every token on Injective—whether deployed using Cosmos modules or via the Ethereum Virtual Machine (EVM)—has one canonical balance and identity. This unified approach prevents fragmentation and eliminates the need for bridging or wrapping tokens, thereby enabling seamless interoperability and unified liquidity for decentralized finance (DeFi) and dApp interactions.
## Why is MTS Important?
* **Seamless Interoperability:** Tokens remain consistent across Cosmos and EVM environments.
* **Unified Liquidity:** A single source of truth avoids liquidity fragmentation.
* **Enhanced Developer Experience:** Standard tools like Hardhat, Foundry, and MetaMask work out of the box.
* **Security & Efficiency:** All token state is maintained centrally in the bank module, ensuring robust security.
## Architecture
The system comprises two main components:
* [**Bank Precompile**](/developers-evm/bank-precompile/):
* Developed in Go, this precompile is embedded directly in the Injective EVM.
* It provides a Solidity interface that proxies ERC20 operations—such as mint, burn, and transfer—to the bank module.
* [**ERC20 Module**](/developers-evm/erc20-module/):
* This module maps native bank denoms (e.g., INJ, IBC tokens, Peggy assets) to an ERC20 contract within the EVM.
* It deploys MTS-compliant ERC20 contracts that always reflect the canonical token balance as maintained by the bank module.
Single Token Representation Architecture
## Network Info
* Chain ID: `1776`
* JSON-RPC Endpoint: `https://sentry.evm-rpc.injective.network/`
* WS Endpoint: `wss://sentry.evm-ws.injective.network`
* Faucet: N/A, to obtain Mainnet INJ see [`injective.com/getinj`](https://injective.com/getinj/)
* Explorer: [`blockscout.injective.network`](https://blockscout.injective.network/)
* Explorer API: `https://blockscout-api.injective.network/api`
Note that the Injective Chain ID is natively `injective-1`.
However, EVM uses a numeric chain ID of `1776`.
While these are different, they map to the **same** network.
See [Injective Mainnet network information](/developers/network-information/#injective-mainnet) for more details.
## Contracts
* **USDT** USDT (MTS) - [`0x88f7F2b685F9692caf8c478f5BADF09eE9B1Cc13`](https://blockscout.injective.network/address/0x88f7F2b685F9692caf8c478f5BADF09eE9B1Cc13)
* **wETH** wrapped ETH (MTS) - [`0x83A15000b753AC0EeE06D2Cb41a69e76D0D5c7F7`](https://blockscout.injective.network/address/0x83A15000b753AC0EeE06D2Cb41a69e76D0D5c7F7)
* **wINJ** wrapped INJ (MTS) - [`0x0000000088827d2d103ee2d9A6b781773AE03FfB`](https://blockscout.injective.network/address/0x0000000088827d2d103ee2d9A6b781773AE03FfB)
* **USDC** USDC (MTS) - [`0x2a25fbD67b3aE485e461fe55d9DbeF302B7D3989`](https://blockscout.injective.network/address/0x2a25fbD67b3aE485e461fe55d9DbeF302B7D3989)
* **MultiCall** - [`0xcA11bde05977b3631167028862bE2a173976CA11`](https://blockscout.injective.network/address/0xcA11bde05977b3631167028862bE2a173976CA11)
Note that tokens that are **MTS** follow the [MultiVM Token Standard](https://docs.injective.network/developers-evm/multivm-token-standard).
This means the same token can be used in all Injective modules (EVM, Cosmos) without using a bridge.
## More Providers
* Explorers
* Blockscout mirror: [`injective.cloud.blockscout.com`](https://injective.cloud.blockscout.com)
* JSON-RPC Providers
* Quicknode [`quicknode.com/chains/inj`](https://www.quicknode.com/chains/inj)
* Note that you will need to create an account on quicknode to obtain an endpoint URL
* [Quicknode JSON-RPC documentation](https://www.quicknode.com/docs/injective/evm/eth_blockNumber)
* ThirdWeb [`thirdweb.com/injective`](https://thirdweb.com/injective)
* Note that you will need to create an account on thirdweb to obtain an endpoint URL
* [ThirdWeb Playground](https://playground.thirdweb.com/)
## Network Info
* Chain ID: `1439`
* JSON-RPC Endpoint: `https://k8s.testnet.json-rpc.injective.network/`
* WS Endpoint: `https://k8s.testnet.ws.injective.network/`
* Faucet: [`testnet.faucet.injective.network/`](https://testnet.faucet.injective.network/)
* Explorer: [`testnet.blockscout.injective.network/`](https://testnet.blockscout.injective.network/)
* Explorer API: `https://testnet.blockscout-api.injective.network/api`
Note that the Injective Chain ID is natively `injective-888`. However, EVM uses a numeric chain ID of `1439`. While these are different, they map to the **same** network.
See [Injective Testnet network information](/developers/network-information/#injective-testnet) for more details.
## Contracts
* **wINJ** wrapped INJ (MTS) - [`0x0000000088827d2d103ee2d9A6b781773AE03FfB`](https://testnet.blockscout.injective.network/address/0x0000000088827d2d103ee2d9A6b781773AE03FfB)
* **USDT** USDT (MTS) - [`0xaDC7bcB5d8fe053Ef19b4E0C861c262Af6e0db60`](https://testnet.blockscout.injective.network/address/0xaDC7bcB5d8fe053Ef19b4E0C861c262Af6e0db60)
Note that tokens that are **MTS** follow the [MultiVM Token Standard](https://docs.injective.network/developers-evm/multivm-token-standard).
This means the same token can be used in all Injective modules (EVM, Cosmos) without using a bridge.
## More Providers
* Explorers
* Blockscout mirror: [`testnet-injective.cloud.blockscout.com/`](https://testnet-injective.cloud.blockscout.com/)
* JSON-RPC Providers
* Quicknode [`quicknode.com/chains/inj`](https://www.quicknode.com/chains/inj)
* Note that you will need to create an account on quicknode to obtain an endpoint URL
* [Quicknode JSON-RPC documentation](https://www.quicknode.com/docs/injective/evm/eth_blockNumber)
* ThirdWeb [`thirdweb.com/injective-evm-testnet`](https://thirdweb.com/injective-evm-testnet)
* Note that you will need to create an account on thirdweb to obtain an endpoint URL
* [ThirdWeb Playground](https://playground.thirdweb.com/)
## More Info
For more information about Injective EVM Testnet see the following pages:
* Basics:
* [Start Building on EVM](/developers-evm)
* [Your first EVM smart contract](/developers-evm/smart-contracts)
* [Your first EVM dApp](/developers-evm/dapps)
* Advanced:
* [EVM Equivalence](/developers-evm/evm-equivalence)
* [MultiVM Token Standard](/developers-evm/multivm-token-standard)
* [Precompiles](/developers-evm/precompiles)
# Precompiles
Source: https://docs.injective.network/developers-evm/precompiles
### What are Precompiles on Injective?
On Injective, precompiles are special, highly-optimized smart contracts embedded directly into our EVM (Ethereum Virtual Machine) layer at the protocol level. Unlike standard Solidity smart contracts that are deployed by users, precompiles are part of the chain's core logic. They are written in Go instead of Solidity and are exposed to the EVM with fixed addresses, making them callable from your Solidity smart contracts just like any other smart contract.
Think of them as native functions of the Injective chain that have been given an Ethereum-style interface.
### Why are they necessary? (Bridging EVM & Native Modules)
The Injective EVM doesn't operate in a silo. It's deeply integrated with Injective's powerful native Cosmos SDK modules, such as the Bank module (for token management), the Exchange module (for the on-chain order book), the Staking module, and more.
Precompiles serve as the crucial **bridge** between the EVM world (where your Solidity contracts live) and these native Injective functionalities. Without precompiles, your EVM smart contracts would be isolated, unable to tap into the rich features and liquidity of the broader Injective ecosystem.
For example, our [MultiVM Token Standard (MTS)](/developers-evm/multivm-token-standard) model, which ensures unified token balances across native and EVM environments, is heavily reliant on the **Bank Precompile**.
### Benefits for Developers
* **Access to Native Features:** Directly interact with Injective's unique modules like the on-chain order book, native staking, governance, and the bank module for MTS.
* **Enhanced Performance:** Operations executed via precompiles can be significantly faster and more gas-efficient than trying to replicate complex native logic purely in Solidity, as they run as optimized native code.
* **Seamless Interoperability:** Build truly integrated applications that leverage the strengths of both the EVM and Injective's Cosmos-native capabilities.
* **Simplified Development:** Interact with complex native functionalities through familiar Solidity interfaces, abstracting away much of the underlying Cosmos complexity.
A range of ERC-20 implementations backed by the Bank precompile, alongside precompile interfaces and abstract contracts, are available at [Injective’s Solidity Contracts Repository](https://github.com/InjectiveLabs/solidity-contracts). Key contracts include:
* [**Bank.sol**](https://github.com/InjectiveLabs/solidity-contracts/blob/master/src/Bank.sol) – precompile interface
* [**BankERC20.sol**](https://github.com/InjectiveLabs/solidity-contracts/blob/master/src/BankERC20.sol) – abstract ERC20 implementation backed by the Bank precompile
* [**FixedSupplyBankERC20.sol**](https://github.com/InjectiveLabs/solidity-contracts/blob/master/src/FixedSupplyBankERC20.sol) – decentralized ERC20 with fixed supply (no owner, no minting or burning)
* [**MintBurnBankERC20.sol**](https://github.com/InjectiveLabs/solidity-contracts/blob/master/src/MintBurnBankERC20.sol) – ERC20 with an owner authorized to mint and burn tokens
These implementations are based on OpenZeppelin’s ERC20 contracts. Developers can freely create custom ERC20 contracts utilizing the Bank precompile.
### Demos to get you started
We've prepared a handful of demos that show how to build contracts using the Bank, Exchange, and Staking precompiles. These examples also demonstrate how to interact with the Injective EVM using the most common Ethereum development framework — **Foundry**.
By leveraging Foundry's `cast` tool, you can easily deploy contracts and interact with the Injective chain directly from your terminal. This enables builders to quickly experiment, test, and deploy powerful applications that tap into Injective's native modules.
Explore the demos below to see:
* How to write Solidity contracts that call precompiles for token management, trading, and staking.
* How to use Foundry scripts and `cast` commands to deploy and interact with these contracts on Injective EVM.
* Best practices for bridging EVM logic with Injective's native features.
Jumpstart your development by cloning the [Injective Solidity Contracts Repository](https://github.com/InjectiveLabs/solidity-contracts/tree/master/demos) and following the step-by-step guides in each demo directory.
* [Bank Precompile Demo](https://github.com/InjectiveLabs/solidity-contracts/tree/master/demos/erc20)
* [Exchange Precompile Demo](https://github.com/InjectiveLabs/solidity-contracts/tree/master/demos/exchange)
* [Staking Precompile Demo](https://github.com/InjectiveLabs/solidity-contracts/tree/master/demos/staking)
### Precompile Addresses
| Name | Purpose | EVM address |
| ----------------------------------------------- | ----------------------------- | ----------- |
| [Bank](/developers-evm/bank-precompile) | Token Management | `0x64` |
| [Exchange](/developers-evm/exchange-precompile) | On-chain Order Book | `0x65` |
| Staking | Native staking token on-chain | `0x66` |
## The non-contract address error
When using Foundry, and you "fork" the Injective Mainnet or Injective Testnet locally,
and execute your smart contracts in that environment,
you may see an error similar to the following:
```text theme={null}
[Revert] call to non-contract address 0x0000000000000000000000000000000000000064
```
This occurs becuase Foundry is *simulating* Injective locally,
rather than actually running on Injective.
It is therefore running a *generic EVM* simulation,
and not one that is specific to Injective.
The difference lies in Injective's native functionality not being present,
and therefore it being unaware of the precompiles.
The fix for this is simple:
Use a version of Foundry that has been patched to include Injective's precompiles:
[github.com/InjectiveLabs/foundry/releases](https://github.com/InjectiveLabs/foundry/releases).
These include pre-built binaries for x86\_64 Linux and macOS ARM64.
# Set up Foundry and compile a smart contract
Source: https://docs.injective.network/developers-evm/smart-contracts/compile-foundry
## Prerequisites
Ensure that you have Foundry installed, by running the following command:
```shell theme={null}
forge --version
```
Note that the version used in this tutorial was `1.2.3-stable`. Be sure to use this version or later when following along.
If you do not have foundry yet, run the following command to install it:
```shell theme={null}
curl -L https://foundry.paradigm.xyz | bash
```
There are other options for how to install Foundry.
See the [the Foundry installation docs](https://getfoundry.sh/introduction/installation).
You will need a wallet, and an account that has been funded with some Testnet INJ.
You can request EVM testnet funds from the [Injective Testnet faucet](https://testnet.faucet.injective.network/).
After creating your account, be sure to copy your private key somewhere accessible, as you will need it to complete this tutorial.
Note that private keys should be handled with caution.
The instructions here should be considered sufficient for local development and Testnet.
However, these are **not** secure enough for private keys used on Mainnet.
Please ensure that you follow best practices for key security on Mainnet, and do not re-use the same keys/ accounts between Mainnet and other networks.
## Set up a new Foundry project
Use git to clone the demo repo, which already has the project completely set up for you.
```shell theme={null}
git clone https://github.com/injective-dev/foundry-inj
cd foundry-inj
```
Install the `forge-std` library, which provides utility functions used in this project.
```shell theme={null}
forge install foundry-rs/forge-std
```
## Orientation
Open the repo in your code editor/ IDE, and take a look at the directory structure.
```text theme={null}
foundry-inj/
src/
Counter.sol → smart contract Solidity code
test/
Counter.t.sol → test cases
foundry.toml → configuration
```
The `foundry.toml` file is already pre-configured to connect to the Injective EVM Testnet.
All you need to do before proceeding is to provide it with a private key of your Injective Testnet account.
Enter the following command to import a private key, and save it against an account named `injTest`:
```shell theme={null}
cast wallet import injTest --interactive
```
This will prompt you for the private key, and also a password that you need to enter each time you wish to use this account.
Use the private key of the account which you have just created and funded earlier (e.g. via the Injective Testnet faucet).
Note that when you type or paste text for the private key and password, nothing is shown in the terminal.
The output should look similar to this:
```text theme={null}
Enter private key:
Enter password:
`injTest` keystore was saved successfully. Address: 0x58f936cb685bd6a7dc9a21fa83e8aaaf8edd5724
```
This saves an encrypted version of the private key in `~/.foundry/keystores`,
and in subsequent commands can be accessed using the `--account` CLI flag.
## Edit the smart contract
The smart contract that is included in this demo is very basic. It:
* Stores one `value` which is a number.
* Exposes a `value()` query method.
* Exposes an `increment(num)` transaction method.
Open the file: `src/Counter.sol`
```solidity theme={null}
// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;
contract Counter {
uint256 public value = 0;
function increment(uint256 num) external {
value += num;
}
}
```
## Compile the smart contract
Run the following command:
```shell theme={null}
forge build
```
Foundry will automatically download and run the version of the Solidity compiler (`solc`) that was configured in the `foundry.toml` file.
## Check the compilation output
After the compiler completes, you should see additional directories in the project directory:
```text theme={null}
foundry-inj/
cache/
...
out/
build-info/
...
Counter.sol/
Counter.json → open this file
```
Open the `Counter.json` file (`out/Counter.sol/Counter.json`).
In it, you should see the compiler outputs, including the `abi` and `bytecode` fields.
These artifacts are used in all later steps (test, deploy, verify, and interact).
## Next steps
Now that you have set up a Foundry project and compiled a smart contract, you are ready to test that smart contract!
Check out the [test a smart contract using Foundry](./test-foundry/) tutorial next.
# Set up Hardhat and compile a smart contract
Source: https://docs.injective.network/developers-evm/smart-contracts/compile-hardhat
## Prerequisites
Ensure that you have a recent version of NodeJs installed.
You can check this using the following command:
```shell theme={null}
node -v
```
This guide was written using the following version:
```text theme={null}
v22.16.0
```
If you do not have NodeJs installed yet, do so using:
* Linux or Mac: [NVM](https://github.com/nvm-sh/nvm)
* Windows: [NVM for Windows](https://github.com/coreybutler/nvm-windows)
You will need a wallet, and an account that has been funded with some Testnet INJ.
You can request EVM testnet funds from the [Injective Testnet faucet](https://testnet.faucet.injective.network/).
After creating your account, be sure to copy your private key somewhere accessible, as you will need it to complete this tutorial.
Note that private keys should be handled with caution.
The instructions here should be considered sufficient for local development and Testnet.
However, these are **not** secure enough for private keys used on Mainnet.
Please ensure that you follow best practices for key security on Mainnet, and do not re-use the same keys/ accounts between Mainnet and other networks.
## Set up a new Hardhat project
Use git to clone the demo repo, which already has the project completely set up for you.
```shell theme={null}
git clone https://github.com/injective-dev/hardhat-inj
```
Install dependencies from npm:
```shell theme={null}
npm install
```
## Orientation
While waiting for npm to download and install, open the repo in your code editor/ IDE, and take a look at the directory structure.
```text theme={null}
hardhat-inj/
contracts/
Counter.sol → smart contract Solidity code
script/
deploy.js → deployment script
test/
Counter.test.js → test cases
hardhat.config.js → configuration
.example.env
```
The `hardhat.config.js` file is already pre-configured to connect to the Injective EVM Testnet.
All you need to do before proceeding is to provide it with a private key of your Injective Testnet account.
```shell theme={null}
cp .example.env .env
```
Edit the `.env` file to add the private key.
Optionally, you may wish to update to any alternative JSON-RPC endpoints.
```shell theme={null}
PRIVATE_KEY=your private key without 0x prefix
INJ_TESTNET_RPC_URL=https://k8s.testnet.json-rpc.injective.network/
```
## Edit the smart contract
The smart contract that is included in this demo is very basic. It:
* Stores one `value` which is a number.
* Exposes a `value()` query method.
* Exposes an `increment(num)` transaction method.
Open the file: `contracts/Counter.sol`
```solidity theme={null}
// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;
contract Counter {
uint256 public value = 0;
function increment(uint256 num) external {
value += num;
}
}
```
## Compile the smart contract
Run the following command:
```shell theme={null}
npx hardhat compile
```
Hardhat will automatically download and run the version of the Solidity compiler (`solc`) that was configured in the `hardhat.config.js` file.
## Check the compilation output
After the compiler completes, you should see additional directories in the project directory:
```text theme={null}
hardhat-inj/
artifacts/
build-info/
...
contracts/
Counter.sol/
Counter.json → open this file
...
cache/
...
```
Open the `Counter.json` file (`artifacts/contracts/Counter.sol/Counter.json`).
In it, you should see the compiler outputs, including the `abi` and `bytecode` fields.
These artifacts are used in all later steps (test, deploy, verify, and interact).
## Next steps
Now that you have set up a Hardhat project and compiled a smart contract, you are ready to test that smart contract!
Check out the [test a smart contract using Hardhat](./test-hardhat/) tutorial next.
# Deploy a smart contract using Foundry
Source: https://docs.injective.network/developers-evm/smart-contracts/deploy-foundry
## Prerequisites
You should already have a Foundry project set up, and have compiled your smart contract successfully.
See the [set up Foundry and compile a smart contract](./compile-foundry/) tutorial for how to do so.
Optionally, but strongly recommended: You should also have tested your smart contract successfully.
See the [test a smart contract using Foundry](./test-foundry/) tutorial for how to do so.
## Run the deployment
Run the following command to deploy the smart contract:
```shell theme={null}
forge create \
src/Counter.sol:Counter \
--rpc-url injectiveEvm \
--legacy \
--account injTest \
--gas-price 160000000 \
--gas-limit 2000000 \
--broadcast
```
Note that we're using the `injTest` account saved to the keystore,
which was previously set up in [set up Foundry and compile a smart contract](./compile-foundry/).
The output should look similar to:
```text theme={null}
Enter keystore password:
Deployer: 0x58f936cb685Bd6a7dC9a21Fa83E8aaaF8EDD5724
Deployed to: 0x213bA803265386C10CE04a2cAa0f31FF3440b9cF
Transaction hash: 0x6aa9022f593083c7779da014a3032efd40f3faa2cf3473f4252a8fbd2a80db6c
```
Copy the deployed address, visit [`https://testnet.blockscout.injective.network`](https://testnet.blockscout.injective.network/), and paste the address in the search field.
You'll visit the smart contract page in the block explorer for the smart contract that you have just deployed.
If you click on the "Contract" tab, you should see the EVM bytecode for that contract, and it will match the EVM bytecode found in your artifacts directory after compilation.
## Next steps
Now that you have deployed your smart contract, you are ready to verify that smart contract!
Check out the [verify a smart contract using Foundry](./verify-foundry/) tutorial next.
# Deploy a smart contract using Hardhat
Source: https://docs.injective.network/developers-evm/smart-contracts/deploy-hardhat
## Prerequisites
You should already have a Hardhat project set up, and have compiled your smart contract successfully.
See the [set up Hardhat and compile a smart contract](./compile-hardhat/) tutorial for how to do so.
Optionally, but strongly recommended: You should also have tested your smart contract successfully.
See the [test a smart contract using Hardhat](./test-hardhat/) tutorial for how to do so.
## Edit the deployment script
In order for the smart contract that you have compiled on your computer to exist on the Injective Testnet, it needs to be deployed onto the network.
To do so, we will make use of a script that uses an `ethers` instance that is pre-configured by Hardhat using the values specified in `hardhat.config.js`.
Open the file: `script/deploy.js`
```js theme={null}
async function main() {
const Counter = await ethers.getContractFactory('Counter');
const counter = await Counter.deploy({
gasPrice: 160e6,
gasLimit: 2e6,
});
await counter.waitForDeployment();
const address = await counter.getAddress();
console.log('Counter smart contract deployed to:', address);
}
```
Recall that after compiling the smart contracts, we looked at `artifacts/contracts/Counter.sol/Counter.json`? In this script, `ethers.getContractFactory('Counter')` retrieves that file, and extracts ABI and EVM bytecode from it.
The following lines use that information to construct a deployment transaction and submit it to the network.
If successful, the address at which your smart contract was deployed will be output, for example:
[`0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b`](https://testnet.blockscout.injective.network/address/0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b)
Note that on other EVM networks, transactions (including deployment transactions), do not need to specify a gas price and a gas limit. Currently, however, this is necessary on Injective.
## Run the deployment script
Run the following command to deploy the smart contract:
```shell theme={null}
npx hardhat run script/deploy.js --network inj_testnet
```
Copy the deployed address, visit [`https://testnet.blockscout.injective.network`](https://testnet.blockscout.injective.network/), and paste the address in the search field.
You'll visit the smart contract page in the block explorer for the smart contract that you have just deployed.
If you click on the "Contract" tab, you should see the EVM bytecode for that contract, and it will match the EVM bytecode found in your artifacts directory after compilation.
## Next steps
Now that you have deployed your smart contract, you are ready to verify that smart contract!
Check out the [verify a smart contract using Hardhat](./verify-hardhat/) tutorial next.
# Your First EVM Smart Contract
Source: https://docs.injective.network/developers-evm/smart-contracts/index
Smart contracts are code that runs on a blockchain.
You can compile Solidity smart contracts,
and test, deploy, verify, and interact with them on Injective's Ethereum Virtual Machine (EVM).
You can do so using standard EVM developer tools and frameworks too.
These guides show you how to do so using Hardhat and Foundry.
## Hardhat
This guide will walk you through building an EVM Smart Contract on Injective Testnet using [Hardhat](https://hardhat.org/).
* [Set up Hardhat and compile a smart contract](/developers-evm/smart-contracts/compile-hardhat/)
* [Test a smart contract using Hardhat](/developers-evm/smart-contracts/test-hardhat/)
* [Deploy a smart contract using Hardhat](/developers-evm/smart-contracts/deploy-hardhat/)
* [Verify a smart contract using Hardhat](/developers-evm/smart-contracts/verify-hardhat/)
* [Interact with a smart contract using Hardhat](/developers-evm/smart-contracts/interact-hardhat/)
## Foundry
This guide will walk you through building an EVM Smart Contract on Injective Testnet using [Foundry](https://getfoundry.sh/).
* [Set up Foundry and compile a smart contract](/developers-evm/smart-contracts/compile-foundry/)
* [Test a smart contract using Foundry](/developers-evm/smart-contracts/test-foundry/)
* [Deploy a smart contract using Foundry](/developers-evm/smart-contracts/deploy-foundry/)
* [Verify a smart contract using Foundry](/developers-evm/smart-contracts/verify-foundry/)
* [Interact with a smart contract using Foundry](/developers-evm/smart-contracts/interact-foundry/)
## Next steps
Smart contracts do not provide a user experience for non-technical users.
To cater to them, you will need to build a decentralised application.
To do so, check out the [your first dApp](/developers-evm/dapps/) guides!
# Interact with a smart contract using Foundry
Source: https://docs.injective.network/developers-evm/smart-contracts/interact-foundry
## Prerequisites
You should already have a Foundry project set up, and have deployed your smart contract successfully.
See the [deploy a smart contract using Foundry](./deploy-foundry/) tutorial for how to do so.
Optionally, but strongly recommended: You should also have successfully verified your smart contract.
See the [verify a smart contract using Foundry](./verify-foundry/) tutorial for how to do so.
## Invoke function - query
Queries are read-only operations.
So smart contract state **is not updated**.
As *no state change* is needed, no wallets, signatures, or transaction fees (gas) are required.
Use the following command to query the `value()` function:
```shell theme={null}
cast call \
--rpc-url injectiveEvm \
${SC_ADDRESS} \
"value()"
```
Replace `${SC_ADDRESS}` with the address at which you deployed your smart contract.
For example, if the smart contract address is `0x213ba803265386c10ce04a2caa0f31ff3440b9cf`, the command is:
```shell theme={null}
cast call \
--rpc-url injectiveEvm \
0x213ba803265386c10ce04a2caa0f31ff3440b9cf \
"value()"
```
This should output the following.
```text theme={null}
0x0000000000000000000000000000000000000000000000000000000000000000
```
Note that `0x0000000000000000000000000000000000000000000000000000000000000000` means `0`.
It is the raw representation in hexadecimal for Solidity's `uint256` (the return type of the `value()` function in the smart contract).
## Invoke function - transaction
Transactions are write operations.
So smart contract **state is updated**.
As *state change* can occur, the transaction must be signed by a wallet, and transaction fees (gas) need to be paid.
Use the following command to transact the `increment(num)` function.
```shell theme={null}
cast send \
--legacy \
--rpc-url injectiveEvm \
--gas-price 160000000 \
--gas-limit 2000000 \
--account injTest \
${SC_ADDRESS} \
"increment(uint256)" \
1
```
Note that gas price is stated in *wei*.
1 wei = 10^-18 INJ.
Replace `${SC_ADDRESS}` with the address at which you deployed your smart contract.
For example, if the smart contract address is `0x213ba803265386c10ce04a2caa0f31ff3440b9cf`, the command is:
```shell theme={null}
cast send \
--legacy \
--rpc-url injectiveEvm \
--gas-price 160000000 \
--gas-limit 2000000 \
--account injTest \
0x213ba803265386c10ce04a2caa0f31ff3440b9cf \
"increment(uint256)" \
1
```
If successful, this should produce a result similar to the following:
```text theme={null}
Enter keystore password:
blockHash 0xe4c1f5faafc5365c43678135d6adc87104f0e288cddfcdffeb2f5aa08282ca22
blockNumber 83078201
contractAddress
cumulativeGasUsed 43623
effectiveGasPrice 160000000
from 0x58f936cb685Bd6a7dC9a21Fa83E8aaaF8EDD5724
gasUsed 43623
logs []
logsBloom 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
root
status 1 (success)
transactionHash 0x3c95e15ba24074301323e09d09d5967cc2858e255d1fdfd912758fd8bbd353b4
transactionIndex 0
type 0
blobGasPrice
blobGasUsed
to 0x213bA803265386C10CE04a2cAa0f31FF3440b9cF
```
After updating the state, you can query the new state.
The result will reflect the state change.
```shell theme={null}
cast call \
--rpc-url injectiveEvm \
${SC_ADDRESS} \
"value()"
```
This time the result should be `0x0000000000000000000000000000000000000000000000000000000000000001` because `0 + 1 = 1`.
```js theme={null}
0x0000000000000000000000000000000000000000000000000000000000000001
```
## Next steps
Congratulations, you have completed this entire guide for developing EVM smart contracts on Injective using Foundry!
Smart contracts do not provide a user experience for non-technical users.
To cater to them, you will need to build a decentralised application.
To do so, check out the [your first dApp](../dapps/) guides!
# Interact with a smart contract using Hardhat
Source: https://docs.injective.network/developers-evm/smart-contracts/interact-hardhat
## Prerequisites
You should already have a Hardhat project set up, and have deployed your smart contract successfully.
See the [deploy a smart contract using Hardhat](./deploy-hardhat/) tutorial for how to do so.
Optionally, but strongly recommended: You should also have successfully verified your smart contract.
See the [verify a smart contract using Hardhat](./verify-hardhat/) tutorial for how to do so.
## Start the Hardhat console
Use the following command to start an interactive Javascript REPL.
```shell theme={null}
npx hardhat console --network inj_testnet
```
Now the shell will be a NodeJs REPL instead of your regular shell (bash, zsh, et cetera).
In this REPL, we will create an instance of the `Counter` smart contract.
To do so, use `ethers.getContractFactory(...)` and `contract.attach('0x...');`.
For example, if the smart contract was deployed to `0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b`, the commands should look like this:
```js theme={null}
const Counter = await ethers.getContractFactory('Counter');
const counter = await Counter.attach('0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b');
```
Note that in this REPL, you will see `> ` as the shell prompt.
The results of each prompt are output without this prefix.
The contents of your terminal will therefore look similar to this:
```js theme={null}
> const Counter = await ethers.getContractFactory('Counter');
undefined
> const counter = await Counter.attach('0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b');
undefined
```
Now you can interact with the smart contract using `counter`.
## Invoke function - query
Queries are read-only operations.
So smart contract state **is not updated**.
As *no state change* is needed, no wallets, signatures, or transaction fees (gas) are required.
Use the following command to query the `value()` function.
```js theme={null}
await counter.value();
```
This should output the following.
```js theme={null}
0n
```
Note that `0n` means `0`, the `n` suffix indicates that it is
a [`BigInt`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt)
and not a [`Number`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number).
This is because Solidity's `uint256` (the return type of the `value()` function in the smart contract),
is not possible to be represented with `Number`,
as the largest possible integer value for that is `2^53 - 1`.
Thus `BigInt` needs to be used instead.
## Invoke function - transaction
Transactions are write operations.
So smart contract **state is updated**.
As *state change* can occur, the transaction must be signed by a wallet, and transaction fees (gas) need to be paid.
Use the following command to transact the `increment(num)` function.
```js theme={null}
await counter.increment(1, { gasPrice: 160e6, gasLimit: 2e6 });
```
Note that gas price is stated in *wei*.
1 wei = 10^-18 INJ.
If successful, this should produce a result similar to the following:
```js theme={null}
ContractTransactionResponse { ...
```
After updating the state, you can query the new state.
The result will reflect the state change.
```js theme={null}
await counter.value();
```
This time the result should be `1n` because `0 + 1 = 1`.
```js theme={null}
1n
```
## Stop the Hardhat console
Press `Ctrl+C` twice in a row, or enter the `.exit` command.
## Next steps
Congratulations, you have completed this entire guide for developing EVM smart contracts on Injective using Hardhat!
Smart contracts do not provide a user experience for non-technical users.
To cater to them, you will need to build a decentralised application.
To do so, check out the [your first dApp](../dapps/) guides!
# Test a smart contract using Foundry
Source: https://docs.injective.network/developers-evm/smart-contracts/test-foundry
## Prerequisites
You should already have a Foundry project set up, and have compiled your smart contract successfully.
See the [set up Foundry and compile a smart contract](./compile-foundry/) tutorial for how to do so.
## Edit the test specifications
As the smart contract we are testing is minimal, so are the test cases that it needs.
Before testing, we need to deploy the smart contract.
This happens in the `setUp` block.
This is because smart contracts cannot execute in isolation, they must be within the EVM to execute.
In Foundry, by default, the tests will execute in an emulated in-memory EVM instance, which is transient, so the deployment is perfunctory.
Open the file: `test/Counter.t.sol`
```solidity theme={null}
// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;
import { Test } from "forge-std/Test.sol";
import { Counter } from "../src/Counter.sol";
contract CounterTest is Test {
Counter public counter;
function setUp() public {
counter = new Counter();
}
function testInitialValue() public view {
assertEq(counter.value(), 0);
}
function testIncrementValueFromZero() public {
counter.increment(100);
assertEq(counter.value(), 100);
}
function testIncrementValueFromNonZero() public {
counter.increment(100);
counter.increment(23);
assertEq(counter.value(), 123);
}
}
```
We see that there are 3 test cases:
* Check the initial `value()`.
* Invoke `increment(num)` and then check that the `value()` has updated.
* Invoke `increment(num)` again, and then check that the `value()` has updated again.
## Execute tests against the smart contract
The following command runs the tests we just looked at.
```shell theme={null}
forge test
```
## Check the test output
If all the tests work as planned, you should see some output similar to the following:
```text theme={null}
Ran 3 tests for test/Counter.t.sol:CounterTest
[PASS] testIncrementValueFromNonZero() (gas: 32298)
[PASS] testIncrementValueFromZero() (gas: 31329)
[PASS] testInitialValue() (gas: 10392)
Suite result: ok. 3 passed; 0 failed; 0 skipped; finished in 5.35ms (3.16ms CPU time)
Ran 1 test suite in 171.04ms (5.35ms CPU time): 3 tests passed, 0 failed, 0 skipped (3 total tests)
```
## Next steps
Now that you have tested your smart contract, you are ready to deploy that smart contract!
Check out the [deploy a smart contract using Foundry](./deploy-foundry/) tutorial next.
# Test a smart contract using Hardhat
Source: https://docs.injective.network/developers-evm/smart-contracts/test-hardhat
## Prerequisites
You should already have a Hardhat project set up, and have compiled your smart contract successfully.
See the [set up Hardhat and compile a smart contract](./compile-hardhat/) tutorial for how to do so.
## Edit the test specifications
As the smart contract we are testing is minimal, so are the test cases that it needs.
Before testing, we need to deploy the smart contract.
This happens in the `before` block.
This is because smart contracts cannot execute in isolation, they must be within the EVM to execute.
In Hardhat, by default, the tests will execute in an emulated in-memory EVM instance, which is transient, so the deployment is perfunctory.
Open the file: `test/Counter.test.js`
```js theme={null}
const { expect } = require('chai');
describe('Counter', function () {
let counter;
before(async function () {
Counter = await ethers.getContractFactory('Counter');
counter = await Counter.deploy();
await counter.waitForDeployment();
});
it('should start with a count of 0', async function () {
expect(await counter.value()).to.equal(0);
});
it('should increment the count starting from zero', async function () {
await counter.increment(100);
expect(await counter.value()).to.equal(100);
});
it('should increment the count starting from non-zero', async function () {
await counter.increment(23);
expect(await counter.value()).to.equal(123);
});
});
```
We see that there are 3 test cases:
* Check the initial `value()`.
* Invoke `increment(num)` and then check that the `value()` has updated.
* Invoke `increment(num)` again, and then check that the `value()` has updated again.
## Execute tests against the smart contract
The following command runs the tests we just looked at.
```shell theme={null}
npx hardhat test
```
The following command runs the test, but **not** within the emulated EVM instance.
Instead, the smart contract is deployed to the Injective Testnet (a public network), and then tests are run against it.
This is **not recommended** in most cases, and is only needed in select/ advanced use cases.
```shell theme={null}
npx hardhat test --network inj_testnet
```
## Check the test output
If all the tests work as planned, you should see some output similar to the following:
```text theme={null}
Counter
✔ should start with a count of 0
✔ should increment the count starting from zero
✔ should increment the count starting from non-zero
3 passing (41ms)
```
This is followed by a table which includes additional reporting on gas, which is a measure of the complexity and transaction costs.
## Next steps
Now that you have tested your smart contract, you are ready to deploy that smart contract!
Check out the [deploy a smart contract using Hardhat](./deploy-hardhat/) tutorial next.
# Verify a smart contract using Foundry
Source: https://docs.injective.network/developers-evm/smart-contracts/verify-foundry
## Prerequisites
You should already have a Foundry project set up, and have deployed your smart contract successfully.
See the [deploy a smart contract using Foundry](./deploy-foundry/) tutorial for how to do so.
## What is smart contract verification?
The process of verification does not have any effect on the smart contract itself, or any other state of the network.
Instead, it is a standardised process through which network explorers are provided with the original source code of the smart contract deployed at a particular address. The network explorer **independently compiles** that source code, and verifies that the resultant bytecode is indeed a **match** with the bytecode present from the smart contract's deployment transaction.
If verification passes (there is a match), the block explorer "unlocks" an enhanced mode within for that particular smart contract's page.
More smart contract details are now displayed, including:
* Full source code (Solidity)
* ABI (JSON)
* Transactions and events are shown with higher detail (parsed using ABI)
Additionally, if the user connects their wallet, they can invoke functions within the network explorer itself to query the smart contract, and even send transactions to update its state.
## Run the verification command
Enter the following command:
```shell theme={null}
forge verify-contract \
--rpc-url injectiveEvm \
--verifier blockscout \
--verifier-url 'https://testnet.blockscout-api.injective.network/api/' \
${SC_ADDRESS} \
src/Counter.sol:Counter
```
Replace `${SC_ADDRESS}` with the address at which you deployed your smart contract.
For example, if the smart contract address is `0x213bA803265386C10CE04a2cAa0f31FF3440b9cF`, the command is:
```shell theme={null}
forge verify-contract \
--rpc-url injectiveEvm \
--verifier blockscout \
--verifier-url 'https://testnet.blockscout-api.injective.network/api/' \
0x213bA803265386C10CE04a2cAa0f31FF3440b9cF \
src/Counter.sol:Counter
```
## Check the verification outcome
You should see output similar to this in the terminal:
```text theme={null}
Start verifying contract `0x213bA803265386C10CE04a2cAa0f31FF3440b9cF` deployed on 1439
Submitting verification for [src/Counter.sol:Counter] 0x213bA803265386C10CE04a2cAa0f31FF3440b9cF.
Submitted contract for verification:
Response: `OK`
GUID: `213ba803265386c10ce04a2caa0f31ff3440b9cf686b778c`
URL: https://testnet.blockscout-api.injective.network/address/0x213ba803265386c10ce04a2caa0f31ff3440b9cf
```
The more interesting outcome is visiting the network explorer.
Visit the network explorer URL from the verification output.
Then select the "Contract" tab.
Then select the "Code" sub-tab.
Previously, there was only "ByteCode" available,
and now "Code", "Compiler", and "ABI" are also available.
Still within the "Contract" tab,
select the "Read/Write contract" sub-tab.
Previously, this did not exist,
but now you can interact with every smart contract function directly from the block explorer.
## Next steps
Now that you have deployed and verified your smart contract, you are ready to interact with that smart contract!
Check out the [interact with a smart contract using Foundry](./interact-foundry/) tutorial next.
# Verify a smart contract using Hardhat
Source: https://docs.injective.network/developers-evm/smart-contracts/verify-hardhat
## Prerequisites
You should already have a Hardhat project set up, and have deployed your smart contract successfully.
See the [deploy a smart contract using Hardhat](./deploy-hardhat/) tutorial for how to do so.
## What is smart contract verification?
The process of verification does not have any effect on the smart contract itself, or any other state of the network.
Instead, it is a standardised process through which network explorers are provided with the original source code of the smart contract deployed at a particular address. The network explorer **independently compiles** that source code, and verifies that the resultant bytecode is indeed a **match** with the bytecode present from the smart contract's deployment transaction.
If verification passes (there is a match), the block explorer "unlocks" an enhanced mode within for that particular smart contract's page.
More smart contract details are now displayed, including:
* Full source code (Solidity)
* ABI (JSON)
* Transactions and events are shown with higher detail (parsed using ABI)
Additionally, if the user connects their wallet, they can invoke functions within the network explorer itself to query the smart contract, and even send transactions to update its state.
## Edit smart contract verification configuration
Open `hardhat.config.js`, and look at the `etherscan` and `sourcify` elements.
```js theme={null}
etherscan: {
apiKey: {
inj_testnet: 'nil',
},
customChains: [
{
network: 'inj_testnet',
chainId: 1439,
urls: {
apiURL: 'https://testnet.blockscout-api.injective.network/api',
browserURL: 'https://testnet.blockscout.injective.network/',
},
},
],
},
sourcify: {
enabled: false,
},
```
Sourcify and Etherscan are two popular block explorers, each with a different API for verification.
Injective uses Blockscout, which is compatible with the Etherscan API.
Hence, Sourcify is disabled in the configuration.
Within the Etherscan configuration, the `apiKey` value is not needed, so any non-empty value is OK.
The `inj_testnet` network within `customChains` is already configured with the appropriate values for Injective Testnet.
## Run the verification command
Enter the following command:
```shell theme={null}
npx hardhat verify --network inj_testnet ${SC_ADDRESS}
```
Replace `${SC_ADDRESS}` with the address at which you deployed your smart contract.
For example, if the smart contract address is `0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b`, the command is:
```shell theme={null}
npx hardhat verify --network inj_testnet 0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b
```
## Check the verification outcome
You should see output similar to this in the terminal:
```text theme={null}
Successfully submitted source code for contract
contracts/Counter.sol:Counter at 0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b
for verification on the block explorer. Waiting for verification result...
Successfully verified contract Counter on the block explorer.
https://testnet.blockscout.injective.network/address/0x98798cc92651B1876e9Cc91EcBcfe64cac720a1b#code
```
The more interesting outcome is visiting the network explorer.
Visit the network explorer URL from the verification output.
Then select the "Contract" tab.
Then select the "Code" sub-tab.
Previously, there was only "ByteCode" available, and now "Code", "Compiler", and "ABI" are also available.
Still within the "Contract" tab,
select the "Read/Write contract" sub-tab.
Previously, this did not exist,
but now you can interact with every smart contract function directly from the block explorer.
## Next steps
Now that you have deployed and verified your smart contract, you are ready to interact with that smart contract!
Check out the [interact with a smart contract using Hardhat](./interact-hardhat/) tutorial next.
# Wrapped INJ (wINJ)
Source: https://docs.injective.network/developers-evm/wrapped-inj
# Wrapped INJ (wINJ)
## What is a wrapped cryptocurrency?
On Injective, INJ is the cryptocurrency, which is what is used to pay transaction fees on the network.
However, some dApps (including DEXes), only accept ERC20 tokens in their interfaces, and thus INJ does **not** work with them.
The solution is to create an ERC20 token which wraps INJ, called "wrapped INJ".
Its token symbol is **wINJ**.
Thus any dApp that accepts ERC20 tokens accepts wINJ.
The mechanism with which the wINJ token works is straightforward:
* Mint: Increase the total supply whenever depositing INJ into it.
* Burn: Decrease the total supply whenever withdrawing INJ from it.
You may think of wINJ as an ERC20 token that is 1-to-1 collateralised with INJ, and therefore be treated as equal value but with a different technical interface.
## Is wINJ the same as wETH?
For those of you familiar with Ethereum,
you may be thinking that this sounds the same as wrapper Ether (wETH).
You are right, so far wINJ behaves in the same way as wETH.
However, note that the Injective network is designed with a MultiVM technical architecture.
This means that if wINJ were to be implemented using a *standard* ERC20 implementation,
as wETH does, wINJ would **not** be accessible when interacting with
the the non-EVM parts of the Injective network (e.g. Cosmos transactions).
This is precisely the type of limitation that Injective's
[MultiVM Token Standard (MTS)](/developers-evm/multivm-token-standard)
was designed for.
Specifically, note
[this line](https://github.com/InjectiveLabs/solidity-contracts/blob/b152129a/src/WINJ9.sol#L9C10-L9C15):
```solidity theme={null}
contract WINJ9 is BankERC20, IWINJ9 {
```
Instead of storing balances as `uint256` values within the smart contract,
as is typical of ERC20 implementations,
the wINJ smart contract uses the `Bank` precompile.
The magic happens in the
[`_update` function of `BankERC20`](https://github.com/InjectiveLabs/solidity-contracts/blob/b152129a/src/BankERC20.sol#L50-L81),
where `mint`, `burn`, or `transfer` functions in the `Bank` module are invoked,
via its [EVM precompile](/developers-evm/bank-precompile "EVM precompile for Injective's native Bank module").
As those balances are stored/ retrieved from the `Bank` precompile,
they are accessible from elsewhere within Injective's MultiVM architecture.
For example, using the Cosmos SDK you can query the wINJ balances,
even after updating them through EVM transactions;
and vice versa.
We refer to this as "native chain balances".
Check out a [full demo of wINJ](https://github.com/InjectiveLabs/solidity-contracts/tree/master/demos/winj9) in action.
## How to use wINJ programmatically
* Address on Injective Mainnet: `0x0000000088827d2d103ee2d9A6b781773AE03FfB`
* Address on Injective Testnet: `0x0000000088827d2d103ee2d9A6b781773AE03FfB`
To convert INJ to wINJ, invoke the `deposit` function on this smart contract:
* The function signature is: `deposit() public payable`
* Note that you do not need to specify the amount as a parameter,
instead set the `value` on the transactions, and `payable` will pick it up as `msg.value`.
To convert wINJ to INJ, invoke the `withdraw` function on this smart contract:
* The function signature is: `withdraw(uint256 wad) public`
* Set the amount of INJ you intend to received as the `wad` parameter.
All other functions, e.g. transfers, are the same as standard ERC20.
## How to use wINJ via the network explorer
* Explorer URL for Injective Mainnet: [`0x0000000088827d2d103ee2d9A6b781773AE03FfB`](https://blockscout.injective.network/address/0x0000000088827d2d103ee2d9A6b781773AE03FfB?tab=contract)
* Explorer URL for Injective Testnet: [`0x0000000088827d2d103ee2d9A6b781773AE03FfB`](https://testnet.blockscout.injective.network/address/0x0000000088827d2d103ee2d9A6b781773AE03FfB?tab=contract)
To convert INJ to wINJ, invoke the `deposit` function on this smart contract:
* Navigate to the "Contract" tab, then the "Read/Write contract" sub tab in the explorer page for the wINJ token.
* Find the `deposit()` function, and expand it by clicking on the `>` symbol
* Fill in the field "Send native INJ (uint256)" with the amount of INJ you wish to convert
* Note that this number is automatically multiplied by `10^18`, you do not need to perform that conversion manually
* Press the "Write" button
* In your wallet, confirm the transaction to sign and submit it.
* Your wallet should reflect an INJ decrease and a wINJ increase by the amount you selected.
* Note that the INJ decrease will be marginally more, because it is used to pay for transaction fees.
To convert wINJ to INJ, invoke the `withdraw` function on this smart contract:
* Navigate to the "Contract" tab, then the "Read/Write contract" sub tab in the explorer page for the wINJ token.
* Find the `withdraw()` function, and expand it by clicking on the `>` symbol
* Fill in the field "wad (uint256)" with the amount of wINJ you wish to convert
* Note that this number is automatically multiplied by `10^18`, you do not need to perform that conversion manually
* Press the "Write" button
* In your wallet, confirm the transaction to sign and submit it.
* Your wallet should reflect an INJ increase and a wINJ decrease by the amount you selected.
* Note that the INJ increase will be marginally less, because it is used to pay for transaction fees.
# How to use wINJ via Injective Do
* Visit [Injective Do](https://do.injective.network/)
* Press the "Connect" button in the top right corner
* Select your wallet
* In your wallet select "Allow" to allow it to connect ot the Injective Do dApp.
* You should now see your wallet address apear in the top right corner (where the "Connect" button was previously)
* In the nav bar at the top, select "EVM"
* In the drop-down menu select "Wrap/Unwrap"
* To convert INJ to wINJ
* Press the "Wrap" tab at the top
* In the "Amount" field, type your desired amount for conversion
* Press the "Wrap" button at the bottom
* When the transaction has completed, check your INJ and wINJ balances in your wallet
* To convert wINJ to INJ
* Press the "Unwrap" tab at the top
* In the "Amount" field, type your desired amount for conversion
* Press the "Unwrap" button at the bottom
* When the transaction has completed, check your INJ and wINJ balances in your wallet
# Ethereum Bridge
Source: https://docs.injective.network/developers-native/bridges/ethereum
The Injective Ethereum bridge enables the Injective Chain to support a trustless, on-chain bidirectional token bridge. In this system, holders of ERC-20 tokens on Ethereum can instantaneously convert their ERC-20 tokens to Cosmos-native coins on the Injective Chain and vice-versa.
The Injective Peggy bridge consists of three main components:
1. Peggy Contract on Ethereum
2. Peggo Orchestrator
3. Peggy Module on the Injective Chain
## Peggy Contract
The function of the Peggy contract is to facilitate efficient, bidirectional cross-chain transfers of ERC-20 tokens from Ethereum to the Injective Chain. Unlike other token bridge setups, the Injective Peggy bridge is a decentralized, non-custodial bridge operated solely by the validators on Injective. The bridge is secured by the proof of stake security of the Injective Chain, as deposits and withdrawals are processed in accordance with attestations made by at least two-thirds of the validators based on consensus staking power.
## Peggo Orchestrator
The orchestrator is an off-chain relayer that every Injective Chain validator operates which serves the function of transmitting ERC-20 token transfer data from Ethereum to the Injective Chain.
## Peggy Module
On a basic level, the Peggy module mints new tokens on the Injective Chain upon an ERC-20 deposit from Ethereum and burns tokens upon withdrawing a token from the Injective Chain back to Ethereum. The Peggy module also manages the economic incentives to ensure that validators act honestly and efficiently, through a variety of mechanisms including slashing penalties, native token rewards, and withdrawal fees.
## From Ethereum to Injective
To transfer from Ethereum to Injective you have to make a Web3 Transaction and interact with the Peggy contract on Ethereum. There are two steps required to make a transfer:
1. As we are basically locking our ERC20 assets on the Peggy Contract which lives on Ethereum, we need to set an allowance for the assets we are transferring to the Peggy Contract. You can use any web3 provider (such as ethers.js or web3.js) to call the ERC-20 `approve` function with the Peggy contract address as the spender.
2. After the allowance is set, we need to call the `sendToInjective` function on the Peggy Contract with the desired amount and asset that we want to transfer to the Injective Chain, You can use the `PeggyContract` class from `@injectivelabs/contracts` (see example below) or interact with the contract directly using the ABI. Once the transaction is confirmed, it’ll take a couple of minutes for the assets to show on the Injective Chain.
Couple of notes about the examples above:
* The destination address (if you want to build the transaction yourself) is in the following format
```ts theme={null}
"0x000000000000000000000000{ETHEREUM_ADDRESS_HERE_WITHOUT_0X_PREFIX}";
// example
"0x000000000000000000000000e28b3b32b6c345a34ff64674606124dd5aceca30";
```
where the Ethereum address is the corresponding Ethereum address of the destination Injective address.
* `walletStrategy` `walletStrategy` is an abstraction that we’ve built which supports a lot of wallets which can be used to sign and broadcast transactions (both on Ethereum and on the Injective Chain), more details can be found in the documentation of the npm package [@injectivelabs/wallet-strategy](https://github.com/InjectiveLabs/injective-ts/tree/master/packages/wallets/wallet-strategy) and [@injectivelabs/wallet-core](https://github.com/InjectiveLabs/injective-ts/tree/master/packages/wallets/wallet-core). Obviously, this is just an example and you can use the web3 package directly, or any web3 provider to handle the transaction.
```ts theme={null}
import { PeggyContract } from "@injectivelabs/contracts";
const contract = new PeggyContract({
ethereumChainId,
address: peggyContractAddress,
web3: web3 as any,
});
```
* The snippet below instantiates a PeggyContract instance which can easily `estimateGas` and `sendTransaction` using the `web3` we provide to the contract’s constructor. Its implementation can be found [here](https://github.com/InjectiveLabs/injective-ts/blob/master/packages/contracts/src/contracts/Peggy.ts). Obviously, this is just an example and you can use the web3 package directly + the ABI of the contract to instantiate the contract, and then handle the logic of signing and broadcasting the transaction using some web3 provider.
## From Injective to Ethereum
Now that you have the ERC20 version of INJ transferred over to Injective, the native `inj` denom on the Injective Chain is minted and it is the canonical version of the INJ token. To withdraw `inj` from Injective to Ethereum we have to prepare, sign and then broadcast a native Cosmos transaction on the Injective Chain.
If you are not familiar with how Transactions (and Messages) work on Cosmos you can find more information here. The Message we need to pack into a transaction to instruct Injective to withdraw funds from Injective to Ethereum is `MsgSendToEth`.
When `MsgSendToEth` is called on the chain, some of the validators will pick up the transaction, batch multiple `MsgSendToEth` requests into one and: burn the assets being withdrawn on Injective, unlock these funds on the Peggy Smart Contract on Ethereum and send them to the respective address.
There is a bridgeFee included in these transactions to incentivize Validators to pick up and process your withdrawal requests faster. The bridgeFee is in the asset the user wants to withdraw to Ethereum (if you withdraw INJ you have to pay the bridgeFee in INJ as well).
Here is an example implementation that prepares the transaction, uses a privateKey to sign it and finally, broadcasts it to Injective:
```ts theme={null}
import { getNetworkInfo, Network } from "@injectivelabs/networks";
import {
TxClient,
TxRestApi,
createTransaction,
} from "@injectivelabs/sdk-ts/core/tx";
import {
PrivateKey,
} from "@injectivelabs/sdk-ts/core/accounts";
import {
MsgSendToEth,
} from "@injectivelabs/sdk-ts/core/modules";
import {
ChainRestAuthApi,
} from "@injectivelabs/sdk-ts/client/chain";
import { toChainFormat, getDefaultStdFee } from "@injectivelabs/utils";
/** MsgSendToEth Example */
(async () => {
const network = getNetworkInfo(Network.Mainnet); // Gets the rpc/lcd endpoints
const privateKeyHash =
"f9db9bf330e23cb7839039e944adef6e9df447b90b503d5b4464c90bea9022f3";
const privateKey = PrivateKey.fromPrivateKey(privateKeyHash);
const injectiveAddress = privateKey.toBech32();
const ethAddress = privateKey.toHex();
const publicKey = privateKey.toPublicKey().toBase64();
/** Account Details **/
const accountDetails = await new ChainRestAuthApi(network.rest).fetchAccount(
injectiveAddress
);
/** Prepare the Message */
const amount = {
amount: toChainFormat(0.01).toFixed(),
denom: "inj",
};
const bridgeFee = {
amount: toChainFormat(0.01).toFixed(),
denom: "inj",
};
const msg = MsgSendToEth.fromJSON({
amount,
bridgeFee,
injectiveAddress,
address: ethAddress,
});
/** Prepare the Transaction **/
const { signBytes, txRaw } = createTransaction({
message: msg,
pubKey: publicKey,
fee: getDefaultStdFee(),
sequence: parseInt(accountDetails.account.base_account.sequence, 10),
accountNumber: parseInt(
accountDetails.account.base_account.account_number,
10
),
chainId: network.chainId,
});
/** Sign transaction */
const signature = await privateKey.sign(Buffer.from(signBytes));
/** Append Signatures */
txRaw.signatures = [signature];
/** Calculate hash of the transaction */
console.log(`Transaction Hash: ${TxClient.hash(txRaw)}`);
const txService = new TxRestApi(network.rest);
/** Simulate transaction */
const simulationResponse = await txService.simulate(txRaw);
console.log(
`Transaction simulation response: ${JSON.stringify(
simulationResponse.gasInfo
)}`
);
/** Broadcast transaction */
const txResponse = await txService.broadcast(txRaw);
if (txResponse.code !== 0) {
console.log(`Transaction failed: ${txResponse.rawLog}`);
} else {
console.log(
`Broadcasted transaction hash: ${JSON.stringify(txResponse.txhash)}`
);
}
})();
```
# Bridges
Source: https://docs.injective.network/developers-native/bridges/index
This section covers bridging assets to and from Injective.
* [Ethereum Bridge](/developers-native/bridges/ethereum/) - Bridge assets between Ethereum and Injective using Peggy
# Overview
Source: https://docs.injective.network/developers-native/index
## What are Modules?
Modules are foundational components in Injective’s blockchain architecture, each built to provide specific functionalities. A module is essentially a self-contained unit with well-defined logic and services, allowing Injective to efficiently manage diverse operations across the network.
Modules work like building blocks that can be combined to expand the blockchain’s capabilities. This approach reduces the friction and technical complexity of implementing core features, making development easier. Each module operates independently but communicates with others through inter-module messaging, making Injective’s architecture modular and adaptable. This allows Injective to continuously evolve, delivering targeted upgrades and functionality without overhauling the entire system.
## Explore Modules
`injective` module
`core` module
# Cosmos Transactions
Source: https://docs.injective.network/developers-native/transactions/cosmos
Every transaction on Injective follows the same flow. The flow consists of three steps: preparing, signing and broadcasting the transaction. Let's dive into each step separately and explain the process in-depth (including examples) so we can understand the whole transaction flow.
## Preparing a transaction
First of, we need to prepare the transaction for signing.
At this point you **can't** use some online abstractions that provide a quick way to prepare the transaction for you based on the provided Message and the signer (ex. using the `@cosmjs/stargate` package). The reason why is that these packages don't support Injective's publicKey typeUrl, so we have to do the preparation of the address on the client side.
To resolve this, we have provided functions which can prepare the `txRaw` transaction within out `@injectivelabs/sdk-ts` package. `txRaw` is the transaction interface used in Cosmos that contains details about the transaction and the signer itself.
Getting a private key from cosmos wallets is usually done by taking the current key for the chainId and accessing the pubKey from there (ex: `const key = await window.keplr.getKey(chainId)` => `const pubKey = key.publicKey`).
```ts theme={null}
import {
MsgSend,
} from "@injectivelabs/sdk-ts/core/modules";
import {
BaseAccount,
} from "@injectivelabs/sdk-ts/core/accounts";
import {
createTransaction,
} from "@injectivelabs/sdk-ts/core/tx";
import { toBigNumber, toChainFormat } from "@injectivelabs/utils";
import {
ChainRestAuthApi,
ChainRestTendermintApi,
} from "@injectivelabs/sdk-ts/client/chain";
import { getStdFee, DEFAULT_BLOCK_TIMEOUT_HEIGHT } from "@injectivelabs/utils";
(async () => {
const injectiveAddress = "inj1";
const chainId = "injective-1"; /* ChainId.Mainnet */
const restEndpoint =
"https://sentry.lcd.injective.network"; /* getNetworkEndpoints(Network.MainnetSentry).rest */
const amount = {
denom: "inj",
amount: toChainFormat(0.01).toFixed(),
};
/** Account Details **/
const chainRestAuthApi = new ChainRestAuthApi(restEndpoint);
const accountDetailsResponse = await chainRestAuthApi.fetchAccount(
injectiveAddress
);
const baseAccount = BaseAccount.fromRestApi(accountDetailsResponse);
/** Block Details */
const chainRestTendermintApi = new ChainRestTendermintApi(restEndpoint);
const latestBlock = await chainRestTendermintApi.fetchLatestBlock();
const latestHeight = latestBlock.header.height;
const timeoutHeight = toBigNumber(latestHeight).plus(
DEFAULT_BLOCK_TIMEOUT_HEIGHT
);
/** Preparing the transaction */
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
/** Get the PubKey of the Signer from the Wallet/Private Key */
const pubKey = await getPubKey();
/** Prepare the Transaction **/
const { txRaw, signDoc } = createTransaction({
pubKey,
chainId,
fee: getStdFee({}),
message: msg,
sequence: baseAccount.sequence,
timeoutHeight: timeoutHeight.toNumber(),
accountNumber: baseAccount.accountNumber,
});
})();
```
## Signing a transaction
Once we have prepared the transaction, we proceed to signing. Once you get the `txRaw` transaction from the previous step use any Cosmos native wallet to sign (ex: Keplr),
```ts theme={null}
import { ChainId } from '@injectivelabs/ts-types'
import { SignDoc } from '@keplr-wallet/types'
const getKeplr = async (chainId: string) => {
await window.keplr.enable(chainId);
const offlineSigner = window.keplr.getOfflineSigner(chainId);
const accounts = await offlineSigner.getAccounts();
const key = await window.keplr.getKey(chainId);
return { offlineSigner, accounts, key }
}
const { offlineSigner } = await getKeplr(ChainId.Mainnet)
/* Sign the Transaction */
const address = 'inj1...'
const signDoc = /* From the previous step */
const directSignResponse = await offlineSigner.signDirect(address, signDoc as SignDoc)
```
You can also use our `@injectivelabs/wallet-strategy` package to get out-of-the-box wallet provides that will give you abstracted methods that you can use to sign transactions. Refer to the documentation of the package, its straightforward to setup and use. **This is the recommended way as you have access to more than one wallet to use in your dApp. The `WalletStrategy` provides more than just signing transaction abstractions.**
## Broadcasting a transaction
Once we have the signature ready, we need to broadcast the transaction to the Injective chain itself. After getting the signature from the second step, we need to include it in the signed transaction and broadcast it to the chain.
```ts theme={null}
import { ChainId } from '@injectivelabs/ts-types'
import {
TxRestApi,
CosmosTxV1Beta1Tx,
BroadcastModeKeplr,
getTxRawFromTxRawOrDirectSignResponse,
TxRaw,
} from '@injectivelabs/sdk-ts/core/tx'
import { TransactionException } from '@injectivelabs/exceptions'
/**
* IMPORTANT NOTE:
* If we use Keplr/Leap wallets
* after signing the transaction we get a `directSignResponse`,
* and instead of adding the signature to the `txRaw` we create
* using the `createTransaction` function we need to append the
* signature from the `directSignResponse` to the transaction that
* got actually signed (i.e `directSignResponse.signed`) and
* the reason why is that the user can make some changes on the original
* transaction (i.e change gas limit or gas prices) and the transaction
* that get's signed and the one that gets broadcasted are not the same.
*/
const directSignResponse = /* From the second step above */;
const txRaw = getTxRawFromTxRawOrDirectSignResponse(directSignResponse)
const broadcastTx = async (chainId: String, txRaw: TxRaw) => {
const getKeplr = async (chainId: string) => {
await window.keplr.enable(chainId);
return window.keplr
}
const keplr = await getKeplr(ChainId.Mainnet)
const result = await keplr.sendTx(
chainId,
CosmosTxV1Beta1Tx.TxRaw.encode(txRaw).finish(),
BroadcastModeKeplr.Sync,
)
if (!result || result.length === 0) {
throw new TransactionException(
new Error('Transaction failed to be broadcasted'),
{ contextModule: 'Keplr' },
)
}
return Buffer.from(result).toString('hex')
}
const txHash = await broadcastTx(ChainId.Mainnet, txRaw)
/**
* Once we get the txHash, because we use the Sync mode we
* are not sure that the transaction is included in the block,
* it can happen that it's still in the mempool so we need to query
* the chain to see when the transaction will be included
*/
const restEndpoint = 'https://sentry.lcd.injective.network' /* getNetworkEndpoints(Network.MainnetSentry).rest */
const txRestApi = new TxRestApi(restEndpoint)
/** This will poll querying the transaction and await for it's inclusion in the block */
const response = await txRestApi.fetchTxPoll(txHash)
```
## Example (Prepare + Sign + Broadcast)
Let's have a look at the whole flow (using Keplr as a signing wallet)
```ts theme={null}
import {
MsgSend,
} from "@injectivelabs/sdk-ts/core/modules";
import {
BaseAccount,
} from "@injectivelabs/sdk-ts/core/accounts";
import { ChainId } from "@injectivelabs/ts-types";
import { SignDoc } from "@keplr-wallet/types";
import { toBigNumber, toChainFormat } from "@injectivelabs/utils";
import { TransactionException } from "@injectivelabs/exceptions";
import {
ChainRestAuthApi,
ChainRestTendermintApi,
} from "@injectivelabs/sdk-ts/client/chain";
import { getStdFee, DEFAULT_BLOCK_TIMEOUT_HEIGHT } from "@injectivelabs/utils";
import {
TxRaw,
TxRestApi,
createTransaction,
CosmosTxV1Beta1Tx,
BroadcastModeKeplr,
getTxRawFromTxRawOrDirectSignResponse,
} from "@injectivelabs/sdk-ts/core/tx";
const getKeplr = async (chainId: string) => {
await window.keplr.enable(chainId);
const offlineSigner = window.keplr.getOfflineSigner(chainId);
const accounts = await offlineSigner.getAccounts();
const key = await window.keplr.getKey(chainId);
return { offlineSigner, accounts, key };
};
const broadcastTx = async (chainId: string, txRaw: TxRaw) => {
const keplr = await getKeplr(ChainId.Mainnet);
const result = await keplr.sendTx(
chainId,
CosmosTxV1Beta1Tx.TxRaw.encode(txRaw).finish(),
BroadcastModeKeplr.Sync
);
if (!result || result.length === 0) {
throw new TransactionException(
new Error("Transaction failed to be broadcasted"),
{ contextModule: "Keplr" }
);
}
return Buffer.from(result).toString("hex");
};
(async () => {
const chainId = "injective-1"; /* ChainId.Mainnet */
const { key, offlineSigner } = await getKeplr(chainId);
const pubKey = Buffer.from(key.pubKey).toString("base64");
const injectiveAddress = key.bech32Address;
const restEndpoint =
"https://sentry.lcd.injective.network"; /* getNetworkEndpoints(Network.MainnetSentry).rest */
const amount = {
denom: "inj",
amount: toChainFormat(0.01).toFixed(),
};
/** Account Details **/
const chainRestAuthApi = new ChainRestAuthApi(restEndpoint);
const accountDetailsResponse = await chainRestAuthApi.fetchAccount(
injectiveAddress
);
const baseAccount = BaseAccount.fromRestApi(accountDetailsResponse);
/** Block Details */
const chainRestTendermintApi = new ChainRestTendermintApi(restEndpoint);
const latestBlock = await chainRestTendermintApi.fetchLatestBlock();
const latestHeight = latestBlock.header.height;
const timeoutHeight = toBigNumber(latestHeight).plus(
DEFAULT_BLOCK_TIMEOUT_HEIGHT
);
/** Preparing the transaction */
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
/** Prepare the Transaction **/
const { signDoc } = createTransaction({
pubKey,
chainId,
fee: getStdFee({}),
message: msg,
sequence: baseAccount.sequence,
timeoutHeight: timeoutHeight.toNumber(),
accountNumber: baseAccount.accountNumber,
});
const directSignResponse = await offlineSigner.signDirect(
injectiveAddress,
signDoc as SignDoc
);
const txRaw = getTxRawFromTxRawOrDirectSignResponse(directSignResponse);
const txHash = await broadcastTx(ChainId.Mainnet, txRaw);
const response = await new TxRestApi(restEndpoint).fetchTxPoll(txHash);
console.log(response);
})();
```
## Example with WalletStrategy (Prepare + Sign + Broadcast)
Example can be found in the [wallet-core package](https://github.com/InjectiveLabs/injective-ts/tree/master/packages/wallets/wallet-core).
# Ledger through Keplr Wallet Transaction
Source: https://docs.injective.network/developers-native/transactions/cosmos-ledger-keplr
On this page, we are going to have a look at the implementation for Injective when your users are using a Ledger device through the Keplr wallet.
As explained before, Injective uses a different derivation curve from the rest of the Cosmos chains which means that the users have to use the Ethereum app (for now) to interact with Injective.
The easiest way all of the edge cases covered and a full out-of-the-box solution for all of the supported wallets on Injective I suggest you have a look at the [MsgBroadcaster + WalletStrategy ](./msgbroadcaster/#msgbroadcaster-+-wallet-strategy)abstraction. If you want to do your own implementation, let's go through the code example together.
## Overview
Keplr exposes a `experimentalSignEIP712CosmosTx_v0` method which can be utilized to sign EIP712 typed data (automatically generated on the Keplr side by passing a Cosmos StdSignDoc to the method above) and allow EVM-compatible chains to get proper signatures when we have Ledger devices connected through Keplr.
Here is the function's signature:
```typescript theme={null}
/**
* Sign the sign doc with ethermint's EIP-712 format.
* The difference from signEthereum(..., EthSignType.EIP712) is that this api returns a new sign doc changed by the user's fee setting and the signature for that sign doc.
* Encoding tx to EIP-712 format should be done on the side using this api.
* Not compatible with cosmjs.
* The returned signature is (r | s | v) format which used in ethereum.
* v should be 27 or 28 which is used in the ethereum mainnet regardless of chain.
* @param chainId
* @param signer
* @param eip712
* @param signDoc
* @param signOptions
*/
experimentalSignEIP712CosmosTx_v0(chainId: string, signer: string, eip712: {
types: Record;
domain: Record;
primaryType: string;
}, signDoc: StdSignDoc, signOptions?: KeplrSignOptions): Promise;
```
What we need to do now is generate the `eip712` and the `signDoc`, pass them to this function and Keplr will ask the user to sign the transaction using the Ethereum app on their Ledger device.
## Example Implementation
Based on the overview above, let's now showcase a full example of how to implement signing transactions on Injective using Ledger + Keplr. Keep in mind that the example below takes into consideration that you are using the [Msgs](https://github.com/InjectiveLabs/injective-ts/blob/master/packages/sdk-ts/src/core/modules/msgs.ts#L60) interface exported from the `@injectivelabs/sdk-ts` package.
```typescript theme={null}
import {
TxGrpcApi,
SIGN_AMINO,
createTransaction,
createTxRawEIP712,
getEip712TypedData
createWeb3Extension,
getGasPriceBasedOnMessage,
} from '@injectivelabs/sdk-ts/core/tx'
import {
BaseAccount,
} from '@injectivelabs/sdk-ts/core/accounts'
import {
ChainRestAuthApi,
ChainRestTendermintApi,
} from '@injectivelabs/sdk-ts/client/chain'
import { EvmChainId, ChainId } from '@injectivelabs/ts-types'
import { getNetworkEndpoints, NetworkEndpoints, Network } from '@injectivelabs/networks'
import { GeneralException, TransactionException } from '@injectivelabs/exceptions'
import { toBigNumber, getStdFee } from '@injectivelabs/utils'
export interface Options {
evmChainId: EvmChainId /* Evm chain id */
chainId: ChainId; /* Injective chain id */
endpoints: NetworkEndpoints /* can be fetched from @injectivelabs/networks based on the Network */
}
export interface Transaction {
memo?: string
injectiveAddress?: string
msgs: Msgs | Msgs[]
// In case we manually want to set gas options
gas?: {
gasPrice?: string
gas?: number /** gas limit */
feePayer?: string
granter?: string
}
}
/** Converting EIP712 tx details to Cosmos Std Sign Doc */
export const createEip712StdSignDoc = ({
memo,
chainId,
accountNumber,
timeoutHeight,
sequence,
gas,
msgs,
}: {
memo?: string
chainId: ChainId
timeoutHeight?: string
accountNumber: number
sequence: number
gas?: string
msgs: Msgs[]
}) => ({
chain_id: chainId,
timeout_height: timeoutHeight || '',
account_number: accountNumber.toString(),
sequence: sequence.toString(),
fee: getStdFee({ gas }),
msgs: msgs.map((m) => m.toEip712()),
memo: memo || '',
})
/**
* We use this method only when we want to broadcast a transaction using Ledger on Keplr for Injective
*
* Note: Gas estimation not available
* @param tx the transaction that needs to be broadcasted
*/
export const experimentalBroadcastKeplrWithLedger = async (
tx: Transaction,
options: Options
) => {
const { endpoints, chainId, evmChainId } = options
const msgs = Array.isArray(tx.msgs) ? tx.msgs : [tx.msgs]
const DEFAULT_BLOCK_TIMEOUT_HEIGHT = 60
/**
* You choose to perform a check if
* the user is indeed connected with Ledger + Keplr
*/
if (/* your condition here */) {
throw new GeneralException(
new Error(
'This method can only be used when Keplr is connected with Ledger',
),
)
}
/** Account Details * */
const chainRestAuthApi = new ChainRestAuthApi(endpoints.rest)
const accountDetailsResponse = await chainRestAuthApi.fetchAccount(
tx.injectiveAddress,
)
const baseAccount = BaseAccount.fromRestApi(accountDetailsResponse)
const accountDetails = baseAccount.toAccountDetails()
/** Block Details */
const chainRestTendermintApi = new ChainRestTendermintApi(endpoints.rest)
const latestBlock = await chainRestTendermintApi.fetchLatestBlock()
const latestHeight = latestBlock.header.height
const timeoutHeight = toBigNumber(latestHeight).plus(
DEFAULT_BLOCK_TIMEOUT_HEIGHT,
)
const key = await window.keplr.getKey(chainId)
const pubKey = Buffer.from(key.pubKey).toString('base64')
const gas = (tx.gas?.gas || getGasPriceBasedOnMessage(msgs)).toString()
/** EIP712 for signing on Ethereum wallets */
const eip712TypedData = getEip712TypedData({
msgs,
fee: getStdFee({ ...tx.gas, gas }),
tx: {
memo: tx.memo,
accountNumber: accountDetails.accountNumber.toString(),
sequence: accountDetails.sequence.toString(),
timeoutHeight: timeoutHeight.toFixed(),
chainId,
},
evmChainId,
})
const aminoSignResponse = await window.keplr.experimentalSignEIP712CosmosTx_v0(
chainId,
tx.injectiveAddress,
eip712TypedData,
createEip712StdSignDoc({
...tx,
...baseAccount,
msgs,
chainId,
gas: gas || tx.gas?.gas?.toString(),
timeoutHeight: timeoutHeight.toFixed(),
})
)
/**
* Create TxRaw from the signed tx that we
* get as a response in case the user changed the fee/memo
* on the Keplr popup
*/
const { txRaw } = createTransaction({
pubKey,
message: msgs,
memo: aminoSignResponse.signed.memo,
signMode: SIGN_AMINO,
fee: aminoSignResponse.signed.fee,
sequence: parseInt(aminoSignResponse.signed.sequence, 10),
timeoutHeight: parseInt(
(aminoSignResponse.signed as any).timeout_height,
10,
),
accountNumber: parseInt(aminoSignResponse.signed.account_number, 10),
chainId,
})
/** Preparing the transaction for client broadcasting */
const web3Extension = createWeb3Extension({
evmChainId,
})
const txRawEip712 = createTxRawEIP712(txRaw, web3Extension)
/** Append Signatures */
const signatureBuff = Buffer.from(
aminoSignResponse.signature.signature,
'base64',
)
txRawEip712.signatures = [signatureBuff]
/** Broadcast the transaction */
const response = await new TxGrpcApi(endpoints.grpc).broadcast(txRawEip712)
if (response.code !== 0) {
throw new TransactionException(new Error(response.rawLog), {
code: UnspecifiedErrorCode,
contextCode: response.code,
contextModule: response.codespace,
})
}
return response
}
```
# Transactions
Source: https://docs.injective.network/developers-native/transactions/index
This section covers how to create, sign, and broadcast transactions on Injective.
* [Cosmos Transactions](/developers-native/transactions/cosmos/) - Sign transactions using Cosmos wallets
* [Cosmos Ledger + Keplr](/developers-native/transactions/cosmos-ledger-keplr/) - Sign transactions using Ledger with Keplr
* [Ethereum Transactions](/developers-native/transactions/ethereum/) - Sign transactions using Ethereum wallets
* [Ethereum Ledger](/developers-native/transactions/ethereum-ledger/) - Sign transactions using Ledger with Ethereum wallets
* [MsgBroadcaster](/developers-native/transactions/msgbroadcaster/) - Use the MsgBroadcaster utility class
* [Private Key](/developers-native/transactions/private-key/) - Sign transactions using a private key
* [Web3 Gateway](/developers-native/transactions/web3-gateway/) - Use the Web3 Gateway for transaction broadcasting
# Accounts
Source: https://docs.injective.network/developers-native/wallets/accounts
Injective defines its own custom Account type that uses Ethereum's ECDSA secp256k1 curve for keys. This satisfies the [EIP84](https://github.com/ethereum/EIPs/issues/84) for full [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) paths. The root HD path for Injective-based accounts is `m/44'/60'/0'/0.`
### Address conversion
You can easily convert between an Injective address and Ethereum address by using our utility functions in the `@injectivelabs/sdk-ts` package:
```ts theme={null}
import {
getInjectiveAddress,
getEthereumAddress,
} from "@injectivelabs/sdk-ts/utils";
const injectiveAddress = "inj1...";
const ethereumAddress = "0x..";
console.log(
"Injective address from Ethereum address => ",
getInjectiveAddress(ethereumAddress)
);
console.log(
"Ethereum address from Injective address => ",
getEthereumAddress(injectiveAddress)
);
```
### Deriving wallets
**Using Injective utility classes**
* Example code snippet on how to derive Injective Account from a private key and/or a mnemonic phrase:
```ts theme={null}
import { PrivateKey } from "@injectivelabs/sdk-ts/core/accounts";
const mnemonic =
"indoor dish desk flag debris potato excuse depart ticket judge file exit";
const privateKey =
"afdfd9c3d2095ef696594f6cedcae59e72dcd697e2a7521b1578140422a4f890";
const privateKeyFromMnemonic = PrivateKey.fromMnemonic(mnemonic);
const privateKeyFromHex = PrivateKey.fromPrivateKey(privateKey);
const address =
privateKeyFromMnemonic.toAddress(); /* or privateKeyFromHex.toAddress() */
console.log({
injectiveAddress: address.toBech32(),
ethereumAddress: address.toHex(),
});
```
* Example code snippet on how to derive a public address from a public key:
```ts theme={null}
import { PublicKey } from "@injectivelabs/sdk-ts/core/accounts";
const pubKey = "AuY3ASbyRHfgKNkg7rumWCXzSGCvvgtpR6KKWlpuuQ9Y";
const publicKey = PublicKey.fromBase64(pubKey);
console.log(publicKey.toAddress().toBech32());
```
* Example code snippet on how to derive an address from a private key:
```ts theme={null}
import { PublicKey } from "@injectivelabs/sdk-ts/core/accounts";
const privateKey =
"afdfd9c3d2095ef696594f6cedcae59e72dcd697e2a7521b1578140422a4f890";
const publicKey = PublicKey.fromPrivateKeyHex(privateKey);
const type = "/injective.crypto.v1beta1.ethsecp256k1.PubKey";
console.log(publicKey.toBase64());
```
**Without using Injective utility classes**
* Example code snippet on how to derive Injective Account from a private key and/or a mnemonic phrase:
```ts theme={null}
import { Wallet } from "ethers";
import { Address as EthereumUtilsAddress } from "ethereumjs-util";
const mnemonic =
"indoor dish desk flag debris potato excuse depart ticket judge file exit";
const privateKey =
"afdfd9c3d2095ef696594f6cedcae59e72dcd697e2a7521b1578140422a4f890";
const defaultDerivationPath = "m/44'/60'/0'/0/0";
const defaultBech32Prefix = "inj";
const isPrivateKey: boolean = true; /* just for the example */
const wallet = isPrivateKey
? Wallet.fromMnemonic(mnemonic, defaultDerivationPath)
: new Wallet(privateKey);
const ethereumAddress = wallet.address;
const addressBuffer = EthereumUtilsAddress.fromString(
ethereumAddress.toString()
).toBuffer();
const injectiveAddress = bech32.encode(
defaultBech32Prefix,
bech32.toWords(addressBuffer)
);
```
* Example code snippet on how to derive a public key from a private key:
```ts theme={null}
import secp256k1 from "secp256k1";
const privateKey =
"afdfd9c3d2095ef696594f6cedcae59e72dcd697e2a7521b1578140422a4f890";
const privateKeyHex = Buffer.from(privateKey.toString(), "hex");
const publicKeyByte = secp256k1.publicKeyCreate(privateKeyHex);
const buf1 = Buffer.from([10]);
const buf2 = Buffer.from([publicKeyByte.length]);
const buf3 = Buffer.from(publicKeyByte);
const publicKey = Buffer.concat([buf1, buf2, buf3]).toString("base64");
const type = "/injective.crypto.v1beta1.ethsecp256k1.PubKey";
```
#### Convert Cosmos address to Injective Address
As Injective has a different derivation path than the default Cosmos one, you need the `publicKey` of the account to convert a Cosmos `publicAddress` to Injective one.
Here is an example of how to do it
```typescript theme={null}
import { config } from "dotenv";
import { PublicKey } from "@injectivelabs/sdk-ts/core/accounts";
import { ChainRestAuthApi } from "@injectivelabs/sdk-ts/client/chain";
config();
(async () => {
const chainApi = new ChainRestAuthApi(
"https://rest.cosmos.directory/cosmoshub"
);
const cosmosAddress = "cosmos1..";
const account = await chainApi.fetchCosmosAccount(cosmosAddress);
if (!account.pub_key?.key) {
console.log("No public key found");
return;
}
console.log(
"injectiveAddress",
PublicKey.fromBase64(account.pub_key.key || "")
.toAddress()
.toBech32()
);
})();
```
# Wallet Connections
Source: https://docs.injective.network/developers-native/wallets/connections
Injective supports both Ethereum and Cosmos native wallets. You can use popular wallets like Metamask, Ledger, Keplr, Leap, etc. to sign transactions on Injective.
### Wallet Strategy
The recommended way to have support for all of these wallets out of the box is to use the [WalletStrategy](./strategy/) abstraction we've built. This approach will enable your dApp users to connect and interact with different wallets.
Combining it with the [MsgBroadcaster](../transactions/msgbroadcaster/) abstraction allows you to sign transactions using one function call. This is what's being used on all products like Helix, Hub, Explorer, etc., and we strongly recommend using this approach in your dApp.
In case you still want to use some wallet natively (without the WalletStrategy class), we are going to provide examples of how to connect to a dApp built on Injective via Metamask and Keplr in this doc.
### Metamask
Metamask is an Ethereum native wallet and can be used to connect and interact with your dApp built on Injective.
* **Get Injective addresses from Metamask**
```ts lines highlight={4-6,11-13} theme={null}
import { getInjectiveAddress } from "@injectivelabs/sdk-ts/utils";
const getEthereum = () => {
if (!window.ethereum) {
throw new Error("Metamask extension not installed");
}
return window.ethereum;
};
const ethereum = getEthereum();
const addresses = await ethereum.request({
method: "eth_requestAccounts",
}); /** these are evm addresses */
const injectiveAddresses = addresses.map(getInjectiveAddress);
console.log(injectiveAddresses);
```
* **Sign transactions using Metamask**
An example of how to prepare + sign + broadcast a transaction on Injective using Metamask can be found [here](../transactions/ethereum/).
### Keplr
Keplr is a Cosmos native wallet and can be used to connect and interact with your dApp built on Injective.
* **Get Injective addresses from Keplr**
```ts lines theme={null}
import { ChainId } from "@injectivelabs/ts-types";
const getKeplr = () => {
if (!window.keplr) {
throw new Error("Keplr extension not installed");
}
return window.keplr;
};
(async () => {
const keplr = getKeplr();
const chainId = ChainId.Mainnet;
await keplr.enable(chainId);
const injectiveAddresses = await keplr
.getOfflineSigner(chainId)
.getAccounts();
console.log(injectiveAddresses);
})();
```
* **Sign transactions using Keplr**
An example of how to prepare + sign + broadcast a transaction on Injective using Keplr can be found in [Cosmos Transactions](../transactions/cosmos/).
# Wallets
Source: https://docs.injective.network/developers-native/wallets/index
This section covers wallet integration and management for Injective.
* [Accounts](/developers-native/wallets/accounts/) - Learn about Injective accounts and address derivation
* [Connections](/developers-native/wallets/connections/) - Connect to different wallet providers
* [Strategy](/developers-native/wallets/strategy/) - Wallet strategy patterns for dApps
* [Offchain Data](/developers-native/wallets/offchain-data/) - Working with offchain data signing
# Offchain (Arbitrary) Data
Source: https://docs.injective.network/developers-native/wallets/offchain-data
On this page, we'll provide an example of how to sign and verify arbitrary data as per the [ADR-036](https://docs.cosmos.network/main/build/architecture/adr-036-arbitrary-signature) specification on Cosmos.
You can use the `generateArbitrarySignDoc` function from `@injectivelabs/sdk-ts` to generate ADR-36 compatible `signDoc`. You can then use it to sign/verify using a browser wallet or in a CLI environment. Make sure you are using the latest package versions.
#### Sign and verify using a browser wallet like Keplr
```typescript theme={null}
(async () => {
const message = "Offline Sign Message Example";
const signer = 'inj1...'
const chainId = 'injective-1'
// Sign Arbitrary Data
const signature = await window.keplr.signArbitrary(chainId, signer, message)
// Verify Arbitrary Data
const result = await window.keplr.verifyArbitrary(chainId, signer, message, signature)
if (result) {
console.log("Signature is valid");
}
})();
```
#### Sign and verify using PrivateKey in a CLI environment
```typescript theme={null}
import { config } from "dotenv";
import { PrivateKey } from "@injectivelabs/sdk-ts/core/accounts";
import { generateArbitrarySignDoc } from "@injectivelabs/sdk-ts/core/tx";
config();
(async () => {
const { privateKey } = PrivateKey.generate();
const injectiveAddress = privateKey.toBech32();
const publicKey = privateKey.toPublicKey();
const message = "Offline Sign Message Example";
const { signDocBuff } = generateArbitrarySignDoc(message, injectiveAddress);
const signature = await privateKey.sign(signDocBuff);
const signatureInHex = Buffer.from(signature).toString("hex");
if (
PrivateKey.verifyArbitrarySignature({
signature: signatureInHex,
signDoc: signDocBuff,
publicKey: publicKey.toHex(),
})
) {
console.log("Signature is valid");
}
})();
```
# Wallet Strategy
Source: https://docs.injective.network/developers-native/wallets/strategy
The main purpose of the `@injectivelabs/wallet-strategy` is to offer developers a way to have different wallet implementations on Injective. All of these wallets implementations are exposing the same `ConcreteStrategy` interface which means that users can just use these methods without the need to know the underlying implementation for specific wallets as they are abstracted away.
To start, you have to make an instance of the `WalletStrategy` class which gives you the ability to use different wallets out of the box. You can switch the current wallet that is used by using the `setWallet` method on the `walletStrategy` instance (note: `setWallet` is async and requires `await`).
Let's have a look at the methods that `WalletStrategy` strategy exposes and what they mean:
**Both Ethereum and Cosmos native wallets:**
* `getAddresses` gets the addresses from the connected wallet strategy. This method returns the Ethereum addresses for Ethereum native wallets (strategies) and Injective addresses for Cosmos native wallets (strategies).
* `signTransaction` signs a transaction using the corresponding wallet type method (`signCosmosTransaction` for Cosmos native wallets, `signEip712TypedData` for Ethereum native wallets)
* `sendTransaction` signs a transaction using the corresponding wallet type method (needs a `sentryEndpoint` passed to the options if we wanna use it on Ethereum native wallets - explanation can be found below)
* `getWalletDeviceType` returns the wallet connection type (mobile, browser, hardware),
**Cosmos native wallets:**
* `signCosmosTransaction` signs an Injective transaction using the connected wallet strategy,
* `getPublicKey` get the public key for the Cosmos native wallet strategies,
**Ethereum native wallets:**
* `getEthereumChainId` get the chain id for the Ethereum native wallet strategies,
* `signEip712TypedData` signs an EIP712 typed data using the connected wallet strategy,
* `sendEvmTransaction` sends an Ethereum Web3 transaction using the connected wallet strategy,
* `signEvmTransaction` signs an Ethereum Web3 transaction using the connected wallet strategy,
* `getEvmTransactionReceipt` get the transaction receipt for Ethereum native transactions for the wallet strategy,
### Arguments
The arguments passed to the WalletStrategy have the following interface:
```ts theme={null}
export interface WalletStrategyEvmOptions {
rpcUrl: string; // rpc url needed **ONLY** the Ethereum native methods on the strategies
evmChainId: EvmChainId; // needed if you are signing EIP712 typed data using the Wallet Strategies
}
export interface EthereumWalletStrategyArgs {
chainId: ChainId; // the Injective chain id
evmOptions?: WalletStrategyEvmOptions; // optional, needed only if you are using Ethereum native wallets
disabledWallets?: Wallet[]; // optional, needed if you wanna disable some wallets for being instantiated
wallet?: Wallet; // optional, the initial wallet selected (defaults to Metamask if `evmOptions` are passed and Keplr if they are not)
}
```
*Note:* When we wanna use the `sendTransaction` on Ethereum native wallets alongside the other options (chainId and address) we also need to pass a gRPC endpoint to a sentry to broadcast the transaction. This is needed because from Ethereum native wallets, we don't have access to a `broadcastTx` method as we have on Keplr or Leap to broadcast the transaction using the wallet's abstraction so we have to broadcast it on the client side directly to the chain.
### Example usage
```ts theme={null}
import { TxRaw } from '@injectivelabs/sdk-ts/types'
import { Web3Exception } from '@injectivelabs/exceptions'
import { ChainId, EvmChainId } from '@injectivelabs/ts-types'
import { WalletStrategy } from '@injectivelabs/wallet-strategy'
const chainId = ChainId.Testnet // The Injective Testnet Chain ID
const evmChainId = EvmChainId.TestnetEvm // The Injective Evm Testnet Chain ID
export const evmRpcEndpoint = `https://eth-sepolia.g.alchemy.com/v2/${process.env.APP_EVM_RPC_KEY}`
export const walletStrategy = new WalletStrategy({
chainId,
evmOptions: {
evmChainId,
rpcUrl: evmRpcEndpoint,
},
})
// Get wallet's addresses
export const getAddresses = async (): Promise => {
const addresses = await walletStrategy.getAddresses()
if (addresses.length === 0) {
throw new Web3Exception(new Error('There are no addresses linked in this wallet.'))
}
return addresses
}
// Sign an Injective transaction
export const signTransaction = async (tx: TxRaw): Promise => {
const response = await walletStrategy.signCosmosTransaction(
/*transaction:*/ { txRaw: tx, accountNumber: /* */, chainId: 'injective-1' },
/*address: */ 'inj1...',
)
return response
}
// Send an Injective transaction
export const sendTransaction = async (tx: TxRaw): Promise => {
const response = await walletStrategy.sendTransaction(
tx,
// `sentryEndpoint` needed if Ethereum wallets are used
{address: 'inj1...', chainId: 'injective-1', sentryEndpoint: 'https://grpc.injective.network' }
)
return response
}
```
# Archival setup
Source: https://docs.injective.network/infra/archival-setup
This guide will walk you through the process of creating a fleet of nodes that serve archival data and how to stitch them together using a gateway
## Architecture
To make serving archival data more accessible we split the data into smaller segments. These segments are stored in `s3://injective-snapshots/mainnet/subnode`
| Snapshot Dir | Height Range | Injective Version | Recommended Disk Size |
| ------------ | ------------ | ----------------- | --------------------- |
| `/0073` | 0 – 73M | v1.12.1 | 42 TiB |
| `/6068` | 60M – 68M | v1.12.1 | 7 TiB |
| `/7380` | 73M – 80M | v1.12.1 | 7 TiB |
| `/8088` | 80M – 88M | v1.13.3 | 7 TiB |
| `/8896` | 88M – 96M | v1.13.3 | 7 TiB |
| `/8898` | 88M – 98M | v1.13.3 | 7 TiB |
| `/98106` | 98M – 106M | v1.13.3 | 7 TiB |
| `/98107` | 98M – 107M | v1.14.0 | 7.5 TiB |
| `/66101` | 66M – 101M | v1.14.0 | 27 TiB |
| `/105116` | 105M – 116M | v1.15.0 | 7.5 TiB |
| `/113127` | 113M – 127M | v1.15.0 | 11 TiB |
| `/119143` | 119M – 143M | v1.17.0 | 16 TiB |
| `/138150` | 138M – 150M | v1.17.2 | 5.8 TiB |
These segments are stitched together via gateway which is an aggregator proxy that routes queries to the appropriate node based on block range
$INJ_HOME
```
#### 2. Download or set the appropriate injective binary or image tag based on the table above
#### 3. Generate your config folder
```bash theme={null}
injectived init $MONIKER --chain-id injective-1 --home $INJ_HOME --overwrite
```
#### 4. Disable pruning in your app.toml file and block p2p and set the log level to error in your config.toml files.
This ensures that the data does not get pruned and the node stays in a halted state. Setting the log level to error lessens disk ops and improves performance.
```bash theme={null}
# Disable pruning in app.toml
sed -i 's/^pruning *= *.*/pruning = "nothing"/' $INJ_HOME/config/app.toml
# Disable p2p and disable create empty blocks on config.toml
awk '
BEGIN { section = "" }
/^\[/ {
section = $0
}
section == "[p2p]" {
if ($1 ~ /^laddr/) $0 = "laddr = \"tcp://0.0.0.0:26656\""
if ($1 ~ /^max_num_inbound_peers/) $0 = "max_num_inbound_peers = 0"
if ($1 ~ /^min_num_inbound_peers/) $0 = "min_num_inbound_peers = 0"
if ($1 ~ /^pex/) $0 = "pex = false"
if ($1 ~ /^seed_mode/) $0 = "seed_mode = false"
}
section == "[consensus]" {
if ($1 ~ /^create_empty_blocks/) $0 = "create_empty_blocks = false"
}
{ print }
' $INJ_HOME/config/config.toml > $INJ_HOME/config/config.tmp && mv $INJ_HOME/config/config.tmp $INJ_HOME/config/config.toml
# Set log level to error (less disk writes = better performance)
sed -i 's/^log_level *= *.*/log_level = "error"/' $INJ_HOME/config/app.toml
```
#### 5. Run your node
```bash theme={null}
injectived start --home $INJ_HOME
```
### Gateway configuration
#### 1. Clone the gateway repository
```bash theme={null}
git clone https://github.com/decentrio/gateway
```
#### 2. Build gateway
```bash theme={null}
make build
```
#### 3. Create your config file
```yaml theme={null}
upstream:
# example node 1 holds blocks 0-80M while node 2 holds blocks 80-88M
- rpc: "http://$NODE1:$RPC_PORT"
grpc: "$NODE1:$GRPC_PORT"
api: "http://$NODE1:$API_PORT"
blocks: [0,80000000]
- rpc: "http://$NODE2:$RPC_PORT"
grpc: "$NODE2:$GRPC_PORT"
api: "http://$NODE2:$API_PORT"
blocks: [80000000,88000000]
#
# Archival tip, this serves the latest x blocks, usually set as a pruned node
- rpc: "http://$PRUNED_NODE:$RPC_PORT"
grpc: "$PRUNED_NODE:$GRPC_PORT"
api: "http://$PRUNED_NODE:$API_PORT"
blocks: [1000]
ports:
rpc: $RPC_PORT
api: $API_PORT
grpc: $GRPC_PORT
# Leave these as zero to disable for now
jsonrpc: 0
jsonrpc_ws: 0
```
#### 4. Run Gateway
```bash theme={null}
gateway start --config $CONFIG_FILE
```
# Premium Endpoints
Source: https://docs.injective.network/infra/premium-endpoints
As a developer, you may be interested in having a dedicated node or indexing solutions powering your dApp.
Here is a list of external providers offering private Injective infrastructure services. For more information, click on their websites below:
* [QuickNode](https://www.quicknode.com/chains/inj)
* [CryptoCrew](https://forms.gle/Aa2XYBB4sLxzHNzc6)
* [Imperator](https://www.imperator.co/products/dedicated-and-rpc-nodes#get-started)
* [AllNodes](https://injective.publicnode.com/)
* [NowNodes](https://nownodes.io/injective-inj)
* [RockX](https://access.rockx.com/product/injective-blockchain-api-for-web3-builders)
| Provider | Chain | Indexer |
| ---------- | ----- | ------- |
| QuickNode | \[x] | \[ ] |
| CryptoCrew | \[x] | \[x] |
| Imperator | \[x] | \[x] |
| AllNodes | \[x] | \[x] |
| NowNodes | \[x] | \[ ] |
| RockX | \[x] | \[ ] |
# Public Endpoints
Source: https://docs.injective.network/infra/public-endpoints
We **do not recommend** using these in production for applications having high usage/traffic. There are thousands of developers using the public infrastructure and we cannot promise 100% uptime and reliability.
## Mainnet
| Service | Address |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| Chain Swagger | [https://sentry.lcd.injective.network/swagger/#/](https://sentry.lcd.injective.network/swagger/#/) |
| Chain LCD | [https://sentry.lcd.injective.network:443](https://sentry.lcd.injective.network:443) |
| Chain RPC | [https://sentry.tm.injective.network:443](https://sentry.tm.injective.network:443) |
| Chain WebSocket | wss\://sentry.tm.injective.network:443/websocket |
| Chain Streamer | sentry.chain.stream.injective.network:443 |
| Chain gRPC | sentry.chain.grpc.injective.network:443 |
| Chain gRPC-Web | [https://sentry.chain.grpc-web.injective.network:443](https://sentry.chain.grpc-web.injective.network:443) |
| Indexer Swagger | [https://sentry.exchange.grpc-web.injective.network/swagger/#/](https://sentry.exchange.grpc-web.injective.network/swagger/#/) |
| Indexer gRPC | sentry.exchange.grpc.injective.network:443 |
| Indexer gRPC-Web | [https://sentry.exchange.grpc-web.injective.network:443](https://sentry.exchange.grpc-web.injective.network:443) |
| Indexer EventProvider | k8s.global.mainnet.events.grpc.injective.network:443 |
| Hub | [https://injhub.com/](https://injhub.com/) |
| Explorer | [https://explorer.injective.network/](https://explorer.injective.network/) |
| Faucet | [https://inj.supply/](https://inj.supply/) |
| Status | [https://uptime.com/statuspage/status.injective.network](https://uptime.com/statuspage/status.injective.network) |
## Testnet
| Service | Address |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Chain Swagger | [https://testnet.sentry.lcd.injective.network/swagger/](https://testnet.sentry.lcd.injective.network/swagger/) |
| Chain RPC | [https://testnet.sentry.tm.injective.network:443](https://testnet.sentry.tm.injective.network:443) |
| Chain LCD | [https://testnet.sentry.lcd.injective.network:443](https://testnet.sentry.lcd.injective.network:443) |
| Chain WebSocket | wss\://testnet.sentry.tm.injective.network:443/websocket |
| Chain Streamer | testnet.sentry.chain.stream.injective.network:443 |
| Chain gRPC | testnet.sentry.chain.grpc.injective.network:443 |
| Chain gRPC-Web | [https://testnet.sentry.chain.grpc-web.injective.network:443](https://testnet.sentry.chain.grpc-web.injective.network:443) |
| Indexer Swagger | [https://testnet.sentry.exchange.grpc-web.injective.network/swagger/#/](https://testnet.sentry.exchange.grpc-web.injective.network/swagger/#/) |
| Indexer gRPC | testnet.sentry.exchange.grpc.injective.network:443 |
| Indexer gRPC-Web | [https://testnet.sentry.exchange.grpc-web.injective.network:443](https://testnet.sentry.exchange.grpc-web.injective.network:443) |
| Indexer EventProvider | k8s.global.testnet.events.grpc.injective.network:443 |
| Hub | [https://testnet.hub.injective.network/](https://testnet.hub.injective.network/) |
| Explorer | [https://testnet.explorer.injective.network/](https://testnet.explorer.injective.network/) |
| Faucet | [https://testnet.faucet.injective.network/](https://testnet.faucet.injective.network/) |
| Status | [https://uptime.com/statuspage/testnet.status.injective.network](https://uptime.com/statuspage/testnet.status.injective.network) |
# Canonical Chain Upgrades
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade
## Verify release versions
### Releases on Github
If you would like to verify `injectived` or `peggo` version numbers via Docker,
follow the instructions in the [`verify-injective-release`](https://github.com/injective-dev/snippets-inj/tree/main/verify-injective-release) code snippet.
This is useful if you are on an operating system other than Linux,
and would like to independently verify the binaries in each release.
For example, for `v1.16.1`, it should produce the following output:
```text theme={null}
injectived version
Version v1.16.1 (8be67e82d)
Compiled at 20250802-1910 using Go go1.23.9 (amd64)
peggo version
Version v1.16.1 (8be67e82d)
Compiled at 20250802-1913 using Go go1.23.9 (amd64)
```
### Releases on Docker
These are more straightforward, as each binary needs a single command.
For `injectived`, use the following command:
```shell theme={null}
docker run -it --rm injectivelabs/injective-core:v1.16.1 injectived version
```
This should produce output similar to:
```text theme={null}
Version v1.16.1 (8be67e8)
Compiled at 20250802-1909 using Go go1.23.9 (arm64)
```
For `peggo`, use the following command:
```shell theme={null}
docker run -it --rm injectivelabs/injective-core:v1.16.1 peggo version
```
This should produce output similar to:
```text theme={null}
Version v1.16.1 (8be67e8)
Compiled at 20250802-1911 using Go go1.23.9 (arm64)
```
Note that you should replace `v1.16.1` in the commands above
with your intended Injective release version number.
### Checking for matches
Note that the output from the above commmands contain
the following in addition to the version numbers (e.g. `v1.16.1`):
* The binary release hashes (e.g. `8be67e82d`)
* The compiled time stamp (e.g. `20250802-1910`)
* The compiler (e.g. `Go go1.23.9 (amd64)`)
You can verify that these **match** the values stated in the [Injective chain releases](https://github.com/InjectiveLabs/injective-chain-releases/releases) page on Github.
# Upgrade to v1.13.0
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.13.0
Thursday, August 1st, 2024
Following [proposal 420](https://injhub.com/proposals/420/) This indicates that the upgrade procedure should be performed on block number **80319200**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validator-operator)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Thursday, August 1st, 2024, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **80319200**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [v1.13.0-1722157491](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.13.0-1722157491)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain v1.12.1 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.12.1-1705909076) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`c1a64b7ed`) of `injectived`:
```bash theme={null}
injectived version
Version dev (c1a64b7ed)
Compiled at 20240122-0743 using Go go1.19.3 (amd64)
```
2. Make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the injective-chain `v1.13.0 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.13.0-1722157491/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
3. Verify you are currently running the correct version (`c1a64b7ed`) of `injectived` after downloading the v1.13.0 release:
```bash theme={null}
injectived version
Version dev (af924ca9)
Compiled at 20240728-0905 using Go go1.22.5 (amd64)
```
4. Start injectived
```bash theme={null}
injectived start
```
5. Verify you are currently running the correct version (`ead1119`) of `peggo` after downloading the v1.13.0 release:
```bash theme={null}
peggo version
Version dev (ead1119)
Compiled at 20240728-0905 using Go go1.22.5 (amd64)
```
6. Start peggo
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.13.2
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.13.2
Tuesday, August 20th, 2024
Following [proposal 424](https://injhub.com/proposal/424/) This indicates that the upgrade procedure should be performed on block number **82830000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validators)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Thursday, August 20th, 2024, 15:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **82830000**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [v1.13.2-1723753267](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.13.2-1723753267)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain v1.13.2 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.13.2-1723753267) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`af924ca9`) of `injectived`:
```bash theme={null}
injectived version
Version dev (af924ca9)
Compiled at 20240728-0905 using Go go1.22.5 (amd64)
```
2. Make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the injective-chain `v1.13.2 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.13.2-1723753267/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
3. Verify you are currently running the correct version (`6f57bf03`) of `injectived` after downloading the v1.13.2 release:
```bash theme={null}
injectived version
Version dev (6f57bf03)
Compiled at 20240815-2021 using Go go1.22.5 (amd64)
```
4. Start injectived
```bash theme={null}
injectived start
```
5. Verify you are currently running the correct version (`ead1119`) of `peggo` after downloading the v1.13.2 release:
```bash theme={null}
peggo version
Version dev (ead1119)
Compiled at 20240815-2021 using Go go1.22.5 (amd64)
```
6. Start peggo
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.13.3
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.13.3
Thursday, Dec 19th, 2024
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validators)
## Summary
The v1.13.3 version is a non-consensus breaking upgrade of v1.13.2.
The following is a short summary of the upgrade steps:
1. Stop the binary.
2. Back up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [release-prod-1734610315](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/release-prod-1734610315)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain v1.13.2 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.13.2-1723753267) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`6f57bf03`) of `injectived`:
```bash theme={null}
Version dev (6f57bf03)
Compiled at 20240815-2021 using Go go1.22.5 (amd64)
```
2. Make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the injective-chain `v1.13.3 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/release-prod-1734610315/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
3. Verify you are currently running the correct version (`d92e96087`) of `injectived` after downloading the v1.13.3 release:
```bash theme={null}
injectived version
Version v1.13.3 (d92e96087)
Compiled at 20241219-1212 using Go go1.22.5 (amd64)
```
4. Start injectived
```bash theme={null}
injectived start
```
5. Verify you are currently running the correct version (`ead1119`) of `peggo` after downloading the v1.13.3 release:
```bash theme={null}
peggo version
Version dev (ead1119)
Compiled at 20240815-2021 using Go go1.22.5 (amd64)
```
6. Start peggo
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.14.0
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.14.0
Monday, February 17th, 2025
Following [Proposal 494](https://injhub.com/proposals/494/) This indicates that the upgrade procedure should be performed on block number **106315000**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Monday, February 17th, 2025, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **106315000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [v1.14.0-1739303348](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.14.0-1739303348)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain v1.13.3 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/release-prod-1734610315) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`d92e96087`) of `injectived`:
```bash theme={null}
injectived version
Version v1.13.3 (d92e96087)
Compiled at 20241219-1212 using Go go1.22.5 (amd64)
```
2. Make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the injective-chain `v1.14.0 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.14.0-1739303348/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
3. Verify you are currently running the correct version (`4139d7dcd`) of `injectived` after downloading the v1.14.0 release:
```bash theme={null}
injectived version
Version v1.14.0 (4139d7dcd)
Compiled at 20250211-1725 using Go go1.23.1 (amd64)
```
4. Start injectived
```bash theme={null}
injectived start
```
5. Verify you are currently running the correct version (`5317d5c`) of `peggo` after downloading the v1.14.0 release:
```bash theme={null}
peggo version
Version dev (5317d5c)
Compiled at 20250211-1726 using Go go1.22.5 (amd64)
```
6. Start peggo
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.14.1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.14.1
Tuesday, March 4th, 2025
Following [Proposal 500](https://injhub.com/proposals/500) This indicates that the upgrade procedure should be performed on block number **108175000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Tuesday, March 4th, 2025, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **108175000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [v1.14.1-1740773301](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.14.1-1740773301)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain v1.14.0 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.14.1-1740773301) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`4139d7dcd`) of `injectived`:
```bash theme={null}
injectived version
Version v1.14.0 (4139d7dcd)
Compiled at 20250211-1725 using Go go1.23.1 (amd64)
```
2. Make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the injective-chain `v1.14.1 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.14.1-1740773301/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
3. Verify you are currently running the correct version (`0fe59376d`) of `injectived` after downloading the v1.14.1 release:
```bash theme={null}
injectived version
Version v1.14.1 (0fe59376d)
Compiled at 20250228-2008 using Go go1.23.1 (amd64)
```
4. Start injectived
```bash theme={null}
injectived start
```
5. Verify you are currently running the correct version (`5317d5c`) of `peggo` after downloading the v1.14.1 release:
```bash theme={null}
peggo version
Version dev (5317d5c)
Compiled at 20250211-1726 using Go go1.22.5 (amd64)
```
6. Start peggo
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.15.0
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.15.0
Tuesday, April 22th, 2025
Following [Proposal 518](https://injhub.com/proposals/518) This indicates that the upgrade procedure should be performed on block number **114590000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Tuesday, April 22th, 2025, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **114590000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [v1.15.0-1744722790](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.15.0-1744722790)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain v1.14.1 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.14.1-1740773301) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`4139d7dcd`) of `injectived`:
```bash theme={null}
injectived version
Version v1.14.1 (0fe59376d)
Compiled at 20250228-2008 using Go go1.23.1 (amd64)
```
2. Make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the injective-chain `v1.15.0 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.15.0-1744722790/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
3. Verify you are currently running the correct version (`013606f41`) of `injectived` after downloading the v1.15.0 release:
```bash theme={null}
injectived version
Version v1.15.0 (013606f41)
```
4. Start injectived
```bash theme={null}
injectived start
```
5. Verify you are currently running the correct version (`5317d5c`) of `peggo` after downloading the v1.15.0 release:
```bash theme={null}
peggo version
Version dev (5317d5c)
Compiled at 20250415-1313 using Go go1.22.5 (amd64)
```
6. Start peggo
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.16.0
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.16.0
Thursday, July 31st, 2025
Following [Proposal 541](https://injhub.com/proposal/541/) This indicates that the upgrade procedure should be performed on block number **127250000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Thursday, July 31st, 2025, 16:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **127250000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [v1.16.0](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.16.0-1753404855) binaries.
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**:\
Validators successfully upgrade the chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**:\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**:\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the `#validators` channel in [Injective's Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to Injective Chain release [v1.15.0-1744722790](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.15.0-1744722790) and continue this earlier chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version:
```shell theme={null}
rm -rf .injectived/wasm/wasm/cache/
```
1. Verify you are currently running the correct version (`v1.15.0`) of `injectived`:
```bash theme={null}
$ injectived version
Version v1.15.0 (013606f41)
Compiled at 20250528-1843 using Go go1.24.0 (amd64)
```
2. Make a backup of your `.injectived` directory:
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the `injective-chain` release for `v1.16.0`:
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.16.0-1753404855/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`v1.16.0`) of `injectived` after downloading the`v1.16.0` release:
```bash theme={null}
Version v1.16.0 (95706035d)
Compiled at 20250725-0055 using Go go1.23.9 (amd64)
```
5. Start `injectived`:
```bash theme={null}
injectived start
```
6. Verify you are currently running the correct version (`v1.16.0-peggofix`) of `peggo` after downloading the `v1.16.0` release:
```bash theme={null}
$ peggo version
Version v1.16.0-peggofix (3b346ece0)
Compiled at 20250730-2027 using Go go1.23.9 (amd64)
```
7. Start peggo:
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.16.1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.16.1
Monday, August 4th, 2025
Following [Proposal 544](https://injhub.com/proposal/544/) This indicates that the upgrade procedure should be performed on block number **127714000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Monday, August 4th, 2025, 12:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **127714000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [v1.16.1](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.16.1-1754161770) binaries.
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**:\
Validators successfully upgrade the chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**:\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**:\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the `#validators` channel in [Injective's Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to Injective Chain release [v1.16.0](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.16.0-1753404855) and continue this earlier chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version:
```shell theme={null}
rm -rf .injectived/wasm/wasm/cache/
```
1. Verify you are currently running the correct version (`v1.16.0`) of `injectived`:
```bash theme={null}
$ injectived version
Version v1.16.0 (95706035d)
Compiled at 20250725-0055 using Go go1.23.9 (amd64)
```
2. Make a backup of your `.injectived` directory:
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the `injective-chain` release for `v1.16.1`:
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.16.1-1754161770/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`v1.16.1`) of `injectived` after downloading the`v1.16.1` release:
```bash theme={null}
Version v1.16.1 (8be67e82d)
Compiled at 20250802-1910 using Go go1.23.9
```
5. Start `injectived`:
```bash theme={null}
injectived start
```
6. Verify you are currently running the correct version (`v1.16.1`) of `peggo` after downloading the `v1.16.1` release:
```bash theme={null}
$ peggo version
Version v1.16.1 (8be67e82d)
Compiled at 20250802-1913 using Go go1.23.9
```
7. Start peggo:
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.16.2
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.16.2
Tuesday, August 19th, 2025
Following [Proposal 550](https://injhub.com/proposal/550/) This indicates that the upgrade procedure should be performed on block number **129772500**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Tuesday, August 19th, 2025, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **129772500**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [v1.16.2](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.16.2-1755212690) binaries.
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**:\
Validators successfully upgrade the chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**:\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**:\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the `#validators` channel in [Injective's Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to Injective Chain release [v1.16.1](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.16.1-1754161770) and continue this earlier chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
You must remove the wasm cache before upgrading to the new version:
```shell theme={null}
rm -rf .injectived/wasm/wasm/cache/
```
1. Verify you are currently running the correct version (`v1.16.1`) of `injectived`:
```bash theme={null}
$ injectived version
Version v1.16.1 (8be67e82d)
Compiled at 20250802-1913 using Go go1.23.9
```
2. Make a backup of your `.injectived` directory:
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the `injective-chain` release for `v1.16.2`:
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.16.2-1755212690/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`v1.16.2`) of `injectived` after downloading the`v1.16.2` release:
```bash theme={null}
Version v1.16.2 (437674d)
Compiled at 20250814-2305 using Go go1.23.9
```
5. Start `injectived`:
```bash theme={null}
injectived start
```
6. Verify you are currently running the correct version (`v1.16.2`) of `peggo` after downloading the `v1.16.2` release:
```bash theme={null}
$ peggo version
Version v1.16.2 (437674d)
Compiled at 20250814-2307 using Go go1.23.9
```
7. Start peggo:
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.16.4
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.16.4
Thursday, 25th September, 2025
Following [IIP 560](https://injhub.com/proposal/560/) This indicates that the upgrade procedure should be performed on block number **134805000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Thursday, 25th September, 2025, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **134805000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [v1.16.4](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.16.4-1758323548) binaries.
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**:\
Validators successfully upgrade the chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**:\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**:\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the `#validators` channel in [Injective's Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to Injective Chain release [v1.16.2](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.16.2-1755212690) and continue this earlier chain until next upgrade announcement.
## Upgrade Procedure
### Notes for Validators
You must remove the wasm cache before upgrading to the new version:
```shell theme={null}
rm -rf .injectived/wasm/wasm/cache/
```
### Steps
1. Verify you are currently running the correct version (`v1.16.2`) of `injectived`:
```bash theme={null}
$ injectived version
Version v1.16.2 (437674d)
Compiled at 20250814-2305 using Go go1.23.9
```
2. Make a backup of your `.injectived` directory:
```bash theme={null}
cp -r ~/.injectived ./injectived-backup
```
3. Download and install the `injective-chain` release for `v1.16.4`:
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.16.4-1758323548/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`v1.16.4`) of `injectived` after downloading the `v1.16.4` release:
```bash theme={null}
$ injectived version
Version v1.16.4 (470633e)
Compiled at 20250915-0554 using Go go1.23.9 (amd64)
```
5. Start `injectived`:
```bash theme={null}
injectived start
```
6. Verify you are currently running the correct version (`v1.16.4`) of `peggo` after downloading the `v1.16.4` release:
```bash theme={null}
$ peggo version
Version v1.16.4 (470633e)
Compiled at 20250915-0555 using Go go1.23.9 (amd64)
```
7. Start peggo:
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.17.0
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.17.0
Tuesday, November 11th, 2025
Following [IIP 583](https://injhub.com/proposal/583/) This indicates that the upgrade procedure should be performed on block number **141150000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Tuesday, November 11th, 2025, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **141150000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [1.17.0](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.17.0-1762751536) binaries.
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**:\
Validators successfully upgrade the chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**:\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**:\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the `#validators` channel in [Injective's Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to Injective Chain release [1.16.4](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/1.16.4-1758323548) and continue this earlier chain until next upgrade announcement.
## Upgrade Procedure
### Notes for Validators
You must remove the wasm cache before upgrading to the new version:
```shell theme={null}
rm -rf .injectived/wasm/wasm/cache/
```
### Steps
1. Verify you are currently running the correct version (`1.16.4`) of `injectived`:
```bash theme={null}
$ injectived version
Version v1.16.4 (470633e)
Compiled at 20250915-0554 using Go go1.23.9 (amd64)
```
2. Make a backup of your `.injectived` directory:
```bash theme={null}
cp -r ~/.injectived ./injectived-backup
```
3. Download and install the `injective-chain` release for `1.17.0`:
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/1.17.0-1762751536/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`1.17.0`) of `injectived` after downloading the `1.17.0` release:
```bash theme={null}
$ injectived version
Version v1.17.0 (33ff202)
Compiled at 20251110-0512 using Go go1.23.9 (amd64)
```
5. Start `injectived`:
```bash theme={null}
injectived start
```
6. Verify you are currently running the correct version (`1.17.0`) of `peggo` after downloading the `1.17.0` release:
```bash theme={null}
$ peggo version
Version v1.17.0 (33ff202)
Compiled at 20251110-0512 using Go go1.23.9 (amd64)
```
7. Start peggo:
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.17.1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.17.1
Wednesday, December 3rd, 2025
Following [Proposal 601](https://injhub.com/proposal/601/) This indicates that the upgrade procedure should be performed on block number **144210000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Wednesday, December 3rd, 2025, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **144210000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [1.17.1](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.17.1-1764720946) binaries.
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**:\
Validators successfully upgrade the chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**:\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**:\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the `#validators` channel in [Injective's Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to Injective Chain release [1.17.0](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/1.17.0-1762751536) and continue this earlier chain until next upgrade announcement.
## Upgrade Procedure
### Notes for Validators
You must remove the wasm cache before upgrading to the new version:
```shell theme={null}
rm -rf .injectived/wasm/wasm/cache/
```
### Steps
1. Verify you are currently running the correct version (`1.17.0`) of `injectived`:
```bash theme={null}
$ injectived version
Version v1.17.0 (33ff202)
Compiled at 20251110-0512 using Go go1.23.9 (amd64)
```
2. Make a backup of your `.injectived` directory:
```bash theme={null}
cp -r ~/.injectived ./injectived-backup
```
3. Download and install the `injective-chain` release for `1.17.1`:
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.17.1-1764720946/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`1.17.1`) of `injectived` after downloading the `1.17.1` release:
```bash theme={null}
$ injectived version
Version v1.17.1 (99ae041)
Compiled at 20251202-2355 using Go go1.23.9 (amd64)
```
5. Start `injectived`:
```bash theme={null}
injectived start
```
6. Verify you are currently running the correct version (`1.17.1`) of `peggo` after downloading the `1.17.1` release:
```bash theme={null}
$ peggo version
Version v1.17.1 (99ae041)
Compiled at 20251202-2355 using Go go1.23.9 (amd64)
```
7. Start peggo:
```bash theme={null}
peggo orchestrator
```
# Upgrade to v1.17.2
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-1.17.2
Thursday, December 18th, 2025
Following [Proposal 603](https://injhub.com/proposal/603/) This indicates that the upgrade procedure should be performed on block number **146295000**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validators](#notes-for-validators)
## Summary
The Injective Chain will undergo a scheduled enhancement upgrade on **Thursday, December 18th, 2025, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **146295000**.
2. Backing up configs, data, and keys used for running the Injective Chain.
3. Install the [1.17.2](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.17.2-1765930431) binaries.
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**:\
Validators successfully upgrade the chain without purging the blockchain history, and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**:\
Validators have trouble upgrading to the latest Canonical chain.
3. **Abort path**:\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the `#validators` channel in [Injective's Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to Injective Chain release [1.17.1](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.17.1-1764720946) and continue this earlier chain until next upgrade announcement.
## Upgrade Procedure
### Notes for Validators
You must remove the wasm cache before upgrading to the new version:
```shell theme={null}
rm -rf .injectived/wasm/wasm/cache/
```
### Steps
1. Verify you are currently running the correct version (`1.17.1`) of `injectived`:
```bash theme={null}
$ injectived version
Version v1.17.1 (99ae041)
Compiled at 20251202-2355 using Go go1.23.9 (amd64)
```
2. Make a backup of your `.injectived` directory:
```bash theme={null}
cp -r ~/.injectived ./injectived-backup
```
3. Download and install the `injective-chain` release for `1.17.2`:
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.17.2-1765930431/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`1.17.2`) of `injectived` after downloading the `1.17.2` release:
```bash theme={null}
$ injectived version
Version v1.17.2 (b2809ae)
Compiled at 20251217-0013 using Go go1.23.9 (amd64)
```
5. Start `injectived`:
```bash theme={null}
injectived start
```
6. Verify you are currently running the correct version (`1.17.2`) of `peggo` after downloading the `1.17.2` release:
```bash theme={null}
$ peggo version
Version v1.17.2 (b2809ae)
Compiled at 20251217-0013 using Go go1.23.9 (amd64)
```
7. Start peggo:
```bash theme={null}
peggo orchestrator
```
# Upgrade to 10002-rc1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10002-rc1
# Upgrade to 10002-rc1
Nov. 8th, 2021
The upgrade will take place via an on-chain software upgrade proposal passed by Injective governance. If passed, this proposal would commit the Injective Mainnet to halting the Canary Chain `injectived` application binary at approximately **14:00 UTC on Nov. 8th, 2021,** and starting the application binary for the Injective Canonical Chain.
In case of a failed migration via the upgrade module, the Injective Labs team will post an official `injective-canonical-chain` genesis file, but it is recommended that validators should do try to export the genesis on their own node to verify the resulting genesis file.
Following [proposal #65](https://injhub.com/proposals/65) This indicates that the upgrade procedure should be performed on block number **4,352,000**.
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
## Summary
The Injective Canary Chain will undergo a scheduled upgrade to Injective Canonical Chain on **Monday, November 8th 2021**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **4,352,000**.
2. Backing up configs, data, and keys used for running the Injective Canary Chain.
3. Install the [Injective 10002-rc1 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.1.0-1636178708)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully migrate from the Canary chain to Canonical chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble migrating from the Canary chain to Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the Canary chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted, and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting the Canary chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10001-rc7 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.0.1-1635956190) and continue the chain until next upgrade announcement.
### Upgrade Procedure
1. Verify you are currently running the correct version (`b174465c`) of `injectived`:
```bash theme={null}
$ injectived version
commit: b174465c
go: go1.16.8
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Canary Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10002-rc1 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.1.0-1636178708/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
```
4. Verify you are currently running the correct version (`eb018590`) of `injectived` after downloading the 10002-rc1 release:
```bash theme={null}
$ injectived version
commit: eb018590
go: go1.17.2
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
# Upgrade to 10002-rc2
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10002-rc2
November 15th, 2021
Following [proposal #70](https://injhub.com/proposals/70) This indicates that the upgrade procedure should be performed on block number **4, 594, 100**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
## Summary
The Injective Canonical Chain will undergo a scheduled upgrade to Injective Canonical Chain on **Monday, November 15th, 2021**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **4, 594, 100**.
2. Backing up configs, data, and keys used for running the Injective Canary Chain.
3. Install the [Injective Chain 10002-rc2 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.1.1-1636733798)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrade chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting the chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10002-rc1 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.1.0-1636178708) and continue the chain until next upgrade announcement.
### Upgrade Procedure
1. Verify you are currently running the correct version (`eb018590`) of `injectived`:
```bash theme={null}
$ injectived version
commit: eb018590
Compiled at 20211106-0605 using Go go1.17.2 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10002-rc2 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.1.1-1636733798/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
```
4. Verify you are currently running the correct version (`096cbe5`) of `injectived` after downloading the 10002-rc2 release:
```bash theme={null}
$ injectived version
Version dev (096cbe5)
Compiled at 20211112-1620 using Go go1.17.2 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
# Upgrade to 10003-rc1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10003-rc1
Thursday, December 30th, 2021
Following [proposal #93](https://injhub.com/proposals/93) This indicates that the upgrade procedure should be performed on block number **6159200**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Notes for DEX Relayer Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Thursday, December 30th, 2021 (approximately 14:00 UTC)**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **6159200**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [Mainnet-10003-rc1-1640627705](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.1.1-1640627705)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10002-rc2 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.1.1-1636733798) and continue the chain until next upgrade announcement.
### Upgrade Procedure
1. Verify you are currently running the correct version (`096cbe5`) of `injectived`:
```bash theme={null}
$ injectived version
commit: 096cbe5
Compiled at 20211106-0605 using Go go1.17.2 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10003-rc1 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.1.1-1640627705/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
```
4. Verify you are currently running the correct version (`260e526`) of `injectived` after downloading the 10003-rc1 release:
```bash theme={null}
$ injectived version
Version dev (260e526)
Compiled at 20211227-1757 using Go go1.17.2 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to 10004-rc1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10004-rc1
Tuesday, January 25th, 2022
Following [proposal #106](https://injhub.com/proposals/106) This indicates that the upgrade procedure should be performed on block number **7067700**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Service Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Tuesday, January 25th, 2022 (approximately at 14:00 UTC)**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **7067700**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [Mainnet-10004-rc1-v1.4.0-1642928125](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.4.0-1642928125)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10003-rc1 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.1.1-1640627705) and continue the chain until next upgrade announcement.
### Upgrade Procedure
1. Verify you are currently running the correct version (`260e526`) of `injectived`:
```bash theme={null}
$ injectived version
commit: 260e526
Compiled at 20211227-1757 using Go go1.17.2 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10004-rc1 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.4.0-1642928125/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
```
4. Verify you are currently running the correct version (`94583db`) of `injectived` after downloading the 10004-rc1 release:
```bash theme={null}
$ injectived version
Version dev (94583db)
Compiled at 20220123-0855 using Go go1.17.6 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to 10004-rc1-patch
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10004-rc1-patch
Sunday, February 20th, 2022
Upgrade Injective from 10004-rc1 to 10004-rc1 [patch version 10004-rc1-1645352045](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.4.0-1645352045) created due to an incident that happened on Sunday, February 20th, 2022, at 3:55 AM UTC-05:00, when [Network halted at block 7941974](https://explorer.injective.network/block/7941974).
This indicates that the upgrade procedure should be performed on block number **7941974**
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for DEX Relayer Providers](#notes-for-dex-relayer-providers)
## Summary
* At 3:55 AM UTC-05:00 Network halted, [block height 7941974](https://explorer.injective.network/block/7941974)
* At 5:05 AM UTC-05:00 [New release created with rolled back fix, Version 10004-rc1-1645352045](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.4.0-1645352045)
* At 06:08 UTC-05:00 [Network is back up](https://explorer.injective.network/block/7941975)
The following is a short summary of the upgrade steps:
1. Backing up configs, data, and keys used for running the Injective Canonical Chain.
2. Install the [Mainnet-10004-rc1-v1.4.0-1642928125](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.4.0-1645352045)
3. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. Happy path\
Validators successfully migrate from the 10004-rc1 Injective Chain to 10004-rc1 patch without purging the blockchain history, and all validators are up within 1-2 hours.
2. Not-so-happy path\
Validators have trouble upgrading the chain. This could be some consensus-breaking changes not covered in the upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. Abort path\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.
## Recovery
Prior to exporting Injective state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally, this can be done by backing up the `.injectived` directory. We would suggest using `aws s3 sync` with the delete flag, this will shorten the snapshotting time as only the file diffs are uploaded to the S3 bucket.
It is critically important to back up the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
## Upgrade Procedure
1. Verify you are currently running the correct (pre-upgrade) version (`94583db`) of `injectived`:
```bash theme={null}
$ injectived version
Version dev (94583db)
Compiled at 20220123-0855 using Go go1.17.6 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the existing Canonical Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install Injective 10004-rc1 release
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.4.0-1645352045/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived /usr/bin
```
4. Verify you are currently running the correct new version (`30b3dbf`) of `injectived` after downloading the 10004-rc1 release:
```bash theme={null}
$ injectived version
Version dev (30b3dbf)
Compiled at 20220220-1014 using Go go1.17.6 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to 10005-rc1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10005-rc1
Monday, April 11th, 2022
Following [proposal #133](https://injhub.com/proposals/133) This indicates that the upgrade procedure should be performed on block number **9614200**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for DEX relayer Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Monday, April 11th, 2022 (approximately at 14:00 UTC)**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **9614200**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [Mainnet-v1.5.0-1649280277](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.5.0-1649280277)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10004-rc1-patch release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.4.0-1645352045) and continue the chain until next upgrade announcement.
### Upgrade Procedure
1. Verify you are currently running the correct version (`30b3dbf`) of `injectived`:
```bash theme={null}
$ injectived version
Version dev (30b3dbf)
Compiled at 20220220-1014 using Go go1.17.6 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10005-rc1 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.5.0-1649280277/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
```
4. Verify you are currently running the correct version (`568ce23`) of `injectived` after downloading the 10005-rc1 release:
```bash theme={null}
$ injectived version
Version dev (568ce23)
Compiled at 20220406-2125 using Go go1.18 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to 10006-rc1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10006-rc1
Tuesday, July 5th, 2022
Following [proposal 159](https://injhub.com/proposals/159/) This indicates that the upgrade procedure should be performed on block number **12569420**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for DEX Relayer Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Tuesday, July 5th, 2022 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **12569420**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [Mainnet-v1.6.0-1656650662](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.6.0-1656650662)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10005-rc1 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.5.0-1649280277/linux-amd64.zip) and continue the chain until next upgrade announcement.
### Upgrade Procedure
1. Verify you are currently running the correct version (`568ce23`) of `injectived`:
```bash theme={null}
$ injectived version
Version dev (568ce23)
Compiled at 20220406-2125 using Go go1.18 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10006-rc1 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.6.0-1656650662/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`ef7f6f7a`) of `injectived` after downloading the 10006-rc1 release:
```bash theme={null}
$ injectived version
Version dev (ef7f6f7a)
Compiled at 20220701-0444 using Go go1.18.3 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
6. As the above release didn't include the updates to peggo correctly, we created a new release for peggo changes. Download and install the new Injective Chain 10006-rc1 release for peggo binary:
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.6.0-1657048292/linux-amd64.zip
unzip linux-amd64.zip
sudo mv peggo /usr/bin
```
7. Verify you are currently running the correct version (`ade8906`) of `peggo` after downloading the 10006-rc1 release:
```bash theme={null}
$ peggo version
Version dev (ade8906)
Compiled at 20220701-0444 using Go go1.18.3 (amd64)
```
8. Start peggo
```
peggo start
```
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to 10007-rc1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10007-rc1
Thursday, September 1st, 2022
Following [proposal 170)](https://injhub.com/proposals/170/) This indicates that the upgrade procedure should be performed on block number **14731000**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validators)
* [Notes for DEX Relayer Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Thursday, September 1st, 2022, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **14730999**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [Mainnet-v1.7.0-1665417543](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.7.0-1665417543)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10006-rc1 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.6.0-1656650662/linux-amd64.zip) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
Validator operators should configure the **timeout\_commit** in **config.toml** to `1s`.
1. Verify you are currently running the correct version (`ef7f6f7a`) of `injectived`:
```bash theme={null}
injectived version
Version dev (ef7f6f7a)
Compiled at 20220705-1911 using Go go1.18.3 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10007 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.7.0-1665417543/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`178f6dbb`) of `injectived` after downloading the 10007 release:
```bash theme={null}
injectived version
Version dev (178f6dbb)
Compiled at 20220903-1641 using Go go1.18.5 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
6. Verify you are currently running the correct version (`ade8906`) of `peggo` after downloading the 10007 release:
```bash theme={null}
peggo version
Version dev (ade8906)
Compiled at 20220830-1738 using Go go1.18.5 (amd64)
```
8. Start peggo
```bash theme={null}
peggo start
```
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to 10008 - Camelot
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10008
Thursday, November 21st, 2022
Following [proposal 182](https://injhub.com/proposals/182/) This indicates that the upgrade procedure should be performed on block number **19761600**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validator-operators)
* [Notes for Service Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Thursday, November 21st, 2022, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **19761599**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [Mainnet-10008-1668679102](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.8.0-1668679102)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10007-rc1 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.7.0-1665417543/linux-amd64.zip) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
Validator operators should configure the **timeout\_commit** in **config.toml** to `300ms`.
1. Verify you are currently running the correct version (`ca447cf8`) of `injectived`:
```bash theme={null}
injectived version
Version dev (ca447cf8)
Compiled at 20221024-1031 using Go go1.18.5 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10008 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.8.0-1668679102/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`64c9081`) of `injectived` after downloading the 10008 release:
```bash theme={null}
injectived version
Version dev (64c9081)
Compiled at 20221117-0959 using Go go1.18.3 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
6. Verify you are currently running the correct version (`ade8906`) of `peggo` after downloading the 10008 release:
```bash theme={null}
peggo version
Version dev (ade8906)
Compiled at 20220830-1738 using Go go1.18.5 (amd64)
```
8. Start peggo
```bash theme={null}
peggo start
```
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to 10009
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-10009
Tuesday, January 18th, 2022
Following [proposal 198](https://injhub.com/proposals/198/) This indicates that the upgrade procedure should be performed on block number **24204000**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validator-operators)
* [Notes for Service Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Tuesday, January 18th, 2022, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **24204000**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [Mainnet-10009-1673640888](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.9.0-1673640888)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10008 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.8.0-1668679102) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
Validator operators should configure the **timeout\_commit** in **config.toml** to `300ms`.
1. Verify you are currently running the correct version (`64c9081`) of `injectived`:
```bash theme={null}
injectived version
Version dev (64c9081)
Compiled at 20221024-1031 using Go go1.18.5 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10009 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.9.0-1673640888/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`3c87354f5`) of `injectived` after downloading the 10009 release:
```bash theme={null}
injectived version
Version dev (3c87354f5)
Compiled at 20230113-2015 using Go go1.18.3 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
6. Verify you are currently running the correct version (`ade8906`) of `peggo` after downloading the 10009 release:
```bash theme={null}
peggo version
Version dev (ade8906)
Compiled at 20220830-1738 using Go go1.18.5 (amd64)
```
8. Start peggo
```bash theme={null}
peggo start
```
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to v1.10
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-v1.10.0
Friday, March 17th, 2023
Following [proposal 207](https://injhub.com/proposals/207/) This indicates that the upgrade procedure should be performed on block number **28864000**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validator-operators)
* [Notes for Service Providers](#notes-for-dex-relayer-providers)
### Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **March 17th 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **28864000**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [Mainnet-v1.10-1678709842](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.10-1678709842)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
### Risks
As a validator performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
### Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10009 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.9.0-1673970775) and continue the chain until next upgrade announcement.
#### Upgrade Procedure
### Notes for Validators
Validator operators should configure the **timeout\_commit** in **config.toml** to `300ms`.
1. Verify you are currently running the correct version (`3c87354f5`) of `injectived`:
```bash theme={null}
injectived version
Version v1.9.0 (3c87354f5)
Compiled at 20230118-1421 using Go go1.18.3 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See Recovery for details on how to proceed.
3. Download and install the injective-chain `10010 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.10-1678709842
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`e218afcf7`) of `injectived` after downloading the 10009 release:
```bash theme={null}
injectived version
Version dev (e218afcf7) │
Compiled at 20230313-1224 using Go go1.18.3 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
6. Verify you are currently running the correct version (`bede2b6`) of `peggo` after downloading the 10009 release:
```bash theme={null}
peggo version
Version dev (bede2b6) │
Compiled at 20230313-1224 using Go go1.18.3 (amd64)
```
8. Start peggo
```bash theme={null}
peggo start
```
### Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded as it relies on several other components that work with injectived.
# Upgrade to v1.11
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-v1.11.0
Thursday, June 1st, 2023
Following [proposal 231](https://injhub.com/proposals/231/) This indicates that the upgrade procedure should be performed on block number **34775000**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validators)
* [Notes for Service Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Thursday, June 1st, 2023, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **34775000**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [v1.11-1685225746](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.11-1685225746)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#mainnet-validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10010 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.10.1-1685036881) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
Validator operators should configure the **timeout\_commit** in **config.toml** to `300ms`. You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`b578d018c8`) of `injectived`:
```bash theme={null}
injectived version
Version dev (b578d018c8)
Compiled at 20230118-1421 using Go go1.18.3 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `10011 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.11-1685225746/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`f77eb5cfd7`) of `injectived` after downloading the 10009 release:
```bash theme={null}
injectived version
Version v1.11 (f77eb5cfd7)
Compiled at 20230527-2215 using Go go1.19.3 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
6. Verify you are currently running the correct version (`5868c94`) of `peggo` after downloading the 10009 release:
```bash theme={null}
peggo version
Version dev (5868c94)
Compiled at 20230527-2216 using Go go1.19.3 (amd64)
```
8. Start peggo
```bash theme={null}
peggo start
```
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to v1.12.0
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-v1.12.0
Thursday, January 11th, 2024
Following [proposal 314](https://injhub.com/proposals/314/) This indicates that the upgrade procedure should be performed on block number **57076000**
* [Summary](#summary)
* [Risks](#risks)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validators)
* [Notes for DEX Relayer Providers](#notes-for-dex-relayer-providers)
## Summary
The Injective Canonical Chain will undergo a scheduled enhancement upgrade on **Thursday, January 11th, 2024, 14:00 UTC**.
The following is a short summary of the upgrade steps:
1. Vote and wait till the node panics at block height **57076000**.
2. Backing up configs, data, and keys used for running the Injective Canonical Chain.
3. Install the [v1.12.0-1704530206](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.12.0-1704530206)
4. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history, and all validators are up within 1-2 hours of the scheduled upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to the latest Canonical chain. This could be some consensus breaking changes not covered in upgrade handler, or compatibility issue of the migrated state with new injectived binary, but validators can at least export the genesis.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes. A new governance proposal for the upgrade will need to be issued and voted on by the community for the next upgrade.
## Risks
As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and being slashed. The most important piece of this procedure is verifying your software version and genesis file hash before starting your validator and signing.
The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. If the network is halted and you have started with a different genesis file than the expected one, seek advice from an Injective developer before resetting your validator.
## Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain 10011 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.11.6-1688984159) and continue the chain until next upgrade announcement.
### Upgrade Procedure
## Notes for Validators
Validator operators should configure the **timeout\_commit** in **config.toml** to `300ms`.
You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`69fb0c5`) of `injectived`:
```bash theme={null}
injectived version
Version dev (69fb0c5)
Compiled at 20230710-1016 using Go go1.19.3 (amd64)
```
2. After the chain has halted, make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
\
**NOTE**: It is recommended for validators and operators to take a full data snapshot at the export height before proceeding in case the upgrade does not go as planned or if not enough voting power comes online in a sufficient and agreed upon amount of time. In such a case, the chain will fallback to continue operating the Chain. See [Recovery](#recovery) for details on how to proceed.
3. Download and install the injective-chain `v1.12.0 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.12.0-1704530206/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
4. Verify you are currently running the correct version (`b92723b13`) of `injectived` after downloading the v1.12.0 release:
```bash theme={null}
injectived version
Version dev (b92723b13)
Compiled at 20240106-0837 using Go go1.19.3 (amd64)
```
5. Coordinate to restart your injectived with other validators
```bash theme={null}
injectived start
```
The binary will perform the upgrade automatically and continue the next consensus round if everything goes well.
6. Verify you are currently running the correct version (`9e702f1`) of `peggo` after downloading the v1.12.0 release:
```bash theme={null}
peggo version
Version dev (9e702f1)
Compiled at 20240106-0837 using Go go1.19.3 (amd64)
```
8. Start peggo
```bash theme={null}
peggo orchestrator
```
## Notes for DEX relayer providers
Relayer upgrade will be available after the chain is successfully upgraded, as it relies on several other components that work with injectived.
# Upgrade to v1.12.1
Source: https://docs.injective.network/infra/validator-mainnet/canonical-chain-upgrade-v1.12.1
Monday, January 22nd, 2024
This is a **non-consensus breaking release**, node operators can upgrade in their earliest convenience.
**Network downtime will not occur during this upgrade.**
All nodes, validator and non-consensus nodes must be upgraded as soon as possible to this version.
Validators should also upgrade the peggo version.
* [Summary](#summary)
* [Recovery](#recovery)
* [Upgrade Procedure](#upgrade-procedure)
* [Notes for Validator Operators](#notes-for-validators)
### Summary
The Injective Canonical Chain will undergo a improvement upgrade on **Jan 22th**.
The following is a short summary of the upgrade steps:
1. Backing up configs, data, and keys used for running the Injective Canonical Chain.
2. Install the [v1.12.1-1705909076](https://github.com/InjectiveLabs/injective-chain-releases/releases/tag/v1.12.1-1705909076)
3. Start your node with the new injectived binary to fulfill the upgrade.
Upgrade coordination and support for validators will be available on the `#validators` private channel of the [Injective Discord](https://discord.gg/injective).
The network upgrade can take the following potential pathways:
1. **Happy path**\
Validators successfully upgrade chain without purging the blockchain history and all validators are up within 5-10 minutes of the upgrade.
2. **Not-so-happy path**\
Validators have trouble upgrading to latest Canonical chain.
3. **Abort path**\
In the rare event that the team becomes aware of unnoticed critical issues, the Injective team will attempt to patch all the breaking states and provide another official binary within 36 hours.\
If the chain is not successfully resumed within 36 hours, the upgrade will be announced as aborted on the #mainnet-validators channel of [Discord](https://discord.gg/injective), and validators will need to resume running the chain without any updates or changes.
### Recovery
Prior to exporting chain state, validators are encouraged to take a full data snapshot at the export height before proceeding. Snapshotting depends heavily on infrastructure, but generally this can be done by backing up the `.injectived` directory.
It is critically important to backup the `.injectived/data/priv_validator_state.json` file after stopping your injectived process. This file is updated every block as your validator participates in a consensus rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails and the previous chain needs to be restarted.
In the event that the upgrade does not succeed, validators and operators must restore the snapshot and downgrade back to [Injective Chain v1.12.0 release](https://github.com/InjectiveLabs/injective-chain-releases/releases/v1.12.0-1704530206) and continue the chain until next upgrade announcement.
#### Upgrade Procedure
### Notes for Validators
You must remove the wasm cache before upgrading to the new version (rm -rf .injectived/wasm/wasm/cache/).
1. Verify you are currently running the correct version (`b92723b13`) of `injectived`:
```bash theme={null}
injectived version
Version dev (b92723b13)
Compiled at 20240106-0837 using Go go1.19.3 (amd64)
```
2. Make a backup of your `.injectived` directory
```bash theme={null}
cp ~/.injectived ./injectived-backup
```
3. Download and install the injective-chain `v1.12.1 release`
```bash theme={null}
wget https://github.com/InjectiveLabs/injective-chain-releases/releases/download/v1.12.1-1705909076/linux-amd64.zip
unzip linux-amd64.zip
sudo mv injectived peggo /usr/bin
sudo mv libwasmvm.x86_64.so /usr/lib
```
3. Verify you are currently running the correct version (`c1a64b7ed`) of `injectived` after downloading the v1.12.1 release:
```bash theme={null}
injectived version
Version dev (c1a64b7ed)
Compiled at 20240122-0743 using Go go1.19.3 (amd64)
```
4. Start injectived
```bash theme={null}
injectived start
```
5. Verify you are currently running the correct version (`e8089a7`) of `peggo` after downloading the v1.12.0 release:
```bash theme={null}
peggo version
Version dev (e8089a7)
Compiled at 20240122-0743 using Go go1.19.3 (amd64)
```
6. Start peggo
```bash theme={null}
peggo orchestrator
```
# Testnet
Source: https://docs.injective.network/infra/validator-testnet/index
Node operators should deploy bare metal servers to achieve optimal performance. Additionally, validator nodes must meet the recommended hardware specifications and particularly the CPU requirements, to ensure high uptime.
#### Hardware Requirements
| *Minimum* | *Recommendation* |
| :-------------------: | :-------------------: |
| RAM Memory 128GB | RAM Memory 128GB |
| CPU 12 cores | CPU 16 cores |
| CPU base clock 3.7GHz | CPU base clock 4.2GHz |
| Storage 2TB NVMe | Storage 2TB NVMe |
| Network 1Gbps+ | Network 1Gbps+ |
### Step 1: Create a Validator Account
First, run the keygen command with your desired validator key name.
```bash theme={null}
export VALIDATOR_KEY_NAME=[my-validator-key]
injectived keys add $VALIDATOR_KEY_NAME
```
This will derive a new private key and encrypt it to disk. Make sure to remember the password you used.
```bash theme={null}
# EXAMPLE OUTPUT
- name: myvalidatorkey
type: local
address: inj1queq795wx8gzqc8706uz80whp07mcgg5nmpj6h
pubkey: injpub1r0mckeepqwzmrzt5af00hgc7fhve05rr0q3q6wvx4xn6k46zguzykdszg6cnu0zca4q
mnemonic: ""
threshold: 0
pubkeys: []
**Important** write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password.
```
**The output will contain a mnemonic phrase that represents your key in plain text. Make sure to save this phrase as a backup of your key, since without a key you will not be able to control your validator. The phrase is better be backed up on physical paper, storing it in cloud storage may compromise your validator later.**
Remember the address starting from `inj`, this is going to be your Injective Chain Validator Account address.
### Step 2: Obtain INJ
In order to proceed with the next step, you will have to obtain some INJ on Injective.
You can request funds from the [Testnet Faucet](https://faucet.injective.network/).
After a few minutes, you should be able to verify that your deposit was successful on the UI. Alternatively, you can query your account balance using the `injectived` CLI with the following command:
```bash theme={null}
injectived q bank balances
```
### Step 3: Create your validator account
Obtain your node's Tendermint validator Bech32 encoded PubKey consensus address.
```bash theme={null}
VALIDATOR_PUBKEY=$(injectived tendermint show-validator)
echo $VALIDATOR_PUBKEY
# Example: {"@type": "/cosmos.crypto.ed25519.PubKey", "key": "GWEJv/KSFhUUcKBWuf9TTT3Ful+3xV/1lFhchyW1TZ8="}
```
Then create your new validator initialized with a self-delegation with your INJ tokens. Most critically, you will need to decide on the values of your validator's staking parameters.
* `--moniker` - Your validator's name
* `--amount` - Your validator's initial amount of INJ to bond
* `--commission-max-change-rate` - Your validator's maximum commission change rate percentage (per day)
* `--commission-max-rate` - Your validator's maximum commission rate percentage
* `--commission-rate` - Your validator's initial commission rate percentage
* `--min-self-delegation` - Your validator's minimum required self delegation
Once you decide on your desired values, set them as follows.
```bash theme={null}
MONIKER=
AMOUNT=100000000000000000000inj # to delegate 100 INJ, as INJ is represented with 18 decimals.
COMMISSION_MAX_CHANGE_RATE=0.1 # e.g. for a 10% maximum change rate percentage per day
COMMISSION_MAX_RATE=0.1 # e.g. for a 10% maximum commission rate percentage
COMMISSION_RATE=0.1 # e.g. for a 10% initial commission rate percentage
MIN_SELF_DELEGATION_AMOUNT=50000000000000000000 # e.g. for a minimum 50 INJ self delegation required on the validator
```
Then run the following command to create your validator.
```bash theme={null}
injectived tx staking create-validator \
--moniker=$MONIKER \
--amount=$AMOUNT \
--gas-prices=500000000inj \
--pubkey=$VALIDATOR_PUBKEY \
--from=$VALIDATOR_KEY_NAME \
--keyring-backend=file \
--yes \
--node=tcp://localhost:26657 \
--chain-id=injective-888
--commission-max-change-rate=$COMMISSION_MAX_CHANGE_RATE \
--commission-max-rate=$COMMISSION_MAX_RATE \
--commission-rate=$COMMISSION_RATE \
--min-self-delegation=$MIN_SELF_DELEGATION_AMOUNT
```
Extra `create-validator` options to consider:
```
--identity= The optional identity signature (ex. UPort or Keybase)
--pubkey= The Bech32 encoded PubKey of the validator
--security-contact= The validator's (optional) security contact email
--website= The validator's (optional) website
```
You can check that your validator was successfully created by checking the
[staking dashboard](https://injhub.com/stake/),
and scrolling down to the "Validators" section.
It looks like this:
**NOTE:** Once you've registered your Orchestrator with the `set-orchestrator-address` message, you **CANNOT** register again. Once this step is complete, your `Validator` is bound to the provided Ethereum address (as well the Delegated address you may have provided). In other words, your peggo must always run with the addresses you provided for registration.
## Step 3: Start the Relayer
```bash theme={null}
peggo orchestrator
```
This starts the Peggo bridge (relayer / orchestrator).
## Step 4: Create a Peggo systemd service
Add `peggo.service` file with below content under `/etc/systemd/system/peggo.service`
```ini theme={null}
[Unit]
Description=peggo
[Service]
WorkingDirectory=/home/ec2-user/.peggo
ExecStart=/bin/bash -c 'peggo orchestrator '
Type=simple
Restart=always
RestartSec=1
User=ec2-user
[Install]
WantedBy=multi-user.target
```
Then, run the following commands to configure Environment variables, start and stop the peggo relayer.
```bash theme={null}
sudo systemctl start peggo
sudo systemctl stop peggo
sudo systemctl restart peggo
sudo systemctl status peggo
# enable start on system boot
sudo systemctl enable peggo
# To check Logs
journalctl -f -u peggo
```
## Step 5: (Optional) Protect Cosmos Keyring from unauthorized access
This is an advanced DevOps topic, consult with your sysadmin.
Learn more about Cosmos Keyring setup [here](https://docs.cosmos.network/v0.46/run-node/keyring.html). Once you've launched your node, the default keyring will have the validator operator key stored on disk in the encrypted form. Usually, the keyring is located within node's homedir, i.e. `~/.injectived/keyring-file`.
Some sections of the Injective Staking documentation will guide you through using this key for governance purposes, i.e., submitting transactions and setting up an Ethereum bridge. In order to protect the keys from unauthorized access, even when the keyring passphrase is leaked via configs, you can set OS permissions to allow disk access to `injectived` / `peggo` processes only.
In Linux systems like Debian, Ubuntu and RHEL, this can be achieved using POSIX Access Control Lists (ACLs). Before beginning to work with ACLs, the file system must be mounted with ACLs turned on. There are some official guides for each distro:
* [Ubuntu](https://help.ubuntu.com/community/FilePermissionsACLs)
* [Debian](https://wiki.debian.org/Permissions)
* [Amazon Linux (RHEL)](https://www.redhat.com/sysadmin/linux-access-control-lists)
## Testnet
## Step 1: Configure your Peggo relayer
```bash theme={null}
mkdir ~/.peggo
cp testnet-config/40014/peggo-config.env ~/.peggo/.env
cd ~/.peggo
```
First, update the `PEGGO_ETH_RPC` in the `.env` file with a valid Ethereum EVM RPC Endpoint.
To create your own Ethereum full node, you can follow our instructions [here](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/). It's possible to use an external Ethereum RPC provider such as Alchemy or Infura, but keep in mind that the Peggo bridge relayer uses heavy use of `eth_getLogs` calls which may increase your cost burden depending on your provider.
Peggo also requires access to your validator's delegated Injective Chain account and Ethereum key credentials to sign transactions for the corresponding networks.
### **Creating your delegated Cosmos Key for sending Injective transactions**
Your peggo relayer can either
* Use an explicitly delegated account key specific for sending validator specific Peggy transactions (i.e. `ValsetConfirm`, `BatchConfirm`, and `SendToCosmos` transactions), or
* Simply use your validator's account key.
For isolation purposes, we recommend creating a delegated Cosmos key to send Injective transactions instead of using your validator account key.
To create a new key, run:
```bash theme={null}
injectived keys add $ORCHESTRATOR_KEY_NAME
```
Then, ensure that your orchestrator inj address has INJ balance.
To obtain your orchestrators's inj address, run:
```bash theme={null}
injectived keys list $ORCHESTRATOR_KEY_NAME
```
You can transfer INJ from your validator account to orchestrator address using this command:
```bash theme={null}
injectived tx bank send $VALIDATOR_KEY_NAME $ORCHESTRATOR_INJ_ADDRESS --chain-id=injective-888 --keyring-backend=file --yes --node=tcp://localhost:26657 --gas-prices=500000000inj
```
Example:
```bash theme={null}
injectived tx bank send genesis inj1u3eyz8nkvym0p42h79aqgf37gckf7szreacy9e 20000000000000000000inj --chain-id=injective-888 --keyring-backend=file --yes --node=tcp://localhost:26657 --gas-prices=500000000inj
```
You can then verify that your orchestrator account has INJ balances by running:
```bash theme={null}
injectived q bank balances $ORCHESTRATOR_INJ_ADDRESS
```
### **Managing Cosmos account keys for `peggo`**
Peggo supports two options to provide Cosmos signing key credentials - using the Cosmos keyring (recommended), or by providing a plaintext private key.
#### **Option 1. Cosmos Keyring**
In the `.env` file, first specify the `PEGGO_COSMOS_FROM` and `PEGGO_COSMOS_FROM_PASSPHRASE` corresponding to your peggo account signing key.
If you are using a delegated account key configuration as recommended above, this will be your `$ORCHESTRATOR_KEY_NAME` and passphrase, respectively. Otherwise, this should be your `$VALIDATOR_KEY_NAME` and associated validator passphrase.
Please note that the default keyring backend is `file` and that, as such, peggo will try to locate keys on disk by default.
To use the default injectived key configuration, you should set the keyring path to the home directory of your injectived node, e.g. `~/.injectived`.
You can also read more about the Cosmos Keyring setup [here](https://docs.cosmos.network/v0.46/run-node/keyring.html).
#### **Option 2. Cosmos Private Key (Unsafe)**
In the `.env` file, specify the `PEGGO_COSMOS_PK` corresponding to your peggo account signing key.
If you are using a delegated account key configuration as recommended above, this will be your orchestrator account's private key. Otherwise, this should be your validator's account private key.
To obtain your orchestrator's Cosmos private key (if applicable), run:
```bash theme={null}
injectived keys unsafe-export-eth-key $ORCHESTRATOR_KEY_NAME
```
To obtain your validator's Cosmos private key (if applicable), run:
```bash theme={null}
injectived keys unsafe-export-eth-key $VALIDATOR_KEY_NAME
```
Again, this method is less secure and is not recommended.
### **Managing Ethereum keys for `peggo`**
Peggo supports two options to provide signing key credentials - using the Geth keystore (recommended), or by providing a plaintext Ethereum private key.
#### **Option 1. Geth Keystore**
Simply create a new private key store and update the following env variables:
* `PEGGO_ETH_KEYSTORE_DIR`
* `PEGGO_ETH_FROM`
* `PEGGO_ETH_PASSPHRASE`
You can find instructions for securely creating a new Ethereum account using a keystore in the Geth Documentation [here](https://geth.ethereum.org/docs/interface/managing-your-accounts).
For convience, an example is provided below.
```bash theme={null}
geth account new --datadir=/home/ec2-user/.peggo/data/
INFO [03-23|18:18:36.407] Maximum peer count ETH=50 LES=0 total=50
Your new account is locked with a password. Please give a password. Do not forget this password.
Password:
Repeat password:
Your new key was generated
Public address of the key: 0x9782dc957DaE6aDc394294954B27e2118D05176C
Path of the secret key file: /home/ec2-user/.peggo/data/keystore/UTC--2021-03-23T15-18-44.284118000Z--9782dc957dae6adc394294954b27e2118d05176c
- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!
```
Make sure you heed the warnings that geth provides, particularly in backing up your key file so that you don't lose your keys by mistake. We also recommend not using any quote or backtick characters in your passphrase for peggo compatibility purposes.
You should now set the following env variables:
```bash theme={null}
# example values, replace with your own
PEGGO_ETH_KEYSTORE_DIR=/home/ec2-user/.peggo/data/keystore
PEGGO_ETH_FROM=0x9782dc957DaE6aDc394294954B27e2118D05176C
PEGGO_ETH_PASSPHRASE=12345678
```
Then, ensure that your Ethereum address has enough ETH.
#### **Option 2. Ethereum Private Key (Unsafe)**
Simply update the `PEGGO_ETH_PK` with a new Ethereum Private Key from a new account.
Then, ensure that your Ethereum address has ETH.
## Step 2: Register Your Orchestrator and Ethereum Address
You can register orchestrator and ethereum address only once. It **CANNOT** be updated later. So Check twice before running below command.
```bash theme={null}
injectived tx peggy set-orchestrator-address $VALIDATOR_INJ_ADDRESS $ORCHESTRATOR_INJ_ADDRESS $ETHEREUM_ADDRESS --from $VALIDATOR_KEY_NAME --chain-id=injective-888 --keyring-backend=file --yes --node=tcp://localhost:26657 --gas-prices=500000000inj
```
* To obtain your validator's inj address, run, `injectived keys list $VALIDATOR_KEY_NAME`
* To obtain your orchestrators's inj address, `injectived keys list $ORCHESTRATOR_KEY_NAME`
Example:
```bash theme={null}
injectived tx peggy set-orchestrator-address inj10m247khat0esnl0x66vu9mhlanfftnvww67j9n inj1x7kvxlz2epqx3hpq6v8j8w859t29pgca4z92l2 0xf79D16a79130a07e77eE36e8067AeA783aBdA3b6 --from validator-key-name --chain-id=injective-888 --keyring-backend=file --yes --node=tcp://localhost:26657 --gas-prices=500000000inj
```
You can verify successful registration by checking for your Validator's mapped Ethereum address on [https://testnet.lcd.injective.dev/peggy/v1/valset/current](https://testnet.lcd.injective.dev/peggy/v1/valset/current).
## Step 3: Start the Relayer
```bash theme={null}
cd ~/.peggo
peggo orchestrator
```
This starts the Peggo bridge (relayer / orchestrator).
## Step 4: Create a Peggo systemd service
Add `peggo.service` file with below content under `/etc/systemd/system/peggo.service`
```ini theme={null}
[Unit]
Description=peggo
[Service]
WorkingDirectory=/home/ec2-user/.peggo
ExecStart=/bin/bash -c 'peggo orchestrator '
Type=simple
Restart=always
RestartSec=1
User=ec2-user
[Install]
WantedBy=multi-user.target
```
Then, run the following commands to configure Environment variables, start and stop the peggo relayer:
```bash theme={null}
sudo systemctl start peggo
sudo systemctl stop peggo
sudo systemctl restart peggo
sudo systemctl status peggo
# enable start on system boot
sudo systemctl enable peggo
# To check Logs
journalctl -f -u peggo
```
## Step 5: (Optional) Protect Cosmos Keyring from unauthorized access
This is an advanced DevOps topic, consult with your sysadmin.
Learn more about Cosmos Keyring setup [here](https://docs.cosmos.network/v0.46/run-node/keyring.html). Once you've launched your node, the default keyring will have the validator operator key stored on disk in the encrypted form. Usually, the keyring is located within node's homedir, i.e. `~/.injectived/keyring-file`.
Some sections of the Injective Staking documentation will guide you through using this key for governance purposes, i.e., submitting transactions and setting up an Ethereum bridge. In order to protect the keys from unauthorized access, even when the keyring passphrase is leaked via configs, you can set OS permissions to allow disk access to `injectived` / `peggo` processes only.
In Linux systems like Debian, Ubuntu and RHEL, this can be achieved using POSIX Access Control Lists (ACLs). Before beginning to work with ACLs, the file system must be mounted with ACLs turned on. There are some official guides for each distro:
* [Ubuntu](https://help.ubuntu.com/community/FilePermissionsACLs)
* [Debian](https://wiki.debian.org/Permissions)
* [Amazon Linux (RHEL)](https://www.redhat.com/sysadmin/linux-access-control-lists)
## Contribute
If you'd like to inspect the Peggo orchestrator source code and contribute, you can do so at [https://github.com/InjectiveLabs/peggo](https://github.com/InjectiveLabs/peggo)
# Indexer API Reference
Source: https://docs.injective.network/redirects/https_api_injective_network_swagger
# Indexer Service Setup Guide
Source: https://docs.injective.network/redirects/https_injective_notion_site_indexer_service_setup_guide
# EVM Testnet Explorer
Source: https://docs.injective.network/redirects/https_testnet_blockscout_injective_network_blocks
# EVM Testnet Faucet
Source: https://docs.injective.network/redirects/https_testnet_faucet_injective_network
# Auction
Source: https://docs.injective.network/developers-native/examples/auction
The `auction` module is heart of the `buy-back-and-burn` on chain mechanism, where 60% of the weekly trading fees are collected and auctioned off to the highest INJ bidder where the submitted INJ of the highest bidder are burned in the process.
## MsgBid
This message is used to submit a bid on the [auction](https://hub.injective.network/auction/) held weekly to allow members to use INJ to bid for the basket of trading fees (60%) collected by Injective that week.
```ts theme={null}
import { ChainId } from '@injectivelabs/ts-types'
import { toChainFormat } from '@injectivelabs/utils'
import { MsgBid } from '@injectivelabs/sdk-ts/core/modules'
import { MsgBroadcasterWithPk } from '@injectivelabs/sdk-ts/core/tx'
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { ChainGrpcAuctionApi } from '@injectivelabs/sdk-ts/client/chain'
const endpointsForNetwork = getNetworkEndpoints(Network.Mainnet)
const auctionApi = new ChainGrpcAuctionApi(endpointsForNetwork.grpc)
const injectiveAddress = 'inj1...'
/* format amount for bid, note that bid amount has to be higher than the current highest bid */
const amount = {
denom: 'inj',
amount: toChainFormat(1).toFixed(),
}
const latestAuctionModuleState = await auctionApi.fetchModuleState()
const latestRound = latestAuctionModuleState.auctionRound
/* create message in proto format */
const msg = MsgBid.fromJSON({
amount,
injectiveAddress,
round: latestRound,
})
const privateKey = '0x...'
/* broadcast transaction */
const txHash = await new MsgBroadcasterWithPk({
network: Network.Mainnet,
privateKey,
}).broadcast({
msgs: msg,
})
console.log(txHash)
```
## Burn Auction Deposit via MsgExternalTransfer
If you would like to grow the burn auction's pool size, you can directly send funds to the Auction subaccount.
Notes:
* You will need to send funds to the pool's subaccount `0x1111111111111111111111111111111111111111111111111111111111111111`.
* Be aware that any funds you send will be reflected in the next auction, not the current one.
* You cannot transfer from your default subaccountId since that balance is now associated with your Injective address in the bank module. Therefore, in order for `MsgExternalTransfer` to work, you will need to transfer from a non-default subaccountId.
How to find the subaccountId that you will be transferring from:
* you can query your existing subaccountIds via the [account portfolio api](../query-indexer/portfolio/).
How to use funds that are currently associated with your Injective Address in bank module:
* If you have existing non-default subaccounts, you'll want to do a[ MsgDeposit ](/developers-native/examples/exchange#msgdeposit)to one of your existing non-default subaccountIds and use that subaccountId as the `srcSubaccountId` below.
* If you don't have existing non-default subaccounts, you can do a [MsgDeposit](/developers-native/examples/exchange#msgdeposit) to a new default subaccountId, which would be done via importing `getSubaccountId` from `sdk-ts` and setting the `subaccountId` field in [MsgDeposit](/developers-native/examples/exchange#msgdeposit) to `getSubaccountId(injectiveAddress, 1)`.
For more info, check out the [burn auction pool docs](https://docs.injective.network/developers/modules/injective/auction).
```ts theme={null}
import { Network } from '@injectivelabs/networks'
import { toChainFormat } from '@injectivelabs/utils'
import { MsgBroadcasterWithPk } from '@injectivelabs/sdk-ts/core/tx'
import { MsgExternalTransfer } from '@injectivelabs/sdk-ts/core/modules'
const injectiveAddress = 'inj1...'
const srcSubaccountId = '0x...'
const POOL_SUBACCOUNT_ID = `0x1111111111111111111111111111111111111111111111111111111111111111`
// USDT Peggy token details
const USDT_DENOM = 'peggy0xdAC17F958D2ee523a2206206994597C13D831ec7'
const USDT_DECIMALS = 6
/* format amount to add to the burn auction pool */
const amount = {
denom: USDT_DENOM,
amount: toChainFormat(1, USDT_DECIMALS).toFixed(),
}
/* create message in proto format */
const msg = MsgExternalTransfer.fromJSON({
amount,
srcSubaccountId,
injectiveAddress,
dstSubaccountId: POOL_SUBACCOUNT_ID,
})
const privateKey = '0x...'
/* broadcast transaction */
const txHash = await new MsgBroadcasterWithPk({
network: Network.Mainnet,
privateKey,
}).broadcast({
msgs: msg,
})
console.log(txHash)
```
# AuthZ
Source: https://docs.injective.network/developers-native/examples/authz
The `authz` module is an implementation of a Cosmos SDK module, per ADR 30, that allows granting arbitrary privileges from one account (the granter) to another account (the grantee).
## Messages
### MsgGrant
An authorization grant is created using the MsgGrant message. If there is already a grant for the (granter, grantee, Authorization) triple, then the new grant will overwrite the previous one. To update or extend an existing grant, a new grant with the same (granter, grantee, Authorization) triple should be created.
List of useful message types:
```
"/injective.exchange.v1beta1.MsgCreateSpotLimitOrder",
"/injective.exchange.v1beta1.MsgCreateSpotMarketOrder",
"/injective.exchange.v1beta1.MsgCancelSpotOrder",
"/injective.exchange.v1beta1.MsgBatchUpdateOrders",
"/injective.exchange.v1beta1.MsgBatchCancelSpotOrders",
"/injective.exchange.v1beta1.MsgDeposit",
"/injective.exchange.v1beta1.MsgWithdraw",
"/injective.exchange.v1beta1.MsgCreateDerivativeLimitOrder",
"/injective.exchange.v1beta1.MsgCreateDerivativeMarketOrder",
"/injective.exchange.v1beta1.MsgCancelDerivativeOrder",
"/injective.exchange.v1beta1.MsgBatchUpdateOrders",
"/injective.exchange.v1beta1.MsgBatchCancelDerivativeOrders",
"/injective.exchange.v1beta1.MsgDeposit",
"/injective.exchange.v1beta1.MsgWithdraw",
```
Per [cosmos sdk docs](https://docs.cosmos.network/main/modules/authz), "Authorizations must be granted for a particular Msg service method one by one", so the following code snippet must be repeated for each message type that you would like for the `grantee` to have authorization on behalf of a `granter`.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgGrant } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const privateKeyOfGranter = "0x...";
const grantee = "inj...";
const granter = "inj...";
const messageType =
"/injective.exchange.v1beta1.MsgCreateSpotLimitOrder"; /* example message type */
const msg = MsgGrant.fromJSON({
messageType,
grantee,
granter,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey: privateKeyOfGranter,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgExec
When a grantee wants to execute a transaction on behalf of a granter, they must send MsgExec. In this example, we'll do a MsgSend to transfer assets from the granter's account address to another account address.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgExec, MsgSend } from "@injectivelabs/sdk-ts/core/modules";
const privateKeyOfGrantee = "0x...";
const grantee = "inj...";
const granter = "inj...";
const msgs = MsgSend.fromJSON({
amount: {
denom: "inj",
amount: toChainFormat(0.01).toFixed(),
},
srcInjectiveAddress: granter,
dstInjectiveAddress: "inj1...",
});
const msg = MsgExec.fromJSON({
msgs,
grantee,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey: privateKeyOfGrantee,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgRevoke
A grant can be removed with the MsgRevoke message.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgRevoke } from "@injectivelabs/sdk-ts/core/modules";
import { getEthereumAddress } from "@injectivelabs/sdk-ts/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const privateKeyOfGranter = "0x...";
const grantee = "inj...";
const granter = "inj...";
const messageType =
"/injective.exchange.v1beta1.MsgCreateSpotLimitOrder"; /* example message type */
const msg = MsgRevoke.fromJSON({
messageType,
grantee,
granter,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey: privateKeyOfGranter,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Bank
Source: https://docs.injective.network/developers-native/examples/bank
The bank module is responsible for handling multi-asset coin transfers between accounts and tracking special-case pseudo-transfers which must work differently with particular kinds of accounts (notably delegating/undelegating for vesting accounts). It exposes several interfaces with varying capabilities for secure interaction with other modules which must alter user balances.
In addition, the bank module tracks and provides query support for the total supply of all assets used in the application.
## Messages
Let's explore (and provide examples) the messages that the Bank module exports and we can use to interact with the Injective chain.
### MsgSend
This message is used to send coins from one address to another. Any TokenFactory token and Peggy token can be used here.
To transfer CW20 tokens, see the `MsgExecuteContract` section in [wasm module examples](/developers-native/examples/wasm.md#msgexecutecontract-transfer).
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgSend } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const amount = {
denom: "inj",
amount: toChainFormat(1).toFixed(),
};
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgMultiSend
This message is used to send to multiple recipients from multiple senders.
```typescript theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgMultiSend } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const denom = "inj";
const decimals = 18;
const records = [
/** add records here */
] as {
address: string;
amount: string /* in a human readable number */;
}[];
const totalToSend = records.reduce((acc, record) => {
return acc.plus(toChainFormat(record.amount, decimals));
}, toChainFormat(0));
const msg = MsgMultiSend.fromJSON({
inputs: [
{
address: injectiveAddress,
coins: [
{
denom,
amount: totalToSend.toFixed(),
},
],
},
],
outputs: records.map((record) => {
return {
address: record.address,
coins: [
{
amount: toChainFormat(record.amount, decimals).toFixed(),
denom,
},
],
};
}),
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Distribution
Source: https://docs.injective.network/developers-native/examples/distribution
The `distribution` module is extended from the cosmos sdk [distribution module](https://github.com/InjectiveLabs/cosmos-sdk/tree/master/x/distribution), where delegator can withdraw their staking rewards from the validator.
Distribution -> MsgWithdrawValidatorCommission
## MsgWithdrawDelegatorReward
This message is used to withdraw all available delegator staking rewards from the validator.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgWithdrawDelegatorReward } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const validatorAddress = "inj1...";
/* create message in proto format */
const msg = MsgWithdrawDelegatorReward.fromJSON({
validatorAddress,
delegatorAddress: injectiveAddress,
});
const privateKey = "0x...";
/* broadcast transaction */
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Mainnet
}).broadcast({
msgs: msg
});
console.log(txHash);
```
## MsgWithdrawValidatorCommission
This message is used by the validator to withdraw the commission earned.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgWithdrawValidatorCommission } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const validatorAddress = "inj1...";
/* create message in proto format */
const msg = MsgWithdrawValidatorCommission.fromJSON({
validatorAddress,
});
const privateKey = "0x...";
/* broadcast transaction */
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet
}).broadcast({
msgs: msg
});
console.log(txHash);
```
# Exchange
Source: https://docs.injective.network/developers-native/examples/exchange
The `exchange` module is the heart of the Injective Chain which enables fully decentralized spot and derivative exchange.
It is the sine qua non module of the chain and integrates tightly with the `auction`, `insurance`, `oracle`, and `peggy` modules.
The exchange protocol enables traders to create and trade on arbitrary spot and derivative markets.
The entire process of orderbook management, trade execution, order matching and settlement occurs on chain through the logic codified by the exchange module.
## Messages
Let's explore (and provide examples) the Messages that the Exchange module exports and we can use to interact with the Injective chain.
### MsgDeposit
This Message is used to send coins from the Bank module to a wallet's subaccount
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgDeposit } from "@injectivelabs/sdk-ts/core/modules";
import { getEthereumAddress } from "@injectivelabs/sdk-ts/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const amount = {
denom: "inj",
amount: toChainFormat(1).toFixed(),
};
const ethereumAddress = getEthereumAddress(injectiveAddress);
const subaccountIndex = 0;
const suffix = "0".repeat(23) + subaccountIndex;
const subaccountId = ethereumAddress + suffix;
const msg = MsgDeposit.fromJSON({
amount,
subaccountId,
injectiveAddress,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgWithdraw
This Message is used to send coins from the wallet's subaccount back to the users Bank funds
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgWithdraw } from "@injectivelabs/sdk-ts/core/modules";
import { getEthereumAddress } from "@injectivelabs/sdk-ts/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const amount = {
denom: "inj",
amount: toChainFormat(1).toFixed(),
};
const ethereumAddress = getEthereumAddress(injectiveAddress);
const subaccountIndex = 0;
const suffix = "0".repeat(23) + subaccountIndex;
const subaccountId = ethereumAddress + suffix;
const msg = MsgWithdraw.fromJSON({
amount,
subaccountId,
injectiveAddress,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgCreateSpotLimitOrder
This Message is used to create a spot limit order
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgCreateSpotLimitOrder } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import {
getEthereumAddress,
getSpotMarketTensMultiplier,
spotPriceToChainPriceToFixed,
spotQuantityToChainQuantityToFixed,
} from "@injectivelabs/sdk-ts/utils";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const feeRecipient = "inj1...";
const market = {
marketId: "0x...",
baseDecimals: 18,
quoteDecimals: 6,
minPriceTickSize: "" /* fetched from the chain */,
minQuantityTickSize: "" /* fetched from the chain */,
priceTensMultiplier:
"" /** can be fetched from getSpotMarketTensMultiplier */,
quantityTensMultiplier:
"" /** can be fetched from getSpotMarketTensMultiplier */,
};
const order = {
price: 1,
quantity: 1,
};
const ethereumAddress = getEthereumAddress(injectiveAddress);
const subaccountIndex = 0;
const suffix = "0".repeat(23) + subaccountIndex;
const subaccountId = ethereumAddress + suffix;
const msg = MsgCreateSpotLimitOrder.fromJSON({
subaccountId,
injectiveAddress,
orderType: 1 /* Buy */,
price: spotPriceToChainPriceToFixed({
value: order.price,
tensMultiplier: market.priceTensMultiplier,
baseDecimals: market.baseDecimals,
quoteDecimals: market.quoteDecimals,
}),
quantity: spotQuantityToChainQuantityToFixed({
value: order.quantity,
tensMultiplier: market.quantityTensMultiplier,
baseDecimals: market.baseDecimals,
}),
marketId: market.marketId,
feeRecipient: feeRecipient,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgCreateSpotMarketOrder
This Message is used to create a spot market order
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgCreateSpotMarketOrder } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import {
getEthereumAddress,
getSpotMarketTensMultiplier,
spotPriceToChainPriceToFixed,
spotQuantityToChainQuantityToFixed,
} from "@injectivelabs/sdk-ts/utils";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const feeRecipient = "inj1...";
const market = {
marketId: "0x...",
baseDecimals: 18,
quoteDecimals: 6,
minPriceTickSize: "" /* fetched from the chain */,
minQuantityTickSize: "" /* fetched from the chain */,
priceTensMultiplier:
"" /** can be fetched from getSpotMarketTensMultiplier */,
quantityTensMultiplier:
"" /** can be fetched from getSpotMarketTensMultiplier */,
};
const order = {
price: 10,
quantity: 1,
};
const ethereumAddress = getEthereumAddress(injectiveAddress);
const subaccountIndex = 0;
const suffix = "0".repeat(23) + subaccountIndex;
const subaccountId = ethereumAddress + suffix;
const msg = MsgCreateSpotMarketOrder.fromJSON({
subaccountId,
injectiveAddress,
orderType: 1 /* Buy */,
price: spotPriceToChainPriceToFixed({
value: order.price,
tensMultiplier: market.priceTensMultiplier,
baseDecimals: market.baseDecimals,
quoteDecimals: market.quoteDecimals,
}),
quantity: spotQuantityToChainQuantityToFixed({
value: order.quantity,
tensMultiplier: market.quantityTensMultiplier,
baseDecimals: market.baseDecimals,
}),
marketId: market.marketId,
feeRecipient: feeRecipient,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgCreateDerivativeLimitOrder
This Message is used to create a derivative limit order
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgCreateDerivativeLimitOrder } from "@injectivelabs/sdk-ts/core/modules";
import {
getEthereumAddress,
getDerivativeMarketTensMultiplier,
derivativePriceToChainPriceToFixed,
derivativeQuantityToChainQuantityToFixed,
derivativeMarginToChainMarginToFixed,
} from "@injectivelabs/sdk-ts/utils";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const feeRecipient = "inj1...";
const market = {
marketId: "0x...",
baseDecimals: 18,
quoteDecimals: 6,
minPriceTickSize: "" /* fetched from the chain */,
minQuantityTickSize: "" /* fetched from the chain */,
priceTensMultiplier:
"" /** can be fetched from getDerivativeMarketTensMultiplier */,
quantityTensMultiplier:
"" /** can be fetched from getDerivativeMarketTensMultiplier */,
};
const order = {
price: 10,
quantity: 1,
margin: 10,
};
const ethereumAddress = getEthereumAddress(injectiveAddress);
const subaccountIndex = 0;
const suffix = "0".repeat(23) + subaccountIndex;
const subaccountId = ethereumAddress + suffix;
const msg = MsgCreateDerivativeLimitOrder.fromJSON({
orderType: 1 /* Buy */,
triggerPrice: "0",
injectiveAddress,
price: derivativePriceToChainPriceToFixed({
value: order.price,
quoteDecimals: market.quoteDecimals,
}),
quantity: derivativeQuantityToChainQuantityToFixed({ value: order.quantity }),
margin: derivativeMarginToChainMarginToFixed({
value: order.margin,
quoteDecimals: market.quoteDecimals,
}),
marketId: market.marketId,
feeRecipient: feeRecipient,
subaccountId: subaccountId,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgCreateDerivativeMarketOrder
This Message is used to create a derivative market order
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgCreateDerivativeMarketOrder } from "@injectivelabs/sdk-ts/core/modules";
import {
getEthereumAddress,
getDerivativeMarketTensMultiplier,
derivativePriceToChainPriceToFixed,
derivativeQuantityToChainQuantityToFixed,
derivativeMarginToChainMarginToFixed,
} from "@injectivelabs/sdk-ts/utils";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const feeRecipient = "inj1...";
const market = {
marketId: "0x...",
baseDecimals: 18,
quoteDecimals: 6,
minPriceTickSize: "" /* fetched from the chain */,
minQuantityTickSize: "" /* fetched from the chain */,
priceTensMultiplier:
"" /** can be fetched from getDerivativeMarketTensMultiplier */,
quantityTensMultiplier:
"" /** can be fetched from getDerivativeMarketTensMultiplier */,
};
const order = {
price: 10,
quantity: 1,
margin: 10,
};
const ethereumAddress = getEthereumAddress(injectiveAddress);
const subaccountIndex = 0;
const suffix = "0".repeat(23) + subaccountIndex;
const subaccountId = ethereumAddress + suffix;
const msg = MsgCreateDerivativeMarketOrder.fromJSON({
orderType: 1 /* Buy */,
triggerPrice: "0",
injectiveAddress,
price: derivativePriceToChainPriceToFixed({
value: order.price,
tensMultiplier: market.priceTensMultiplier,
quoteDecimals: market.quoteDecimals,
}),
quantity: derivativeQuantityToChainQuantityToFixed({
value: order.quantity,
tensMultiplier: market.quantityTensMultiplier,
}),
margin: derivativeMarginToChainMarginToFixed({
value: order.margin,
quoteDecimals: market.quoteDecimals,
tensMultiplier: market.priceTensMultiplier,
}),
marketId: market.marketId,
feeRecipient: feeRecipient,
subaccountId: subaccountId,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgBatchUpdateOrders
This Message is used to batch update orders on the chain
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { OrderSide } from "@injectivelabs/sdk-ts/types";
import { MsgBatchUpdateOrders } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { GrpcOrderType } from "@injectivelabs/sdk-ts/client/chain";
import {
getEthereumAddress,
getDerivativeMarketTensMultiplier,
derivativePriceToChainPriceToFixed,
derivativeQuantityToChainQuantityToFixed,
derivativeMarginToChainMarginToFixed,
spotPriceToChainPriceToFixed,
spotQuantityToChainQuantityToFixed,
} from "@injectivelabs/sdk-ts/utils";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const feeRecipient = "inj1...";
const derivativeMarket = {
marketId: "0x...",
baseDecimals: 18,
quoteDecimals: 6,
minPriceTickSize: "" /* fetched from the chain */,
minQuantityTickSize: "" /* fetched from the chain */,
priceTensMultiplier:
"" /** can be fetched from getDerivativeMarketTensMultiplier */,
quantityTensMultiplier:
"" /** can be fetched from getDerivativeMarketTensMultiplier */,
};
const derivativeOrder = {
price: 10,
quantity: 1,
margin: 10,
orderType: OrderSide.Buy,
};
const spotMarket = {
marketId: "0x...",
baseDecimals: 18,
quoteDecimals: 6,
minPriceTickSize: "" /* fetched from the chain */,
minQuantityTickSize: "" /* fetched from the chain */,
priceTensMultiplier:
"" /** can be fetched from getSpotMarketTensMultiplier */,
quantityTensMultiplier:
"" /** can be fetched from getSpotMarketTensMultiplier */,
};
const spotOrder = {
price: 10,
quantity: 1,
margin: 10,
orderType: OrderSide.Buy,
};
const ethereumAddress = getEthereumAddress(injectiveAddress);
const subaccountIndex = 0;
const suffix = "0".repeat(23) + subaccountIndex;
const subaccountId = ethereumAddress + suffix;
const msg = MsgBatchUpdateOrders.fromJSON({
injectiveAddress,
subaccountId: subaccountId,
derivativeOrdersToCreate: [
{
orderType: derivativeOrder.orderType as GrpcOrderType,
price: derivativePriceToChainPriceToFixed({
value: derivativeOrder.price,
quoteDecimals: 6 /* USDT has 6 decimals */,
}),
quantity: derivativeQuantityToChainQuantityToFixed({
value: derivativeOrder.quantity,
}),
margin: derivativeMarginToChainMarginToFixed({
value: derivativeOrder.margin,
quoteDecimals: 6 /* USDT has 6 decimals */,
}),
marketId: derivativeMarket.marketId,
feeRecipient: injectiveAddress,
},
],
spotOrdersToCreate: [
{
orderType: spotOrder.orderType as GrpcOrderType,
price: spotPriceToChainPriceToFixed({
value: spotOrder.price,
baseDecimals: 18 /* INJ has 18 decimals */,
quoteDecimals: 6 /* USDT has 6 decimals */,
}),
quantity: spotQuantityToChainQuantityToFixed({
value: spotOrder.quantity,
baseDecimals: 18 /* INJ has 18 decimals */,
}),
marketId: spotMarket.marketId,
feeRecipient: injectiveAddress,
},
],
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgBatchCancelSpotOrders
This Message is used to batch cancel spot orders on the chain
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgBatchCancelSpotOrders } from "@injectivelabs/sdk-ts/core/modules";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const orders = [
{
marketId: "0x...",
subaccountId: "0x...",
orderHash: "0x...",
},
{
marketId: "0x...",
subaccountId: "0x...",
orderHash: "0x...",
},
];
const messages = orders.map((order) =>
MsgBatchCancelSpotOrders.fromJSON({
injectiveAddress,
orders: [
{
marketId: order.marketId,
subaccountId: order.subaccountId,
orderHash: order.orderHash,
},
],
})
);
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: messages,
});
console.log(txHash);
```
This Message is used to batch cancel spot orders on the chain
### MsgBatchCancelDerivativeOrders
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgBatchCancelDerivativeOrders } from "@injectivelabs/sdk-ts/core/modules";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const orders = [
{
marketId: "0x...",
subaccountId: "0x...",
orderHash: "0x...",
},
{
marketId: "0x...",
subaccountId: "0x...",
orderHash: "0x...",
},
];
const messages = orders.map((order) =>
MsgBatchCancelDerivativeOrders.fromJSON({
injectiveAddress,
orders: [
{
marketId: order.marketId,
subaccountId: order.subaccountId,
orderHash: order.orderHash,
},
],
})
);
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: messages,
});
console.log(txHash);
```
### MsgRewardsOptOut
This Message is used to opt out of the Trade & Earn program.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgRewardsOptOut } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const privateKey = "0x...";
const injectiveAddress = "inj...";
const msg = MsgRewardsOptOut.fromJSON({ sender: injectiveAddress });
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgExternalTransfer
This message is used to transfer balance from one subaccount to another subaccount.
Note:
* You cannot transfer from your default subaccountId since that balance is now associated with your Injective address in the bank module. Therefore, in order for `MsgExternalTransfer` to work, you will need to transfer from a non-default subaccountId.
How to find the subaccountId that you will be transferring from:
* you can query your existing subaccountIds via the [account portfolio api](../query-indexer/portfolio).
How to use funds that are currently associated with your Injective Address in bank module:
* If you have existing non-default subaccounts, you'll want to do a [MsgDeposit](/developers-native/examples/exchange#msgdeposit) to one of your existing non-default subaccountIds and use that subaccountId as the `srcSubaccountId` below.
* If you don't have existing non-default subaccounts, you can do a [MsgDeposit](/developers-native/examples/exchange#msgdeposit) to a new default subaccountId, which would be done via importing `getSubaccountId` from `sdk-ts` and setting the `subaccountId` field in [MsgDeposit](/developers-native/examples/exchange#msgdeposit) to `getSubaccountId(injectiveAddress, 1)`.
```ts theme={null}
import { toChainFormat } from "@injectivelabs/utils";
import { Network } from "@injectivelabs/networks";
import { MsgExternalTransfer } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const injectiveAddress = "inj...";
const srcSubaccountId = "0x...";
const dstSubaccountId = `0x...`;
// INJ token details
const INJ_DENOM = "inj";
const INJ_DECIMALS = 18;
/* format amount to add to the burn auction pool */
const amount = {
denom: INJ_DENOM,
amount: toChainFormat(1, INJ_DECIMALS).toFixed(),
};
/* create message in proto format */
const msg = MsgExternalTransfer.fromJSON({
amount,
dstSubaccountId,
srcSubaccountId,
injectiveAddress,
});
const privateKey = "0x...";
/* broadcast transaction */
const txHash = await new MsgBroadcasterWithPk({
network: Network.Testnet,
privateKey,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Fee Grant
Source: https://docs.injective.network/developers-native/examples/feegrant
The `feegrant` module allows accounts (granters) to grant fee allowances to other accounts (grantees). This allows the grantee to use the granter's funds to pay for transaction fees.
## Messages
### MsgGrantAllowance
A fee allowance grant is created using the `MsgGrantAllowance` message. If there is already a grant for the (granter, grantee) pair, then the new grant will overwrite the previous one.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgGrantAllowance } from "@injectivelabs/sdk-ts/core/modules";
const privateKeyOfGranter = "0x...";
const date = new Date("2023-10-02T00:00:00Z");
const expiration = date.getTime() / 1000;
const granter = "inj...";
const grantee = "inj...";
const allowance = {
spendLimit: [
{
denom: "inj",
amount: "10000",
},
],
expiration,
};
const msg = MsgGrantAllowance.fromJSON({
granter,
grantee,
allowance,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey: privateKeyOfGranter,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgRevokeAllowance
A grant can be removed using the MsgRevokeAllowance message. The grantee will no longer be able to use the granter's funds to pay for transaction fees.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgRevokeAllowance } from "@injectivelabs/sdk-ts/core/modules";
const privateKey = "0x...";
const granteeAddress = "inj...";
const granterAddress = "inj...";
const params = {
grantee: granteeAddress,
granter: granterAddress,
};
const msg = MsgRevokeAllowance.fromJSON(params);
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Governance
Source: https://docs.injective.network/developers-native/examples/governance
Injective is a community-run blockchain and users who have staked INJ are able to participate in governance as it relates to the blockchain. Proposals can be submitted to make revisions to Injective programs, tech upgrades, or any other Injective related changes that impact the entire Injective ecosystem.
For every proposal you create, we require you to deposit at least 1 INJ. This is to ensure that you are an active participant of the Injective community and you are eligible to make proposals and govern the protocol moving forward. For the proposal to pass to the voting stage, it must have 500 INJ deposited. You can deposit the 500 INJ yourself or collaborate with the community to deposit them collectively.
## Messages
Let's explore (and provide examples) the messages that the Governance module exports and we can use to interact with the Injective chain. For example, you can use these messages to propose new spot, perpetual, or futures markets.
### MsgGovDeposit
This message can be used to deposit towards an existing proposal.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgGovDeposit } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const denom = "inj";
const proposalId = 12345;
const privateKey = "0x...";
const injectiveAddress = "inj...";
const amount = toChainFormat(1).toFixed();
const message = MsgGovDeposit.fromJSON({
amount: {
denom,
amount,
},
proposalId,
depositor: injectiveAddress,
});
/* broadcast transaction */
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: message,
});
```
### MsgVote
After the proposal is properly funded, voting can commence. You can vote "Yes", "No", "Abstain", or "No with Veto".
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { VoteOption } from "@injectivelabs/sdk-ts/types";
import { MsgVote } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const proposalId = 12345;
const privateKey = "0x...";
const injectiveAddress = "inj...";
const vote = VoteOption.VOTE_OPTION_YES;
const message = MsgVote.fromJSON({
vote,
proposalId,
voter: injectiveAddress,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: message,
});
```
### MsgSubmitTextProposal
Propose any action on Injective. TextProposal defines a standard text proposal whose changes need to be manually updated in case of approval.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgSubmitTextProposal } from "@injectivelabs/sdk-ts/core/modules";
const denom = "inj";
const privateKey = "0x...";
const injectiveAddress = "inj...";
const amount = toChainFormat(1).toFixed();
const message = MsgSubmitTextProposal.fromJSON({
title: "Title of Proposal",
description: "Description of Proposal",
proposer: injectiveAddress,
deposit: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: message,
});
```
### MsgSubmitProposalSpotMarketLaunch
This message allows you to propose a new spot market. Ensure that the ticker is accurate and provide the base asset denom followed by the quote asset denom. Base denom refers to the asset you would like to trade and quote denom refers to the asset by which your base asset is denominated. For instance, in the INJ/USDT market you would buy or sell INJ using USDT.
```ts theme={null}
import { TokenStaticFactory } from "@injectivelabs/sdk-ts/service";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { toChainFormat, toHumanReadable } from "@injectivelabs/utils";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { MsgSubmitProposalSpotMarketLaunch } from "@injectivelabs/sdk-ts/core/modules";
// refer to https://github.com/InjectiveLabs/injective-lists
import { tokens } from "../data/tokens.json";
const tokenStaticFactory = new TokenStaticFactory(tokens as TokenStatic[]);
const denom = "inj";
const privateKey = "0x...";
const injectiveAddress = "inj...";
const amount = toChainFormat(1).toFixed();
const market = {
baseDenom: "inj", // for example
quoteDenom: "peggy0x...",
makerFeeRate: "0.001",
takerFeeRate: "0.002",
title: "INJ/USDT Spot Market Launch",
description:
"This proposal will launch the INJ/USDT Spot Market with maker and taker fees 0.001% and 0.002% respectively",
ticker: "INJ/USDT",
minPriceTickSize: "0.001",
minQuantityTickSize: "0.001",
};
const baseDenom = tokenStaticFactory.toToken(market.baseDenom);
const quoteDenom = tokenStaticFactory.toToken(market.quoteDenom);
const marketWithDecimals: SpotMarketLaunchProposal = {
...market,
baseTokenDecimals: baseDenom ? baseDenom.decimals : 18,
quoteTokenDecimals: quoteDenom ? quoteDenom.decimals : 6,
};
const marketWithTickSizes = {
...market,
minPriceTickSize: toHumanReadable(
marketWithDecimals.minPriceTickSize,
marketWithDecimals.baseTokenDecimals - marketWithDecimals.quoteTokenDecimals
).toFixed(),
minQuantityTickSize: toChainFormat(
marketWithDecimals.minQuantityTickSize,
marketWithDecimals.baseTokenDecimals
).toFixed(),
};
const message = MsgSubmitProposalSpotMarketLaunch.fromJSON({
market: marketWithTickSizes,
proposer: injectiveAddress,
deposit: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: message,
});
```
### MsgSubmitProposalPerpetualMarketLaunch
This message allows you to propose a new perpetual market. perpetual futures contracts, or perps, are derivative futures contracts that allow users to buy or sell the value of an underlying base asset without actually owning it. This is the message you can use to create a perp market for a specified token pair.
```ts theme={null}
import {
TokenStaticFactory,
MsgBroadcasterWithPk,
MsgSubmitProposalPerpetualMarketLaunch,
} from "@injectivelabs/sdk-ts/core/modules";
import { toChainFormat } from "@injectivelabs/utils";
import { TokenStaticFactory } from "@injectivelabs/sdk-ts/service";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
// refer to https://github.com/InjectiveLabs/injective-lists
import { tokens } from "../data/tokens.json";
const tokenStaticFactory = new TokenStaticFactory(tokens as TokenStatic[]);
const denom = "inj";
const privateKey = "0x...";
const injectiveAddress = "inj...";
const amount = toChainFormat(1).toFixed();
const market = {
title: "INJ/USDT Perpetual Market Launch",
description:
"This proposal will launch the INJ/USDT Spot Market with maker and taker fees 0.001% and 0.002% respectively",
ticker: "INJ/USDT PERP",
quoteDenom: "peggy0x...",
oracleBase: "INJ",
oracleQuote: "USDT",
oracleScaleFactor: 6,
oracleType: 10, // BAND IBC
initialMarginRatio: "0.05",
maintenanceMarginRatio: "0.02",
makerFeeRate: "0.01",
takerFeeRate: "0.02",
minPriceTickSize: "0.01",
minQuantityTickSize: "0.01",
};
const quoteDenom = await tokenStaticFactory.toToken(market.quoteDenom);
const marketWithDecimals = {
...market,
quoteTokenDecimals: quoteDenom ? quoteDenom.decimals : 6,
};
const marketWithTickSizes = {
...market,
minPriceTickSize: toChainFormat(
marketWithDecimals.minPriceTickSize,
marketWithDecimals.quoteTokenDecimals
).toFixed(),
};
const message = MsgSubmitProposalPerpetualMarketLaunch.fromJSON({
market: marketWithTickSizes,
proposer: injectiveAddress,
deposit: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: message,
});
```
### MsgSubmitProposalExpiryFuturesMarketLaunch
An expiry futures contract is an agreement between two counterparties to buy and sell a specific amount of an underlying base asset at a specific future price, which is set to expire at a specified date in the future. This is the message you can use to create a futures market for a specified token pair.
```ts theme={null}
import {
TokenStaticFactory,
MsgBroadcasterWithPk,
MsgSubmitProposalExpiryFuturesMarketLaunch,
import { toChainFormat } from "@injectivelabs/utils";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
// refer to https://github.com/InjectiveLabs/injective-lists
import { tokens } from "../data/tokens.json";
const tokenStaticFactory = new TokenStaticFactory(tokens as TokenStatic[]);
const denom = "inj";
const injectiveAddress = "inj...";
const privateKey = "0x...";
const amount = toChainFormat(1).toFixed();
const market = {
title: "INJ/USDT Futures Market Launch",
description:
"This proposal will launch the INJ/USDT Spot Market with maker and taker fees 0.001% and 0.002% respectively",
ticker: "INJ/USDT 24-MAR-2023",
quoteDenom: "peggy0x...",
oracleBase: "INJ",
oracleQuote: "USDT",
expiry: 1000000, // when the market will expire, in ms
oracleScaleFactor: 6,
oracleType: 10, // BAND IBC
initialMarginRatio: "0.05",
maintenanceMarginRatio: "0.02",
makerFeeRate: "0.01",
takerFeeRate: "0.02",
minPriceTickSize: "0.01",
minQuantityTickSize: "0.01",
};
const quoteDenom = await tokenStaticFactory.toToken(market.quoteDenom);
const marketWithDecimals = {
...market,
quoteTokenDecimals: quoteDenom ? quoteDenom.decimals : 6,
};
const marketWithTickSizes = {
...market,
minPriceTickSize: toChainFormat(
marketWithDecimals.minPriceTickSize,
marketWithDecimals.quoteTokenDecimals
).toFixed(),
};
const message = MsgSubmitProposalExpiryFuturesMarketLaunch.fromJSON({
market: marketWithTickSizes,
proposer: injectiveAddress,
deposit: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: message,
});
```
### MsgSubmitProposalSpotMarketParamUpdate
This message can be used to update the params of a spot market.
```ts theme={null}
import {
MsgBroadcasterWithPk,
MsgSubmitProposalSpotMarketParamUpdate,
} from "@injectivelabs/sdk-ts/core/modules";
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { GrpcMarketStatusMap } from "@injectivelabs/sdk-ts/client/chain";
const denom = "inj";
const privateKey = "0x...";
const injectiveAddress = "inj...";
const amount = toChainFormat(1).toFixed();
const market = {
title: "INJ/USDT Spot Market Launch",
description:
"This proposal will launch the INJ/USDT Spot Market with maker and taker fees 0.001% and 0.002% respectively",
marketId: "0x...",
makerFeeRate: "0.02",
takerFeeRate: "0.03",
relayerFeeShareRate: "0.4", // 40%, the percent of tsx fees that go to the relayers
minPriceTickSize: "0.002",
minQuantityTickSize: "0.002",
status: GrpcMarketStatusMap.Active,
};
const message = MsgSubmitProposalSpotMarketParamUpdate.fromJSON({
market,
proposer: injectiveAddress,
deposit: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: message,
});
```
# IBC
Source: https://docs.injective.network/developers-native/examples/ibc
## Messages
## MsgTransfer
This message is used to send coins from the sender's Bank module on Injective to the receiver's Bank module on another Cosmos chain through IBC, which is Cosmos's Inter-Blockchain Communication Protocol.
Note that Injective only supports mainnet transfers across IBC for most networks.
Application to application communication in IBC is conducted over channels, which route between an application module on one chain, and the corresponding application module on another one. More info on IBC channels can be found at [https://tutorials.cosmos.network/academy/3-ibc/3-channels.html](https://tutorials.cosmos.network/academy/3-ibc/3-channels.html).
A list of canonical channel Ids for mainnet transfers to and from Injective can be found in the [Injective Lists repository](https://github.com/InjectiveLabs/injective-lists).
Also noteworthy is that the application module on each chain has a portId to designate the type of module on each end.
For example, `transfer` is the portId designating the transfer of ICS-20 tokens between bank modules.
In this example, we will transfer ATOM from Injective to CosmosHub
For token metadata (symbols, decimals, channel mappings), please use
[Injective Lists](https://github.com/InjectiveLabs/injective-lists) which
provides up-to-date token information in JSON format.
```ts theme={null}
import { toChainFormat, toBigNumber } from "@injectivelabs/utils";
import { ChainId, CosmosChainId } from "@injectivelabs/ts-types";
import { MsgTransfer } from "@injectivelabs/sdk-ts/core/modules";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { ChainGrpcBankApi } from "@injectivelabs/sdk-ts/client/chain";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { makeTimeoutTimestampInNs } from "@injectivelabs/sdk-ts/utils";
import { ChainRestTendermintApi } from "@injectivelabs/sdk-ts/client/chain";
const injectiveChainId = CosmosChainId["Injective"];
const destinationChainId = CosmosChainId["Cosmoshub"];
const endpointsForNetwork = getNetworkEndpoints(Network.Mainnet);
/**
* For IBC transfers, you need:
* 1. The IBC denom hash for the token on Injective
* 2. The channel ID for the destination chain
*
* You can find this information in the Injective Lists repository:
* https://github.com/InjectiveLabs/injective-lists
*/
const injectiveToCosmosHubChannelId = "channel-1";
/**
* The IBC denom for ATOM on Injective
* Format: ibc/{hash} where hash is derived from the channel and base denom
*/
const atomIbcDenom =
"ibc/C4CFF46FD6DE35CA4CF4CE031E643C8FDC9BA4B99AE598E9B0ED98FE3A2319F9";
/* format amount for transfer (0.001 ATOM with 6 decimals) */
const amount = {
denom: atomIbcDenom,
amount: toChainFormat(0.001, 6).toFixed(),
};
const injectiveAddress = "inj...";
const destinationAddress = "cosmos...";
const port = "transfer";
const timeoutTimestamp = makeTimeoutTimestampInNs();
/* get the latestBlock from the origin chain */
const tendermintRestApi = new ChainRestTendermintApi(endpointsForNetwork.rest);
/* Block details from the origin chain */
const latestBlock = await tendermintRestApi.fetchLatestBlock();
const latestHeight = latestBlock.header.height;
const timeoutHeight = toBigNumber(latestHeight).plus(
30 // default block timeout height
);
/* create message in proto format */
const msg = MsgTransfer.fromJSON({
port,
memo: `IBC transfer from ${injectiveChainId} to ${destinationChainId}`,
sender: injectiveAddress,
receiver: destinationAddress,
channelId: injectiveToCosmosHubChannelId,
timeout: timeoutTimestamp,
height: {
revisionHeight: timeoutHeight.toNumber(),
revisionNumber: parseInt(latestBlock.header.version.block, 10),
},
amount,
});
const privateKey = "0x...";
/* broadcast transaction */
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Mainnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Transaction Examples
Source: https://docs.injective.network/developers-native/examples/index
This section provides code examples for common transaction types on Injective.
* [Auction](/developers-native/examples/auction/) - Auction module transactions
* [Authz](/developers-native/examples/authz/) - Authorization module transactions
* [Bank](/developers-native/examples/bank/) - Bank module transactions
* [Distribution](/developers-native/examples/distribution/) - Distribution module transactions
* [Exchange](/developers-native/examples/exchange/) - Exchange module transactions
* [Feegrant](/developers-native/examples/feegrant/) - Fee grant module transactions
* [Governance](/developers-native/examples/governance/) - Governance module transactions
* [IBC](/developers-native/examples/ibc/) - IBC module transactions
* [Insurance](/developers-native/examples/insurance/) - Insurance module transactions
* [Peggy](/developers-native/examples/peggy/) - Peggy bridge transactions
* [Permissions](/developers-native/examples/permissions/) - Permissions module transactions
* [Staking](/developers-native/examples/staking/) - Staking module transactions
* [Token Factory](/developers-native/examples/token-factory/) - Token factory module transactions
* [Wasm](/developers-native/examples/wasm/) - CosmWasm transactions
# Insurance
Source: https://docs.injective.network/developers-native/examples/insurance
This module provides insurance funds for derivative markets in the exchange module of the Injective Chain to use in order to support higher leverage trading. On a high level, insurance funds for each derivative market are funded by a permissionless group of underwriters who each own a proportional claim (represented through insurance fund share tokens) over the underlying assets in the insurance fund.
## Messages
Let's explore (and provide examples) the Messages that the Insurance module exports and we can use to interact with the Injective chain.
### MsgCreateInsuranceFund
This Message is used to create an Insurance Fund
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgCreateInsuranceFund } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const amount = 5;
const fund = {
ticker: "BTC/USDT",
quoteDenom: "peggy0x...",
oracleBase: "BTC",
oracleQuote: "USDT",
oracleType: 10, // BANDIBC
};
const msg = MsgCreateInsuranceFund.fromJSON({
fund,
injectiveAddress,
deposit: {
denom: fund.quoteDenom,
amount: toChainFormat(amount, 6 /* 6 because USDT has 6 decimals */).toFixed(),
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgRequestRedemption
This Message is used to request redemption.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgRequestRedemption } from "@injectivelabs/sdk-ts/core/modules";
const marketId = "0x....";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const denom = "share1"; // the insurance fund denom (share{id})
const amount = toChainFormat(5).toFixed();
const msg = MsgRequestRedemption.fromJSON({
marketId,
injectiveAddress,
amount: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgUnderwrite
This Message is used to underwrite to an insurance fund.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgUnderwrite } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const usdtDecimals = 6;
const marketId = "0x...";
const privateKey = "0x...";
const denom = "peggy0x...";
const injectiveAddress = "inj1...";
const amount = toChainFormat(5, usdtDecimals).toFixed();
const msg = MsgUnderwrite.fromJSON({
marketId,
injectiveAddress,
amount: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Peggy
Source: https://docs.injective.network/developers-native/examples/peggy
The `peggy` module is the heart of the injective ↔ ethereum bridge, where deposited funds will be locked on the ethereum [peggy contract](https://etherscan.io/address/0xF955C57f9EA9Dc8781965FEaE0b6A2acE2BAD6f3#code) and minted on the Injective chain. Similarly withdrawal funds will be burned on the injective chain and unlocked on the ethereum peggy contract.
## Messages
### MsgSendToEth
This message is used to withdraw funds from the Injective Chain via the [peggy contract](https://etherscan.io/address/0xF955C57f9EA9Dc8781965FEaE0b6A2acE2BAD6f3#code), in the process funds will be burned on the injective chain and distributed to the ethereum address from the peggy contract.
Note that a \$10 USD bridge fee will be charged for this transaction to cover for the ethereum gas fee on top of the standard INJ transaction fee.
```ts theme={null}
import { ChainId } from '@injectivelabs/ts-types'
import { toBigNumber, toChainFormat } from '@injectivelabs/utils'
import { MsgSendToEth } from '@injectivelabs/sdk-ts/core/modules'
import { MsgBroadcasterWithPk } from '@injectivelabs/sdk-ts/core/tx'
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { TokenPrice, TokenStaticFactory } from '@injectivelabs/sdk-ts/service'
// refer to https://github.com/InjectiveLabs/injective-lists
import { tokens } from '../data/tokens.json'
export const tokenStaticFactory = new TokenStaticFactory(tokens as TokenStatic[])
const tokenPriceMap = new TokenPrice(Network.Mainnet)
const tokenService = new TokenService({
chainId: ChainId.Mainnet,
network: Network.Mainnet,
})
const ETH_BRIDGE_FEE_IN_USD = 10
const endpointsForNetwork = getNetworkEndpoints(Network.Mainnet)
const tokenSymbol = 'INJ'
const tokenMeta = tokenStaticFactory.toToken(tokenSymbol)
const amount = 1
const injectiveAddress = 'inj1...'
const destinationAddress = '0x...' // ethereum address
const tokenDenom = `peggy${tokenMeta.erc20.address}`
if (!tokenMeta) {
return
}
const tokenUsdPrice = tokenPriceMap[tokenMeta.coinGeckoId]
const amountToFixed = toChainFormat(amount, tokenMeta.decimals).toFixed()
const bridgeFeeInToken = toBigNumber(ETH_BRIDGE_FEE_IN_USD).dividedBy(tokenUsdPrice).toFixed()
const msg = MsgSendToEth.fromJSON({
injectiveAddress,
address: destinationAddress,
amount: {
denom: tokenDenom,
amount: amountToFixed,
},
bridgeFee: {
denom: tokenDenom,
amount: bridgeFeeInToken,
},
})
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Mainnet,
}).broadcast({
msgs: msg,
})
```
# Permissions
Source: https://docs.injective.network/developers-native/examples/permissions
The Permissions Module facilitates the management of namespaces, roles, and permissions within the Injective ecosystem. This documentation outlines the key message types and their usage for interacting with permissions-related data.
## Messages
Let's explore (and provide examples) the Messages that the Permissions module exports and we can use to interact with the Injective chain.
### `MsgClaimVoucher`
This message is used to claim a voucher tied to a specific address within a namespace.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgClaimVoucher } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const denom = "inj";
const msg = MsgClaimVoucher.fromJSON({
injectiveAddress,
denom,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### `MsgCreateNamespace`
This message is used to creates a new namespace with permissions and roles.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgCreateNamespace } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const secondAddress = "inj2.....";
const privateKey = "0x...";
const denom = "inj";
const wasmHook = "inj3....";
const mintsPausedValue = false;
const sendsPausedValue = false;
const burnsPausedValue = false;
const role1 = "Everyone";
const permissions1 = 1;
const msg = MsgCreateNamespace.fromJSON({
injectiveAddress,
namespace: {
denom,
wasmHook,
mintsPausedValue,
sendsPausedValue,
burnsPausedValue,
rolePermissions: {
role: role1,
permissions: permissions1,
},
addressRoles: {
address: injectiveAddress,
roles: [role1],
},
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### `MsgDeleteNamespace`
This message is used to delete an existing namespace.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgDeleteNamespace } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const denom = "inj";
const msg = MsgDeleteNamespace.fromJSON({
injectiveAddress,
denom,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### `MsgRevokeNamespaceRoles`
This message is used to revoke roles from specified addresses in a namespace.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgRevokeNamespaceRoles } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const denom = "inj";
const roles = ["role1", "role2"];
const msg = MsgRevokeNamespaceRoles.fromJSON({
injectiveAddress,
denom,
addressRolesToRevoke: {
injectiveAddress,
roles: roles,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### `MsgUpdateNamespace`
This message is used to update namespace properties like mints, sends, and burns.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgUpdateNamespace } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1..."
const privateKey = "0x...";
const denom = "inj";
const wasmHookValue = "inj2...";
const mintsPausedValue = false;
const sendsPausedValue = false;
const burnsPausedValue = true;
const msg = await new MsgUpdateNamespace.fromJSON({
injectiveAddress,
denom,
wasmHook: {
newValue: wasmHookValue
},
mintsPaused: {
newValue: mintsPausedValue;
},
sendsPaused: {
newValue: sendsPausedValue;
},
burnsPaused: {
newValue: burnsPausedValue;
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet
}).broadcast({
msgs: msg
});
console.log(txHash);
```
### `MsgUpdateNamespaceRoles`
This message is used to modify the roles and permissions for addresses in a namespace.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgUpdateNamespaceRoles } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const denom = "inj";
const role = "role1";
const permissions = 4;
const msg = MsgUpdateNamespaceRoles.fromJSON({
injectiveAddress,
denom,
rolePermissions: {
role,
permissions: permissions,
},
addressRoles: {
injectiveAddress,
roles: [role],
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Staking
Source: https://docs.injective.network/developers-native/examples/staking
The module enables Cosmos SDK-based blockchain to support an advanced Proof-of-Stake (PoS) system. In this system, holders of the native staking token of the chain can become validators and can delegate tokens to validators, ultimately determining the effective validator set for the system.
## Messages
Let's explore (and provide examples) the Messages that the Staking module exports and we can use to interact with the Injective chain.
### MsgBeginRedelegate
This Message is used to Redelegate staked INJ from one validator to another.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgBeginRedelegate } from "@injectivelabs/sdk-ts/core/modules";
const denom = "inj";
const privateKey = "0x...";
const amount = toChainFormat(5);
const injectiveAddress = "inj1...";
const sourceValidatorAddress = "inj1...";
const destinationValidatorAddress = "inj1...";
const msg = MsgBeginRedelegate.fromJSON({
injectiveAddress,
dstValidatorAddress: destinationValidatorAddress,
srcValidatorAddress: sourceValidatorAddress,
amount: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgDelegate
This Message is used to Delegate INJ to a validator.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgDelegate } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const denom = "inj";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const validatorAddress = "inj1...";
const amount = toChainFormat(5).toFixed();
const msg = MsgDelegate.fromJSON({
injectiveAddress,
validatorAddress,
amount: {
denom,
amount,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgCancelUnbondingDelegation
This message is used to cancel unbonding from a validator, reset the bonding period, and delegate back to the previous validator.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgCancelUnbondingDelegation } from "@injectivelabs/sdk-ts/core/modules";
const denom = "inj";
const delegatorAddress = "inj1...";
const privateKey = "0x...";
const amount = toChainFormat(5).toFixed();
const validatorAddress = "inj1...";
const creationHeight = "123456"; // the height at which the unbonding was initiated
const msg = MsgCancelUnbondingDelegation.fromJSON({
delegatorAddress,
validatorAddress,
amount: {
denom,
amount,
},
creationHeight,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Token Factory
Source: https://docs.injective.network/developers-native/examples/token-factory
This `tokenfactory` module allows any account to create a new token with the name `factory/{creator address}/{subdenom}`. Because tokens are namespaced by creator address, this allows token minting to be permissionless, due to not needing to resolve name collisions.
*Note: If you want your denom to be visible on products like Helix, Hub, Explorer, etc, it's important to add token metadata information using the `MsgSetDenomMetadata` message as explained below.*
*Note #2: It's recommended to change your admin to the zero address for safety and preventing supply manipulation.*
## Messages
Let's explore (and provide examples) the Messages that the TokenFactory module exports and we can use to interact with the Injective chain.
### MsgCreateDenom
Creates a denom of `factory/{creator address}/{subdenom}` given the denom creator address and the subdenom. Subdenoms can contain \[a-zA-Z0-9./]. Keep in mind that there is a `creation fee` which you need to cover when creating a new token.
Keep in mind that that the `admin` of the token can change the supply (mint or burn new tokens). Its recommended that the `admin` is unset using the `MsgChangeAdmin`, as explained below.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgCreateDenom } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const subdenom = "inj-test";
const msg = MsgCreateDenom.fromJSON({
subdenom,
symbol: "InjTest",
name: "Inj Testing",
sender: injectiveAddress,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgMint
Minting of a specific denom is only allowed for the current admin. Note, the current admin is defaulted to the creator of the denom.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgMint } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const subdenom = "inj-test";
const amountToMint = 1_000_000_000;
const msg = MsgMint.fromJSON({
sender: injectiveAddress,
amount: {
denom: `factory/${injectiveAddress}/${subdenom}`,
amount: amountToMint,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgBurn
The admin can burn the supply of the token factory. Everyone else can use this message to burn their funds only.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBurn } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const subdenom = "inj-test";
const amountToBurn = 1_000_000_000;
const msg = MsgBurn.fromJSON({
sender: injectiveAddress,
amount: {
denom: `factory/${injectiveAddress}/${subdenom}`,
amount: amountToBurn,
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgSetDenomMetadata
Setting of metadata for a specific denom is only allowed for the admin of the denom. It allows the overwriting of the denom metadata in the bank module.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgSetDenomMetadata } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const subdenom = 'inj-test'
const denom = `factory/${injectiveAddress}/${subdenom}`;
const denomUnitsIfTokenHas0Decimals = [
{
denom: denom,
exponent: 0,
aliases: [subdenom]
},
]
const denomUnitsIfTokenHas6Decimals = [
{
denom: denom, /** we use the whole denom here */
exponent: 0,
aliases: [subdenom]
},
{
denom: subdenom,
exponent: 6, /** we use the subdenom only here (if you want your token to have 6 decimals) */
aliases: []
},
]
const msg = MsgSetDenomMetadata.fromJSON({
sender: injectiveAddress,
metadata: {
base: denom, /** the base denom */
description: '', /** description of your token */
display: subdenom, /** the display alias of your token on UIs (it's the denom of the unit with highest decimals) */
name: '', /** the name of your token */
symbol: '', /** the symbol of your token */
uri: '' /** the logo of your token, should be hosted on IPFS and should be a small webp image */
denomUnits: denomUnitsIfTokenHas6Decimals /** choose if you want to have 6 or 0 decimals for the token */,
decimals: 6 /** choose if you want to have 6 or 0 decimals for the token */
}
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet
}).broadcast({
msgs: msg
});
console.log(txHash);
```
### MsgChangeAdmin
The admin of the denom can mint new supply or burn existing one. It's recommended to change the admin to the zero address as to not allow changing the token's supply.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgChangeAdmin } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const subdenom = "inj-test";
const denom = `factory/${injectiveAddress}/${subdenom}`;
const msg = MsgChangeAdmin.fromJSON({
denom,
sender: injectiveAddress,
newAdmin:
"inj1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqe2hm49" /** SET TO ZERO ADDRESS */,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
## Full Example
Here is a full example on how to create a new token, mint new tokens and set token metadata on Injective.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgSetDenomMetadata, MsgCreateDenom, MsgMint, MsgChangeAdmin } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const privateKey = "0x...";
const subdenom = 'inj-test'
const denom = `factory/${injectiveAddress}/${subdenom}`;
const amount = 1_000_000_000
const msgCreateDenom = MsgCreateDenom.fromJSON({
subdenom,
sender: injectiveAddress,
});
const msgMint = MsgMint.fromJSON({
sender: injectiveAddress,
amount: {
denom: `factory/${injectiveAddress}/${subdenom}`,
amount: amount
}
});
const msgChangeAdmin = MsgChangeAdmin.fromJSON({
denom: `factory/${injectiveAddress}/${subdenom}`,
sender: injectiveAddress,
newAdmin: 'inj1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqe2hm49' /** SET TO ZERO ADDRESS */
});
const msgSetDenomMetadata = MsgSetDenomMetadata.fromJSON({
sender: injectiveAddress,
metadata: {
base: denom, /** the base denom */
description: '', /** description of your token */
display: '', /** the displayed name of your token on UIs */,
name: '', /** the name of your token */,
symbol: '' /** the symbol of your token */,
uri: '' /** the logo of your token, should be hosted on IPFS and should be a small webp image */
denomUnits: [
{
denom: denom,
exponent: 0,
aliases: [subdenom]
},
{
denom: subdenom,
exponent: 6, /** if you want your token to have 6 decimals */
aliases: []
},
]
}
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet
}).broadcast({
msgs: [msgCreateDenom, msgMint, msgSetDenomMetadata, msgChangeAdmin]
});
console.log(txHash);
```
# Wasm
Source: https://docs.injective.network/developers-native/examples/wasm
The `wasm` module is the heart of interacting with the wasm smart contracts deployed on the injective chain, here you can find a list of [smart contracts](https://injscan.com/smart-contracts/) that are deployed on the Injective chain.
`MsgUpdateCode` and `MsgStoreCode` are not supported by Ethereum (ex:
Metamask) wallets.
## Messages
### MsgExecuteContract (Transfer)
This message is used to execute contract function, below we will use the [CW20 spec](https://github.com/CosmWasm/cw-plus/blob/main/packages/cw20/README.md) transfer message as an example.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgExecuteContract } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const recipientAddress = "inj2...";
const contractAddress = "cw...";
const msg = MsgExecuteContract.fromJSON({
contractAddress,
sender: injectiveAddress,
exec: {
action: "transfer",
msg: {
recipient: recipientAddress,
amount: 100000,
},
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Mainnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgExecuteContract (funds example)
In some scenarios, depending on the smart contract's function we have to transfer tokens to the smart contract, following cosmwasm convention, we use the funds field to transfer tokens to the smart contract from the user's bank module.
Below is an example of how we can send the `MsgExecuteContract` using an `test` contract function.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgExecuteContract } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const contractAddress = "cw...";
const msg = MsgExecuteContract.fromJSON({
contractAddress,
sender: injectiveAddress,
exec: {
action: "test",
funds: [
{
denom: "inj",
amount: toChainFormat(1).toFixed(),
},
],
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Mainnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
### MsgExecuteContractCompat
There are some compatibility issues parsing the `funds` array and `msgs` object in the previous example with EIP712. Since `MsgExecuteContract` can't be properly converted to EIP712 and then signed by Ethereum wallets, we introduced `MsgExecuteContractCompat` which is fully compatible with EIP712.
***Note:*** *`MsgExecuteContract` and `MsgExecuteContractCompat` underlying messages are the same. `MsgExecuteContractCompat` is just EIP712 compatible.*
Below is an example of how we can send the `MsgExecuteContractCompact` using an `test` contract function.
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
import { MsgExecuteContractCompat } from "@injectivelabs/sdk-ts/core/modules";
const injectiveAddress = "inj1...";
const contractAddress = "cw...";
const msg = MsgExecuteContractCompat.fromJSON({
contractAddress,
sender: injectiveAddress,
exec: {
action: "test",
funds: [
{
denom: "inj",
amount: toChainFormat(1).toFixed(),
},
],
},
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Mainnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# State
Source: https://docs.injective.network/developers-native/injective/auction/01_state
# State
## Params
Params is a module-wide configuration structure that stores system parameters and defines overall functioning of the auction module.
* Params: `Paramsspace("auction") -> legacy_amino(params)`
```go theme={null}
type Params struct {
// auction_period_duration defines the auction period duration
AuctionPeriod int64
// min_next_bid_increment_rate defines the minimum increment rate for new bids
MinNextBidIncrementRate math.LegacyDec
}
```
### **LastBid**
Keeps track of the current highest bid
* LastBid: `0x01 -> ProtocolBuffer(Bid)`
```go theme={null}
type Bid struct {
Bidder string
Amount sdk.Coin
}
```
### **AuctionRound**
The current auction round.
* AuctionRound: `0x03 -> BigEndian(AuctionRound)`
### **EndingTimeStamp**
This value is compared against current block time to decide an auction round settlement. When the exported chain is imported again, the EndingTimeStamp will be updated to the next value in future.
* `EndingTimeStamp`: `0x04 -> BigEndian(EndingTimestamp)`
### **LastAuctionResult**
Keeps track of the last auction result.
* LastAuctionResult: `0x05 -> ProtocolBuffer(LastAuctionResult)`
```go theme={null}
type LastAuctionResult struct {
Winner string
Amount sdk.Coin
Round uint64
}
```
# Messages
Source: https://docs.injective.network/developers-native/injective/auction/02_messages
# Messages
In this section we describe the processing of the auction messages and the corresponding updates to the state.
## Msg/Bid
An auction basket from a given round is bid upon by using the `Msg/Bid` service message.
```protobuf theme={null}
// Bid defines a SDK message for placing a bid for an auction
message MsgBid {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
// amount of the bid in INJ tokens
cosmos.base.v1beta1.Coin bid_amount = 2 [(gogoproto.nullable) = false];
// the current auction round being bid on
uint64 round = 3;
}
```
This service message is expected to fail if:
* `Round` does not equal the current auction round
* `BidAmount` does not exceed the previous highest bid amount by at least `min_next_increment_rate` percent.
This service message transfers the `BidAmount` of INJ from the `Sender` to the auction module, stores the bid, and refunds the last bidder's bid amount.
# End-Block
Source: https://docs.injective.network/developers-native/injective/auction/03_end_block
# End-Block
### Auction Settlement
The settlement of a given auction round occurs when `blockTime ≥ EndingTimeStamp.` If a non-zero INJ bid was placed during this period (i.e. there exists a `LastBid`), the following procedure will take place:
* The winning INJ bid amount is burned.
* The basket of coins held by the auction module is transferred to the winning bidder.
* `LastAuctionResult` is written to state and `EventAuctionResult` is emitted.
* The `LastBid` is cleared.
* The AuctionRound is incremented by 1 and the EndingTimestamp is incremented by `AuctionPeriod`.
* The accumulated exchange fees are transferred from the `exchange` module to the `auction` module for the new upcoming auction.
If the round closed without any successful bids, the existing coin basket will be rolled over into the next auction and combined with the new accumulated fee basket.
('', query)
console.log(response.data.data)
```
## Complete Example
```ts theme={null}
import { HttpClient } from '@injectivelabs/utils'
interface Token {
id: string
symbol: string
name: string
}
interface TokensResponse {
tokens: Token[]
}
const client = new HttpClient('YOUR_GRAPHQL_ENDPOINT')
// Set auth headers if required
client.setConfig({
headers: {
authorization: 'Bearer YOUR_API_KEY'
}
})
const query = JSON.stringify({
query: `
query GetTokens($first: Int!) {
tokens(first: $first, orderBy: symbol) {
id
symbol
name
}
}
`,
variables: {
first: 10
}
})
const response = await client.post('', query)
console.log(response.data.data.tokens)
```
## Error Handling
GraphQL responses may contain errors even with a 200 status code. Always check for errors:
```ts theme={null}
interface GraphQLResponse {
data?: T
errors?: Array<{ message: string }>
}
const response = await client.post }>('', query)
if (response.data.errors && response.data.errors.length > 0) {
throw new Error(response.data.errors[0].message)
}
const data = response.data.data
```
# Account
Source: https://docs.injective.network/developers-native/query-indexer-stream/account
Example code snippets to stream from the indexer for account module related data using StreamManagerV2.
## Using gRPC Stream with StreamManagerV2
### Stream subaccount balance
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcAccountStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcAccountStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'subaccount-balance',
streamFactory: () => stream.streamSubaccountBalance({
subaccountId: '0x...',
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (balance) => {
console.log(balance)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
# Auction
Source: https://docs.injective.network/developers-native/query-indexer-stream/auction
Example code snippets to stream from the indexer for auction module related data using StreamManagerV2.
## Using gRPC Stream with StreamManagerV2
### Stream auction bids
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcAuctionStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcAuctionStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'auction-bids',
streamFactory: () => stream.streamBids({
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (bids) => {
console.log(bids)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
# Derivatives
Source: https://docs.injective.network/developers-native/query-indexer-stream/derivatives
Example code snippets to stream from the indexer for derivatives market module related data using StreamManagerV2.
## Using gRPC Stream with StreamManagerV2
### Stream orderbook updates
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcDerivativesStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcDerivativesStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'derivatives-orderbook-updates',
streamFactory: () => stream.streamOrderbookUpdates({
marketIds: ['0x...'],
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (orderbookUpdates) => {
console.log(orderbookUpdates)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream derivative orders
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { OrderSide } from '@injectivelabs/sdk-ts/types'
import {
StreamManagerV2,
IndexerGrpcDerivativesStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcDerivativesStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'derivatives-orders',
streamFactory: () => stream.streamOrders({
marketId: '0x...',
subaccountId: '0x...', // optional
orderSide: OrderSide.Buy, // optional
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (orders) => {
console.log(orders)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream derivative order history
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
TradeDirection,
TradeExecutionType,
} from '@injectivelabs/sdk-ts/types'
import {
StreamManagerV2,
IndexerGrpcDerivativesStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcDerivativesStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'derivatives-order-history',
streamFactory: () => stream.streamOrdersHistory({
marketId: '0x...', // optional
subaccountId: '0x...', // optional
direction: TradeDirection.Buy, // optional
executionTypes: [TradeExecutionType.Market], // optional
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (orderHistory) => {
console.log(orderHistory)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream derivative trades
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { TradeDirection } from '@injectivelabs/sdk-ts/types'
import {
StreamManagerV2,
IndexerGrpcDerivativesStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcDerivativesStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'derivatives-trades',
streamFactory: () => stream.streamTrades({
marketIds: ['0x...'], // optional
subaccountId: '0x...', // optional
direction: TradeDirection.Buy, // optional
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (trades) => {
console.log(trades)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream derivative positions
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcDerivativesStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcDerivativesStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'derivatives-positions',
streamFactory: () => stream.streamPositions({
marketId: '0x...', // optional
subaccountId: '0x...', // optional
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (positions) => {
console.log(positions)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream derivative markets
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcDerivativesStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcDerivativesStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'derivatives-markets',
streamFactory: () => stream.streamMarkets({
marketIds: ['0x...'], // optional
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (markets) => {
console.log(markets)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
# Explorer
Source: https://docs.injective.network/developers-native/query-indexer-stream/explorer
Example code snippets to stream from the indexer for explorer module related data using StreamManagerV2.
## Using gRPC Stream with StreamManagerV2
### Stream blocks
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcExplorerStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcExplorerStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'explorer-blocks',
streamFactory: () => stream.streamBlocks({
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (blocks) => {
console.log(blocks)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream blocks with transactions
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcExplorerStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcExplorerStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'explorer-blocks-with-txs',
streamFactory: () => stream.streamBlocksWithTxs({
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (blocksWithTransactions) => {
console.log(blocksWithTransactions)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream transactions
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcExplorerStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcExplorerStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'explorer-transactions',
streamFactory: () => stream.streamTransactions({
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (transactions) => {
console.log(transactions)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
# Streaming the Indexer
Source: https://docs.injective.network/developers-native/query-indexer-stream/index
This section covers how to stream real-time data from the Injective Indexer API using StreamManagerV2.
## StreamManagerV2
StreamManagerV2 provides an event-based architecture for managing gRPC streams with automatic retry, exponential backoff, and comprehensive error handling.
### Key Features
* **Event-based lifecycle** - Listen to connect, disconnect, error, and data events
* **Automatic retry** - Configurable exponential backoff with retry limits
* **Error handling** - Distinguishes retryable vs non-retryable errors
* **Persistent mode** - Continue retrying indefinitely after max attempts
* **Fine-grained control** - Start, stop, and manage stream lifecycle
### Basic Usage
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcSpotStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcSpotStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'my-stream',
streamFactory: () => stream.streamOrders({
marketId: '0x...',
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (data) => {
console.log(data)
},
retryConfig: {
enabled: true,
maxAttempts: 5,
initialDelayMs: 1000,
maxDelayMs: 30000,
backoffMultiplier: 2,
persistent: true
}
})
// Event listeners
streamManager.on('connect', () => console.log('Connected'))
streamManager.on('disconnect', (reason) => console.log('Disconnected:', reason))
streamManager.on('error', (error) => console.error('Error:', error))
streamManager.on('stateChange', ({ from, to }) => console.log(`State: ${from} -> ${to}`))
// Start/stop
streamManager.start()
streamManager.stop()
```
### Available Stream Classes
* `IndexerGrpcAccountStreamV2` - Account balance and transaction streams
* `IndexerGrpcAccountPortfolioStreamV2` - Portfolio value streams
* `IndexerGrpcArchiverStreamV2` - Archiver data streams
* `IndexerGrpcAuctionStreamV2` - Auction bid streams
* `IndexerGrpcDerivativesStreamV2` - Derivatives market streams
* `IndexerGrpcExplorerStreamV2` - Blockchain explorer streams
* `IndexerGrpcMitoStreamV2` - Mito vault streams
* `IndexerGrpcOracleStreamV2` - Oracle price feed streams
* `IndexerGrpcSpotStreamV2` - Spot market streams
* `IndexerGrpcTradingStreamV2` - Trading automation streams
### Retry Configuration
```ts theme={null}
retryConfig: {
enabled: true, // Enable/disable retry
maxAttempts: 5, // Max retry attempts (0 = unlimited)
initialDelayMs: 1000, // Initial backoff delay
maxDelayMs: 30000, // Maximum backoff delay
backoffMultiplier: 2, // Exponential backoff multiplier
persistent: true // Continue with max delay after maxAttempts
}
```
### Event Types
* `connect` - Stream successfully connected
* `disconnect` - Stream disconnected with reason
* `error` - Stream error occurred
* `data` - New data received
* `stateChange` - Stream state changed
* `retry` - Retry attempt started
* `warn` - Warning message
## Stream Examples
* [Account](/developers-native/query-indexer-stream/account/) - Stream account updates
* [Archiver](/developers-native/query-indexer-stream/archiver/) - Stream archiver data
* [Auction](/developers-native/query-indexer-stream/auction/) - Stream auction updates
* [Derivatives](/developers-native/query-indexer-stream/derivatives/) - Stream derivatives market updates
* [Explorer](/developers-native/query-indexer-stream/explorer/) - Stream explorer updates
* [Mito](/developers-native/query-indexer-stream/mito/) - Stream Mito vault updates
* [Oracle](/developers-native/query-indexer-stream/oracle/) - Stream oracle price updates
* [Portfolio](/developers-native/query-indexer-stream/portfolio/) - Stream portfolio updates
* [Spot](/developers-native/query-indexer-stream/spot/) - Stream spot market updates
* [Trading](/developers-native/query-indexer-stream/trading/) - Stream trading automation updates
# Oracle
Source: https://docs.injective.network/developers-native/query-indexer-stream/oracle
Example code snippets to stream from the indexer for oracle module related data using StreamManagerV2.
## Using gRPC Stream with StreamManagerV2
### Stream oracle prices
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcOracleStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcOracleStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'oracle-prices',
streamFactory: () => stream.streamOraclePrices({
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (oraclePrices) => {
console.log(oraclePrices)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream oracle prices by markets
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcOracleStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcOracleStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'oracle-prices-by-markets',
streamFactory: () => stream.streamOraclePricesByMarkets({
marketIds: ['0x...'],
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (oraclePrices) => {
console.log(oraclePrices)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
# Portfolio
Source: https://docs.injective.network/developers-native/query-indexer-stream/portfolio
Example code snippets to stream from the indexer for portfolio module related data using StreamManagerV2.
## Using gRPC Stream with StreamManagerV2
### Stream an account's portfolio
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcAccountPortfolioStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcAccountPortfolioStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'account-portfolio',
streamFactory: () => stream.streamAccountPortfolio({
accountAddress: 'inj...',
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (portfolioResults) => {
console.log(portfolioResults)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
# Spot
Source: https://docs.injective.network/developers-native/query-indexer-stream/spot
Example code snippets to stream from the indexer for spot market module related data using StreamManagerV2.
## Using gRPC Stream with StreamManagerV2
### Stream orderbook updates
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
StreamManagerV2,
IndexerGrpcSpotStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcSpotStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'spot-orderbook-updates',
streamFactory: () => stream.streamOrderbookUpdates({
marketIds: ['0x...'],
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (orderbookUpdates) => {
console.log(orderbookUpdates)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream spot orders
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { OrderSide } from '@injectivelabs/sdk-ts/types'
import {
StreamManagerV2,
IndexerGrpcSpotStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcSpotStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'spot-orders',
streamFactory: () => stream.streamOrders({
marketId: '0x...',
subaccountId: '0x...', // optional
orderSide: OrderSide.Buy, // optional
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (orders) => {
console.log(orders)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream spot order history
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import {
TradeDirection,
TradeExecutionType,
} from '@injectivelabs/sdk-ts/types'
import {
StreamManagerV2,
IndexerGrpcSpotStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcSpotStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'spot-order-history',
streamFactory: () => stream.streamOrderHistory({
marketId: '0x...', // optional
subaccountId: '0x...', // optional
direction: TradeDirection.Buy, // optional
executionTypes: [TradeExecutionType.Market], // optional
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (orderHistory) => {
console.log(orderHistory)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
### Stream spot trades
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { TradeDirection } from '@injectivelabs/sdk-ts/types'
import {
StreamManagerV2,
IndexerGrpcSpotStreamV2
} from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const stream = new IndexerGrpcSpotStreamV2(endpoints.indexer)
const streamManager = new StreamManagerV2({
id: 'spot-trades',
streamFactory: () => stream.streamTrades({
marketIds: ['0x...'], // optional
subaccountId: '0x...', // optional
direction: TradeDirection.Buy, // optional
callback: (response) => {
streamManager.emit('data', response)
}
}),
onData: (trades) => {
console.log(trades)
},
retryConfig: { enabled: true }
})
streamManager.on('connect', () => console.log('Stream connected'))
streamManager.start()
```
# Account
Source: https://docs.injective.network/developers-native/query-indexer/account
Example code snippets to query the indexer for subaccount related data.
## Using gRPC
### Fetch user's portfolio details
This includes available balance, unrealized Pnl, and portfolio value. Note: **deprecated** → use [Portfolio](../query-indexer/portfolio/#using-grpc) instead
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAccountApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAccountApi = new IndexerGrpcAccountApi(endpoints.indexer);
const injectiveAddress = "inj...";
const portfolio = await indexerGrpcAccountApi.fetchPortfolio(injectiveAddress);
console.log(portfolio);
```
### Fetch user's trading rewards per epoch
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAccountApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAccountApi = new IndexerGrpcAccountApi(endpoints.indexer);
const injectiveAddress = "inj...";
const epoch = -1; // current epoch
const tradingRewards = await indexerGrpcAccountApi.fetchRewards({
address: injectiveAddress,
epoch,
});
console.log(tradingRewards);
```
### Fetch subaccounts associated with an injective address
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAccountApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAccountApi = new IndexerGrpcAccountApi(endpoints.indexer);
const injectiveAddress = "inj...";
const subaccountsList = await indexerGrpcAccountApi.fetchSubaccountsList(
injectiveAddress
);
console.log(subaccountsList);
```
### Fetch balance of a subaccount for a specific denom
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAccountApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAccountApi = new IndexerGrpcAccountApi(endpoints.indexer);
const subaccountId = "0x...";
const denom = "inj";
const subaccountBalance = await indexerGrpcAccountApi.fetchSubaccountBalance(
subaccountId,
denom
);
console.log(subaccountBalance);
```
### Fetch of balances for a subaccount
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAccountApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAccountApi = new IndexerGrpcAccountApi(endpoints.indexer);
const subaccountId = "0x...";
const subaccountBalanceList =
await indexerGrpcAccountApi.fetchSubaccountBalancesList(subaccountId);
console.log(subaccountBalanceList);
```
### Fetch subaccount history
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcAccountApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcAccountApi = new IndexerGrpcAccountApi(endpoints.indexer)
const subaccountId = '0x...'
const denom = 'inj'
const pagination = {...} as PaginationOption
const subaccountHistory = await indexerGrpcAccountApi.fetchSubaccountHistory({
subaccountId,
denom,
pagination /* optional param */
})
console.log(subaccountHistory)
```
### Fetch a summary of a subaccount's orders
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAccountApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAccountApi = new IndexerGrpcAccountApi(endpoints.indexer);
const subaccountId = "0x...";
const marketId = "0x";
const orderDirection = "buy";
const orderSummary = await indexerGrpcAccountApi.fetchSubaccountOrderSummary({
subaccountId,
marketId,
orderDirection,
});
console.log(orderSummary);
```
### Fetch states of spot or (and) derivatives orders
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAccountApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAccountApi = new IndexerGrpcAccountApi(endpoints.indexer);
const spotOrderHashes = ["0x..."];
const derivativeOrderHashes = ["0x..."];
const orderStates = await indexerGrpcAccountApi.fetchOrderStates({
spotOrderHashes,
derivativeOrderHashes,
});
console.log(orderStates);
```
# Auction
Source: https://docs.injective.network/developers-native/query-indexer/auction
Example code snippets to query the indexer for auction module related data.
## Using gRPC
### Fetch auction based off the round
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAuctionApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAuctionApi = new IndexerGrpcAuctionApi(endpoints.indexer);
const round = 1;
const auction = await indexerGrpcAuctionApi.fetchAuction(round);
console.log(auction);
```
### Fetch auctions
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcAuctionApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcAuctionApi = new IndexerGrpcAuctionApi(endpoints.indexer);
const auction = await indexerGrpcAuctionApi.fetchAuctions();
console.log(auction);
```
# Derivatives
Source: https://docs.injective.network/developers-native/query-indexer/derivatives
Example code snippets to query the indexer for derivative module related data.
## Using gRPC
### Fetch markets
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcDerivativesApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(
endpoints.indexer
);
const markets = await indexerGrpcDerivativesApi.fetchMarkets();
console.log(markets);
```
### Fetch market based on a market id
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcDerivativesApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(
endpoints.indexer
);
const marketId = "0x...";
const market = await indexerGrpcDerivativesApi.fetchMarket(marketId);
console.log(market);
```
### Fetch binary options markets
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcDerivativesApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(
endpoints.indexer
);
const binaryOptionsMarket =
await indexerGrpcDerivativesApi.fetchBinaryOptionsMarkets();
console.log(binaryOptionsMarket);
```
### Fetch binary options market based on market id
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcDerivativesApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(
endpoints.indexer
);
const marketId = "0x...";
const binaryOptionsMarket =
await indexerGrpcDerivativesApi.fetchBinaryOptionsMarket(marketId);
console.log(binaryOptionsMarket);
```
### Fetch a market's orderbook based on market id
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcDerivativesApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(
endpoints.indexer
);
const marketId = "0x...";
const orderbook = await indexerGrpcDerivativesApi.fetchOrderbookV2(marketId);
console.log(orderbook);
```
### Fetch a market's orders
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { OrderSide } from '@injectivelabs/sdk-ts/types'
import { PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcDerivativesApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const orderSide = OrderSide.Buy /* optional param */
const subaccountId = '0x...' /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const orders = await indexerGrpcDerivativesApi.fetchOrders({
marketId,
orderSide,
subaccountId,
pagination
})
console.log(orders)
```
### Fetch a market's order history
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { OrderSide, TradeDirection, PaginationOption, TradeExecutionType } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcDerivativesApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer)
const marketIds = ['0x...'] /* optional param */
const executionTypes = [TradeExecutionType.Market] /* optional param */
const orderTypes = OrderSide.StopBuy /* optional param */
const direction = TradeDirection.Buy /* optional param */
const subaccountId = '0x...' /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const orderHistory = await indexerGrpcDerivativesApi.fetchOrderHistory({
marketIds,
executionTypes,
orderTypes,
direction,
subaccountId,
pagination
})
console.log(orderHistory)
```
### Fetch a market's positions
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { TradeDirection, PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcDerivativesApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer)
const marketIds = ['0x...'] /* optional param */
const direction = TradeDirection.Buy /* optional param */
const subaccountId = '0x...' /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const positions = await indexerGrpcDerivativesApi.fetchPositions({
marketIds,
direction,
subaccountId,
pagination
})
console.log(positions)
```
### Fetch a market's trades
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { TradeDirection, PaginationOption, TradeExecutionType } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcDerivativesApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const executionTypes = [TradeExecutionType.Market] /* optional param */
const direction = TradeDirection.Buy /* optional param */
const subaccountId = '0x...'/* optional param */
const pagination = {...} as PaginationOption /* optional param */
const trades = await indexerGrpcDerivativesApi.fetchTrades({
marketId,
executionTypes,
direction,
subaccountId,
pagination
})
console.log(trades)
```
### Fetch funding payments for a market
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcDerivativesApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer)
const marketIds = ['0x...'] /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const fundingPayments = await indexerGrpcDerivativesApi.fetchFundingPayments({
marketIds,
pagination
})
console.log(fundingPayments)
```
### Fetch funding rates for a market
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcDerivativesApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const fundingRates = await indexerGrpcDerivativesApi.fetchFundingRates({
marketId,
pagination
})
console.log(fundingRates)
```
### Fetch subaccount orders
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcDerivativesApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const subaccountId = '0x...' /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const subaccountOrders = await indexerGrpcDerivativesApi.fetchSubaccountOrdersList({
marketId,
subaccountId,
pagination
})
console.log(subaccountOrders)
```
### Fetch subaccount trades
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { TradeDirection, TradeExecutionType, PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcDerivativesApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const subaccountId = '0x...' /* optional param */
const executionType = TradeExecutionType.LimitFill /* optional param */
const direction = TradeDirection.Sell /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const subaccountTrades = await indexerGrpcDerivativesApi.fetchSubaccountTradesList({
marketId,
subaccountId,
executionType,
direction,
pagination
})
console.log(subaccountTrades)
```
### Fetch orderbooks for multiple markets
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcDerivativesApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(
endpoints.indexer
);
const marketIds = ["0x..."];
const orderbooks = await indexerGrpcDerivativesApi.fetchOrderbooksV2(marketIds);
console.log(orderbooks);
```
### Fetch orderbook for a market
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcDerivativesApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(
endpoints.indexer
);
const marketId = "0x...";
const orderbook = await indexerGrpcDerivativesApi.fetchOrderbookV2(marketId);
console.log(orderbook);
```
## Using HTTP REST
### Fetch market summary, such as a history of prices and 24 hr volume
```ts theme={null}
import { IndexerRestDerivativesChronosApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestDerivativesChronosApi = new IndexerRestDerivativesChronosApi(
`${endpoints.chronos}/api/chronos/v1/derivative`
);
const marketId = "0x...";
const marketSummary = await indexerRestDerivativesChronosApi.fetchMarketSummary(
marketId
);
console.log(marketSummary);
```
### Fetch all markets' summaries, such as a history of prices and 24 hr volume
```ts theme={null}
import { IndexerRestDerivativesChronosApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestDerivativesChronosApi = new IndexerRestDerivativesChronosApi(
`${endpoints.chronos}/api/chronos/v1/derivative`
);
const marketSummaries =
await indexerRestDerivativesChronosApi.fetchMarketsSummary(marketId);
console.log(marketSummaries);
```
# Explorer
Source: https://docs.injective.network/developers-native/query-indexer/explorer
Example code snippets to query the indexer for explorer module related data.
## Using gRPC
### Fetch transaction by hash
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const txsHash = "...";
const transaction = await indexerGrpcExplorerApi.fetchTxByHash(txsHash);
console.log(transaction);
```
### Fetch an account transaction by address
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const injectiveAddress = "inj...";
const account = await indexerGrpcExplorerApi.fetchAccountTx({
injectiveAddress,
});
console.log(account);
```
### Fetch a validator by address
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const validatorAddress = "injvaloper...";
const validator = await indexerGrpcExplorerApi.fetchValidator(validatorAddress);
console.log(validator);
```
### Fetch a validator's uptime by address
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const validatorAddress = "injvaloper...";
const validatorUptime = await indexerGrpcExplorerApi.fetchValidatorUptime(
validatorAddress
);
console.log(validatorUptime);
```
### Fetch a validator's uptime by address
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const validatorAddress = "injvaloper...";
const validatorUptime = await indexerGrpcExplorerApi.fetchValidatorUptime(
validatorAddress
);
console.log(validatorUptime);
```
### Fetch Peggy deposit transactions from Ethereum
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const sender = "0x..."; /* optional parameter */
const receiver = "inj..."; /* optional parameter */
const limit = 100; /* optional pagination parameter */
const skip = 20; /* optional pagination parameter */
const peggyDeposits = await indexerGrpcExplorerApi.fetchPeggyDepositTxs({
sender,
receiver,
limit,
skip,
});
console.log(peggyDeposits);
```
### Fetch Peggy withdrawal transactions to Ethereum
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const receiver = "0x..."; /* optional parameter */
const sender = "inj..."; /* optional parameter */
const limit = 100; /* optional pagination parameter */
const skip = 20; /* optional pagination parameter */
const peggyWithdrawals = await indexerGrpcExplorerApi.fetchPeggyWithdrawalTxs({
sender,
receiver,
limit,
skip,
});
console.log(peggyWithdrawals);
```
### Fetch blocks
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const after = 30; /* optional pagination parameter */
const limit = 100; /* optional pagination parameter */
const blocks = await indexerGrpcExplorerApi.fetchBlocks({
after,
limit,
});
console.log(blocks);
```
### Fetch block by height
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const height = 123456;
const block = await indexerGrpcExplorerApi.fetchBlock(height);
console.log(block);
```
### Fetch transactions
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const after = 20; /* optional pagination parameter */
const limit = 100; /* optional pagination parameter */
const transactions = await indexerGrpcExplorerApi.fetchTxs({
after,
limit,
});
console.log(transactions);
```
### Fetch IBC transfer transactions
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerGrpcExplorerApi(endpoints.explorer);
const sender = "osmo...";
const receiver = "inj...";
const ibcTransactions = await indexerGrpcExplorerApi.fetchIBCTransferTxs({
sender,
receiver,
});
console.log(ibcTransactions);
```
## Using HTTP REST
### Fetch a block and details
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const blockHashHeight = 1;
const block = await indexerRestExplorerApi.fetchBlock(blockHashHeight);
console.log(block);
```
### Fetch blocks and details
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const before = 200; /* optional pagination param */
const limit = 100; /* optional pagination param */
const blocks = await indexerRestExplorerApi.fetchBlocks({
before,
limit,
});
console.log(blocks);
```
### Fetch blocks with transaction details
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const before = 200; /* optional pagination param */
const limit = 100; /* optional pagination param */
const blocks = await indexerRestExplorerApi.fetchBlocksWithTx({
before,
limit,
});
console.log(blocks);
```
### Fetch transactions
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const after = 200; /* optional pagination param */
const limit = 100; /* optional pagination param */
const fromNumber = 1; /* optional param */
const toNumber = 100; /* optional param */
const transactions = await indexerRestExplorerApi.fetchTransactions({
after,
limit,
fromNumber,
toNumber,
});
console.log(transactions);
```
### Fetch transactions for an address
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const account = "inj...";
const after = 200; /* optional pagination param */
const limit = 100; /* optional pagination param */
const fromNumber = 1; /* optional param */
const toNumber = 100; /* optional param */
const accountTransactions =
await indexerRestExplorerApi.fetchAccountTransactions({
account,
params: {
account,
after,
limit,
fromNumber,
toNumber,
},
});
console.log(accountTransactions);
```
### Fetch transaction using transaction hash
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const txsHash = "...";
const transaction = await indexerRestExplorerApi.fetchTransaction(txsHash);
console.log(transaction);
```
### Fetch validators
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const validators = await indexerRestExplorerApi.fetchValidators();
console.log(validators);
```
### Fetch validator uptime
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const validatorAddress = "injvalcons";
const validatorUptime = await indexerRestExplorerApi.fetchValidatorUptime(
validatorAddress
);
console.log(validatorUptime);
```
### Fetch a contract by contract address
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const contractAddress = "inj...";
const contract = await indexerRestExplorerApi.fetchContract(contractAddress);
console.log(contract);
```
### Fetch contracts
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const limit = 100; /* optional pagination param */
const skip = 50; /* optional pagination param */
const contracts = await indexerRestExplorerApi.fetchContracts({
limit,
skip,
});
console.log(contracts);
```
### Fetch contract transactions
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const contractAddress = "inj...";
const limit = 100; /* optional pagination param */
const skip = 50; /* optional pagination param */
const transactions = await indexerRestExplorerApi.fetchContractTransactions({
contractAddress,
params: {
limit,
skip,
},
});
console.log(transactions);
```
### Fetch cosmwasm code details
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const codeId = 1;
const codeDetails = await indexerRestExplorerApi.fetchWasmCode(codeId);
console.log(codeDetails);
```
### Fetch wasm codes and details
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const limit = 100; /* optional pagination param */
const fromNumber = 50; /* optional pagination param */
const toNumber = 150; /* optional pagination param */
const codes = await indexerRestExplorerApi.fetchWasmCodes({
limit,
fromNumber,
toNumber,
});
console.log(codes);
```
### Fetch cw20 balances
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestExplorerApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestExplorerApi = new IndexerRestExplorerApi(
`${endpoints.explorer}/api/explorer/v1`
);
const address = "inj...";
const cw20Balances = await indexerRestExplorerApi.fetchCW20BalancesNoThrow(
address
);
console.log(cw20Balances);
```
# Querying the Indexer
Source: https://docs.injective.network/developers-native/query-indexer/index
This section covers how to query data from the Injective Indexer API.
* [Account](/developers-native/query-indexer/account/) - Query account data
* [Auction](/developers-native/query-indexer/auction/) - Query auction data
* [Derivatives](/developers-native/query-indexer/derivatives/) - Query derivatives market data
* [Explorer](/developers-native/query-indexer/explorer/) - Query explorer data
* [Insurance Funds](/developers-native/query-indexer/insurance-funds/) - Query insurance funds data
* [Markets](/developers-native/query-indexer/markets/) - Query market data
* [Leaderboard](/developers-native/query-indexer/leaderboard/) - Query leaderboard data
* [Mito](/developers-native/query-indexer/mito/) - Query Mito vault data
* [Oracle](/developers-native/query-indexer/oracle/) - Query oracle data
* [Portfolio](/developers-native/query-indexer/portfolio/) - Query portfolio data
* [Spot](/developers-native/query-indexer/spot/) - Query spot market data
* [Transaction](/developers-native/query-indexer/transaction/) - Query transaction data
# Insurance Funds
Source: https://docs.injective.network/developers-native/query-indexer/insurance-funds
Example code snippets to query the indexer for insurance fund module related data.
## Using gRPC
### Fetch redemptions for an injective address
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcInsuranceFundApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcInsuranceFundApi = new IndexerGrpcInsuranceFundApi(
endpoints.indexer
);
const injectiveAddress = "inj...";
const redemptions = await indexerGrpcInsuranceFundApi.fetchRedemptions({
injectiveAddress,
});
console.log(redemptions);
```
### Fetch insurance funds
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcInsuranceFundApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcInsuranceFundApi = new IndexerGrpcInsuranceFundApi(
endpoints.indexer
);
const insuranceFunds = await indexerGrpcInsuranceFundApi.fetchInsuranceFunds();
console.log(insuranceFunds);
```
# Leaderboard
Source: https://docs.injective.network/developers-native/query-indexer/leaderboard
Example code snippets to query the indexer for leaderboard module related data.
## Using HTTP REST
### Fetch leaderboard
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestLeaderboardChronosApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcExplorerApi = new IndexerRestLeaderboardChronosApi(
`${endpoints.chronos}/api/chronos/v1/leaderboard`
);
const SelectList = {
Day: "1d",
Week: "7d",
};
const resolution = SelectList.Day;
const leaderboard = await indexerGrpcExplorerApi.fetchLeaderboard(resolution);
console.log(leaderboard);
```
# Markets
Source: https://docs.injective.network/developers-native/query-indexer/markets
Example code snippets to query the indexer for all markets data
## Using HTTP REST
### Fetch markets History
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerRestMarketChronosApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestMarketChronosApi = new IndexerRestMarketChronosApi(
`${endpoints.chronos}/api/chronos/v1/market`
);
const SelectList = {
Hour: "60",
Day: "1d",
Week: "7d",
};
// const resolution = MARKETS_HISTORY_CHART_ONE_HOUR
// const countback = MARKETS_HISTORY_CHART_SEVEN_DAYS
const marketIds = ["0x"];
const countback = 154; // in unit of hours
const resolution = SelectList.Day;
const marketsHistory = await indexerRestMarketChronosApi.fetchMarketsHistory({
marketIds,
resolution,
countback,
});
console.log(marketsHistory);
```
# Mito
Source: https://docs.injective.network/developers-native/query-indexer/mito
Example code snippets to query the indexer for Mito vault module related data.
Mito Documentation has been moved here visit[ Mito's
Docs](https://docs.mito.fi/).
## (Outdated) Using gRPC
### Fetch a vault based off it's contract address, such as a vault's tvl or profits
```ts theme={null}
import { IndexerGrpcMitoApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcMitoApi = new IndexerGrpcMitoApi(endpoints.indexer);
const contractAddress = "0x..."; /* optional param */
const slug = "derivative-vault"; /* optional param */
const vault = await indexerGrpcMitoApi.fetchVault({
contractAddress,
slug,
});
console.log(vault);
```
### Fetch vaults and associated details
```ts theme={null}
import { IndexerGrpcMitoApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcMitoApi = new IndexerGrpcMitoApi(endpoints.indexer);
const vault = await indexerGrpcMitoApi.fetchVaults();
console.log(vault);
```
### Fetch the lp token price chart for a vault based on the vault address
```ts theme={null}
import { IndexerGrpcMitoApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcMitoApi = new IndexerGrpcMitoApi(endpoints.indexer);
const vaultAddress = "inj...";
const from = 50; /* optional pagination params */
const to = 150; /* optional pagination params */
const lpTokenPriceChart = await indexerGrpcMitoApi.fetchLpTokenPriceChart({
vaultAddress,
from,
to,
});
console.log(lpTokenPriceChart);
```
### Fetch the tvl token chart for a vault based on the vault address
```ts theme={null}
import { IndexerGrpcMitoApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcMitoApi = new IndexerGrpcMitoApi(endpoints.indexer);
const vaultAddress = "inj...";
const from = 50; /* optional pagination params */
const to = 150; /* optional pagination params */
const tvlChart = await indexerGrpcMitoApi.fetchTVLChartRequest({
vaultAddress,
from,
to,
});
console.log(tvlChart);
```
### Fetch the vaults associated with a holder of its lp tokens
```ts theme={null}
import { IndexerGrpcMitoApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcMitoApi = new IndexerGrpcMitoApi(endpoints.indexer);
const holderAddress = "inj...";
const vaults = await indexerGrpcMitoApi.fetchVaultsByHolderAddress({
holderAddress,
});
console.log(vaults);
```
### Fetch the lp token holders from the vault address
```ts theme={null}
import { IndexerGrpcMitoApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcMitoApi = new IndexerGrpcMitoApi(endpoints.indexer);
const vaultAddress = "inj...";
const holders = await indexerGrpcMitoApi.fetchLPHolders({
vaultAddress,
});
console.log(holders);
```
### Fetch the lp holder's portfolio
```ts theme={null}
import { IndexerGrpcMitoApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcMitoApi = new IndexerGrpcMitoApi(endpoints.indexer);
const holderAddress = "inj...";
const portfolio = await indexerGrpcMitoApi.fetchHolderPortfolio(holderAddress);
console.log(portfolio);
```
### Fetch the leaderboard to see Pnl rankings
```ts theme={null}
import { IndexerGrpcMitoApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcMitoApi = new IndexerGrpcMitoApi(endpoints.indexer);
const leaderboard = await indexerGrpcMitoApi.fetchLeaderboard();
console.log(leaderboard);
```
# Oracle
Source: https://docs.injective.network/developers-native/query-indexer/oracle
Example code snippets to query the indexer for oracle module related data.
## Using gRPC
### Fetch list of oracles
```ts theme={null}
import { IndexerGrpcOracleApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcOracleApi = new IndexerGrpcOracleApi(endpoints.indexer);
const oracleList = await indexerGrpcOracleApi.fetchOracleList();
console.log(oracleList);
```
### Fetch price from the oracle
Base and Quote oracle symbols are always fetched from the market itself. They can be in a different representation than plain symbols (i.e hashes for `pyth` oracle).
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import {
IndexerGrpcOracleApi,
IndexerGrpcDerivativesApi,
} from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcDerivativesApi = new IndexerGrpcDerivativesApi(endpoints.indexer);
const indexerGrpcOracleApi = new IndexerGrpcOracleApi(endpoints.indexer);
// Fetch the list of derivative markets
const markets = await indexerGrpcDerivativesApi.fetchMarkets();
// Find the specific market by ticker
const market = markets.find((market) => market.ticker === "INJ/USDT PERP");
if (!market) {
throw new Error("Market not found");
}
// These values are a part of the market object
// fetched from the indexer i.e `oracleBase` and `oracleQuote`
const baseSymbol = market.oracleBase;
const quoteSymbol = market.oracleQuote;
const oracleType = market.oracleType;
const oraclePrice = await indexerGrpcOracleApi.fetchOraclePriceNoThrow({
baseSymbol,
quoteSymbol,
oracleType,
});
console.log(oraclePrice);
```
# Portfolio
Source: https://docs.injective.network/developers-native/query-indexer/portfolio
Example code snippets to query the indexer for portfolio module related data.
## Using gRPC
### Fetch portfolio based on injective address, such as bank balances and subaccount balances
```ts lines highlight={1} theme={null}
import { IndexerGrpcPortfolioApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcPortfolioApi = new IndexerGrpcPortfolioApi(endpoints.indexer);
const injectiveAddress = "inj...";
const portfolio = await indexerGrpcPortfolioApi.fetchAccountPortfolioBalances(
injectiveAddress
);
console.log(portfolio);
```
# Spot
Source: https://docs.injective.network/developers-native/query-indexer/spot
Example code snippets to query the indexer for spot market module related data.
## Using gRPC
### Fetch markets
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcSpotApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer);
const markets = await indexerGrpcSpotApi.fetchMarkets();
console.log(markets);
```
### Fetch market based on market id
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcSpotApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer);
const marketId = "0x...";
const market = await indexerGrpcSpotApi.fetchMarket(marketId);
console.log(market);
```
### Fetch market's orders
```ts theme={null}
import { OrderSide } from '@injectivelabs/sdk-ts/types'
import { PaginationOption } from '@injectivelabs/sdk-ts/types'
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { IndexerGrpcSpotApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const orderSide = OrderSide.Buy /* optional param */
const subaccountId = '0x...' /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const orders = await indexerGrpcSpotApi.fetchOrders({
marketId,
orderSide,
subaccountId,
pagination
})
console.log(orders)
```
### Fetch market's order history
```ts theme={null}
import { TradeDirection, PaginationOption, TradeExecutionType, OrderSide } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcSpotApi } from '@injectivelabs/sdk-ts/client/indexer'
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer)
const marketIds = ['0x...'] /* optional param */
const executionTypes = [TradeExecutionType.Market] /* optional param */
const orderTypes = OrderSide.Buy /* optional param */
const direction = TradeDirection.Buy /* optional param */
const subaccountId = '0x...' /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const orderHistory = await indexerGrpcSpotApi.fetchOrderHistory({
marketIds,
executionTypes,
orderTypes,
direction,
subaccountId,
pagination
})
console.log(orderHistory)
```
### Fetch market's trades
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { TradeDirection, PaginationOption, TradeExecutionType } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcSpotApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const executionTypes = [TradeExecutionType.Market] /* optional param */
const direction = TradeDirection.Buy /* optional param */
const subaccountId = '0x...'/* optional param */
const pagination = {...} as PaginationOption /* optional param */
const trades = await indexerGrpcSpotApi.fetchTrades({
marketId,
executionTypes,
direction,
subaccountId,
pagination
})
console.log(trades)
```
### Fetch list of subaccount orders
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcSpotApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const subaccountId = '0x...' /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const subaccountOrders = await indexerGrpcSpotApi.fetchSubaccountOrdersList({
marketId,
subaccountId,
pagination
})
console.log(subaccountOrders)
```
### Fetch list of subaccount trades
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { TradeDirection, TradeExecutionType, PaginationOption } from '@injectivelabs/sdk-ts/types'
import { IndexerGrpcSpotApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer)
const marketId = '0x...' /* optional param */
const subaccountId = '0x...' /* optional param */
const executionType = TradeExecutionType.LimitFill /* optional param */
const direction = TradeDirection.Sell /* optional param */
const pagination = {...} as PaginationOption /* optional param */
const subaccountTrades = await indexerGrpcSpotApi.fetchSubaccountTradesList({
marketId,
subaccountId,
executionType,
direction,
pagination
})
console.log(subaccountTrades)
```
### Fetch orderbooks for multiple markets
```ts theme={null}
import { IndexerGrpcSpotApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer);
const marketIds = ["0x..."];
const orderbooks = await indexerGrpcSpotApi.fetchOrderbooksV2(marketIds);
console.log(orderbooks);
```
### Fetch orderbook for a market
```ts theme={null}
import { IndexerGrpcSpotApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcSpotApi = new IndexerGrpcSpotApi(endpoints.indexer);
const marketId = "0x...";
const orderbook = await indexerGrpcSpotApi.fetchOrderbookV2(marketId);
console.log(orderbook);
```
## Using HTTP REST
### Fetch market summary, such as a history of prices and 24 hr volume
```ts theme={null}
import { IndexerRestSpotChronosApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestSpotChronosApi = new IndexerRestSpotChronosApi(
`${endpoints.chronos}/api/chronos/v1/spot`
);
const marketId = "0x...";
const marketSummary = await indexerRestSpotChronosApi.fetchMarketSummary(
marketId
);
console.log(marketSummary);
```
### Fetch all markets summaries, such as a history of prices and 24 hr volume
```ts theme={null}
import { IndexerRestSpotChronosApi } from "@injectivelabs/sdk-ts/client/indexer";
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerRestSpotChronosApi = new IndexerRestSpotChronosApi(
`${endpoints.chronos}/api/chronos/v1/spot`
);
const marketSummaries = await indexerRestSpotChronosApi.fetchMarketsSummary(
marketId
);
console.log(marketSummaries);
```
# Web3 Gateway Transactions
Source: https://docs.injective.network/developers-native/query-indexer/transaction
Example code snippets to query the indexer for transaction module related data. Used only when interacting with the [Web3Gateway](../transactions/web3-gateway/)
## Using gRPC
### Fetch response for preparing a transaction
```ts theme={null}
import { EvmChainId } from '@injectivelabs/ts-types'
import { Msgs } from '@injectivelabs/sdk-ts/core/modules'
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { IndexerGrpcTransactionApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcTransactionApi = new IndexerGrpcTransactionApi(endpoints.indexer)
const address = '0x...' // ethereum address
const chainId = EvmChainId.Sepolia
const message = { ... } as Msgs
const memo = '...'
const prepareTxResponse = await indexerGrpcTransactionApi.prepareTxRequest({
address,
chainId,
message,
memo
})
console.log(prepareTxResponse)
```
### Fetch response for preparing a cosmos transaction
```ts theme={null}
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { IndexerGrpcTransactionApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcTransactionApi = new IndexerGrpcTransactionApi(endpoints.indexer)
const address = 'inj...'
const message = { ... }
const prepareCosmosTxResponse = await indexerGrpcTransactionApi.prepareCosmosTxRequest({
address,
message
})
console.log(prepareCosmosTxResponse)
```
### Fetch response for broadcasting transactions using the Web3Gateway
Use `MsgBroadcasterWithPk` to broadcast transactions within a node/CLI environment, which can be found in `@injectivelabs/sdk-ts`.
Use `@injectivelabs/wallet-core`'s `MsgBroadcaster` class for more details on broadcasting a transactions in a browser environment.
```ts theme={null}
import { Msgs } from '@injectivelabs/sdk-ts/core/modules'
import { ChainId, EvmChainId } from '@injectivelabs/ts-types'
import { WalletStrategy } from '@injectivelabs/wallet-strategy'
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { IndexerGrpcTransactionApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcTransactionApi = new IndexerGrpcTransactionApi(endpoints.indexer)
const chainId = ChainId.Testnet // The Injective Testnet Chain ID
const evmChainId = EvmChainId.TestnetEvm // The Injective Evm Testnet Chain ID
export const evmRpcEndpoint = `https://eth-sepolia.g.alchemy.com/v2/${process.env.APP_EVM_RPC_KEY}`
const walletStrategy = new WalletStrategy({
chainId,
evmOptions: {
evmChainId,
rpcUrl: evmRpcEndpoint,
},
})
const address = '0x...' // ethereum address
const message = { ... } as Msgs
const memo = '...'
const response = { ... } // response from prepareTxRequest
const signature = await walletStrategy.signEip712TypedData(
response.getData(),
address,
) /* see @injectivelabs/wallet-strategy implementation of WalletStrategy. Essentially, you use the signEip712TypedData method of the wallet, if the wallet supports signing ethereum transactions */
const broadcastTxResponse = await indexerGrpcTransactionApi.broadcastTxRequest({
signature,
chainId,
message,
txResponse: response
})
console.log(broadcastTxResponse)
```
### Fetch response for broadcasting a cosmos transactions.
```ts theme={null}
import { TxRaw } from '@injectivelabs/sdk-ts/types'
import { getNetworkEndpoints, Network } from '@injectivelabs/networks'
import { IndexerGrpcTransactionApi } from '@injectivelabs/sdk-ts/client/indexer'
const endpoints = getNetworkEndpoints(Network.Testnet)
const indexerGrpcTransactionApi = new IndexerGrpcTransactionApi(endpoints.indexer)
const address = 'inj...' // ethereum address
const signature = '...' // base64
const txRaw = { ... } as TxRaw
const pubKey = {
type: string,
value: string // base64
}
const broadcastCosmosTxResponse = await indexerGrpcTransactionApi.broadcastCosmosTxRequest({
address,
signature,
txRaw,
pubKey
})
console.log(broadcastCosmosTxResponse)
```
### Fetch Web3Gateway Fee Payer
```ts theme={null}
import { getNetworkEndpoints, Network } from "@injectivelabs/networks";
import { IndexerGrpcTransactionApi } from "@injectivelabs/sdk-ts/client/indexer";
const endpoints = getNetworkEndpoints(Network.Testnet);
const indexerGrpcTransactionApi = new IndexerGrpcTransactionApi(
endpoints.indexer
);
const feePayer = await indexerGrpcTransactionApi.fetchFeePayer();
console.log(feePayer);
```
# Ethereum Transaction
Source: https://docs.injective.network/developers-native/transactions/ethereum
Every transaction on Injective follows the same flow. The flow consists of three steps: preparing, signing and broadcasting the transaction. Let's dive into each step separately and explain the process in-depth (including examples) so we can understand the whole transaction flow.
## Preparing a transaction
First of, we need to prepare the transaction for signing. To use Ethereum native wallets, we have to convert the transaction to EIP712 typed data and use the wallet to sign this typed data.
Using our custom abstraction for the Messages which allows the developer to get EIP712 TypedData straight from the proto file of the particular message.
```ts theme={null}
import {
MsgSend,
} from "@injectivelabs/sdk-ts/core/modules";
import {
BaseAccount,
} from "@injectivelabs/sdk-ts/core/accounts";
import {
ChainRestAuthApi,
ChainRestTendermintApi,
} from "@injectivelabs/sdk-ts/client/chain";
import {
getEip712TypedDataV2,
} from "@injectivelabs/sdk-ts/core/tx";
import {
toBigNumber,
toChainFormat,
DEFAULT_BLOCK_TIMEOUT_HEIGHT,
} from "@injectivelabs/utils";
import { ChainId, EvmChainId } from "@injectivelabs/ts-types";
import { Network, getNetworkEndpoints } from "@injectivelabs/networks";
const injectiveAddress = "inj1";
const chainId = ChainId.Mainnet;
const evmChainId = EvmChainId.Mainnet;
const restEndpoint =
"https://lcd.injective.network"; /* getNetworkEndpoints(Network.Mainnet).rest */
const amount = {
denom: "inj",
amount: toChainFormat(0.01).toFixed(),
};
/** Account Details **/
const chainRestAuthApi = new ChainRestAuthApi(restEndpoint);
const accountDetailsResponse = await chainRestAuthApi.fetchAccount(
injectiveAddress
);
const baseAccount = BaseAccount.fromRestApi(accountDetailsResponse);
const accountDetails = baseAccount.toAccountDetails();
/** Block Details */
const chainRestTendermintApi = new ChainRestTendermintApi(restEndpoint);
const latestBlock = await chainRestTendermintApi.fetchLatestBlock();
const latestHeight = latestBlock.header.height;
const timeoutHeight = toBigNumber(latestHeight).plus(
DEFAULT_BLOCK_TIMEOUT_HEIGHT
);
/** Preparing the transaction */
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
/** EIP712 for signing on Ethereum wallets */
const eip712TypedData = getEip712TypedDataV2({
msgs: [msg],
tx: {
accountNumber: accountDetails.accountNumber.toString(),
sequence: accountDetails.sequence.toString(),
timeoutHeight: timeoutHeight.toFixed(),
chainId: chainId,
},
evmChainId,
});
```
## Signing a transaction
Once we have prepared the EIP712 typed data, we proceed to signing.
```ts theme={null}
/** Use your preferred approach to sign EIP712 TypedData, example with Metamask */
const signature = await window.ethereum.request({
method: "eth_signTypedData_v4",
params: [
ethereumAddress,
JSON.stringify(eip712TypedData /* from previous step */),
],
});
/** Get Public Key of the signer */
const publicKeyHex = recoverTypedSignaturePubKey(eip712TypedData, signature);
const publicKeyBase64 = hexToBase64(publicKeyHex);
```
You can also use our `@injectivelabs/wallet-strategy` package to get out-of-the-box wallet provides that will give you abstracted methods which you can use to sign transaction. Refer to the documentation of the package, its really simple to setup and use. **This is the recommended way as you have access to more than one wallet to use in your dApp. The `WalletStrategy` provides more than just signing transaction abstractions.**
## Broadcasting a transaction
Once we have the signature ready, we need to broadcast the transaction to the Injective chain itself. After getting the signature from the second step, we need to include that signature in the signed transaction and broadcast it to the chain.
```ts theme={null}
import {
Network,
SIGN_AMINO,
getNetworkEndpoints,
} from "@injectivelabs/networks";
import { getDefaultStdFee } from "@injectivelabs/utils";
import { ChainId, EvmChainId } from "@injectivelabs/ts-types";
import { createTransaction, TxRestApi } from "@injectivelabs/sdk-ts/core/tx";
const evmChainId = EvmChainId.Mainnet;
const { txRaw } = createTransaction({
message: msgs,
memo: memo,
signMode: SIGN_AMINO,
fee: getDefaultStdFee(),
pubKey: publicKeyBase64 /* From previous step */,
sequence: baseAccount.sequence,
timeoutHeight: timeoutHeight.toNumber(),
accountNumber: baseAccount.accountNumber,
chainId: chainId,
});
const web3Extension = createWeb3Extension({
evmChainId,
});
const txRawEip712 = createTxRawEIP712(txRaw, web3Extension);
/** Append Signatures */
txRawEip712.signatures = [signatureBuff /* From previous step */];
/** Broadcast the Transaction */
const restEndpoint =
"https://lcd.injective.network"; /* getNetworkEndpoints(Network.Mainnet).rest */
const txRestApi = new TxRestApi(restEndpoint);
const txHash = await txRestApi.broadcast(txRawEip712);
/**
* Once we get the txHash, because we use the Sync mode we
* are not sure that the transaction is included in the block,
* it can happen that it's still in the mempool so we need to query
* the chain to see when the transaction will be included
*/
/** This will poll querying the transaction and await for it's inclusion in the block */
const response = await txRestApi.fetchTxPoll(txHash);
```
## Example without WalletStrategy (Prepare + Sign + Broadcast)
Let's have a look at the whole flow (using Metamask as a signing wallet)
```ts theme={null}
import {
MsgSend,
} from "@injectivelabs/sdk-ts/core/modules";
import {
BaseAccount,
} from "@injectivelabs/sdk-ts/core/accounts";
import {
TxRestApi,
SIGN_AMINO,
hexToBase64,
createTransaction,
createTxRawEIP712,
getEip712TypedData,
createWeb3Extension,
recoverTypedSignaturePubKey,
} from "@injectivelabs/sdk-ts/core/tx";
import {
ChainRestAuthApi,
ChainRestTendermintApi,
} from "@injectivelabs/sdk-ts/client/chain";
import {
getEthereumAddress,
} from "@injectivelabs/sdk-ts/utils";
import {
toBigNumber,
toChainFormat,
getDefaultStdFee,
DEFAULT_BLOCK_TIMEOUT_HEIGHT,
} from "@injectivelabs/utils";
import { ChainId, EvmChainId } from "@injectivelabs/ts-types";
import { Network, getNetworkEndpoints } from "@injectivelabs/networks";
const injectiveAddress = "inj1";
const chainId = ChainId.Mainnet;
const evmChainId = EvmChainId.Mainnet;
const ethereumAddress = getEthereumAddress(injectiveAddress);
const restEndpoint = getNetworkEndpoints(Network.MainnetSentry).rest;
const amount = {
denom: "inj",
amount: toChainFormat(0.01).toFixed(),
};
/** Account Details **/
const chainRestAuthApi = new ChainRestAuthApi(restEndpoint);
const accountDetailsResponse = await chainRestAuthApi.fetchAccount(
injectiveAddress
);
const baseAccount = BaseAccount.fromRestApi(accountDetailsResponse);
const accountDetails = baseAccount.toAccountDetails();
/** Block Details */
const chainRestTendermintApi = new ChainRestTendermintApi(restEndpoint);
const latestBlock = await chainRestTendermintApi.fetchLatestBlock();
const latestHeight = latestBlock.header.height;
const timeoutHeight = toBigNumber(latestHeight).plus(
DEFAULT_BLOCK_TIMEOUT_HEIGHT
);
/** Preparing the transaction */
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
/** EIP712 for signing on Ethereum wallets */
const eip712TypedData = getEip712TypedData({
msgs: [msg],
tx: {
accountNumber: accountDetails.accountNumber.toString(),
sequence: accountDetails.sequence.toString(),
timeoutHeight: timeoutHeight.toFixed(),
chainId,
},
evmChainId,
});
/** Use your preferred approach to sign EIP712 TypedData, example with Metamask */
const signature = await window.ethereum.request({
method: "eth_signTypedData_v4",
params: [ethereumAddress, JSON.stringify(eip712TypedData)],
});
/** Get Public Key of the signer */
const publicKeyHex = recoverTypedSignaturePubKey(eip712TypedData, signature);
const publicKeyBase64 = hexToBase64(publicKeyHex);
const signatureBuff = Buffer.from(signature.replace("0x", ""), "hex");
const { txRaw } = createTransaction({
message: [msg],
memo: "",
signMode: SIGN_AMINO,
fee: getDefaultStdFee(),
pubKey: publicKeyBase64,
sequence: baseAccount.sequence,
timeoutHeight: timeoutHeight.toNumber(),
accountNumber: baseAccount.accountNumber,
chainId: chainId,
});
const web3Extension = createWeb3Extension({
evmChainId,
});
const txRawEip712 = createTxRawEIP712(txRaw, web3Extension);
/** Append Signatures */
txRawEip712.signatures = [signatureBuff];
/** Broadcast the Transaction */
const txRestApi = new TxRestApi(restEndpoint);
const txResponse = await txRestApi.broadcast(txRawEip712);
const response = await txRestApi.fetchTxPoll(txResponse.txHash);
```
## Example with WalletStrategy (Prepare + Sign + Broadcast)
Example can be found in the [wallet-core package](https://github.com/InjectiveLabs/injective-ts/tree/master/packages/wallets/wallet-core).
# Ethereum Ledger Transaction
Source: https://docs.injective.network/developers-native/transactions/ethereum-ledger
## Signing Transactions on Injective using Ledger
The goal of this document is to explain how to use Ledger to sign transactions on Injective and broadcast them to the chain. The implementation differs from the default approach that Cosmos SDK native chains have because Injective defines its custom Account type that uses Ethereum's ECDSA secp256k1 curve for keys.
## Implementation
To understand how we should do the implementation, let’s go through some concepts so it's easier to understand the approach we are going to take.
### Background
A derivation path is a piece of data that tells a Hierarchical Deterministic (HD) wallet how to derive a specific key within a tree of keys. Derivation paths are used as a standard and were introduced with HD wallets as a part of BIP32. A Hierarchical Deterministic Wallet is a term used to describe a wallet that uses a seed to derive many public and private keys.
This is what a derivation path looks like
`m/purpose'/coin_type'/account'/change/address_index`
Each of the parts in the sequence plays a part and each changes what the private key, public key, and address would be. We are not going to deep dive into the exact details about what every part of the HD path means, instead, we are just going to briefly explain the `coin_type`. Each blockchain has a number that represents it i.e the `coin_type`. Bitcoin is `0`, Ethereum is `60`, Cosmos is `118`.
### Injective specific context
Injective uses the same `coin_type` as Ethereum, i.e `60`. This means for Ledger to be used to sign transactions on Injective, **we have to use the Ethereum app on Ledger**.
Ledger is limited to having one installed application for one `coin_type`. As we have to use the Ethereum app to sign transactions on Injective, we have to explore available options to us to get a valid signature. One of the available options is the `EIP712` procedure for hashing and signing typed structured data. Ledger exposes the `signEIP712HashedMessage` which we are going to use.
Once we sign the `EIP712` typed data, we are going to pack the transaction using the normal Cosmos-SDK approach of packing and broadcasting the transaction. There are some minor differences, one of them being using the `SIGN_MODE_LEGACY_AMINO_JSON` mode and appending a `Web3Exension` to the Cosmos transaction and we are going to explain them in this document.
### EIP712 Typed Data
EIP 712 is a standard for hashing and signing of typed structured data. For every EIP712 typed data, each of the values the user passes (that need to be signed) has a type representative which explains the exact type of that particular value. In addition to the value the user wants to sign and its type (the `PrimaryType` of the EIP712 typedData), every EIP712 typed data should contain an `EIP712Domain` which provides context about the source of the transaction.
## Transaction Flow
The implementation itself consists of a few steps, namely:
1. Preparing the transaction to be signed using the Ethereum app on Ledger,
2. Preparing and signing the transaction on Ledger,
3. Preparing the transaction to be broadcasted,
4. Broadcast the transaction.
We are going deep dive into each step and elaborate on the actions we need to take to get the transaction signed and broadcasted to the chain.
### Preparing the transaction (for signing)
As we’ve said above, the transaction needs to be signed using the Ethereum app on Ledger. This means that the user has to be prompted to switch (or open) the Ethereum app on Ledger once they reach the signing stage.
We know that each Cosmos transaction consists of messages which signify the instructions the user wants to execute on the chain. If we want to send funds from one address to another, we are going to pack the `MsgSend` message into a transaction and broadcast it to the chain.
Knowing this, the Injective team made [abstraction](https://github.com/InjectiveLabs/injective-ts/blob/master/packages/sdk-ts/src/core/modules/MsgBase.ts) of these Messages to simplify the way they are packed into a transaction. Each of these Messages accepts a specific set of parameters that are needed to instantiate the message. Once this is done, the abstraction exposes a couple of convenient methods which we can use based on the signing/broadcasting method we chose to use. As an example, the Message exposes the `toDirectSign` method which returns the type and the proto representation of the message which can be then used to pack the transaction using the default Cosmos approach, sign it using a privateKey and broadcast it to the chain.
What is of importance for us for this particular implementation are the `toEip712Types` and `toEip712` methods. Calling the first one on an instance of the Message gives out the types of the Message for the EIP712 typed data and the second one gives the values of the Message for the EIP712 data. When we combine these two methods we can generate valid EIP712 typed data which can be passed down to the signing process.
So, let’s see a quick code snippet of the usage of these methods and how we can generate EIP712 typedData from a message:
```ts theme={null}
import {
MsgSend,
} from "@injectivelabs/sdk-ts/core/modules";
import {
getEip712TypedDataV2,
type Eip712ConvertTxArgs,
type Eip712ConvertFeeArgs,
} from "@injectivelabs/sdk-ts/core/tx";
import { EvmChainId } from "@injectivelabs/ts-types";
import { toChainFormat, getDefaultStdFee } from "@injectivelabs/utils";
/** More details on these two interfaces later on */
const txArgs: Eip712ConvertTxArgs = {
accountNumber: accountDetails.accountNumber.toString(),
sequence: accountDetails.sequence.toString(),
timeoutHeight: timeoutHeight.toFixed(),
chainId: chainId,
};
const txFeeArgs: Eip712ConvertFeeArgs = getDefaultStdFee();
const injectiveAddress = "inj14au322k9munkmx5wrchz9q30juf5wjgz2cfqku";
const amount = {
denom: "inj",
amount: toChainFormat(0.01).toFixed(),
};
const evmChainId = EvmChainId.Mainnet;
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
/** The EIP712 TypedData that can be used for signing **/
const eip712TypedData = getEip712TypedDataV2({
msgs: msg,
tx: txArgs,
evmChainId,
fee: txFeeArgs,
});
return eip712TypedData;
```
### Preparing the signing process on Ledger
Now that we have the `eip712TypedData` we need to sign it using Ledger. First, we need to get the Ledger’s transport depending on the support that the user has on the browser and use the `@ledgerhq/hw-app-eth` to make a Ledger instance with the transport that’ll use the Ethereum app on the Ledger device for executing the user’s actions (confirming transactions). After we get the `eip712TypedData` from Step 1, we can use the `signEIP712HashedMessage` on the `EthereumApp` to sign this typedData and return the signature.
```ts theme={null}
import { TypedDataUtils } from 'eth-sig-util'
import { bufferToHex, addHexPrefix } from 'ethereumjs-util'
import EthereumApp from '@ledgerhq/hw-app-eth'
const domainHash = (message: any) =>
TypedDataUtils.hashStruct('EIP712Domain', message.domain, message.types, true)
const messageHash = (message: any) =>
TypedDataUtils.hashStruct(
message.primaryType,
message.message,
message.types,
true,
)
const transport = /* Get the transport from Ledger */
const ledger = new EthereumApp(transport)
const derivationPath = /* Get the derivation path for the address */
/* eip712TypedData from Step 1 */
const object = JSON.parse(eip712TypedData)
const result = await ledger.signEIP712HashedMessage(
derivationPath,
bufferToHex(domainHash(object)),
bufferToHex(messageHash(object)),
)
const combined = `${result.r}${result.s}${result.v.toString(16)}`
const signature = combined.startsWith('0x') ? combined : `0x${combined}`
return signature;
```
### Preparing the transaction to be broadcasted
Now that we have the signature, we can prepare the transaction using the default cosmos approach.
```ts theme={null}
import {
SIGN_AMINO,
createTransaction,
createTxRawEIP712,
createWeb3Extension,
} from "@injectivelabs/sdk-ts/core/tx";
import {
BaseAccount,
} from "@injectivelabs/sdk-ts/core/accounts";
import {
ChainRestAuthApi,
ChainRestTendermintApi,
} from "@injectivelabs/sdk-ts/client/chain";
import { ChainId, EvmChainId } from "@injectivelabs/ts-types";
import {
toBigNumber,
DEFAULT_BLOCK_TIMEOUT_HEIGHT,
} from "@injectivelabs/utils";
const msg: MsgSend; /* from Step 1 */
const chainId = ChainId.Mainnet;
const evmChainId = EvmChainId.Mainnet;
/** Account Details **/
const chainRestAuthApi = new ChainRestAuthApi(lcdEndpoint);
const accountDetailsResponse = await chainRestAuthApi.fetchAccount(
injectiveAddress
);
const baseAccount = BaseAccount.fromRestApi(accountDetailsResponse);
const accountDetails = baseAccount.toAccountDetails();
/** Block Details */
const chainRestTendermintApi = new ChainRestTendermintApi(lcdEndpoint);
const latestBlock = await chainRestTendermintApi.fetchLatestBlock();
const latestHeight = latestBlock.header.height;
const timeoutHeight = toBigNumber(latestHeight).plus(
DEFAULT_BLOCK_TIMEOUT_HEIGHT
);
const { txRaw } = createTransaction({
message: msgs,
memo: "",
signMode: SIGN_AMINO,
fee: getDefaultStdFee(),
pubKey: publicKeyBase64,
sequence: baseAccount.sequence,
timeoutHeight: timeoutHeight.toNumber(),
accountNumber: baseAccount.accountNumber,
chainId,
});
const web3Extension = createWeb3Extension({
evmChainId,
});
const txRawEip712 = createTxRawEIP712(txRaw, web3Extension);
/** Append Signatures */
const signatureBuff = Buffer.from(signature.replace("0x", ""), "hex");
txRawEip712.signatures = [signatureBuff];
return txRawEip712;
```
### Broadcasting the transaction
Now that we have the transaction packed into `TxRaw` we can broadcast it to the node using the default cosmos approach.
## Codebase
Let’s see an example codebase containing all of the steps above
```ts theme={null}
import {
TxRestApi,
SIGN_AMINO,
createTransaction,
createTxRawEIP712,
createWeb3Extension,
getEip712TypedDataV2,
type Eip712ConvertTxArgs,
type Eip712ConvertFeeArgs
} from '@injectivelabs/sdk-ts/core/tx'
import {
MsgSend,
} from '@injectivelabs/sdk-ts/core/modules'
import {
BaseAccount,
} from '@injectivelabs/sdk-ts/core/accounts'
import {
ChainRestAuthApi,
ChainRestTendermintApi,
} from '@injectivelabs/sdk-ts/client/chain'
import { TypedDataUtils } from 'eth-sig-util'
import EthereumApp from '@ledgerhq/hw-app-eth'
import { bufferToHex, addHexPrefix } from 'ethereumjs-util'
import { EvmChainId, ChainId } from '@injectivelabs/ts-types'
import { toChainFormat, DEFAULT_BLOCK_TIMEOUT_HEIGHT, getDefaultStdFee } from '@injectivelabs/utils'
const domainHash = (message: any) =>
TypedDataUtils.hashStruct('EIP712Domain', message.domain, message.types, true)
const messageHash = (message: any) =>
TypedDataUtils.hashStruct(
message.primaryType,
message.message,
message.types,
true,
)
const signTransaction = async (eip712TypedData: any) => {
const transport = /* Get the transport from Ledger */
const ledger = new EthereumApp(transport)
const derivationPath = /* Get the derivation path for the address */
/* eip712TypedData from Step 1 */
const result = await ledger.signEIP712HashedMessage(
derivationPath,
bufferToHex(domainHash(eip712TypedData)),
bufferToHex(messageHash(eip712TypedData)),
)
const combined = `${result.r}${result.s}${result.v.toString(16)}`
const signature = combined.startsWith('0x') ? combined : `0x${combined}`
return signature;
}
const getAccountDetails = (address: string): BaseAccount => {
const chainRestAuthApi = new ChainRestAuthApi(
lcdEndpoint,
)
const accountDetailsResponse = await chainRestAuthApi.fetchAccount(
address,
)
const baseAccount = BaseAccount.fromRestApi(accountDetailsResponse)
const accountDetails = baseAccount.toAccountDetails()
return accountDetails
}
const getTimeoutHeight = () => {
const chainRestTendermintApi = new ChainRestTendermintApi(
lcdEndpoint,
)
const latestBlock = await chainRestTendermintApi.fetchLatestBlock()
const latestHeight = latestBlock.header.height
const timeoutHeight = latestHeight + DEFAULT_BLOCK_TIMEOUT_HEIGHT
return timeoutHeight
}
const address = 'inj14au322k9munkmx5wrchz9q30juf5wjgz2cfqku'
const chainId = ChainId.Mainnet
const evmChainId = EvmChainId.Mainnet
const accountDetails = getAccountDetails()
const timeoutHeight = getTimeoutHeight
const txArgs: Eip712ConvertTxArgs = {
accountNumber: accountDetails.accountNumber.toString(),
sequence: accountDetails.sequence.toString(),
timeoutHeight: timeoutHeight.toString(),
chainId: chainId,
}
const txFeeArgs: Eip712ConvertFeeArgs = getDefaultStdFee()
const injectiveAddress = 'inj14au322k9munkmx5wrchz9q30juf5wjgz2cfqku'
const amount = {
amount: toChainFormat(0.01).toFixed(),
denom: "inj",
};
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
/** The EIP712 TypedData that can be used for signing **/
const eip712TypedData = getEip712TypedDataV2({
msgs: msg,
tx: txArgs,
evmChainId,
fee: txFeeArgs
})
/** Signing on Ethereum */
const signature = await signTransaction(eip712TypedData)
/** Preparing the transaction for client broadcasting */
const { txRaw } = createTransaction({
message: msg,
memo: '',
signMode: SIGN_AMINO,
fee: getDefaultStdFee(),
pubKey: publicKeyBase64,
sequence: accountDetails.sequence,
timeoutHeight: timeoutHeight.toNumber(),
accountNumber: accountDetails.accountNumber,
chainId: chainId,
})
const web3Extension = createWeb3Extension({
evmChainId,
})
const txRawEip712 = createTxRawEIP712(txRaw, web3Extension)
/** Append Signatures */
const signatureBuff = Buffer.from(signature.replace('0x', ''), 'hex')
txRawEip712.signatures = [signatureBuff]
/** Broadcast the transaction **/
const txRestApi = new TxRestApi(lcdEndpoint)
const response = await txRestApi.broadcast(txRawEip712)
if (response.code !== 0) {
throw new Error(`Transaction failed: ${response.rawLog}`)
}
return response.txhash
```
# MsgBroadcaster Transaction
Source: https://docs.injective.network/developers-native/transactions/msgbroadcaster
The `MsgBroadcaster` abstraction class is a way to broadcast transactions on Injective with ease. With it, you can pass a Message that you want to be packed in a transaction and the signer's address and the transaction will be prepared, signed, and broadcasted.
An example of usage can be found on our [Helix demo repo](https://github.com/InjectiveLabs/injective-helix-demo). As for the messages that you can pass to the `broadcast` methods, you can find examples in the [Core Modules](../examples/) section of the docs.
## MsgBroadcaster + Wallet Strategy
This MsgBroadcaster is used alongside the Wallet Strategy class for building decentralized applications.
To instantiate (and use) the `MsgBroadcaster` class, you can use the following code snippet
```ts theme={null}
import { toChainFormat } from "@injectivelabs/utils";
import { ChainId, EvmChainId } from "@injectivelabs/ts-types";
import { MsgSend } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcaster } from "@injectivelabs/wallet-core";
import { WalletStrategy } from "@injectivelabs/wallet-strategy";
import { Network, getNetworkEndpoints } from "@injectivelabs/networks";
export const evmRpcEndpoint = "";
export const walletStrategy = new WalletStrategy({
chainId: ChainId.Mainnet,
evmOptions: {
rpcUrl: evmRpcEndpoint,
evmChainId: EvmChainId.Mainnet,
},
strategies: {},
});
export const msgBroadcaster = new MsgBroadcaster({
walletStrategy,
simulateTx: true,
network: Network.Mainnet,
endpoints: getNetworkEndpoints(Network.Mainnet),
gasBufferCoefficient: 1.1,
});
// Usage Example
const signer = "inj1...";
const msg = MsgSend.fromJSON({
amount: {
denom: "inj",
amount: toChainFormat(0.01, 18).toFixed(),
},
srcInjectiveAddress: signer,
dstInjectiveAddress: "inj1...",
});
// Prepare + Sign + Broadcast the transaction using the Wallet Strategy
await msgBroadcaster.broadcast({
injectiveAddress: signer,
msgs: msg,
});
```
### Constructor/Broadcast Options
We allow to override some of the options passed to the constructor of `MsgBroadcaster` as well as when broadcasting the transaction. Here is the interface and the meaning of each field
```typescript theme={null}
import { Msgs } from '@injectivelabs/sdk-ts/core/modules'
import { ChainId, EvmChainId } from '@injectivelabs/ts-types'
import { Network, NetworkEndpoints } from '@injectivelabs/networks'
import type { WalletStrategy } from '../strategies'
export interface MsgBroadcasterOptions {
network: Network /** network configuration (chainId, fees, etc) - Network.MainnetSentry for mainnet or Network.TestnetSentry for testnet */
endpoints?: NetworkEndpoints /** optional - overriding the endpoints taken from the `network` param **/
feePayerPubKey?: string /** optional - if you are using the fee delegation service, you can set the fee payer so you don't do an extra query to the Web3Gateway */
simulateTx?: boolean /** simulate the transaction before broadcasting + get gas fees needed for the transaction */
txTimeout?: number /** optional - blocks to wait for tx to be included in a block **/
walletStrategy: WalletStrategy
gasBufferCoefficient?: number /** optional - as gas buffer to add to the simulated/hardcoded gas to ensure the transaction is included in a block */
}
export interface MsgBroadcasterTxOptions {
memo?: string /** MEMO added to the transaction **/
injectiveAddress: string /** the signer of the transaction **/
msgs: Msgs | Msgs[] /** the messages to pack into a transaction **/
/*
*** overriding the hardcoded gas/simulation -
*** depending on the simulateTx parameter in
*** the MsgBroadcaster constructor
*/
gas?: {
gasPrice?: string
gas?: number /** gas limit */
feePayer?: string
granter?: string
}
}
```
To override the `endpoints` and use your infrastructure (which is something we
recommend), please read more on the
[Networks](../../developers/concepts/networks/) page on the endpoints you need
to provide and how to set them up.
## MsgBroadcaster with Private Key
This MsgBroadcaster is used with a private key (mostly used for CLI environments). Constructor/broadcast options are quite similar as for the `MsgBroadcaster`.
```ts theme={null}
import { toChainFormat } from "@injectivelabs/utils";
import { MsgSend } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
export const msgBroadcasterWithPk = new MsgBroadcasterWithPk({
privateKey: `0x...` /** private key hash or PrivateKey class from sdk-ts */,
network: NETWORK,
});
// Usage Example
const signer = "inj1...";
const msg = MsgSend.fromJSON({
amount: {
denom: "inj",
amount: toChainFormat(0.01, 18).toFixed(),
},
srcInjectiveAddress: signer,
dstInjectiveAddress: "inj1...",
});
// Prepare + Sign + Broadcast the transaction using the Private Key
await msgBroadcasterWithPk.broadcast({
injectiveAddress: signer,
msgs: msg,
});
```
# Private Key Transaction
Source: https://docs.injective.network/developers-native/transactions/private-key
In this document, we are going to show you how to use a PrivateKey to sign transactions on Injective.
Every transaction on Injective follows the same flow. The flow consists of three steps: preparing, signing and broadcasting the transaction. Let's dive into each step separately and explain the process in-depth (including examples) so we can understand the whole transaction flow.
## Preparing a transaction
First of, we need to prepare the transaction for signing.
```ts theme={null}
import {
toBigNumber,
toChainFormat,
getDefaultStdFee,
DEFAULT_BLOCK_TIMEOUT_HEIGHT,
} from "@injectivelabs/utils";
import {
ChainRestAuthApi,
ChainRestTendermintApi,
} from "@injectivelabs/sdk-ts/client/chain";
import { ChainId } from "@injectivelabs/ts-types";
import { MsgSend } from "@injectivelabs/sdk-ts/core/modules";
import { createTransaction } from "@injectivelabs/sdk-ts/core/tx";
import { Network, getNetworkEndpoints } from "@injectivelabs/networks";
import { PrivateKey, BaseAccount } from "@injectivelabs/sdk-ts/core/accounts";
const privateKeyHash = "";
const privateKey = PrivateKey.fromHex(privateKeyHash);
const injectiveAddress = privateKey.toBech32();
const address = privateKey.toAddress();
const pubKey = privateKey.toPublicKey().toBase64();
const chainId = "injective-1"; /* ChainId.Mainnet */
const restEndpoint =
"https://lcd.injective.network"; /* getNetworkEndpoints(Network.Mainnet).rest */
const amount = {
denom: "inj",
amount: toChainFormat(0.01).toFixed(),
};
/** Account Details **/
const chainRestAuthApi = new ChainRestAuthApi(restEndpoint);
const accountDetailsResponse = await chainRestAuthApi.fetchAccount(
injectiveAddress
);
const baseAccount = BaseAccount.fromRestApi(accountDetailsResponse);
const accountDetails = baseAccount.toAccountDetails();
/** Block Details */
const chainRestTendermintApi = new ChainRestTendermintApi(restEndpoint);
const latestBlock = await chainRestTendermintApi.fetchLatestBlock();
const latestHeight = latestBlock.header.height;
const timeoutHeight = toBigNumber(latestHeight).plus(
DEFAULT_BLOCK_TIMEOUT_HEIGHT
);
/** Preparing the transaction */
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
/** Prepare the Transaction **/
const { txRaw, signBytes } = createTransaction({
pubKey,
chainId,
message: msg,
fee: getDefaultStdFee(),
sequence: baseAccount.sequence,
timeoutHeight: timeoutHeight.toNumber(),
accountNumber: baseAccount.accountNumber,
});
```
## Signing a transaction
Once we have prepared the transaction, we proceed to signing. Once you get the `txRaw` transaction from the previous step use any Cosmos native wallet to sign (ex: Keplr),
```ts theme={null}
import { ChainId } from '@injectivelabs/ts-types'
/* Sign the Transaction */
const privateKeyHash = ''
const privateKey = PrivateKey.fromHex(privateKeyHash);
const signBytes = /* From the previous step */
/** Sign transaction */
const signature = await privateKey.sign(Buffer.from(signBytes));
```
## Broadcasting a transaction
Once we have the signature ready, we need to broadcast the transaction to the Injective chain itself. After getting the signature from the second step, we need to include that signature in the signed transaction and broadcast it to the chain.
```ts theme={null}
import { ChainId } from '@injectivelabs/ts-types'
import { TxClient } from '@injectivelabs/sdk-ts/core/tx'
import { TxGrpcApi } from '@injectivelabs/sdk-ts/client/chain'
import { Network, getNetworkInfo } from '@injectivelabs/networks'
/** Append Signatures */
const network = getNetworkInfo(Network.Testnet);
const txRaw = /* from the first step */
const signature = /* from the second step */
txRaw.signatures = [signature];
/** Calculate hash of the transaction */
console.log(`Transaction Hash: ${TxClient.hash(txRaw)}`);
const txService = new TxGrpcApi(network.grpc);
/** Simulate transaction */
const simulationResponse = await txService.simulate(txRaw);
console.log(
`Transaction simulation response: ${JSON.stringify(
simulationResponse.gasInfo
)}`
);
/** Broadcast transaction */
const txResponse = await txService.broadcast(txRaw);
console.log(txResponse);
if (txResponse.code !== 0) {
console.log(`Transaction failed: ${txResponse.rawLog}`);
} else {
console.log(
`Broadcasted transaction hash: ${JSON.stringify(txResponse.txHash)}`
);
}
```
## Example (Prepare + Sign + Broadcast)
Let's have a look at the whole flow (using Keplr as a signing wallet)
```ts theme={null}
import {
TxClient,
TxGrpcApi,
createTransaction,
} from "@injectivelabs/sdk-ts/core/tx";
import { MsgSend } from "@injectivelabs/sdk-ts/core/modules";
import { PrivateKey } from "@injectivelabs/sdk-ts/core/accounts";
import { getNetworkInfo, Network } from "@injectivelabs/networks";
import { ChainRestAuthApi } from "@injectivelabs/sdk-ts/client/chain";
import { toChainFormat, getDefaultStdFee } from "@injectivelabs/utils";
/** MsgSend Example */
(async () => {
const network = getNetworkInfo(Network.Testnet);
const privateKeyHash =
"f9db9bf330e23cb7839039e944adef6e9df447b90b503d5b4464c90bea9022f3";
const privateKey = PrivateKey.fromHex(privateKeyHash);
const injectiveAddress = privateKey.toBech32();
const publicKey = privateKey.toPublicKey().toBase64();
/** Account Details **/
const accountDetails = await new ChainRestAuthApi(network.rest).fetchAccount(
injectiveAddress
);
/** Prepare Message */
const amount = {
denom: "inj",
amount: toChainFormat(0.01).toFixed(),
};
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
/** Prepare the Transaction **/
const { signBytes, txRaw } = createTransaction({
message: msg,
memo: "",
pubKey: publicKey,
fee: getDefaultStdFee(),
sequence: parseInt(accountDetails.account.base_account.sequence, 10),
accountNumber: parseInt(
accountDetails.account.base_account.account_number,
10
),
chainId: network.chainId,
});
/** Sign transaction */
const signature = await privateKey.sign(Buffer.from(signBytes));
/** Append Signatures */
txRaw.signatures = [signature];
/** Calculate hash of the transaction */
console.log(`Transaction Hash: ${TxClient.hash(txRaw)}`);
const txService = new TxGrpcApi(network.grpc);
/** Simulate transaction */
const simulationResponse = await txService.simulate(txRaw);
console.log(
`Transaction simulation response: ${JSON.stringify(
simulationResponse.gasInfo
)}`
);
/** Broadcast transaction */
const txResponse = await txService.broadcast(txRaw);
if (txResponse.code !== 0) {
console.log(`Transaction failed: ${txResponse.rawLog}`);
} else {
console.log(
`Broadcasted transaction hash: ${JSON.stringify(txResponse.txHash)}`
);
}
})();
```
## Example with MsgBroadcasterWithPk
You can use the `MsgBroadcasterWithPk` class from the `@injectivelabs/sdk-ts` package which abstracts away most of the logic written above into a single class.
**This abstraction allows you to sign transactions in a Node/CLI environment.**
```ts theme={null}
import { Network } from "@injectivelabs/networks";
import { toChainFormat } from "@injectivelabs/utils";
import { MsgSend } from "@injectivelabs/sdk-ts/core/modules";
import { MsgBroadcasterWithPk } from "@injectivelabs/sdk-ts/core/tx";
const privateKey = "0x...";
const injectiveAddress = "inj1...";
const amount = {
denom: "inj",
amount: toChainFormat(1).toFixed(),
};
const msg = MsgSend.fromJSON({
amount,
srcInjectiveAddress: injectiveAddress,
dstInjectiveAddress: injectiveAddress,
});
const txHash = await new MsgBroadcasterWithPk({
privateKey,
network: Network.Testnet,
}).broadcast({
msgs: msg,
});
console.log(txHash);
```
# Web3 Gateway Transaction
Source: https://docs.injective.network/developers-native/transactions/web3-gateway
*Pre-requisite reading #1:* [Transaction Lifecycle](https://docs.cosmos.network/main/basics/tx-lifecycle)
*Pre-requisite reading #2:* Transactions on Injective
The Web3Gateway microservice exposes an API to the end user with the main purpose of providing fee delegation for transactions that happen on Injective. This allows users to enjoy a gasless environment while interacting with Injective as the gas is paid for by the runner of the Web3Gateway service.
Alongside fee delegation support, Web3Gateway allows developers to convert Messages to EIP712 typed data. After converting the Message the EIP712 data, it can be signed by any Ethereum native wallet and then broadcasted to Injective.
## Fee Delegation
As said before, fee delegation allows users to interact with Injective (submit transactions) without having to pay for gas. As a part of the *Transaction Lifecycle* of every Cosmos-SDK powered chain, we have `AnteHandler`'s, which, among other things perform a signature verification, gas calculation, and fee deduction.
There are a couple of things that we need to know:
* Transactions can have multiple signers (i.e we can include multiple signatures within a transaction),
* Gas Fee for the transaction is deducted from the `authInfo.fee.feePayer` value and the signature that gets verified against the `feePayer` is the first signature within the signatures list of the Transaction ([reference](https://github.com/cosmos/cosmos-sdk/blob/e2d6cbdeb55555893ffde3f2ae0ed6db7179fd0d/x/auth/ante/fee.go#L15-L24)),
* The rest of the signatures are being verified against the actual sender of the transaction.
Knowing this, to achieve fee delegation, we have to sign the transaction using the private key of the Web3Gateway microservice, including the address of that `privateKey` as a `feePayer`, sign this transaction using the privateKey that we want to interact with Injective from, and broadcast that transaction.
## Web3Gateway API
Everyone can run the Web3Gateway microservice and provide fee delegation services to their users. An example usage can be developers who build exchange dApps on top of Injective run this microservice to offer a gasless trading environment to their traders.
This microservice exposes an API containing two core methods:
* `PrepareTx`(and `PrepareCosmosTx`)
* `BroadcastTx` (and `BroadcastCosmosTx`)
## PrepareTx
The `PrepareTx` method accepts a Message(s) including context for the transaction the user wants to execute (`chainId`, `signerAddress`, `timeoutHeight`, etc), and returns an EIP712 typed data of the particular message, including its signature within the EIP712 typed data. We can use this EIP712 typed data to sign it using any Ethereum native wallet and get the signature for users who want to interact with Injective.
The EIP712 typed data is generated from the proto definition of the Message we pass to the `PrepareTx` method.
## BroadcastTx
The `BroadcastTx` method is responsible for broadcasting the transaction to the node. Alongside the full response of the `PrepareTx` API call, we pass in the signature of the EIP712 typed data. Then, the `BroadcastTx` packs the Message into a native Cosmos transaction, prepares the transaction (including its context) and broadcasts it to Injective. As a result, the transaction hash is being returned to the user.
## Prepare/BroadcastCosmosTx
The above methods are used when we use **Ethereum Native wallets** to sign and broadcast transactions as we sign an EIP712 transaction representation.
If we want support fee delegation on Cosmos native wallets using the Web3Gateway, we can omit the PrepareCosmosTx call (or call it if we need the Web3Gateway signer's `publicKey`), prepare the transaction on the client side, sign it using a Cosmos wallet, and broadcast it using the `BroadcastCosmosTx` method.
The way this works is we add the `publicKey` of the `Web3Gateway`'s signer to the `authInfo` object in the `TxRaw` and then sign the transaction using the `privateKey` on the API side when we broadcast
The difference with the previous EIP712 approach is that we need to sign the transaction using the `Web3Gateway`'s signer in advance i.e when we generate the EIP712 → meaning that we need to use `PrepareTx` and can't generate the transaction on the client side.).
# Core
Source: https://docs.injective.network/developers-native/core/index
## Core Modules
# State Transitions
Source: https://docs.injective.network/developers-native/injective/insurance/02_state_transitions
# State Transitions
This document describes the state transition operations pertaining to:
* Creating an insurance fund
* Underwriting an insurance fund
* Request a redemption from the insurance fund
* Automatic processing of matured redemption requests
## Creating insurance fund
**Params description**
`Sender` field describes the creator of an insurance fund .
`Ticker`, `QuoteDenom`, `OracleBase`, `OracleQuote`, `OracleType`, `Expiry` fields describe the derivative market info
that the insurance fund associated to.
`InitialDeposit` field describes the initial deposit amount to be put on the insurance fund.
**Steps**
* Get `MarketId` for the insurance fund - **Note**, market could be not available yet on `exchange` and it's not an
issue
* Ensure if insurance fund associated to the `MarketId` does not exist
* Ensure if initial deposit amount is not zero
* Get `shareDenom` that is unique - it's incremented when share denom is requested for insurance fund creation or when
underwriting insurance fund that has zero balance and non-zero total share denom supply.
* Send coins from creator's account to insurance fund module account
* Create insurance fund object with `DefaultRedemptionNoticePeriodDuration` and with the params provided
* Set `Balance` of fund object to initial deposit amount
* Mint `InsuranceFundInitialSupply` (10^18) `shareDenom` tokens to creator account
* Save insurance fund object to store
* Register newly created insurance fund `shareDenom` metadata inside BankKeeper
## Underwriting an insurance fund
**Params description**
`Sender` field describes the underwriter of an insurance fund .
`MarketId` field describes the derivative market id to the insurance fund.
`Deposit` field describes the deposit amount to be added on the insurance fund.
**Steps**
* Ensure if insurance fund associated to the `MarketId` does exist
* Send underwriting tokens from sender's account to module account
* Make actions based on the status of insurance fund associated to the `MarketId`.
* A. when `Balance` and `ShareDenomSupply` are zero
1. mint `InsuranceFundInitialSupply` (10^18) to the sender.
2. set `Balance` to deposit amount
3. set `ShareDenomSupply` to `InsuranceFundInitialSupply`
* B. when `Balance` is zero and `ShareDenomSupply` is not zero
1. change `ShareDenom` of the the insurance fund to start new insurance fund from beginning.
2. register newly created `ShareDenom` in bank keeper
3. mint `InsuranceFundInitialSupply` (10^18) to the sender.
4. set `Balance` to deposit amount
5. set `ShareDenomSupply` to `InsuranceFundInitialSupply`
* C. when `Balance` is not zero and `ShareDenomSupply` is zero
1. mint `InsuranceFundInitialSupply` (10^18) to the sender.
2. increase `Balance` by deposit amount
3. set `ShareDenomSupply` to `InsuranceFundInitialSupply`
* D. when both `Balance` and `ShareDenomSupply` are not zero - normal case
1. increase `Balance` by deposit amount
2. mint `prev_ShareDenomSupply * deposit_amount / prev_Balance` amount of `ShareDenom` to sender
3. increase `ShareDenomSupply` with mint amount
* Save insurance fund object to store
## Requesting a redemption from an insurance fund
**Params description**
`Sender` field describes the redemption requester of an insurance fund .
`MarketId` field describes the derivative market id associated to the insurance fund.
`Amount` field describes the share token amount to be redeemed.
**Steps**
* Ensure insurance fund associated to the `MarketId` does exist
* Send `ShareDenom` to module account
* Get new redemption schedule ID
* Calculate `ClaimTime` from insurance fund's redemption notice period duration and current block time
* Calculate key to store pending redemption (redemption schedule)
* Create redemption schedule object with details
* Store redemption schedule object to store
## Insurance fund actions on liquidation events in derivative market
**Steps**
* `exchange` module finds relative insurance fund from the insurance keeper.
* if `missingFund` is positive, it withdraws the amount from the insurance fund through `WithdrawFromInsuranceFund`.
* if `missingFund` is negative, it deposits the amount into the insurance fund through `DepositIntoInsuranceFund`.
## Automatic processing of pending redemptions
**Steps**
Iterate all matured redemptions by sorted order by `ClaimTime` and perform the following actions:
* If `ClaimTime` is after current block time, break early
* Ensure the insurance fund exist for matured redemption schedule
* Calculate redeem amount from share amount - `shareAmt * fund.Balance * fund.TotalShare`
* Send calculate redeem amount from module account to redeemer account
* Burn share tokens sent to the module account at the time of redemption schedule
* Delete redemption schedule object
* Reduce insurance fund's `Balance` by redeem amount
* Store updated insurance object to store
# Hooks
Other modules may register operations to execute when a certain event has occurred within insurance fund. These events
can be registered to execute either right `Before` or `After` the exchange event (as per the hook name). The following
hooks can registered with the exchange:
**Note**: Hooks are not available and exchange module calls insurance keeper function directly.
**Steps**
When liquidation event happen in derivative market
* `exchange` module finds relative insurance fund from the insurance keeper.
* if `missingFund` is positive, it withdraws the amount from the insurance fund through `WithdrawFromInsuranceFund`.
* if `missingFund` is negative, it deposits the amount into the insurance fund through `DepositIntoInsuranceFund`.
# Messages
Source: https://docs.injective.network/developers-native/injective/insurance/03_messages
# Messages
In this section we describe the processing of the exchange messages and the corresponding updates to the state. All created/modified state objects specified by each message are defined within the [state](./02_state_transitions) section.
## Msg/CreateInsuranceFund
`MsgCreateInsuranceFund` defines a message to create an insurance fund for a derivative market.
```protobuf theme={null}
// MsgCreateInsuranceFund a message to create an insurance fund for a derivative market.
message MsgCreateInsuranceFund {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
// Creator of the insurance fund.
string sender = 1;
// Ticker for the derivative market.
string ticker = 2;
// Coin denom to use for the market quote denom
string quote_denom = 3;
// Oracle base currency
string oracle_base = 4;
// Oracle quote currency
string oracle_quote = 5;
// Oracle type
injective.oracle.v1beta1.OracleType oracle_type = 6;
// Expiration time of the market. Should be -1 for perpetual markets.
int64 expiry = 7;
// Initial deposit of the insurance fund
cosmos.base.v1beta1.Coin initial_deposit = 8 [(gogoproto.nullable) = false];
}
```
**Fields description**
* `Sender` field describes the creator of an insurance fund .
* `Ticker`, `QuoteDenom`, `OracleBase`, `OracleQuote`, `OracleType`, `Expiry` fields describe the derivative market info
that the insurance fund corresponds to.
* `InitialDeposit` specifies the initial deposit amount used to underwrite the insurance fund.
Disclaimer: When creating an insurance fund a small portion of shares (1%) will be reserved by the fund itself (protocol owned liquidity). A value of 1 USD is recommended as first subscription.
Motivation behind this feature is to avoid potential rounding issues when underwriting to a fund. For example, without having protocol owned liquidity, if the original fund creator would take out most of their shares leaving but a small amount, the value of the share token could diverge drastically from the original value. The next underwriter would then have to provide a much larger deposit despite gaining the same amount of shares.
## Msg/Underwrite
`MsgUnderwrite` defines a message to underwrite an insurance fund
```protobuf theme={null}
// MsgUnderwrite defines a message for depositing coins to underwrite an insurance fund
message MsgUnderwrite {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
// Address of the underwriter.
string sender = 1;
// MarketID of the insurance fund.
string market_id = 2;
// Amount of quote_denom to underwrite the insurance fund.
cosmos.base.v1beta1.Coin deposit = 3 [(gogoproto.nullable) = false];
}
```
**Fields description**
* `Sender` field describes the underwriter of an insurance fund .
* `MarketId` field describes the derivative market id to the insurance fund.
* `Deposit` field describes the deposit amount to be added on the insurance fund.
## Msg/RequestRedemption
`MsgRequestRedemption` defines a message to request redemption from the insurance fund.
```protobuf theme={null}
// MsgRequestRedemption defines a message for requesting a redemption of the sender's insurance fund tokens
message MsgRequestRedemption {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
// Address of the underwriter requesting a redemption.
string sender = 1;
// MarketID of the insurance fund.
string market_id = 2;
// Insurance fund share token amount to be redeemed.
cosmos.base.v1beta1.Coin amount = 3 [(gogoproto.nullable) = false];
}
```
**Fields description**
* `Sender` field describes the redemption requester of an insurance fund .
* `MarketId` field describes the derivative market id associated to the insurance fund.
* `Amount` field describes the share token amount to be redeemed.
# End-Block
Source: https://docs.injective.network/developers-native/injective/insurance/04_end_block
# End-Block
At each EndBlock, redemption requests that have matured are automatically processed, resulting in the insurance pool token for the redemption being burned and the pro-rata quote currency amount corresponding to the redemption being withdrawn from the insurance module to the underwriter's balances. More details can be found in the in Automatic withdrawal of pending redemptions in the [state transitions](./02_state_transitions) section.
# Events
Source: https://docs.injective.network/developers-native/injective/insurance/05_events
# Events
The insurance module emits the following events:
## Handlers
### MsgCreateInsuranceFund
| Type | Attribute Key | Attribute Value |
| ---------------------------------------------------- | ------------- | --------------- |
| injective.insurance.v1beta1.EventInsuranceFundUpdate | fund | |
### MsgUnderwrite
| Type | Attribute Key | Attribute Value |
| ---------------------------------------------------- | ------------- | --------------- |
| injective.insurance.v1beta1.EventInsuranceFundUpdate | fund | |
### MsgRequestRedemption
| Type | Attribute Key | Attribute Value |
| -------------------------------------------------- | ------------- | --------------- |
| injective.insurance.v1beta1.EventRequestRedemption | schedule | |
## EndBlocker
| Type | Attribute Key | Attribute Value |
| ---------------------------------------------------- | ------------- | --------------- |
| injective.insurance.v1beta1.EventInsuranceFundUpdate | fund | |
| injective.insurance.v1beta1.EventWithdrawRedemption | schedule | |
| injective.insurance.v1beta1.EventWithdrawRedemption | redeem\_coin | |
# Parameters
Source: https://docs.injective.network/developers-native/injective/insurance/06_params
# Parameters
The insurance module contains the following parameter:
| Key | Type | Example |
| --------------------------------------------- | ------------- | --------------------- |
| default\_redemption\_notice\_period\_duration | time.Duration | `time.Hour * 24 * 14` |
# Future Improvements
Source: https://docs.injective.network/developers-native/injective/insurance/07_future_improvements
# Future improvements
## Precision Loss Edge Case Handling
Insurance Fund share tokens currently have a decimal scale of `10^18`. There could be potential problems using this as user deposits amount could be various and in the future, share token's price could be very higher or lower.
# Error Codes
Source: https://docs.injective.network/developers-native/injective/insurance/99_errors
This document lists the error codes used in the module.
| Module | Error Code | description |
| --------- | ---------- | --------------------------------- |
| insurance | 1 | insurance fund already exists |
| insurance | 2 | insurance fund not found |
| insurance | 3 | redemption already exists |
| insurance | 4 | invalid deposit amount |
| insurance | 5 | invalid deposit denom |
| insurance | 6 | insurance payout exceeds deposits |
| insurance | 7 | invalid ticker |
| insurance | 8 | invalid quote denom |
| insurance | 9 | invalid oracle |
| insurance | 10 | invalid expiration time |
| insurance | 11 | invalid marketID |
| insurance | 12 | invalid share denom |
# Concepts
Source: https://docs.injective.network/developers-native/injective/ocr/01_concepts
# Concepts
The `ocr` module is to store chainlink's OCR information into on-chain by verified members.
Off-chain reporting consists of N nodes (oracles), gathering data from external sources. Reports are being exchanged in a p2p fashion between oracles to get signatures of approval. A subset of nodes (transmitters) is identified by the `ocr` module on-chain, they must submit the reports to module, the first transmitter who hits the chain gets an extra reward to cover gas costs. Other transmitters are not. All oracles participating in the round are getting paid. `ocr` module stores median value from the reports.
## OCR Terminology
The protocol periodically sends **oracle reports** to the OCR module. The reporting protocol is comprised of three components: **pacemaker**, **report generation** and **transmission**.
**Pacemaker**
The pacemaker drives the report generation process which is structured in **epochs**. Each epoch has a designatd leader who the pacemaker then tasks with starting the report generation protocol. If the leader does not produce a valid report in time, the pacemaker also aborts the current report generation and starts a new epoch.
**Report Generation**
For a given epoch, the report generation protocol enters into **rounds** where **observations** are gathered and (given conditions are met such as heartbeat and deviation) a signed oracle **report** is generated. The rounds are controlled by a leader node who controls the frequency of rounds, gathers the observations and generates the report.
**Transmission**
The transmission protocol then transmits the generated report to the OCR module.
## Off-chain OCR integration
* Provide means to communicate with Injective using sdk-go
* Read data from the module, such as a list of approved oracles
* Submit reports as Msgs (Implement `ContractTransmitter`)
* Implement `OffchainConfigDigester`
* Implement `OnchainKeyring` for producing signatures that will work on the target chain module
* Implement `ContractConfigTracker` for tracking changes of the chain module config (gov approved)
Notes:
* Reports are timestamped in Epoch-Round fashion
* `ocr` module verifies the signatures of oracles on the report
* `ocr` module records oracles who contributed to a report, for the payout
* `ocr` module stores the median of the observations
* `ocr` module provides extra reward for the first submitter of a Msg
### Integration Overview
Chainlink has several [price data feeds](https://data.chain.link/ethereum/mainnet/stablecoins) including:
* 80 Crypto/USD pairs (e.g. ETH/USD, BTC/USD)
* 17 Stablecoin pairs (e.g. USDT/USD, USDC/USD)
* 73 ETH pairs (e.g. LINK/ETH)
* 17 Forex pairs (e.g. GBP/USD, CNY/USD)
A derivative market on Injective specifies the following oracle parameters:
* An oracleBase (e.g. BTC)
* An oracleQuote (e.g. USDT)
* An oracleType (e.g. Chainlink)
Thus for a BTC/USDT derivative market on Injective, the oracleBase would be BTC/USD, the oracleQuote would be USDT/USD and the oracleType would be Chainlink. The price for the market would then be obtained by dividing the BTC/USD price with the USDT/USD price, leaving the BTC/USDT price.
# State
Source: https://docs.injective.network/developers-native/injective/ocr/02_state
# State
Genesis state defines the initial state of the module to be used to setup the module.
```go theme={null}
// GenesisState defines the OCR module's genesis state.
type GenesisState struct {
// params defines all the parameters of related to OCR.
Params Params
// feed_configs stores all of the supported OCR feeds
FeedConfigs []*FeedConfig
// latest_epoch_and_rounds stores the latest epoch and round for each feedId
LatestEpochAndRounds []*FeedEpochAndRound
// feed_transmissions stores the last transmission for each feed
FeedTransmissions []*FeedTransmission
// latest_aggregator_round_ids stores the latest aggregator round ID for each feedId
LatestAggregatorRoundIds []*FeedLatestAggregatorRoundIDs
// reward_pools stores the reward pools
RewardPools []*RewardPool
// feed_observation_counts stores the feed observation counts
FeedObservationCounts []*FeedCounts
// feed_transmission_counts stores the feed transmission counts
FeedTransmissionCounts []*FeedCounts
// pending_payeeships stores the pending payeeships
PendingPayeeships []*PendingPayeeship
}
```
## Params
`Params` is a module-wide configuration that stores system parameters and defines overall functioning of the ocr module.
This module is modifiable by governance using params update proposal natively supported by `gov` module.
Struct for the `ocr` module params store.
```go theme={null}
type Params struct {
// Native denom for LINK coin in the bank keeper
LinkDenom string
// The block number interval at which payouts are made
PayoutBlockInterval uint64
// The admin for the OCR module
ModuleAdmin string
}
```
## FeedConfig
`FeedConfig` is to manage the configurations of feed and it exists one per feed.
```go theme={null}
type FeedConfig struct {
// signers ith element is address ith oracle uses to sign a report
Signers []string
// transmitters ith element is address ith oracle uses to transmit a report via the transmit method
Transmitters []string
// f maximum number of faulty/dishonest oracles the protocol can tolerate while still working correctly
F uint32
// onchain_config contains properties relevant only for the Cosmos module.
OnchainConfig *OnchainConfig
// offchain_config_version version of the serialization format used for "offchain_config" parameter
OffchainConfigVersion uint64
// offchain_config serialized data used by oracles to configure their offchain operation
OffchainConfig []byte
}
```
### FeedConfigInfo
`FeedConfigInfo` is storing the information that needs to be updated more often for each transmission event.
```go theme={null}
type FeedConfigInfo struct {
LatestConfigDigest []byte
F uint32
N uint32
// config_count ordinal number of this config setting among all config settings
ConfigCount uint64
LatestConfigBlockNumber int64
}
```
### Transmission
`Transmission` is the unit to save transition information on the store.
```go theme={null}
// Transmission records the median answer from the transmit transaction at
// time timestamp
type Transmission struct {
Answer math.LegacyDec
ObservationsTimestamp int64
TransmissionTimestamp int64
}
```
### Report
`Report` is the unit to save report information on the store.
```go theme={null}
type Report struct {
ObservationsTimestamp int64
Observers []byte
Observations []math.LegacyDec
}
```
`ReportToSign` saves the information that needs to be signed by observers.
```go theme={null}
type ReportToSign struct {
ConfigDigest []byte
Epoch uint64
Round uint64
ExtraHash []byte
// Opaque report
Report []byte
}
```
### OnchainConfig
`OnchainConfig` saves the configuration that needs to be managed on-chain for feed config.
```go theme={null}
type OnchainConfig struct {
// chain_id the ID of the Cosmos chain itself.
ChainId string
// feed_id is an unique ID for the target of this config
FeedId string
// lowest answer the median of a report is allowed to be
MinAnswer math.LegacyDec
// highest answer the median of a report is allowed to be
MaxAnswer math.LegacyDec
// Fixed LINK reward for each observer
LinkPerObservation math.Int
// Fixed LINK reward for transmitter
LinkPerTransmission math.Int
// Native denom for LINK coin in the bank keeper
LinkDenom string
// Enables unique reports
UniqueReports bool
// short human-readable description of observable this feed's answers pertain to
Description string
// feed administrator
FeedAdmin string
// feed billing administrator
BillingAdmin string
}
```
### ContractConfig
`ContractConfig` saves the configuration that is related to contract to store OCR.
```go theme={null}
type ContractConfig struct {
// config_count ordinal number of this config setting among all config settings
ConfigCount uint64
// signers ith element is address ith oracle uses to sign a report
Signers []string
// transmitters ith element is address ith oracle uses to transmit a report via the transmit method
Transmitters []string
// f maximum number of faulty/dishonest oracles the protocol can tolerate while still working correctly
F uint32
// onchain_config serialized config that is relevant only for the module.
OnchainConfig []byte
// offchain_config_version version of the serialization format used for "offchain_config" parameter
OffchainConfigVersion uint64
// offchain_config serialized data used by oracles to configure their offchain operation
OffchainConfig []byte
}
```
### FeedProperties
`FeedProperties` is a unit to store the properties of feed by id.
```go theme={null}
type FeedProperties struct {
// feed_id is an unique ID for the target of this config
FeedId string
// f maximum number of faulty/dishonest oracles the protocol can tolerate while still working correctly
F uint32
// offchain_config_version version of the serialization format used for "offchain_config" parameter
OffchainConfigVersion uint64
// offchain_config serialized data used by oracles to configure their offchain operation
OffchainConfig []byte
// lowest answer the median of a report is allowed to be
MinAnswer math.LegacyDec
// highest answer the median of a report is allowed to be
MaxAnswer math.LegacyDec
// Fixed LINK reward for each observer
LinkPerObservation math.Int
// Fixed LINK reward for transmitter
LinkPerTransmission math.Int
// Enables unique reports
UniqueReports bool
// short human-readable description of observable this feed's answers pertain to
Description string
}
```
### PendingPayeeship
`PendingPayeeship` is a record that is stored when a person is delegating payeeship to another address.
When proposed payee accept this, this record is removed.
```go theme={null}
type PendingPayeeship struct {
FeedId string
Transmitter string
ProposedPayee string
}
```
# Messages
Source: https://docs.injective.network/developers-native/injective/ocr/03_messages
# Messages
In this section we describe the processing of the ocr messages and the corresponding updates to the state.
## Msg/CreateFeed
`MsgCreateFeed` is a message to create feed config and it is restricted message that is executable by module admin.
```protobuf theme={null}
message MsgCreateFeed {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
FeedConfig config = 2;
}
```
**Steps**
* Ensure `Sender` is module admin
* Ensure `msg.Config.OnchainConfig.LinkDenom` is module param's `LinkDenom`
* Set `OnchainConfig.ChainId` from `ctx.ChainID`
* Ensure `FeedConfig` with same `FeedId` does not exist
* Set latest `EpochAndRound` to `(0, 0)`
* Set feed config for `feedId`
* Set feed trasmissions count and observations count to 1
## Msg/UpdateFeed
`MsgCreateFeed` is a message to update feed config and it is restricted message that is executable by feed admin or feed billing admin.
```protobuf theme={null}
message MsgUpdateFeed {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
// feed_id is an unique ID for the target of this config
string feed_id = 2;
// signers ith element is address ith oracle uses to sign a report
repeated string signers = 3;
// transmitters ith element is address ith oracle uses to transmit a report via the transmit method
repeated string transmitters = 4;
// Fixed LINK reward for each observer
string link_per_observation = 5[
(gogoproto.customtype) = "cosmossdk.io/math.Int",
(gogoproto.nullable) = true
];
// Fixed LINK reward for transmitter
string link_per_transmission = 6[
(gogoproto.customtype) = "cosmossdk.io/math.Int",
(gogoproto.nullable) = true
];
// Native denom for LINK coin in the bank keeper
string link_denom = 7;
// feed administrator
string feed_admin = 8;
// feed billing administrator
string billing_admin = 9;
}
```
**Steps**
* Get previous feed config by `feedId` and ensure it exists
* Ensure `Sender` is feed admin or feed billing admin
* Ensure billing admin is not changing Signers, Transmitters and feed admin
* Process rewards payout for previous feed config
* Delete previous feed transmission and observation counts
* Set latest `EpochAndRound` to `(0, 0)`
* Update signers, transmitters, `LinkPerObservation`, `LinkPerTransmission`, `LinkDenom`, `FeedAdmin`, `BillingAdmin` if set.
## Msg/Transmit
`MsgTransmit` is a message to transmit a report for specific feed. When broadcasting the message, there should be enough amount of signatures from observers to be accepted.
```protobuf theme={null}
message MsgTransmit {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
// Address of the transmitter
string transmitter = 1;
bytes config_digest = 2;
string feed_id = 3;
uint64 epoch = 4;
uint64 round = 5;
bytes extra_hash = 6;
Report report = 7;
repeated bytes signatures = 8;
}
```
**Steps**
* Get epoch and round for `feedId`
* Ensure that the report is not staled one by checking `msg.Epoch` and `msg.Round`
* Get feed config and config info from `feedId`
* Check msg.ConfigDigest equals to feed config info's latest config digest
* Check if transmitter is valid transmitter configured in `feedConfig`
* Save transmitter report
* Emit event for trasmission
* Validate signatures and the number of signatures
* Increment feed observation and transmission counts
## Msg/FundFeedRewardPool
`MsgFundFeedRewardPool` is a message to add funds to feed reward pool to be given to transmitters and observers.
```protobuf theme={null}
message MsgFundFeedRewardPool {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
string feed_id = 2;
cosmos.base.v1beta1.Coin amount = 3 [(gogoproto.nullable) = false];
}
```
**Steps**
* Get previous reward pool amount from `feedId`
* If previous amount is empty, initiate the pool amount with zero integer
* Ensure previous amount denom is not different from deposit denom if exist
* Send coins from account to the module account (`ocr` module)
* Update reward pool amount with `amount` field addition
* Call `AfterFundFeedRewardPool` hook if hooks is set
## Msg/WithdrawFeedRewardPool
`MsgFundFeedRewardPool` is a message to withdraw funds from feed reward pool and is restricted to feed admin or billing admin.
```protobuf theme={null}
message MsgWithdrawFeedRewardPool {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
string feed_id = 2;
cosmos.base.v1beta1.Coin amount = 3 [(gogoproto.nullable) = false];
}
```
**Steps**
* Get feed config from `feedId`
* Ensure `msg.Sender` is `feedAdmin` or `billingAdmin`
* Process reward for the feed
* Withdraw specified amount `msg.Amount` from module account
## Msg/SetPayees
`MsgSetPayees` is a message to set payee for transmitters - it is restricted to feed admin. Once it's set, it should be changed only by payee.
```protobuf theme={null}
message MsgSetPayees {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
string feed_id = 2;
// addresses oracles use to transmit the reports
repeated string transmitters = 3;
// addresses of payees corresponding to list of transmitters
repeated string payees = 4;
}
```
**Steps**
* Get feed config from `feedId` and ensure that feed config exists
* Ensure `msg.Sender` is feed admin
* Iterating `msg.Transmitters`,
* 1. Ensure payee is set already for the transmitter
* 2. Set payee for the transmitter
## Msg/TransferPayeeship
`MsgTransferPayeeship` is a message to transfer payeeship for a specific transmitter of feed. After execution, pending payeeship object is created.
```protobuf theme={null}
message MsgTransferPayeeship {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
// transmitter address of oracle whose payee is changing
string sender = 1;
string transmitter = 2;
string feed_id = 3;
// new payee address
string proposed = 4;
}
```
**Steps**
* Get feed config from `feedId` and ensure that feed config exists
* Ensure msg.Sender is current payee
* Check previous pending payeeship transfer record and ensure previous payeeship transfer does not conflict
* Set payeeship transfer record
## Msg/AcceptPayeeship
`MsgTransferPayeeship` is a message to accept payeeship for a specific transmitter of feed.
```protobuf theme={null}
message MsgAcceptPayeeship {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
// new payee address
string payee = 1;
// transmitter address of oracle whose payee is changing
string transmitter = 2;
string feed_id = 3;
}
```
**Steps**
* Get feed config from `feedId` and ensure that feed config exists
* Get pending payeeship transfer record for `msg.Transmitter` and `feedId`
* Reset payee for `feedId` and `transmitter`
* Delete pending payeeship transfer for `transmitter` of `feedId`
# Governance Proposals
Source: https://docs.injective.network/developers-native/injective/ocr/04_proposals
# Governance Proposals
## SetConfigProposal
`SetConfigProposal` is a proposal to set feed config by governance.
```protobuf theme={null}
message SetConfigProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
FeedConfig config = 3;
}
```
**Steps**
* Validate basics for the proposal
* Ensure module's `LinkDenom` is same as proposal's `LinkDenom`
* set `p.Config.OnchainConfig.ChainId` from `ctx.ChainID`
* Set feed config for `feedId`
* Set feed transmissions and observations count for `Config.Transmitters`
## SetBatchConfigProposal
`SetBatchConfigProposal` is a proposal to set multiple feed configs at once by governance.
```protobuf theme={null}
message SetBatchConfigProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
// signers ith element is address ith oracle uses to sign a report
repeated string signers = 3;
// transmitters ith element is address ith oracle uses to transmit a report via the transmit method
repeated string transmitters = 4;
// Native denom for LINK coin in the bank keeper
string link_denom = 5;
repeated FeedProperties feed_properties = 6;
}
```
# Begin-Block
Source: https://docs.injective.network/developers-native/injective/ocr/05_begin_block
# Begin-Block
At each BeginBlock, it checks if it's time for payout interval and if it's time, it process payout for all feeds.
**Steps**
* Ensure it's the begin block of payout interval
* While iterating all feed configs, process reward payouts
# null
Source: https://docs.injective.network/developers-native/injective/ocr/06_hooks
# Hooks
Other modules may register operations to execute when a certain event has occurred within ocr module. The following hooks can registered with ocr:
* `AfterSetFeedConfig(ctx sdk.Context, feedConfig *FeedConfig)`
* called after feed config is created or updated
* `AfterTransmit(ctx sdk.Context, feedId string, answer math.LegacyDec, timestamp int64)`
* called when info is transmitted
* `AfterFundFeedRewardPool(ctx sdk.Context, feedId string, newPoolAmount sdk.Coin)`
* called when feed reward pool is updated
Note:
`oracle` module is accepting `AfterTransmit` hook to store cumulative price when transmission is made.
# Events
Source: https://docs.injective.network/developers-native/injective/ocr/07_events
# Events
The ocr module emits the following events:
## Handlers
### MsgCreateFeed
| Type | Attribute Key | Attribute Value |
| ------- | ------------- | --------------- |
| message | action | MsgCreateFeed |
| message | sender | |
### MsgUpdateFeed
| Type | Attribute Key | Attribute Value |
| ------- | ------------- | --------------- |
| message | action | MsgUpdateFeed |
| message | sender | |
### MsgTransmit
| Type | Attribute Key | Attribute Value |
| -------------------- | --------------------- | --------------- |
| EventNewTransmission | FeedId | |
| EventNewTransmission | AggregatorRoundId | |
| EventNewTransmission | Answer | |
| EventNewTransmission | Transmitter | |
| EventNewTransmission | ObservationsTimestamp | |
| EventNewTransmission | Observations | |
| EventNewTransmission | Observers | |
| EventNewTransmission | ConfigDigest | |
| EventNewTransmission | EpochAndRound | |
| EventTransmitted | ConfigDigest | |
| EventTransmitted | Epoch | |
| message | action | MsgTransmit |
| message | sender | |
### MsgFundFeedRewardPool
| Type | Attribute Key | Attribute Value |
| ------- | ------------- | --------------------- |
| message | action | MsgFundFeedRewardPool |
| message | sender | |
### MsgWithdrawFeedRewardPool
| Type | Attribute Key | Attribute Value |
| ------- | ------------- | ------------------------- |
| message | action | MsgWithdrawFeedRewardPool |
| message | sender | |
### MsgSetPayees
| Type | Attribute Key | Attribute Value |
| ------- | ------------- | --------------- |
| message | action | MsgSetPayees |
| message | sender | |
### MsgTransferPayeeship
| Type | Attribute Key | Attribute Value |
| ------- | ------------- | -------------------- |
| message | action | MsgTransferPayeeship |
| message | sender | |
### MsgAcceptPayeeship
| Type | Attribute Key | Attribute Value |
| ------- | ------------- | ------------------ |
| message | action | MsgAcceptPayeeship |
| message | sender | |
## Proposals
### SetConfigProposal
| Type | Attribute Key | Attribute Value |
| -------------- | ------------------------- | --------------- |
| EventConfigSet | ConfigDigest | |
| EventConfigSet | PreviousConfigBlockNumber | |
| EventConfigSet | Config | |
| EventConfigSet | ConfigInfo | |
### SetBatchConfigProposal
| Type | Attribute Key | Attribute Value |
| ----------------- | ------------------------- | --------------- |
| EventConfigSet\[] | ConfigDigest | |
| EventConfigSet\[] | PreviousConfigBlockNumber | |
| EventConfigSet\[] | Config | |
| EventConfigSet\[] | ConfigInfo | |
## BeginBlocker
| Type | Attribute Key | Attribute Value |
| ---- | ------------- | --------------- |
# Params
Source: https://docs.injective.network/developers-native/injective/ocr/08_params
# Parameters
The ocr module contains the following parameters:
| Key | Type | Example |
| ------------------- | ------ | ------- |
| LinkDenom | string | link |
| PayoutBlockInterval | uint64 | 100 |
| ModuleAdmin | string | |
# Error Codes
Source: https://docs.injective.network/developers-native/injective/ocr/99_errors
This document lists the error codes used in the module.
| Module | Error Code | description |
| ------ | ---------- | ---------------------------------------- |
| ocr | 1 | stale report |
| ocr | 2 | incomplete proposal |
| ocr | 3 | repeated oracle address |
| ocr | 4 | too many signers |
| ocr | 5 | incorrect config |
| ocr | 6 | config digest doesn't match |
| ocr | 7 | wrong number of signatures |
| ocr | 8 | incorrect signature |
| ocr | 9 | no transmitter specified |
| ocr | 10 | incorrect transmission data |
| ocr | 11 | no transmissions found |
| ocr | 12 | median value is out of bounds |
| ocr | 13 | LINK denom doesn't match |
| ocr | 14 | Reward Pool doesn't exist |
| ocr | 15 | wrong number of payees and transmitters |
| ocr | 16 | action is restricted to the module admin |
| ocr | 17 | feed already exists |
| ocr | 19 | feed doesnt exists |
| ocr | 20 | action is admin-restricted |
| ocr | 21 | insufficient reward pool |
| ocr | 22 | payee already set |
| ocr | 23 | action is payee-restricted |
| ocr | 24 | feed config not found |
# OCR
Source: https://docs.injective.network/developers-native/injective/ocr/index
## Abstract
OCR module is to store chainlink's OCR(Off-Chain Report) info into the chain storage.
Feed configuration is managed by module admin and report move to on-chain by transmitters and observers.
Transmitters and observers are rewarded in LINK token on the chain configured by governance.
While storing feed information, module provide hooks where oracle module can use for the calculation of cumulative price for futures market.
## Contents
1. [Concepts](/developers-native/injective/ocr/01_concepts)
2. [State](/developers-native/injective/ocr/02_state)
3. [Messages](/developers-native/injective/ocr/03_messages)
4. [Proposals](/developers-native/injective/ocr/04_proposals)
5. [Begin-Block](/developers-native/injective/ocr/05_begin_block)
6. [Hooks](/developers-native/injective/ocr/06_hooks)
7. [Events](/developers-native/injective/ocr/07_events)
8. [Parameters](/developers-native/injective/ocr/08_params)
# State
Source: https://docs.injective.network/developers-native/injective/oracle/01_state
# State
## Params
The oracle module parameters.
```protobuf theme={null}
message Params {
option (gogoproto.equal) = true;
string pyth_contract = 1;
}
```
## PriceState
PriceState is common type to manage cumulative price and latest price along with timestamp for all oracle types.
```protobuf theme={null}
message PriceState {
string price = 1 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
string cumulative_price = 2 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
int64 timestamp = 3;
}
```
where
* `Price` represents the normalized decimal price
* `CumulativePrice` represents the cumulative price for a given oracle price feed since the start of the oracle price feed's creation.
* `Timestamp` represents the time at which the blocktime at which the price state was relayed.
Note that the `CumulativePrice` value follows the convention set by the [Uniswap V2 Oracle](https://uniswap.org/docs/v2/core-concepts/oracles/) and is used to allows modules to calculate Time-Weighted Average Price (TWAP) between 2 arbitrary block time intervals (t1, t2).
$\mathrm{TWAP = \frac{CumulativePrice_2 - CumulativePrice_1}{Timestamp_2 - Timestamp_1}}$
## Band
Band price data for a given symbol are represented and stored as follows:
* BandPriceState: `0x01 | []byte(symbol) -> ProtocolBuffer(BandPriceState)`
```protobuf theme={null}
message BandPriceState {
string symbol = 1;
string rate = 2 [(gogoproto.customtype) = "cosmossdk.io/math.Int", (gogoproto.nullable) = false];
uint64 resolve_time = 3;
uint64 request_ID = 4;
PriceState price_state = 5 [(gogoproto.nullable) = false];
}
```
Note that the `Rate` is the raw USD rate for the `Symbol` obtained from the Band chain which has is scaled by 1e9 (e.g. a price of 1.42 is 1420000000) while the PriceState has the normalized decimal price (e.g. 1.42).
Band relayers are stored by their address as follows.
* BandRelayer: `0x02 | RelayerAddr -> []byte{}`
## Band IBC
This section describes all the state management to maintain the price by connecting to Band chain via IBC.
* LatestClientID is maintained to manage unique clientID for band IBC packets. It is increased by 1 when sending price request packet into bandchain.
- LatestClientID: `0x32 -> Formated(LatestClientID)`
* LatestRequestID is maintained to manage unique `BandIBCOracleRequests`. Incremented by 1 when creating a new `BandIBCOracleRequest`.
- LatestRequestID: `0x36 -> Formated(LatestRequestID)`
* Band IBC price data for a given symbol is stored as follows:
- BandPriceState: `0x31 | []byte(symbol) -> ProtocolBuffer(BandPriceState)`
```protobuf theme={null}
message BandPriceState {
string symbol = 1;
string rate = 2 [(gogoproto.customtype) = "cosmossdk.io/math.Int", (gogoproto.nullable) = false];
uint64 resolve_time = 3;
uint64 request_ID = 4;
PriceState price_state = 5 [(gogoproto.nullable) = false];
}
```
* BandIBCCallDataRecord is stored as follows when sending price request packet into bandchain:
- CalldataRecord: `0x33 | []byte(ClientId) -> ProtocolBuffer(CalldataRecord)`
```protobuf theme={null}
message CalldataRecord {
uint64 client_id = 1;
bytes calldata = 2;
}
```
* BandIBCOracleRequest is stored as follows when the governance configure oracle requests to send:
- BandOracleRequest: `0x34 | []byte(RequestId) -> ProtocolBuffer(BandOracleRequest)`
```protobuf theme={null}
message BandOracleRequest {
// Unique Identifier for band ibc oracle request
uint64 request_id = 1;
// OracleScriptID is the unique identifier of the oracle script to be executed.
int64 oracle_script_id = 2;
// Symbols is the list of symbols to prepare in the calldata
repeated string symbols = 3;
// AskCount is the number of validators that are requested to respond to this
// oracle request. Higher value means more security, at a higher gas cost.
uint64 ask_count = 4;
// MinCount is the minimum number of validators necessary for the request to
// proceed to the execution phase. Higher value means more security, at the
// cost of liveness.
uint64 min_count = 5;
// FeeLimit is the maximum tokens that will be paid to all data source providers.
repeated cosmos.base.v1beta1.Coin fee_limit = 6 [(gogoproto.nullable) = false, (gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.Coins"];
// PrepareGas is amount of gas to pay to prepare raw requests
uint64 prepare_gas = 7;
// ExecuteGas is amount of gas to reserve for executing
uint64 execute_gas = 8;
}
```
* BandIBCParams is stored as follows and configured by governance:
- BandIBCParams: `0x35 -> ProtocolBuffer(BandIBCParams)`
`BandIBCParams` contains the information for IBC connection with band chain.
```protobuf theme={null}
message BandIBCParams {
// true if Band IBC should be enabled
bool band_ibc_enabled = 1;
// block request interval to send Band IBC prices
int64 ibc_request_interval = 2;
// band IBC source channel
string ibc_source_channel = 3;
// band IBC version
string ibc_version = 4;
// band IBC portID
string ibc_port_id = 5;
}
```
Note:
1. `BandIbcEnabled` describes the status of band ibc connection
2. `IbcSourceChannel`, `IbcVersion`, `IbcPortId` are common parameters required for IBC connection.
3. `IbcRequestInterval` describes the automatic price fetch request interval that is automatically triggered on injective chain on beginblocker.
## Coinbase
Coinbase price data for a given symbol ("key") are represented and stored as follows:
* CoinbasePriceState: `0x21 | []byte(key) -> CoinbasePriceState`
```protobuf theme={null}
message CoinbasePriceState {
// kind should always be "prices"
string kind = 1;
// timestamp of the when the price was signed by coinbase
uint64 timestamp = 2;
// the symbol of the price, e.g. BTC
string key = 3;
// the value of the price scaled by 1e6
uint64 value = 4;
// the price state
PriceState price_state = 5 [(gogoproto.nullable) = false];
}
```
More details about the Coinbase price oracle can be found in the [Coinbase API docs](https://docs.pro.coinbase.com/#oracle) as well as this explanatory [blog post](https://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068).
Note that the `Value` is the raw USD price data obtained from Coinbase which has is scaled by 1e6 (e.g. a price of 1.42 is 1420000) while the PriceState has the normalized decimal price (e.g. 1.42).
## Pricefeed
Pricefeed price data for a given base quote pair are represented and stored as follows:
* PriceFeedInfo: `0x11 + Keccak256Hash(base + quote) -> PriceFeedInfo`
```protobuf theme={null}
message PriceFeedInfo {
string base = 1;
string quote = 2;
}
```
* PriceFeedPriceState: `0x12 + Keccak256Hash(base + quote) -> PriceFeedPriceState`
```protobuf theme={null}
message PriceFeedState {
string base = 1;
string quote = 2;
PriceState price_state = 3;
repeated string relayers = 4;
}
```
* PriceFeedRelayer: `0x13 + Keccak256Hash(base + quote) + relayerAddr -> relayerAddr`
## Provider
Provider price feeds are represented and stored as follows:
* ProviderInfo: `0x61 + provider + @@@ -> ProviderInfo`
```protobuf theme={null}
message ProviderInfo {
string provider = 1;
repeated string relayers = 2;
}
```
* ProviderIndex: `0x62 + relayerAddress -> provider`
* ProviderPrices: `0x63 + provider + @@@ + symbol -> ProviderPriceState`
```protobuf theme={null}
message ProviderPriceState {
string symbol = 1;
PriceState state = 2;
}
```
## Pyth
Pyth prices are represented and stored as follows:
* PythPriceState: `0x71 + priceID -> PythPriceState`
```protobuf theme={null}
message PythPriceState {
bytes price_id = 1;
string ema_price = 2 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
string ema_conf = 3 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
string conf = 4 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
uint64 publish_time = 5;
PriceState price_state = 6 [(gogoproto.nullable) = false];
}
```
## Stork
Stork prices are represented and stored as follows:
* StorkPriceState: `0x81 + symbol -> PythPriceState`
```protobuf theme={null}
message StorkPriceState {
// timestamp of the when the price was signed by stork
uint64 timestamp = 1;
// the symbol of the price, e.g. BTC
string symbol = 2;
// the value of the price scaled by 1e18
string value = 3 [
(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
(gogoproto.nullable) = false
];
// the price state
PriceState price_state = 5 [ (gogoproto.nullable) = false ];
}
```
Stork publishers are represented and stored as follows:
* Publisher: `0x82 + stork_publisher -> publisher`
```protobuf theme={null}
string stork_publisher
```
# Keepers
Source: https://docs.injective.network/developers-native/injective/oracle/02_keeper
# Keepers
The oracle module currently provides three different exported keeper interfaces which can be passed to other modules
which need to read price feeds. Modules should use the least-permissive interface which provides the functionality they
require.
## Oracle Module ViewKeeper
The oracle module ViewKeeper provides the ability to obtain price data as well as cumulative price data for any
supported oracle type and oracle pair.
```go theme={null}
type ViewKeeper interface {
GetPrice(ctx sdk.Context, oracletype types.OracleType, base string, quote string) *math.LegacyDec // Returns the price for a given pair for a given oracle type.
GetCumulativePrice(ctx sdk.Context, oracleType types.OracleType, base string, quote string) *math.LegacyDec // Returns the cumulative price for a given pair for a given oracle type.
}
```
Note that the `GetPrice` for Coinbase oracles returns the 5 minute TWAP price.
## Band
The BandKeeper provides the ability to create/modify/read/delete BandPricefeed and BandRelayer.
```go theme={null}
type BandKeeper interface {
GetBandPriceState(ctx sdk.Context, symbol string) *types.BandPriceState
SetBandPriceState(ctx sdk.Context, symbol string, priceState types.BandPriceState)
GetAllBandPriceStates(ctx sdk.Context) []types.BandPriceState
GetBandReferencePrice(ctx sdk.Context, base string, quote string) *math.LegacyDec
IsBandRelayer(ctx sdk.Context, relayer sdk.AccAddress) bool
GetAllBandRelayers(ctx sdk.Context) []string
SetBandRelayer(ctx sdk.Context, relayer sdk.AccAddress)
DeleteBandRelayer(ctx sdk.Context, relayer sdk.AccAddress)
}
```
## Band IBC
The BandIBCKeeper provides the ability to create/modify/read/delete BandIBCOracleRequest, BandIBCPriceState, BandIBCLatestClientID and BandIBCCallDataRecord.
```go theme={null}
type BandIBCKeeper interface {
SetBandIBCOracleRequest(ctx sdk.Context, req types.BandOracleRequest)
GetBandIBCOracleRequest(ctx sdk.Context) *types.BandOracleRequest
DeleteBandIBCOracleRequest(ctx sdk.Context, requestID uint64)
GetAllBandIBCOracleRequests(ctx sdk.Context) []*types.BandOracleRequest
GetBandIBCPriceState(ctx sdk.Context, symbol string) *types.BandPriceState
SetBandIBCPriceState(ctx sdk.Context, symbol string, priceState types.BandPriceState)
GetAllBandIBCPriceStates(ctx sdk.Context) []types.BandPriceState
GetBandIBCReferencePrice(ctx sdk.Context, base string, quote string) *math.LegacyDec
GetBandIBCLatestClientID(ctx sdk.Context) uint64
SetBandIBCLatestClientID(ctx sdk.Context, clientID uint64)
SetBandIBCCallDataRecord(ctx sdk.Context, clientID uint64, bandIBCCallDataRecord []byte)
GetBandIBCCallDataRecord(ctx sdk.Context, clientID uint64) *types.CalldataRecord
}
```
## Coinbase
The CoinbaseKeeper provides the ability to create, modify and read CoinbasePricefeed data.
```go theme={null}
type CoinbaseKeeper interface {
GetCoinbasePrice(ctx sdk.Context, base string, quote string) *math.LegacyDec
HasCoinbasePriceState(ctx sdk.Context, key string) bool
GetCoinbasePriceState(ctx sdk.Context, key string) *types.CoinbasePriceState
SetCoinbasePriceState(ctx sdk.Context, priceData *types.CoinbasePriceState) error
GetAllCoinbasePriceStates(ctx sdk.Context) []*types.CoinbasePriceState
}
```
The `GetCoinbasePrice` returns the 5 minute TWAP price of the CoinbasePriceState based off the `CoinbasePriceState.Timestamp` values provided by Coinbase.
## PriceFeeder
The PriceFeederKeeper provides the ability to create/modify/read/delete PriceFeedPrice and PriceFeedRelayer.
```go theme={null}
type PriceFeederKeeper interface {
IsPriceFeedRelayer(ctx sdk.Context, oracleBase, oracleQuote string, relayer sdk.AccAddress) bool
GetAllPriceFeedStates(ctx sdk.Context) []*types.PriceFeedState
GetAllPriceFeedRelayers(ctx sdk.Context, baseQuoteHash common.Hash) []string
SetPriceFeedRelayer(ctx sdk.Context, oracleBase, oracleQuote string, relayer sdk.AccAddress)
SetPriceFeedRelayerFromBaseQuoteHash(ctx sdk.Context, baseQuoteHash common.Hash, relayer sdk.AccAddress)
DeletePriceFeedRelayer(ctx sdk.Context, oracleBase, oracleQuote string, relayer sdk.AccAddress)
HasPriceFeedInfo(ctx sdk.Context, priceFeedInfo *types.PriceFeedInfo) bool
GetPriceFeedInfo(ctx sdk.Context, baseQuoteHash common.Hash) *types.PriceFeedInfo
SetPriceFeedInfo(ctx sdk.Context, priceFeedInfo *types.PriceFeedInfo)
GetPriceFeedPriceState(ctx sdk.Context, base string, quote string) *types.PriceState
SetPriceFeedPriceState(ctx sdk.Context, oracleBase, oracleQuote string, priceState *types.PriceState)
GetPriceFeedPrice(ctx sdk.Context, base string, quote string) *math.LegacyDec
}
```
## Stork
The StorkKeeper provides the ability to create/modify/read StorkPricefeed and StorkPublishers data.
```go theme={null}
type StorkKeeper interface {
GetStorkPrice(ctx sdk.Context, base string, quote string) *math.LegacyDec
IsStorkPublisher(ctx sdk.Context, address string) bool
SetStorkPublisher(ctx sdk.Context, address string)
DeleteStorkPublisher(ctx sdk.Context, address string)
GetAllStorkPublishers(ctx sdk.Context) []string
SetStorkPriceState(ctx sdk.Context, priceData *types.StorkPriceState)
GetStorkPriceState(ctx sdk.Context, symbol string) types.StorkPriceState
GetAllStorkPriceStates(ctx sdk.Context) []*types.StorkPriceState
}
```
The GetStorkPrice returns the price(`value`) of the StorkPriceState.
# Messages
Source: https://docs.injective.network/developers-native/injective/oracle/03_messages
# Messages
## MsgRelayBandRates
Authorized Band relayers can relay price feed data for multiple symbols with the `MsgRelayBandRates` message.
The registered handler iterates over all the symbols present in the `MsgRelayBandRates` and creates/updates the
`BandPriceState` for each symbol.
```protobuf theme={null}
message MsgRelayBandRates {
string relayer = 1;
repeated string symbols = 2;
repeated uint64 rates = 3;
repeated uint64 resolve_times = 4;
repeated uint64 requestIDs = 5;
}
```
This message is expected to fail if the Relayer is not an authorized Band relayer.
## MsgRelayCoinbaseMessages
Relayers of Coinbase provider can send price data using `MsgRelayCoinbaseMessages` message.
Each Coinbase `Messages` is authenticated by the `Signatures` provided by the Coinbase oracle address `0xfCEAdAFab14d46e20144F48824d0C09B1a03F2BC`, thus allowing anyone to submit the `MsgRelayCoinbaseMessages`.
```protobuf theme={null}
message MsgRelayCoinbaseMessages {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
repeated bytes messages = 2;
repeated bytes signatures = 3;
}
```
This message is expected to fail if signature verification fails or if the Timestamp submitted is not more recent than the last previously submitted Coinbase price.
## MsgRelayPriceFeedPrice
Relayers of PriceFeed provider can send the price feed using `MsgRelayPriceFeedPrice` message.
```protobuf theme={null}
// MsgRelayPriceFeedPrice defines a SDK message for setting a price through the pricefeed oracle.
message MsgRelayPriceFeedPrice {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
repeated string base = 2;
repeated string quote = 3;
// price defines the price of the oracle base and quote
repeated string price = 4 [
(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
(gogoproto.nullable) = false
];
}
```
This message is expected to fail if the Relayer (`Sender`) is not an authorized pricefeed relayer for the given Base Quote pair or if the price is greater than 10000000.
## MsgRequestBandIBCRates
`MsgRequestBandIBCRates` is a message to instantly broadcast a request to bandchain.
```protobuf theme={null}
// MsgRequestBandIBCRates defines a SDK message for requesting data from BandChain using IBC.
message MsgRequestBandIBCRates {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
uint64 request_id = 2;
}
```
Anyone can broadcast this message and no specific authorization is needed.
The handler checks if `BandIbcEnabled` flag is true and go ahead sending a request.
## MsgRelayPythPrices
`MsgRelayPythPrices` is a message for the Pyth contract relay prices to the oracle module.
```protobuf theme={null}
// MsgRelayPythPrices defines a SDK message for updating Pyth prices
message MsgRelayPythPrices {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string sender = 1;
repeated PriceAttestation price_attestations = 2;
}
message PriceAttestation {
string product_id = 1;
bytes price_id = 2;
int64 price = 3;
uint64 conf = 4;
int32 expo = 5;
int64 ema_price = 6;
uint64 ema_conf = 7;
PythStatus status = 8;
uint32 num_publishers = 9;
uint32 max_num_publishers = 10;
int64 attestation_time = 11;
int64 publish_time = 12;
}
enum PythStatus {
// The price feed is not currently updating for an unknown reason.
Unknown = 0;
// The price feed is updating as expected.
Trading = 1;
// The price feed is not currently updating because trading in the product has been halted.
Halted = 2;
// The price feed is not currently updating because an auction is setting the price.
Auction = 3;
}
```
This message is expected to fail if the Relayer (`sender`) does not equal the Pyth contract address as defined in the
oracle module Params.
## MsgRelayStorkPrices
`MsgRelayStorkPrices` is a message for the Stork contract relay prices to the oracle module.
```protobuf theme={null}
// MsgRelayStorkPrices defines a SDK message for relaying price message from Stork API.
message MsgRelayStorkPrices {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
option (cosmos.msg.v1.signer) = "sender";
string sender = 1;
repeated AssetPair asset_pairs = 2;
}
message AssetPair {
string asset_id = 1;
repeated SignedPriceOfAssetPair signed_prices = 2;
}
message SignedPriceOfAssetPair {
string publisher_key = 1;
uint64 timestamp = 2;
string price = 3 [
(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
(gogoproto.nullable) = false
];
bytes signature = 4;
}
```
This message is expected to fail if:
* the Relayer (`sender`) is not an authorized oracle publisher or if `assetId` is not unique amongst the provided asset pairs
* ECDSA signature verification fails for the `SignedPriceOfAssetPair`
* the difference between timestamps exceeds the `MaxStorkTimestampIntervalNano` (500 milliseconds).
## MsgRelayProviderPrices
Relayers of a particular Provider can send the price feed using `MsgRelayProviderPrices` message.
```protobuf theme={null}
// MsgRelayProviderPrice defines a SDK message for setting a price through the provider oracle.
message MsgRelayProviderPrices {
option (amino.name) = "oracle/MsgRelayProviderPrices";
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
option (cosmos.msg.v1.signer) = "sender";
string sender = 1;
string provider = 2;
repeated string symbols = 3;
repeated string prices = 4 [
(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec",
(gogoproto.nullable) = false
];
}
```
This message is expected to fail if the Relayer (`Sender`) is not an authorized pricefeed relayer for the given Base Quote pair or if the price is greater than 10000000.
# Governance Proposals
Source: https://docs.injective.network/developers-native/injective/oracle/04_proposals
# Governance Proposals
## GrantBandOraclePrivilegeProposal
Band Oracle privileges can be granted to Relayer accounts of Band provider through a `GrantBandOraclePrivilegeProposal`.
```protobuf theme={null}
// Grant Privileges
message GrantBandOraclePrivilegeProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
repeated string relayers = 3;
}
```
## RevokeBandOraclePrivilegeProposal
Band Oracle privileges can be revoked from Relayer accounts of Band provider through a `RevokeBandOraclePrivilegeProposal`.
```protobuf theme={null}
// Revoke Privileges
message RevokeBandOraclePrivilegeProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
repeated string relayers = 3;
}
```
## GrantPriceFeederPrivilegeProposal
Price feeder privileges for a given base quote pair can be issued to relayers through a `GrantPriceFeederPrivilegeProposal`.
```protobuf theme={null}
// Grant Privileges
message GrantPriceFeederPrivilegeProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
string base = 3;
string quote = 4;
repeated string relayers = 5;
}
```
## RevokePriceFeederPrivilegeProposal
Price feeder privileges can be revoked from Relayer accounts through a `RevokePriceFeederPrivilegeProposal`.
```protobuf theme={null}
// Revoke Privileges
message RevokePriceFeederPrivilegeProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
string base = 3;
string quote = 4;
repeated string relayers = 5;
}
```
## AuthorizeBandOracleRequestProposal
This proposal is to add a band oracle request into the list. When this is accepted, injective chain fetches one more price info from bandchain.
```protobuf theme={null}
message AuthorizeBandOracleRequestProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
BandOracleRequest request = 3 [(gogoproto.nullable) = false];
}
```
## UpdateBandOracleRequestProposal
This proposal is used for deleting a request or updating the request.
When `DeleteRequestId` is not zero, it deletes the request with the id and finish its execution.
When `DeleteRequestId` is zero, it update the request with id `UpdateOracleRequest.RequestId` to UpdateOracleRequest.
```protobuf theme={null}
message UpdateBandOracleRequestProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
uint64 delete_request_id = 3;
BandOracleRequest update_oracle_request = 4;
}
```
## EnableBandIBCProposal
This proposal is to enable IBC connection between Band chain and Injective chain.
When the proposal is approved, it updates the BandIBCParams into newer one configured on the proposal.
```protobuf theme={null}
message EnableBandIBCProposal {
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
string title = 1;
string description = 2;
BandIBCParams band_ibc_params = 3 [(gogoproto.nullable) = false];
}
```
The details of `BandIBCParams`, can be checked at **[State](./01_state)**
## GrantStorkPublisherPrivilegeProposal
Stork Publisher privileges can be granted from Publishers through a `GrantStorkPublisherPrivilegeProposal`.
```protobuf theme={null}
// Grant Privileges
message GrantStorkPublisherPrivilegeProposal {
option (amino.name) = "oracle/GrantStorkPublisherPrivilegeProposal";
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
option (cosmos_proto.implements_interface) = "cosmos.gov.v1beta1.Content";
string title = 1;
string description = 2;
repeated string stork_publishers = 3;
}
```
## RevokeStorkPublisherPrivilegeProposal
Stork Publisher privileges can be revoked from Publishers through a `RevokeStorkPublisherPrivilegeProposal`.
```protobuf theme={null}
// Revoke Privileges
message RevokeStorkPublisherPrivilegeProposal {
option (amino.name) = "oracle/RevokeStorkPublisherPrivilegeProposal";
option (gogoproto.equal) = false;
option (gogoproto.goproto_getters) = false;
option (cosmos_proto.implements_interface) = "cosmos.gov.v1beta1.Content";
string title = 1;
string description = 2;
repeated string stork_publishers = 3;
}
```
# Events
Source: https://docs.injective.network/developers-native/injective/oracle/05_events
# Events
The oracle module emits the following events:
## Band
```protobuf theme={null}
message SetBandPriceEvent {
string relayer = 1;
string symbol = 2;
string price = 3 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
uint64 resolve_time = 4;
uint64 request_id = 5;
}
message SetBandIBCPriceEvent {
string relayer = 1;
repeated string symbols = 2;
repeated string prices = 3 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
uint64 resolve_time = 4;
uint64 request_id = 5;
int64 client_id = 6;
}
message EventBandIBCAckSuccess {
string ack_result = 1;
int64 client_id = 2;
}
message EventBandIBCAckError {
string ack_error = 1;
int64 client_id = 2;
}
message EventBandIBCResponseTimeout {
int64 client_id = 1;
}
```
## Chainlink
```protobuf theme={null}
message SetChainlinkPriceEvent {
string feed_id = 1;
string answer = 2 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
uint64 timestamp = 3;
}
```
## Coinbase
```protobuf theme={null}
message SetCoinbasePriceEvent {
string symbol = 1;
string price = 2 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
uint64 timestamp = 3;
}
```
## Provider
```protobuf theme={null}
message SetProviderPriceEvent {
string provider = 1;
string relayer = 2;
string symbol = 3;
string price = 4 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
}
```
## Pricefeed
```protobuf theme={null}
message SetPriceFeedPriceEvent {
string relayer = 1;
string base = 2;
string quote = 3;
// price defines the price of the oracle base and quote
string price = 4 [(gogoproto.customtype) = "cosmossdk.io/math.LegacyDec", (gogoproto.nullable) = false];
}
```
## Pyth
```protobuf theme={null}
message EventSetPythPrices {
repeated PythPriceState prices = 1;
}
```
## Stork
```protobuf theme={null}
message EventSetStorkPrices {
repeated StorkPriceState prices = 1;
}
```
# Future Improvements
Source: https://docs.injective.network/developers-native/injective/oracle/06_future_improvements
# Future Improvements
Extend support for other oracle providers including Chainlink, Razor, DIA, API3, UMA, Pyth as well as Band oracle data through IBC.
Of the following above, development is ongoing to integrate Band and Pyth oracle data through IBC, as well as Chainlink oracle data through the OCR (off-chain reporting) mechanism.
# Error Codes
Source: https://docs.injective.network/developers-native/injective/oracle/99_errors
This document lists the error codes used in the module.
| Module | Error Code | description |
| ------ | ---------- | ---------------------------------------- |
| oracle | 1 | relayer address is empty |
| oracle | 2 | bad rates count |
| oracle | 3 | bad resolve times |
| oracle | 4 | bad request ID |
| oracle | 5 | relayer not authorized |
| oracle | 6 | bad price feed base count |
| oracle | 7 | bad price feed quote count |
| oracle | 8 | unsupported oracle type |
| oracle | 9 | bad messages count |
| oracle | 10 | bad Coinbase message |
| oracle | 11 | bad Ethereum signature |
| oracle | 12 | bad Coinbase message timestamp |
| oracle | 13 | Coinbase price not found |
| oracle | 14 | Prices must be positive |
| oracle | 15 | Prices must be less than 10 million. |
| oracle | 16 | Invalid Band IBC Request |
| oracle | 17 | sample error |
| oracle | 18 | invalid packet timeout |
| oracle | 19 | invalid symbols count |
| oracle | 20 | could not claim port capability |
| oracle | 21 | invalid IBC Port ID |
| oracle | 22 | invalid IBC Channel ID |
| oracle | 23 | invalid Band IBC request interval |
| oracle | 24 | Invalid Band IBC Update Request Proposal |
| oracle | 25 | Band IBC Oracle Request not found |
| oracle | 26 | Base Info is empty |
| oracle | 27 | provider is empty |
| oracle | 28 | invalid provider name |
| oracle | 29 | invalid symbol |
| oracle | 30 | relayer already exists |
| oracle | 31 | provider price not found |
| oracle | 32 | invalid oracle request |
| oracle | 33 | no price for oracle was found |
| oracle | 34 | no address for Pyth contract found |
| oracle | 35 | unauthorized Pyth price relay |
| oracle | 36 | unauthorized Pyth price relay |
| oracle | 37 | unauthorized Pyth price relay |
| oracle | 38 | unauthorized Pyth price relay |
| oracle | 39 | empty price attestations |
| oracle | 40 | bad Stork message timestamp |
| oracle | 41 | sender stork is empty |
| oracle | 42 | invalid stork signature |
| oracle | 43 | stork asset id not unique |
# Oracle
Source: https://docs.injective.network/developers-native/injective/oracle/index
## Abstract
This specification specifies the oracle module, which is primarily used by the `exchange` modules to obtain external price data.
## Workflow
1. New price feed providers must first obtain oracle privileges through a governance proposal which grants privileges to a list of relayers. The exception to this is for the Coinbase price oracle, as anyone can send Coinbase price updates since they are already exclusively signed by the Coinbase oracle private key. [flags]
```
* The json file should have the following format (remove all comments before submitting):
```json theme={null}
{ // Remove all comments before submitting!
"denom": "factory/inj1address/myTokenDenom",
"contract_hook": "ContractHookAddress",
"role_permissions": [ // CAUTION: makes sure to set role permissions for all namespace management roles!
{
"name": "EVERYONE",
"role_id": 0,
"permissions": 10 // SEND (8) + RECEIVE (2); excludes MINT, SUPER_BURN, and management actions
},
{
"name": "admin",
"role_id": 1,
"permissions": 2013265920 // MODIFY_ROLE_PERMISSIONS, MODIFY_ROLE_MANAGERS, etc. (all namespace management actions)
},
{
"name": "user",
"role_id": 2,
"permissions": 15 // MINT (1), RECEIVE (2), BURN (4), SEND (8)
}
],
"actor_roles": [
{
"actor": "inj1specificactoraddress",
"roles": ["admin"]
},
{
"actor": "inj1anotheractoraddress",
"roles": ["user"]
}
],
"role_managers": [ // CAUTION: Make sure to set role managers for all namespace management roles!
{
"manager": "inj1manageraddress",
"roles": ["admin"]
}
],
"policy_statuses": [
{
"action": 1, // Action_MINT
"is_disabled": false,
"is_sealed": false
},
{
"action": 4, // Action_BURN
"is_disabled": false,
"is_sealed": false
}
],
"policy_manager_capabilities": [
{
"manager": "inj1policymanageraddress",
"action": 268435456, // MODIFY_CONTRACT_HOOK
"can_disable": true,
"can_seal": false
}
]
}
```
## `update-namespace`
```json theme={null}
injectived tx permissions update-namespace [flags]
```
* Namespace updates are incremental, so unless a change is explicitly stated in the JSON, existing state will be untouched
```json theme={null}
{ // Remove all comments before submitting!
"denom": "factory/inj1address/myTokenDenom",
"contract_hook": {
"new_value": "newContractHookAddress"
},
"role_permissions": [
{
"name": "user",
"role_id": 2,
"permissions": 10 // RECEIVE (2) + SEND (8)
},
{
"name": "EVERYONE",
"role_id": 0,
"permissions": 0 // Revoke all permissions
}
],
"role_managers": [
{
"manager": "inj1manageraddress",
"roles": ["admin", "user"]
}
],
"policy_statuses": [
{
"action": 1, // MINT
"is_disabled": true,
"is_sealed": false
},
{
"action": 4, // BURN
"is_disabled": false,
"is_sealed": true
}
],
"policy_manager_capabilities": [
{
"manager": "inj1policymanageraddress",
"action": 536870912, // MODIFY_ROLE_PERMISSIONS
"can_disable": true,
"can_seal": false
}
]
}
```
## `update-namespace-roles`
```json theme={null}
injectived tx permissions update-namespace-roles [flags]
```
```json theme={null}
{
"denom": "factory/inj1address/myTokenDenom",
"role_actors_to_add": [
{
"role": "admin",
"actors": [
"inj1actoraddress1",
"inj1actoraddress2"
]
},
{
"role": "user",
"actors": [
"inj1actoraddress3"
]
}
],
"role_actors_to_revoke": [
{
"role": "user",
"actors": [
"inj1actoraddress4"
]
},
{
"role": "admin",
"actors": [
"inj1actoraddress5"
]
}
]
}
```
## `claim-voucher`
```bash theme={null}
injectived tx permissions claim-voucher
```
* No JSON is needed for this command since the only parameter needed is the denom
# Error Codes
Source: https://docs.injective.network/developers-native/injective/permissions/99_errors
This document lists the error codes used in the module.
| Module | Error Code | description |
| ----------- | ---------- | ---------------------------------- |
| permissions | 2 | namespace for denom already exists |
| permissions | 3 | unauthorized account |
| permissions | 4 | invalid genesis |
| permissions | 5 | invalid namespace |
| permissions | 6 | invalid permissions |
| permissions | 7 | unknown role |
| permissions | 8 | unknown contract address |
| permissions | 9 | restricted action |
| permissions | 10 | invalid role |
| permissions | 11 | namespace for denom does not exist |
| permissions | 12 | wasm hook query error |
| permissions | 13 | voucher not found |
| permissions | 14 | invalid contract hook |
| permissions | 15 | unknown policy |
| permissions | 16 | unauthorized policy change |
# Permissions
Source: https://docs.injective.network/developers-native/injective/permissions/index
## Abstract
Bringing real world permissioned assets (e.g. tokenized treasury yield products) on-chain require certain levels of control over asset actions/properties such as transfers, holders (whitelists), and more.
The `permissions` module allows managing certain prefixed actions and roles for real world assets and permissioned denoms created within a namespace on the chain-level. It provides a flexible and extensible way to define and enforce permissions and roles and serves as the entry point through which real world assets can be natively issued and managed on Injective.
## Contents
1. [Concepts](/developers-native/injective/permissions/01_concepts)
2. [State](/developers-native/injective/permissions/02_state)
3. [State Transitions](/developers-native/injective/permissions/03_state_transitions)
4. [How to Launch Permissioned Assets](/developers-native/injective/permissions/04_launch_permissioned_asset)
5. [Error Codes](/developers-native/injective/permissions/99_errors)
# Concepts
Source: https://docs.injective.network/developers-native/injective/tokenfactory/01_concepts
# Concepts
The `tokenfactory` module allows any account to create a new token with
the name `factory/{creator address}/{subdenom}`. Because tokens are
namespaced by creator address, this allows token minting to be
permissionless, due to not needing to resolve name collisions. A single
account can create multiple denoms, by providing a unique subdenom for each
created denom. Once a denom is created, the original creator is given
"admin" privileges over the asset. This allows them to:
* Mint their denom to any account
* Burn their denom from any account (if enabled)
* Create a transfer of their denom between any two accounts
* Change the admin. In the future, more admin capabilities may be added. Admins
can choose to share admin privileges with other accounts using the authz
module. The `ChangeAdmin` functionality, allows changing the master admin
account, or even setting it to `""`, meaning no account has admin privileges
of the asset.
# State
Source: https://docs.injective.network/developers-native/injective/tokenfactory/02_state
# State
The tokenfactory module keeps state of the following primary objects:
## Denom Authority Metadata
* 0x02 + | + denom + | + 0x01 ⇒ `DenomAuthorityMetadata`
## Denom Creators
* 0x03 + | + creator + | denom ⇒ denom
```protobuf theme={null}
// DenomAuthorityMetadata specifies metadata for addresses that have specific
// capabilities over a token factory denom.
message DenomAuthorityMetadata {
option (gogoproto.equal) = true;
// Can be empty for no admin, or a valid injective address
string admin = 1 [ (gogoproto.moretags) = "yaml:\"admin\"" ];
// true if the admin can burn tokens from other addresses
bool admin_burn_allowed = 2 [ (gogoproto.moretags) = "yaml:\"admin_burn_allowed\"" ];
}
```
Genesis state defines the initial state of the module to be used to setup the module.
```protobuf theme={null}
// GenesisState defines the tokenfactory module's genesis state.
message GenesisState {
// params defines the parameters of the module.
Params params = 1 [ (gogoproto.nullable) = false ];
repeated GenesisDenom factory_denoms = 2 [
(gogoproto.moretags) = "yaml:\"factory_denoms\"",
(gogoproto.nullable) = false
];
}
// GenesisDenom defines a tokenfactory denom that is defined within genesis
// state. The structure contains DenomAuthorityMetadata which defines the
// denom's admin.
message GenesisDenom {
option (gogoproto.equal) = true;
string denom = 1 [ (gogoproto.moretags) = "yaml:\"denom\"" ];
DenomAuthorityMetadata authority_metadata = 2 [
(gogoproto.moretags) = "yaml:\"authority_metadata\"",
(gogoproto.nullable) = false
];
}
```
## Params
`Params` is a module-wide configuration that stores system parameters and defines overall functioning of the tokenfactory module.
This module is modifiable by governance using params update proposal natively supported by `gov` module.
Struct for the `ocr` module params store.
```protobuf theme={null}
// Params defines the parameters for the tokenfactory module.
message Params {
repeated cosmos.base.v1beta1.Coin denom_creation_fee = 1 [
(gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.Coins",
(gogoproto.moretags) = "yaml:\"denom_creation_fee\"",
(gogoproto.nullable) = false
];
}
```
# null
Source: https://docs.injective.network/developers-native/injective/tokenfactory/03_messages
# Messages
In this section we describe the processing of the tokenfactory messages and the corresponding updates to the state.
## Messages
### CreateDenom
Creates a denom of `factory/{creator address}/{subdenom}` given the denom creator
address, subdenom and associated metadata (name, symbol, decimals). Subdenoms can contain `[a-zA-Z0-9./]`.
`allow_admin_burn` can be set to true to allow the admin to burn tokens from other addresses.
```protobuf theme={null}
message MsgCreateDenom {
string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
// subdenom can be up to 44 "alphanumeric" characters long.
string subdenom = 2 [ (gogoproto.moretags) = "yaml:\"subdenom\"" ];
string name = 3 [ (gogoproto.moretags) = "yaml:\"name\"" ];
string symbol = 4 [ (gogoproto.moretags) = "yaml:\"symbol\"" ];
uint32 decimals = 5 [ (gogoproto.moretags) = "yaml:\"decimals\"" ];
// true if admins are allowed to burn tokens from other addresses
bool allow_admin_burn = 6 [ (gogoproto.moretags) = "yaml:\"allow_admin_burn\"" ];}
```
**State Modifications:**
* Fund community pool with the denom creation fee from the creator address, set
in `Params`.
* Set `DenomMetaData` via bank keeper.
* Set `AuthorityMetadata` for the given denom to store the admin for the created
denom `factory/{creator address}/{subdenom}`. Admin is automatically set as the
Msg sender.
* Add denom to the `CreatorPrefixStore`, where a state of denoms created per
creator is kept.
### Mint
Minting of a specific denom is only allowed for the current admin.
Note, the current admin is defaulted to the creator of the denom.
```protobuf theme={null}
message MsgMint {
string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
cosmos.base.v1beta1.Coin amount = 2 [
(gogoproto.moretags) = "yaml:\"amount\"",
(gogoproto.nullable) = false
];
}
```
**State Modifications:**
* Safety check the following
* Check that the denom minting is created via `tokenfactory` module
* Check that the sender of the message is the admin of the denom
* Mint designated amount of tokens for the denom via `bank` module
### Burn
Burning of a specific denom is only allowed for the current admin.
Note, the current admin is defaulted to the creator of the denom.
```protobuf theme={null}
message MsgBurn {
string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
cosmos.base.v1beta1.Coin amount = 2 [
(gogoproto.moretags) = "yaml:\"amount\"",
(gogoproto.nullable) = false
];
}
```
**State Modifications:**
* Safety check the following
* Check that the denom minting is created via `tokenfactory` module
* Check that the sender of the message is the admin of the denom
* Burn designated amount of tokens for the denom via `bank` module
### ChangeAdmin
Change the admin of a denom. Note, this is only allowed to be called by the current admin of the denom. After the admin address is set to zero address, token holders can still execute `MsgBurn` for tokens they possess.
```protobuf theme={null}
message MsgChangeAdmin {
string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
string denom = 2 [ (gogoproto.moretags) = "yaml:\"denom\"" ];
string newAdmin = 3 [ (gogoproto.moretags) = "yaml:\"new_admin\"" ];
}
```
### SetDenomMetadata
Setting of metadata for a specific denom is only allowed for the admin of the denom.
It allows the overwriting of the denom metadata in the bank module. The admin can also disable the admin burn
capability, if enabled.
```protobuf theme={null}
message MsgSetDenomMetadata {
option (amino.name) = "injective/tokenfactory/set-denom-metadata";
option (cosmos.msg.v1.signer) = "sender";
string sender = 1 [ (gogoproto.moretags) = "yaml:\"sender\"" ];
cosmos.bank.v1beta1.Metadata metadata = 2 [
(gogoproto.moretags) = "yaml:\"metadata\"",
(gogoproto.nullable) = false
];
message AdminBurnDisabled {
// true if the admin burn capability should be disabled
bool should_disable = 1 [ (gogoproto.moretags) = "yaml:\"should_disable\"" ];
}
AdminBurnDisabled admin_burn_disabled = 3 [ (gogoproto.moretags) = "yaml:\"admin_burn_disabled\"" ];
}
```
**State Modifications:**
* Check that sender of the message is the admin of denom
* Modify `AuthorityMetadata` state entry to change the admin of the denom and to potentially disable admin burn capability.
## Expectations from the chain
The chain's bech32 prefix for addresses can be at most 16 characters long.
This comes from denoms having a 128 byte maximum length, enforced from the SDK,
and us setting longest\_subdenom to be 44 bytes.
A token factory token's denom is: `factory/{creator address}/{subdenom}`
Splitting up into sub-components, this has:
* `len(factory) = 7`
* `2 * len("/") = 2`
* `len(longest_subdenom)`
* `len(creator_address) = len(bech32(longest_addr_length, chain_addr_prefix))`.
Longest addr length at the moment is `32 bytes`. Due to SDK error correction
settings, this means `len(bech32(32, chain_addr_prefix)) = len(chain_addr_prefix) + 1 + 58`.
Adding this all, we have a total length constraint of `128 = 7 + 2 + len(longest_subdenom) + len(longest_chain_addr_prefix) + 1 + 58`.
Therefore `len(longest_subdenom) + len(longest_chain_addr_prefix) = 128 - (7 + 2 + 1 + 58) = 60`.
The choice between how we standardized the split these 60 bytes between maxes
from longest\_subdenom and longest\_chain\_addr\_prefix is somewhat arbitrary.
Considerations going into this:
* Per [BIP-0173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32)
the technically longest HRP for a 32 byte address ('data field') is 31 bytes.
(Comes from encode(data) = 59 bytes, and max length = 90 bytes)
* subdenom should be at least 32 bytes so hashes can go into it
* longer subdenoms are very helpful for creating human readable denoms
* chain addresses should prefer being smaller. The longest HRP in cosmos to date is 11 bytes. (`persistence`)
For explicitness, its currently set to `len(longest_subdenom) = 44` and `len(longest_chain_addr_prefix) = 16`.
Please note, if the SDK increases the maximum length of a denom from 128 bytes,
these caps should increase.
So please don't make code rely on these max lengths for parsing.
# Events
Source: https://docs.injective.network/developers-native/injective/tokenfactory/04_events
# Events
The tokenfactory module emits the following events:
An EventCreateTFDenom is emitted upon MsgCreateDenom execution, which creates a new token factory denom.
```protobuf theme={null}
message EventCreateTFDenom {
string account = 1;
string denom = 2;
}
```
An EventMintTFDenom is emitted upon MsgMint execution, which mints a new token factory denom for a recipient.
```protobuf theme={null}
message EventMintTFDenom {
string recipient_address = 1;
cosmos.base.v1beta1.Coin amount = 2 [(gogoproto.nullable) = false];
}
```
An EventBurnDenom is emitted upon MsgBurn execution, which burns a specified amount for any denom for a user.
```protobuf theme={null}
message EventBurnDenom {
string burner_address = 1;
cosmos.base.v1beta1.Coin amount = 2 [(gogoproto.nullable) = false];
}
```
An EventChangeTFAdmin is emitted upon MsgChangeAdmin execution, which changes the admin address for a new token factory denom.
```protobuf theme={null}
message EventChangeTFAdmin {
string denom = 1;
string new_admin_address = 2;
}
```
An EventSetTFDenomMetadata is emitted upon MsgSetDenomMetadata execution, which sets the token factory denom metadata for a given token factory denom.
```protobuf theme={null}
message EventSetTFDenomMetadata {
string denom = 1;
cosmos.bank.v1beta1.Metadata metadata = 2[(gogoproto.nullable) = false];
}
```
# Params
Source: https://docs.injective.network/developers-native/injective/tokenfactory/05_params
# Parameters
The tokenfactory module contains the following parameters:
```protobuf theme={null}
// Params defines the parameters for the tokenfactory module.
message Params {
repeated cosmos.base.v1beta1.Coin denom_creation_fee = 1 [
(gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.Coins",
(gogoproto.moretags) = "yaml:\"denom_creation_fee\"",
(gogoproto.nullable) = false
];
}
```
# Error Codes
Source: https://docs.injective.network/developers-native/injective/tokenfactory/99_errors
This document lists the error codes used in the module.
| Module | Error Code | description |
| ------------ | ---------- | -------------------------------------------------------------------- |
| tokenfactory | 2 | attempting to create a denom that already exists (has bank metadata) |
| tokenfactory | 3 | unauthorized account |
| tokenfactory | 4 | invalid denom |
| tokenfactory | 5 | invalid creator |
| tokenfactory | 6 | invalid authority metadata |
| tokenfactory | 7 | invalid genesis |
| tokenfactory | 8 | subdenom too long, max length is %d bytes |
| tokenfactory | 9 | subdenom too short, min length is %d bytes |
| tokenfactory | 10 | nested subdenom too short, each one should have at least %d bytes |
| tokenfactory | 11 | creator too long, max length is %d bytes |
| tokenfactory | 12 | denom does not exist |
| tokenfactory | 13 | amount has to be positive |
# Tokenfactory
Source: https://docs.injective.network/developers-native/injective/tokenfactory/index
## Abstract
The tokenfactory module allows for the permissionless creation of new bank denom tokens.
## Contents
1. [Concepts](/developers-native/injective/tokenfactory/01_concepts)
2. [State](/developers-native/injective/tokenfactory/02_state)
3. [Messages](/developers-native/injective/tokenfactory/03_messages)
4. [Events](/developers-native/injective/tokenfactory/04_events)
5. [Parameters](/developers-native/injective/tokenfactory/05_params)
# Concepts
Source: https://docs.injective.network/developers-native/injective/wasmx/01_concepts
## Concepts
### Begin blocker execution
Smart contracts can only respond to incoming messages and do not have the ability to execute actions on their own schedule. The Wasmx module allows contracts to be registered and called in the begin blockers section of each block.
To be eligible for this, each registered contract must respond to the sudo message called `begin_blocker` which can only be called by the chain itself and not directly by any user or other contract. This ensures that the "begin\_blocker" message can be trusted.
### Registration
Upon registering a contract, the user must declare a gas price, which is the amount they are willing to pay for contract execution, as well as a gas limit, which is the maximum amount of gas that can be consumed during the execution of the contract.
Currently, contract registration can only be done through a governance proposal. This proposal, if approved, will add the contract at a specific address to the list of contracts that are run during each "begin blockers" period.
For security reasons, the proposer must specify a code\_id for the contract, which will be verified upon registration and each time the contract is executed. This is to prevent an attacker from registering a benign contract but later upgrading it to a malicious one. The proposer can request to be exempt from this check when registering the contract to avoid delays when a new version of the contract is released, but this may affect the voting results depending on the trustworthiness of the proposer.
The proposer can also request for the contract to be "pinned," meaning it is loaded and kept in memory, which can greatly improve the performance of the contract.
### Deregistration
A contract can be deregistered through a governance proposal, which can be initiated by anyone, including the contract owner if they no longer require the contract or by any other individual if the contract is found to be malicious.
If contract fails to execute due to insufficient gas it will be automatically deregistered.
When contract is deregistered, wasmx will call special `deregister{}` callback (if present) as a sudo message in the contract.
### Deactivation
A contract can be deactivated automatically if it runs out of gas, or manually by the contract owner. When a contract is deactivated, wasmx will call a special `deactivate{}` callback (if present) as a sudo message in the contract. The contract can be reactivated by the contract owner.
### Fee Grant
The Wasmx module allows other addresses (contracts, EOAs) to pay for the Begin blocker execution of other contracts through the [`x/feegrant`](https://docs.cosmos.network/main/modules/feegrant) module.
When a contract is being registered for the first time, users specify the `FundingMode` which indicates how the contract's execution will be funded. Three modes are supported:
* `SelfFunded` - contract will pay for its own execution (default)
* `GrantOnly` - contract will execute if its associated allowance covers for it (provided by the `GranterAddress` in the `ContractRegistrationRequest`)
* `Dual` - contract will prioritize spending its allowance's funds. In case the allowance cannot cover for execution, it will use its own funds instead
Given there are 3 kinds of allowances provided by the `x/feegrant` module (Basic, Periodic and AllowedMsg), the wasmx module supports only Basic and Periodic. Granting an `AllowedMsgAllowance` to a contract is discouraged as any contract attempting to use this kind of allowance will error by default.
### Pausing, params update
The owner of a contract has the ability to deactivate or activate the contract at any time without requiring a governance vote. They can also update the parameters for contract execution, such as the gas price or gas limit, at any time.
### Batch methods
For convenience, the Wasmx module provides batch versions of some of the previously mentioned proposals, such as batch registration and deregistration, as well as a batch version of the StoreCodeProposal. These batch versions allow multiple proposals to be processed at the same time, rather than individually.
# Data
Source: https://docs.injective.network/developers-native/injective/wasmx/02_data
## Data
### RegisteredContract
Data stored about each contract
```go theme={null}
type RegisteredContract struct {
// limit of gas per BB execution
GasLimit uint64 json:"gas_limit,omitempty"
// gas price that contract is willing to pay for execution in BeginBlocker
GasPrice uint64 json:"gas_price,omitempty"
// is contract currently active
IsExecutable bool json:"is_executable,omitempty"
// code_id that is allowed to be executed (to prevent malicious updates) - if nil/0 any code_id can be executed
CodeId uint64 json:"code_id,omitempty"ł
// optional - admin addr that is allowed to update contract data
AdminAddress string json:"admin_address,omitempty"
// address of an account providing grant for execution
GranterAddress string
// enum indicating how contract's execution is funded
FundMode FundingMode
}
type FundingMode int32
const (
FundingMode_Unspecified FundingMode = 0
FundingMode_SelfFunded FundingMode = 1
FundingMode_GrantOnly FundingMode = 2
FundingMode_Dual FundingMode = 3
)
```
# Governance Proposals
Source: https://docs.injective.network/developers-native/injective/wasmx/03_proposals
## Governance Proposals
### ContractRegistrationRequest
`ContractRegistrationRequest` is a base message for registering new contracts (shouldn't be used directly but as a part of proposal)
```go theme={null}
type ContractRegistrationRequest struct {
ContractAddress string
GasLimit uint64
GasPrice uint64
PinContract bool
AllowUpdating bool
CodeId uint64
ContractAdmin string
GranterAddress string
FundMode FundingMode
}
```
**Fields description**
* `ContractAddress` - unique Identifier for contract instance to be registered.
* `GasLimit` - Maximum gas to be used for the smart contract execution.
* `GasPrice` - Gas price to be used for the smart contract execution.
* `PinContract` - should contract be pinned.
* `AllowUpdating`- defines wether contract owner can migrate it without need to register again (if false only current code\_id will be allowed to be executed)
* `CodeId` - code\_id of the contract being registered - will be verified on execution to allow last minute change (after votes were cast)
* `AdminAddress` - optional address of admin account (that will be allowed to pause or update contract params)
* `GranterAddress` - address of an account which granted funds for execution. Must be set if `FundMode` is other than `SelfFunded` (see below for an explanation)
`FundingMode` indicates how the contract will fund its own execution.
```go theme={null}
enum FundingMode {
Unspecified = 0;
SelfFunded = 1;
GrantOnly = 2;
Dual = 3;
}
```
* `SelfFunded` - contract will use its own funds to execute.
* `GrantOnly` - contract wil only use funds provided by the grant.
* `Dual` - contract will first deplete grant's funds before using its own.
### ContractRegistrationRequestProposal
`ContractRegistrationRequestProposal` defines an SDK message to register a single contract in wasmx contract registry.
```go theme={null}
type ContractRegistrationRequestProposal struct {
Title string
Description string
ContractRegistrationRequest ContractRegistrationRequest
}
```
**Fields description**
* `Title` describes the title of the proposal.
* `Description` describes the description of the proposal.
* `ContractRegistrationRequest` contains contract registration request (as described above)
### BatchContractRegistrationRequestProposal
`BatchContractRegistrationRequestProposal` defines an SDK message to register a batch of contracts in wasmx contract registry.
```go theme={null}
type BatchContractRegistrationRequestProposal struct {
Title string
Description string
ContractRegistrationRequests []ContractRegistrationRequest
}
```
**Fields description**
* `Title` describes the title of the proposal.
* `Description` describes the description of the proposal.
* `ContractRegistrationRequests` contains a list of contracts registration requests (as described above)
### BatchStoreCodeProposal
`BatchStoreCodeProposal` defines an SDK message to store a batch of contracts in wasm.
```go theme={null}
type BatchStoreCodeProposal struct {
Title string
Description string
Proposals []types.StoreCodeProposal
}
```
**Fields description**
* `Title` describes the title of the proposal.
* `Description` describes the description of the proposal.
* `Proposals` contains a list of store code proposals (as defined by Cosmos wasm module)
### BatchContractDeregistrationProposal
`BatchContractDeregistrationProposal` defines an SDK message to deregister a batch of contracts in wasm.
```go theme={null}
type BatchContractDeregistrationProposal struct {
Title string
Description string
Contracts []string
}
```
**Fields description**
* `Title` describes the title of the proposal.
* `Description` describes the description of the proposal.
* `Contracts` contains a list of addresses of contracts to be deregistered
# Messages
Source: https://docs.injective.network/developers-native/injective/wasmx/04_messages
## Messages
### MsgUpdateContract
Updates registered contract execution params (gas price, limit). Can also define a new admin account.
Can be called only by admin (if defined) or contract itself.
```go theme={null}
type MsgUpdateContract struct {
Sender string `json:"sender,omitempty"`
// Unique Identifier for contract instance to be registered.
ContractAddress string `json:"contract_address,omitempty"`
// Maximum gas to be used for the smart contract execution.
GasLimit uint64 `json:"gas_limit,omitempty"`
// gas price to be used for the smart contract execution.
GasPrice uint64 `json:"gas_price,omitempty"`
// optional - admin account that will be allowed to perform any changes
AdminAddress string `json:"admin_address,omitempty"`
}
```
### MsgDeactivateContract
Deactivates a registered contract (it will no longer be executed in begin blocker)
```go theme={null}
type MsgDeactivateContract struct {
Sender string `json:"sender,omitempty"`
// Unique Identifier for contract instance to be activated.
ContractAddress string `json:"contract_address,omitempty"`
}
```
### MsgActivateContract
Reactivates a registered contract (it will be executed in begin blocker from now on again)
```go theme={null}
type MsgActivateContract struct {
Sender string `json:"sender,omitempty"`
// Unique Identifier for contract instance to be activated.
ContractAddress string `json:"contract_address,omitempty"`
}
```
### MsgExecuteContract
Invokes a function defined within the smart contract. Function and parameters are encoded in `ExecuteMsg`, which is a JSON message encoded in Base64.
```go theme={null}
type MsgExecuteContract struct {
Sender sdk.AccAddress `json:"sender" yaml:"sender"`
Contract sdk.AccAddress `json:"contract" yaml:"contract"`
ExecuteMsg core.Base64Bytes `json:"execute_msg" yaml:"execute_msg"`
Coins sdk.Coins `json:"coins" yaml:"coins"`
}
```
### MsgMigrateContract
Can be issued by the owner of a migratable smart contract to reset its code ID to another one. `MigrateMsg` is a JSON message encoded in Base64.
```go theme={null}
type MsgMigrateContract struct {
Owner sdk.AccAddress `json:"owner" yaml:"owner"`
Contract sdk.AccAddress `json:"contract" yaml:"contract"`
NewCodeID uint64 `json:"new_code_id" yaml:"new_code_id"`
MigrateMsg core.Base64Bytes `json:"migrate_msg" yaml:"migrate_msg"`
}
```
### MsgUpdateContractOwner
Can be issued by the smart contract's owner to transfer ownership.
```go theme={null}
type MsgUpdateContractOwner struct {
Owner sdk.AccAddress `json:"owner" yaml:"owner"`
NewOwner sdk.AccAddress `json:"new_owner" yaml:"new_owner"`
Contract sdk.AccAddress `json:"contract" yaml:"contract"`
}
```
# Params
Source: https://docs.injective.network/developers-native/injective/wasmx/05_params
## Params
The subspace for the wasmx module is `wasmx`.
```go theme={null}
type Params struct {
// Set the status to active to indicate that contracts can be executed in begin blocker.
IsExecutionEnabled bool ` json:"is_execution_enabled,omitempty"`
// Maximum aggregate total gas to be used for the contract executions in the BeginBlocker.
MaxBeginBlockTotalGas uint64 `json:"max_begin_block_total_gas,omitempty"`
// the maximum gas limit each individual contract can consume in the BeginBlocker.
MaxContractGasLimit uint64 `json:"max_contract_gas_limit,omitempty"`
// min_gas_price defines the minimum gas price the contracts must pay to be executed in the BeginBlocker.
MinGasPrice uint64 `json:"min_gas_price,omitempty"`
}
```
# Error Codes
Source: https://docs.injective.network/developers-native/injective/wasmx/99_errors
This document lists the error codes used in the module.
| Module | Error Code | description |
| ------ | ---------- | ------------------------------- |
| wasmx | 1 | invalid gas limit |
| wasmx | 2 | invalid gas price |
| wasmx | 3 | invalid contract address |
| wasmx | 4 | contract already registered |
| wasmx | 5 | duplicate contract |
| wasmx | 6 | no contract addresses found |
| wasmx | 7 | invalid code id |
| wasmx | 8 | not possible to deduct gas fees |
| wasmx | 9 | missing granter address |
| wasmx | 10 | granter address does not exist |
| wasmx | 11 | invalid funding mode |
# Wasmx
Source: https://docs.injective.network/developers-native/injective/wasmx/index
## Abstract
The `wasmx` module handles integration of [CosmWasm](https://cosmwasm.com) smart contracts with Injective Chain.
Its main function is to provide a method for contracts to be executed in the begin blocker section of each block.
A contract may be automatically deactivated if it runs out of gas but can be reactivated by the contract owner.
It also includes helper methods for managing contracts, such as a batch code storage proposal. These functions allow for seamless integration of CosmWasm contracts with the Injective Chain and provide useful tools for managing and maintaining those contracts.
## Contents
1. [Concepts](/developers-native/injective/wasmx/01_concepts)
2. [Data](/developers-native/injective/wasmx/02_data)
3. [State](/developers-native/injective/wasmx/03_proposals)
4. [Messages](/developers-native/injective/wasmx/04_messages)
5. [Params](/developers-native/injective/wasmx/05_params)
# Injective FAQ
Source: https://docs.injective.network/faq
## Fundamentals
Q: What account address types are supported in Injective?
A: There are 2 address types supported:
* Bech32 (`inj...`), which is primarily used when interacting via Cosmos wallets/ tools
* Hexadecimal (`0x...`), which is primarily used when interacting via EVM wallets/ tools
***
Q: Is there a way to find which Injective Cosmos address is mapped to which Injective EVM address?
A: The mapping between these address types is done through a mathematical operation,
which is 1 to 1, and bidirectional.
* Live example: [Injective Testnet Faucet](https://testnet.faucet.injective.network/)
* Docs: [TS code examples](https://docs.injective.network/developers/convert-addresses)
***
## Infrastructure
Q: When maintaining a private node:
* Should we store 2.5 Ti archival data (event provider)?
* Can we skip that part and make indexer work?
A: Event provider can be pruned. One can use the public event provider endpoint for the initial sync. Then resort to local deployment, but only from the latest height. Therefore, yes can be skipped.
***
## EVM
Q: Does Injective have a deployment of the [`multicall3`](https://www.multicall3.com/) smart contract?
A: Yes.
* Injective Mainnet `multicall3`: [`0xcA11bde05977b3631167028862bE2a173976CA11`](https://blockscout.injective.network/address/0xcA11bde05977b3631167028862bE2a173976CA11?tab=contract)
* Injective Testnet `multicall3`: [`0xcA11bde05977b3631167028862bE2a173976CA11`](https://testnet.blockscout.injective.network/address/0xcA11bde05977b3631167028862bE2a173976CA11?tab=contract)
***
# Glossary
Source: https://docs.injective.network/glossary
Pocket size cheat sheet for Injective. Use this glossary to learn about terms specific to Injective.
### Active set
The validators that participate in consensus and receive rewards.
### Airdrops
Additional rewards given to delegators through certain validators that are separate from staking rewards. Airdrops are generally given by applications in the Injective ecosystem to increase visibility.
### Arbitrage
A process by which users seek to capitalize on a price difference across markets. Arbitrageurs typically purchase assets in one market and sell them in another market for a higher price.
### Blockchain
An unchangeable ledger of transactions copied among a network of independent computer systems.
### Blocks
Groups of information stored on a blockchain. Each block contains transactions that are grouped, verified, and signed by validators.
### Bonded validator
A validator in the active set participating in consensus. Bonded validators are able to earn rewards.
### Bonding
When a user delegates or bonds INJ to a validator to receive staking rewards. Validators never have ownership of a delegator's INJ, even when bonded. Delegating, bonding, and staking generally refer to the same process.
### Burn
The permanent destruction of assets. Injective burns INJ after each burn auction.
### Burn Auction
A weekly event in which community members can use INJ to bid for 60% of all exchange fees collected by Injective. The INJ used by the winning bidder will be burnt.
### Commission
The percentage of staking rewards a validator keeps before distributing the rest of the rewards to delegators. A validator’s income relies solely on this commission. Validators set their own commission rates.
### Community pool
A special fund designated for funding community projects. Any community member can create a governance proposal to spend the tokens in the community pool. If the proposal passes, the funds are spent as specified in the proposal.
### Consensus
A system used by validators or miners to agree that each block of transactions in a blockchain is correct. Injective uses the Tendermint consensus framework. Validators earn rewards for participating in consensus. Visit the [Tendermint official documentation site](https://docs.tendermint.com/) for more information.
### Cosmos-SDK
The open-source framework the Injective blockchain is built on. For more information, check out the [Cosmos SDK Documentation](https://docs.cosmos.network/).
### CosmWasm
The library utilized by Injective to power on-chain smart contracts. For more information, check out the CosmWasm Documentation.
### dApp
Decentralized application. An application built on a decentralized platform.
### DDoS
Distributed denial of service attack. When an attacker floods a network with traffic or requests in order to disrupt service.
### DeFi
Decentralized finance. A movement away from traditional finance and toward systems that do not require financial intermediaries.
### Delegate
When users or delegators add their INJ to a validator's stake in exchange for rewards. Delegated INJ is bonded to a validator. Validators never have ownership of a delegator's INJ. Delegating, bonding, and staking generally refer to the same process.
### Delegator
A user who delegates, bonds, or stakes INJ to a validator to earn rewards. Delegating, bonding, and staking generally refer to the same process.
### Devnet
Development network. A network that operates independently of the mainnet, allowing users to test new features or products without disrupting the primary network.
### Frequent Batch Auction (FBA)
The model used by Injective for on-chain order matching. This model uses capital more efficiently compared to Continuous Double Auction (CDA), which is utilized by most of the Centralized exchanges offering crypto derivatives and traditional financial markets. The Frequent Batch Auction model also eliminates front-running possibilities.
### Full node
A computer connected to the \[Injective mainnet that can validate transactions and interact with Injective. All active validators run full nodes.
### Gas Fees
Compute fees added on to all transactions to avoid spamming. Validators set minimum gas prices and reject transactions that have implied gas prices below this threshold.
### Governance
Governance is the democratic process that allows users and validators to make changes to Injective. Community members submit, vote, and implement proposals. One staked INJ is equal to one vote.
### Governance proposal
A written submission for a change or addition to the Injective protocol. Topics of proposals can vary from community pool spending, software changes, parameter changes, or any change pertaining to Injective.
### IBC
Inter-Blockchain Communication. The technology that enables different blockchains to interact with each other. IBC allows for assets to be traded and transacted across different blockchains.
### INJ
The native token of Injective.
### injectived
The command-line interface for interacting with an Injective node.
For more information on injectived, see `injectived` guides.
### Injective core
The official source code for Injective.
For more information on the Injective core, see Injective core modules.
### Injective Hub
Inejctive's platform for wallets, governance, staking and INJ burn auctions.
To learn about the features of Injective Hub, visit the Injective Hub guide.
### Inactive set
Validators that are not in the active set. These validators do not participate in consensus and do not earn rewards.
### Jailed
Validators who misbehave are jailed or excluded from the active set for a period of time.
### Maximum Extractable Value (MEV)
The maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block.
Injective is MEV-resistant.
### Module
A section of the Injective core that represents a particular function of Injective. Visit the Injective core module specifications for more information.
### Oracle
A 3rd party service enabling Injective to access external, real-world data. Typically, this is the price feed.
### Pools
Groups of tokens. Supply pools represent the total supply of tokens in a market.
### Proof of Stake
A validation method utilized by blockchains in which validators are chosen to propose blocks according to the number of coins they hold.
### Quorum
The minimum amount of votes needed to make an election viable. 33% of all staked INJ must vote to meet quorum. If quorum is not met before the voting period ends, the proposal fails, and the proposer's deposit is burned.
### Redelegate
When a delegator wants to transfer their bonded INJ to a different validator. Redelegating INJ is instant and does not require a 21-day unbonding period.
### Rewards
Revenue generated from fees given to validators and disbursed to delegators.
### Self-delegation
The amount of INJ a validator bonds to themselves. Also referred to as self-bond.
### Slashing
Punishment for validators that misbehave. Validators lose part of their stake when they get slashed.
### Slippage
The difference in an asset’s price between the start and end of a transaction.
### Stake
The amount of INJ bonded to a validator.
### Staking
When a user delegates or bonds their INJ to an active validator to receive rewards. Bonded INJ adds to a validator's stake. Validators provide their stakes as collateral to participate in the consensus process. Validators with larger stakes are chosen to participate more often. Validators receive staking rewards for their participation. A validator's stake can be slashed if the validator misbehaves. Validators never have ownership of a delegator's INJ, even when staking.
For more information on staking, visit the concepts page.
### Tendermint consensus
The consensus framework used by Injective. First, a validator proposes a new block. Other validators vote on the block in two rounds. If a block receives a two-thirds majority or greater of yes votes in both rounds, it gets added to the blockchain. Validators get rewarded with the block's transaction fees. Proposers get rewarded extra. Each validator is chosen to propose based on their weight. Check out the [Tendermint official documentation](https://docs.tendermint.com/) for more information.
### Mainnet
Injective's blockchain network where all transactions take place.
### Testnet
A version of the mainnet used for testing. The testnet does not use real assets. You can use the testnet to get familiar with transactions and the overall network.
### Total stake
The total amount of INJ bonded to a delegator, including self-bonded INJ.
### Unbonded validator
A validator that is not in the active set and does not participate in consensus or receive rewards. Some unbonded validators may be jailed.
### Unbonding validator
A validator transitioning from the active set to the inactive set. An unbonding validator does not participate in consensus or earn rewards. The unbonding process takes 21 days.
### Unbonded INJ
INJ that can be freely traded and is not staked to a validator.
### Unbonding
When a delegator decides to undelegate their INJ from a validator. This process takes 21 days. No rewards accrue during this period. This action cannot be stopped once executed.
### Unbonding INJ
INJ that is transitioning from bonded to unbonded. INJ that is unbonding cannot be traded freely. The unbonding process takes 21 days. No rewards accrue during this period. This action cannot be stopped once executed.
### Undelegate
When a delegator no longer wants to have their INJ bonded to a validator. This process takes 21 days. No rewards accrue during this period. This action cannot be stopped once executed.
### Uptime
The amount of time a validator is active in a given timeframe. Validators with low up time may be slashed.
### Validator
An Injective blockchain miner that is responsible for verifying transactions on the blockchain. Validators run programs called full nodes that allow them to participate in consensus, verify blocks, participate in governance, and receive rewards. Only the active set of validators can participate in consensus.
### Weight
The measure of a validator's total stake. Validators with higher weights get selected more often to propose blocks. A validator's weight is also a measure of their voting power in governance.
# References
Source: https://docs.injective.network/references
Important references and links for the Injective Ecosystem
## Developer Resources
### Developer Tools and Resources
Developer tools and resources to get you building on Injective
| **Resource** | **Description** |
| --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| [MCP Server](./developers/ai/mcp) | Connect AI assistants to Injective documentation using the Model Context Protocol |
| [Injective 101](https://injective.notion.site/Injective-101-589dedc4c9c04531aae503dbb235d443) | One-stop-shop for Injective resources |
| [Injectived](./developers/injectived/) | Command-line interface and node daemon that connects to Injective |
| [Injective Explorer](https://explorer.injective.network/) | Analytics platform that enables anyone to search addresses, trades, tokens, transactions, and other activities on Injective |
| [Injective Local](https://github.com/InjectiveLabs/injective-local) | Injective testnet and ecosystem containerized with Docker and orchestrated with a simple docker-compose file. |
| [Injective REST API](https://lcd.injective.network/swagger/) | Swagger API explorer |
| [Injective TypeScript SDK](https://docs.ts.injective.network) | Build dApps on Injectuve using TypeScript |
| [Injective API Reference](https://api.injective.exchange) | Detailed API documentation for interacting with Injective for traders |
| [Cosmovisor](./infra/cosmovisor/) | Small process manager around Cosmos SDK binaries that monitors the governance module |
| [CosmosSDK](https://docs.cosmos.network/main/build) | The Cosmos SDK documentation serving as a valuable resource for developers integrating with the Injective ecosystem |
### Ecosystem Tools and Resources
Tools and resources developed by ecosystem developers and partners
| **Resource** | **Description** |
| -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Desig](https://desig.io/) | Multi-party computation (MPC) multisig solution |
| [DiscoverINJ](https://alpha.discoverinj.com/) | UI smart contract query / execute |
| [The Graph](https://docs.substreams.dev/tutorials/intro-to-tutorials/injective) | Substreams for extracting data from the Injective blockchain. |
| [NewMetric](https://app.newmetric.xyz/) | Custom, high-performance RPC nodes |
| [Notifi](https://injective.com/notifications/) | Receive notifications for the latest chain updates, ecosystem developments, market insights, and more via Notifi |
| [Pyth](https://docs.pyth.network/home) | Price feed oracles and market data |
| [Starship](https://docs.cosmology.zone/starship) | Unified development environment that allows developers to spin up a fully simulated mini-cosmos ecosystem and write end-to-end test cases |
| [SubQuery](https://github.com/subquery/cosmos-subql-starter/tree/main/Injective/injective-starter) | Open-source data indexer providing custom APIs |
| [Remix IDE](https://docs.welldonestudio.io/code/deploy-and-run/injective) | Smart Contract Deployment & Development APIs |
| [Synternet](https://docs.synternet.com/build/data-layer/developer-portal/subscribe-to-streams) | Subscribe or publish real-time live data stream |
| [Wormhole](https://docs.wormhole.com/wormhole) | Cross-chain messaging protocol |
| [DAO DAO](https://daodao.zone/dao/injective) | DAO DAO helps you build and operate DAOs by providing a visual interface to easily interact with the underlying smart contracts that run on the blockchain. DAO DAO also offers a multisig solution. |
### Helpful Repos
Helpful repositories for developing on and integrating Injective
| **Repo** | **Description** |
| ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
| [CosmWasm101](https://github.com/InjectiveLabs/CosmWasm101) | Guide to match the CosmWasm 101 presentation for the 2023 Injective Global Hackathon |
| [cw20-adapter](https://github.com/InjectiveLabs/cw20-adapter/tree/master/contracts/cw20-adapter) | Contract that allows exchanging CW-20 tokens for Injective-chain issued native tokens (using the TokenFactory module) and vice-versa |
| [cw-injective](https://github.com/InjectiveLabs/cw-injective) | Packages that can be used to integrate CosmWasm with Injective |
| [injective-rust](https://github.com/InjectiveLabs/injective-rust) | A place where all rust binding generators for Injective-Core live. |
| [injective-ts-examples](https://github.com/InjectiveLabs/injective-ts-examples) | Helpful repo to get started building on the injective-ts library |
| [injective-ui](https://github.com/InjectiveLabs/injective-ui) | Collection of UI packages to ease development on Injective |
| [swap-contract](https://github.com/InjectiveLabs/swap-contract) | Open source atomic token swap contract that showcasing an instant swap between two different tokens |
| [test-tube](https://github.com/injectiveLabs/test-tube) | Generic library for building testing environments for CosmWasm smart contracts |
### Developer Support
Find developer support on Discord or Telegram
1. Join the [Injective Discord server](https://discord.gg/injective) and find the relevant channel
2. Join the [Injective Developer Telegram channel](https://t.me/+qorn-J06fzA0YTZl)
### Public Endpoints
For a list of public endpoints, visit [public endpoints](./infra/public-endpoints/ "mention")
### Private / Dedicated Node Services
For a full list of private node services, see [premium endpoints](./infra/premium-endpoints/ "mention")