{address ? (
{transactionHash && (
) : (
)}
Transaction successful:{' '} {transactionHash}
)}
{address ? (
{transactionHash && (
) : (
)}
Transaction successful:{' '} {transactionHash}
)}
Clicking on "Connect" will open the wallet selector
Once a wallet is connected, clicking on "Send 1 INIT" will send a transaction to the wallet.
Once the transaction is sent, the transaction hash will be displayed in the interface.
And that's it! You have successfully integrated the Initia Wallet Widget into your NextJS project. You can further extend this example in various ways, such as:
* Showing the user's INIT balance when the wallet is connected.
* Preventing the user from sending transactions if they do not have enough INIT balance.
* Allowing users to specify the amount of INIT to send and the destination address
and more.
# Exchange Integration
Source: https://docs.initia.xyz/developers/developer-guides/guides/exchange-integration
This guide provides instructions for exchanges on how to integrate with Initia, from running a node to handling transactions and monitoring network activities.
## Network Details
You can find the details of Initia's network, including the chain endpoints, nodes, and peer information, below.
* [Initia L1 Networks](/resources/developer/initia-l1)
## Running a Node
For more information on running a node, please refer to
* [Running an Initia Node](/nodes-and-rollups/running-nodes/running-l1-nodes/l1-nodes-initiad)
## Creating and Managing Accounts
* [Creating an Account](/developers/developer-guides/tools/sdks/initia-js/accounts)
## Sending Transactions
### Transferring Tokens
* [Sending Transactions](/developers/developer-guides/tools/sdks/initia-js/transactions/sending-transactions)
### Signing Transactions Offline
In cases where network security is crucial, signing transactions offline ensures safe transaction handling.
* [Signing Transactions](/developers/developer-guides/tools/sdks/initia-js/transactions/signing-transactions)
### Handle Transaction Errors
Learn how to handle transaction errors to ensure that your transactions are executed properly.
* [Handling Errors](/developers/developer-guides/tools/sdks/initia-js/transactions/handling-errors)
## Monitoring Transactions
Initia provides various tools to monitor transaction activities, including event indexing and querying network data.
To keep track of transactions and blockchain events, you can use a simple indexer example:
* [Simple Indexer](https://github.com/initia-labs/simple-indexer)
For additional data like account balances and block details, you can use InitiaJS:
* [Querying Data](/developers/developer-guides/tools/sdks/initia-js/querying-data)
Additionally, you can manually monitor transactions with the following tools:
* [InitiaScan](https://scan.testnet.initia.xyz/initiation-2)
* [LCD Swagger](https://lcd.testnet.initia.xyz/swagger/#/Service/GetTx)
# Interacting with InitiaDEX
Source: https://docs.initia.xyz/developers/developer-guides/integrating-initia-apps/initiadex
## Creating New Pools
InitiaDEX allows anyone to create a liquidity pool.
```move
public entry fun create_pair_script(
creator: &signer,
name: String,
symbol: String,
swap_fee_rate: Decimal128,
coin_a_weight: Decimal128,
coin_b_weight: Decimal128,
coin_a_metadata: Object
| Category | Amount | % of Supply | Vesting |
| ----------------------------- | ------ | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Foundation | 77.5M | 7.75% | 50% upfront, remaining 50% vested every 6 months over 48 months |
| Protocol Developers | 150M | 15.00% | 25% after 12 month cliff, remaining 75% linearly vested over 36 months |
| Protocol Sales (Investors) | 152.5M | 15.25% | 25% after 12 month cliff, remaining 75% linearly vested over 36 months |
| Enshrined Liquidity & Staking | 250M | 25.00% | 5% will be released each year on a block-by-block basis, with a slightly shortened schedule due to [accelerated emissions](https://forum.initia.xyz/t/inflation-correction-and-unstaking-subsidy-plan) in the first month. |
| VIP Rewards | 250M | 25.00% | 7% released per year, linearly distributed over 12 months |
| Binance Launch Campaign | 60M | 6.00% | 100% unlocked |
| Airdrop | 50M | 5.00% | 100% unlocked |
| Echo.xyz Community Sale | 10M | 1.00% | 25% of the total amount on the 12/15/18/24th month post THE |
## Breakdown
### Foundation
**77,500,000 INIT (7.75% of total supply)**
The Initia Foundation's main goal is to advance the Interwoven Economy, help redefine the boundaries of multichain capabilities, and ensure a vibrant ecosystem of diverse applications. To this end, 7.75% of the total token supply is set aside towards the Initia Foundation for a variety of endeavors—including initial liquidity bootstrapping for Enshrined Liquidity, genesis validator delegations, and future strategic initiatives and ecosystem grants.
### Protocol Developers (Team)
**150,000,000 INIT (15% of total supply)**
Protocol developers, including current and future Initia team members and contributors, have been allocated 15% of the supply in aggregate. All recipients of tokens from this category are subject to a 4 year vesting period that includes a 12 month lock and a 36 month unlocking period.
### Protocol Sales (Investors)
**Amount: 152,500,000 INIT (15.25% of total supply)**
The Interwoven Economy's progress would have not been possible without the early backing of Initia by its investors. Across three total rounds of fundraises, Initia has been able maintain dilution to investors by 15.25% of the total supply, marking a distinct departure from many other L1 chains with high investor allocations. Similar to tokens allocated to Protocol Developers, tokens in the Protocol Sales category are subject to a 4 year vesting period that includes a 12 month lock and a 36 month unlocking period.
### Enshrined Liquidity & Staking Rewards
**250,000,000 INIT (25% of total supply)**
At the core of the Interwoven Ecosystem is Initia's Enshrined Liquidity mechanism, which replaces the typical L1 PoS system. In Enshrined Liquidity, capital is put to effective use through liquidity provision and allows users to simultaneously provide L1 economic security while earning staking rewards, trading fees, and external ecosystem incentives allocated for voting in VIP gauge votes. Initially, EL & staking rewards have a block-by-block release rate of 5% per year (12,500,000 INIT per year).
Due to a [governance proposal](https://forum.initia.xyz/t/inflation-correction-and-unstaking-subsidy-plan/201/10) to fix inflation rate, the overall emission schedule has been shortened slightly to stay within the 250M INIT cap.
### Vested Interest Program (VIP) Rewards
**250,000,000 INIT (25% of total supply)**
Vested Interest Program is Initia's novel and dominant incentive mechanism that is used to align the interests of all the participants in the Interwoven Economy, including application end users, application builders, and L1 stakeholders. These rewards are wholly allocated to the community of users. VIP rewards are distributed in escrowed form and can be vested through maintaining VIP KPIs over several epochs. Similar to staking rewards, VIP rewards have an initial release rate of 7% per year (17,500,000 INIT per year).
### Binance Launch Campaign
**60,000,000 INIT (6% of total supply)**
For the initial CEX liquidity bootstrapping, 6% of the total supply is allocated towards Binance's Launch Campaign.
### Airdrop
**50,000,000 INIT (5% of total supply)**
Initia's airdrop will initially distribute 50,000,000 INIT tokens (5% of the total network supply) to network testers, advocates, and users of the technology who have helped make Initia's vision of an interwoven multichain world possible. These tokens will be immediately available on genesis for eligible participants to claim.
### Echo.xyz Community Sale
**10,000,000 INIT (1% of total supply)**
Tokens in this category have been allocated to the community of users who participated in Echo.xyz's investment round. Tokens in this category unlock in four equal tranches 12/15/18/24 months post-genesis.
## Release Schedule
The monthly and annual release schedules for the Initia token for the first four years are shown below.
**Annual Release Schedule**
**Monthly Release Schedule**
# High Level Architecture
Source: https://docs.initia.xyz/home/core-concepts/initia-and-rollups/high-level-architecture
Initia's architecture is composed of three main components:
* **Initia L1**: The Initia L1 is the base layer and central liquidity hub for all Interwoven rollups
* **Interwoven Rollups**: An ecosystem of blockchain rollups built atop Initia L1
* **Interwoven Stack**: Initia's framework for easily and painlessly building rollups and applications
## Components
### Initia L1
Initia L1 is a Layer 1 blockchain designed to serve as the coordination layer and central hub for all Initia rollups. This layer provides essential services to Rollups, including:
* Network Security
* Governance
* Liquidity Solutions
* Bridging and Interoperability
### Interwoven Rollups
Interwoven Rollups are an ecosystem of Layer 2 blockchains built atop Initia L1, offering a scalable, customizable, and secure infrastructure for any application. Developers have the flexibility to deploy and customize their own rollup, tailoring various aspects such as:
* Smart Contract Virtual Machine
* Gas Tokens
* Other Customizable Features
### The Interwoven Stack
The [Interwoven Stack](/home/core-concepts/interwoven-stack) is Initia's framework for building rollups and applications. It offers a seamless, integrated experience for developers.
The Stack aims to simplify the process of building and operating blockchain applications by providing native, out-of-the-box solutions for common tasks. All the tools and features that appchain developers typically need are built directly into the core Interwoven Stack, making them accessible from day one.
By reducing choice overload, Initia minimizes fragmentation and allows teams to concentrate on creating the best applications.
# Initia L1
Source: https://docs.initia.xyz/home/core-concepts/initia-and-rollups/initia-l1
## Overview
The Initia L1 is a custom-built Layer 1 blockchain that serves as the central coordination layer for all Interwoven Rollups. The L1 is built on the [Cosmos SDK](https://docs.cosmos.network) and is responsible for:
1. **Security**: Rollups leverage Initia L1's security for various purposes including token bridging, state commitments, and fraud proofs
2. **Liquidity**: The [InitiaDEX](/home/core-concepts/initiadex) on L1 acts as a central liquidity hub for the ecosystem, providing a seamless experience for token liquidity and cross-rollup bridging and swaps
3. **Interoperability**: L1 functions as a central hub and router for rollups, enabling seamless communication and state transitions both between rollups and with the broader blockchain ecosystem
4. **Incentives**: L1 powers various incentive schemes including the [Vested Interest Program (VIP)](/home/core-concepts/vip/introduction) and the [Enshrined Liquidity](/home/core-concepts/enshrined-liquidity/introduction)
# Introduction
Source: https://docs.initia.xyz/home/core-concepts/initia-and-rollups/rollups/introduction
Interwoven Rollups are Layer 2 rollups built using Initia's [Interwoven Stack](/home/core-concepts/interwoven-stack/introduction). These rollups are designed to be scalable, highly interoperable, and fully customizable.
* **Virtual Machines**: Rollup teams can choose between EVM, Move, or Wasm as the virtual machine for their rollup to best suit their application and needs
* **Gas Tokens & Fees**: Each rollup can choose its own gas token and fee structure. This can include INIT, stablecoins, their native token, or even multiple tokens.
* **Transaction Ordering**: If needed, rollups can also implement their own transaction ordering mechanism.
# EVM Compatibility
Source: https://docs.initia.xyz/home/core-concepts/initia-and-rollups/rollups/vms/minievm/evm-compatibility-and-changes
## Compatibility
The MiniEVM framework is compatible with all standard EVM developer workflows, tooling, and libraries that developers are already familiar. This includes popular tools like [Foundry](https://github.com/foundry-rs/foundry), [Hardhat](https://hardhat.org/), and [Remix IDE](https://remix.ethereum.org/). However, there are minor differences in the way the MiniEVM operates that may require some adjustments to your existing development workflows.
## Changes
### General
**EIP-1559 Transactions**
MiniEVM currently does not support EIP-1559 transactions. This means that when using tools like Foundry to deploy or interact with contracts, or to generally send transactions, you will need to use the legacy transaction type.
### Cosmos SDK Integrations
#### Token Representation
By default, any new Cosmos coins created on the chain, whether they are fee denomination tokens, tokens minted via IBC, or other tokens created at genesis will also have an ERC20 representation on the MiniEVM. This allows developers and users to interact with these tokens using both the Cosmos Coin interface and messages, as well as the EVM ERC20 interface.
#### Fee Tokens
While the Cosmos SDK and rollup design supports multiple fee denominations on a single network, the MiniEVM's EVM module uses a single fee token denomination for all transactions. This denomination must be one of those set on the Cosmos side.
Once set, the EVM fee denomination effectively becomes the equivalent of native tokens (e.g. ETH) on other EVM networks. This denomination will then be used for transaction fees sent via the EVM's JSON-RPC, as well as for any funds attached to EVM transactions via `msg.value`.
However, as mentioned above, unlike other EVM networks, the MiniEVM's native token is also represented by an ERC20 interface. This means that for any transaction or logic, you can also interact with it using the ERC20 interface.
## Tool Compatibility
### Foundry
**EIP 1559 Transactions**
When using Foundry to deploy or interact with contracts, or to generally send transactions, you will need to use the legacy transaction type. This can be done by using the `--legacy` flag.
**Precompiles and Foundry Scripts**
Foundry's forge script feature always simulates all script transactions on a local standard EVM (without precompiles), and there is currently [no way to skip this simulation](https://github.com/foundry-rs/foundry/issues/5776). Consequently, any contract deployment or transaction that relies on MiniEVM precompiles will fail.
# MiniEVM Introduction
Source: https://docs.initia.xyz/home/core-concepts/initia-and-rollups/rollups/vms/minievm/introduction
## Overview
The MiniEVM is a variant of Initia's rollup framework with Ethereum Virtual Machine ([EVM](https://ethereum.org/en/developers/docs/evm/)) integration. With the MiniEVM, developers can deploy and interact with Solidity and other EVM-based smart contracts just as they would on other EVM networks. All of the tools such as wallets, explorers, and developer tools that users are familiar with also work out of the box with the MiniEVM.
In addition to EVM compatibility, the MiniEVM provides a number of unique features, including:
* **Cosmos Integration**
* **Single Token Standard**
* **IBC Compatibility**
## Cosmos Integration
The MiniEVM interacts with the Cosmos blockchain through a set of custom precompiles. This integration allows the EVM to:
* **Read the Underlying Cosmos Chain State**: Access and read the state of the Cosmos blockchain directly from the EVM.
* **Send Cosmos Transactions**: Initiate and send transactions on the Cosmos blockchain.
### Notable Features
* **Query Native Connect Price Data**: Retrieve price data from the native Connect oracle.
* **Query All Tokens Held by an Account**: Obtain a comprehensive list of tokens held by a specific account.
## Single Token Standard
The MiniEVM revolves around a single token standard by implementing a custom Bank Interface that provides an ERC20 interface for all tokens on the chain. This includes:
* **Native Tokens**: Tokens that are native to the Cosmos blockchain.
* **Fee Denom Tokens**: Tokens used for transaction fees.
* **Tokens Bridged via IBC**: Tokens transferred through the Inter-Blockchain Communication (IBC) protocol.
* **ERC20 Tokens Created on the Rollup**: Standard ERC20 tokens created within the rollup framework.
### Benefits
* **Unified Balance Querying**: Ability to query all tokens held by an account in a single query.
* **Simplified Token Handling**: No need to handle different token standards in smart contracts, making development more straightforward.
***
For more detailed information, please refer to the specific sections of this documentation.
# MiniMove Introduction
Source: https://docs.initia.xyz/home/core-concepts/initia-and-rollups/rollups/vms/minimove/introduction
## Overview
The MiniMove is a [MoveVM](https://move-language.github.io/move)-based variant of Initia's rollup framework, designed to support deployment and interaction with MoveVM smart contracts.
Specifically, our MoveVM is based on the [Aptos variant](https://aptos.dev/en/build/smart-contracts) of the MoveVM, with additions and changes to improve performance and enable compatibility with the rollup's underlying Cosmos SDK stack and the wider Initia ecosystem.
# MiniWasm Introduction
Source: https://docs.initia.xyz/home/core-concepts/initia-and-rollups/rollups/vms/miniwasm/introduction
## Overview
The MiniWasm is a variant of Initia's rollup framework with [CosmWasm](https://cosmwasm.com/) integration, enabling developers to deploy and interact with CosmWasm smart contracts.
# InitiaDEX
Source: https://docs.initia.xyz/home/core-concepts/initiadex
The InitiaDEX is a decentralized exchange (DEX) built on the Initia L1. It serves as a Balancer-style weighted pool for diverse asset pairs and a StableSwap pool for assets with closely correlated prices. This design ensures an optimal trading experience across various asset types.
The DEX aims to be the central liquidity hub for all Interwoven Rollups, facilitating daily trading and more complex cross-rollup interactions and swaps. The InitiaDEX is essential for promoting the growth, stability, and alignment of the entire Initia ecosystem.
To support these goals, the DEX features [Enshrined Liquidity](/home/core-concepts/enshrined-liquidity/introduction). This allows certain liquidity pairs, whitelisted by the Initia L1 governance, to be used as staking assets for the Initia L1.
# Introduction
Source: https://docs.initia.xyz/home/core-concepts/interwoven-stack/introduction
## Overview
The **Interwoven Stack** is Initia's comprehensive, all-in-one solution designed to empower developers and teams in building and deploying rollups with unmatched ease and efficiency.
Historically, building a rollup requires developers to research, select, and piece together numerous components and services. These include:
* Choosing the right scaling solution while considering VM compatibility for each option.
* Sourcing or building wallets, explorers, bridges, and other essential tools.
* Integrating various services such as oracles, bridges, fiat on-ramps, and more.
All of these tasks divert time and resources from developers, preventing them from focusing on building their applications.
The Interwoven Stack aims to address these challenges by focusing on the following key areas:
1. **Comprehensive Product Suite:** The Stack provides developers and teams with everything needed to launch and operate a rollup, including bridges, wallets, explorers, and a multi-VM compatible [rollup framework](/home/core-concepts/interwoven-stack/opinit-framework).
2. **Seamless Interoperability:** The tools built into the Stack facilitate easy communication for the rollup, whether it's between rollups, with Initia L1, or with other blockchain ecosystems.
3. **Enhanced Security:** Robust security measures are integrated into the Stack, providing a solid foundation for building secure and trustworthy applications.
With this approach, developers can focus solely on building, improving, and shipping their applications, while the Interwoven Stack manages the heavy lifting of selecting the right tools and components for a performant and secure rollup, ensuring a smooth and optimal developer and user experience.
# Challenger
Source: https://docs.initia.xyz/home/core-concepts/interwoven-stack/opinit-framework/components/challenger
The Challenger is a process distinct from the Executor, responsible for monitoring the Executor's output proposals and challenging any invalid submissions. This ensures the integrity of rollup's state and prevents malicious actions by the Executor.
The primary responsibilities of the Challenger include:
1. **Verifying Deposits**:
* Ensure that the `MsgInitiateTokenDeposit` event is relayed correctly to the `MsgFinalizeTokenDeposit` event.
* Check if `MsgInitiateTokenDeposit` was relayed within the required time frame.
2. **Verifying Oracle Updates**:
* Confirm that Oracle data is correctly relayed to `MsgUpdateOracle`.
* Ensure that Oracle updates are processed on time.
3. **Validating Outputs**:
* Check that the `OutputRoot` submitted with `MsgProposeOutput` is accurate.
* Ensure that the next `MsgProposeOutput` is submitted within the expected time frame.
## Detailed Architecture
The Challenger architecture is designed to ensure that interactions between Initia (L1) and rollup (L2) are correctly validated, securing internal processes within the Initia ecosystem. Each part of the architecture is tailored to handle specific challenges while maintaining the security and reliability of the Initia-rollup interactions.
### Deposit Challenges
Deposits from L1 to L2 must follow a strict verification process to ensure that tokens are correctly transferred between chains.
The Challenger plays a critical role in this by confirming that `MsgInitiateTokenDeposit` is not only correctly triggered but also completed within a specific timeframe by matching it to `MsgFinalizeTokenDeposit`.
This prevents potential discrepancies or fraud, ensuring that deposits are secure.
When a `MsgInitiateTokenDeposit` event is detected on the L1 chain, it is recorded as a **Deposit** challenge.
The system checks if it matches the `MsgFinalizeTokenDeposit` event for the same sequence.
```go
// Deposit is the challenge event for deposit data
type Deposit struct {
EventType string `json:"event_type"`
Sequence uint64 `json:"sequence"`
L1BlockHeight uint64 `json:"l1_block_height"`
From string `json:"from"`
To string `json:"to"`
L1Denom string `json:"l1_denom"`
Amount string `json:"amount"`
Time time.Time `json:"time"`
Timeout bool `json:"timeout"`
}
```
## Output Challenges
**Outputs**, which represent state changes in the L2 chain, must be correctly submitted to maintain the synchronization between L1 and L2.
The Challenger ensures that the OutputRoot of the submitted `MsgProposeOutput` matches the system’s expectations and that future proposals are made within the designated timeframe.
This process prevents any incorrect or malicious outputs from being finalized, ensuring the integrity of the system.
When a `MsgProposeOutput` event is detected on the L1 chain, it triggers an **Output** challenge.
The system replays up to the L2 block number and verifies whether the `OutputRoot` matches the one submitted.
```go
// Output is the challenge event for output data
type Output struct {
EventType string `json:"event_type"`
L2BlockNumber uint64 `json:"l2_block_number"`
OutputIndex uint64 `json:"output_index"`
OutputRoot []byte `json:"output_root"`
Time time.Time `json:"time"`
Timeout bool `json:"timeout"`
}
```
### Oracle Challenges
Oracles serve as external data providers for the blockchain, and any failure in updating their data can lead to inaccuracies within the system.
The Challenger ensures that oracle updates happen in a timely manner and are properly relayed from L1 to L2 through `MsgUpdateOracle`, safeguarding the accuracy of external data within the Initia ecosystem.
If the `oracle_enable` setting is turned on in bridge config, the 0th transaction's bytes are saved as an **Oracle** challenge event.
This data is verified against the `MsgUpdateOracle` for the same L1 height.
```go
// Oracle is the challenge event for oracle data
type Oracle struct {
EventType string `json:"event_type"`
L1Height uint64 `json:"l1_height"`
Data []byte `json:"data"`
Time time.Time `json:"time"`
Timeout bool `json:"timeout"`
}
```
## Rollback Challenges (TBA)
If a challenge is created and the event is not finalized within the timeout period, it is possible to rollback before the challenge is finalized. This feature will be announced in a future release.
# Executor
Source: https://docs.initia.xyz/home/core-concepts/interwoven-stack/opinit-framework/components/executor
The OPinit Bot Executor is a critical component in maintaining the communication and operational integrity between the Initia L1 and rollup blockchains. It handles and automates key tasks related to the OPinit Bridge, which facilitates cross-chain interactions and ensures that both blockchains remain synchronized and secure.
The primary responsibilities of the Executor include:
1. **Executing Token Transfers:** Executing token transfers between Initia L1 and rollup
2. **Submitting Output Proposals:** Submitting output proposals to the Initia L1
3. **Transaction Batch DA Submission:** Submitting rollup transaction batches to the DA layer
4. **Relaying Oracle Update (Optional):** Relaying oracle price feed updates to the rollup
## Detailed Architecture
### Transfer Token from L1 to L2 (Deposit)
The token deposit process begins when a user submits a deposit transaction on the Initia L1 chain. Once the transaction is confirmed, the Bridge Executor retrieves the latest block data (including the deposit) from the L1 node. It then submits a message to the rollup node to finalize the deposit. After the L2 node confirms the finalized deposit, it mints the corresponding opINIT tokens on the specified rollup.
```mermaid
sequenceDiagram
participant User
participant IL1 as Initia L1
participant OPH as OPhost Module
participant OPB as OPinit Bot
participant OPC as OPchild Module
participant R as Rollup
User->>IL1: Initiate token deposit
IL1->>OPH: Process deposit
OPH->>OPB: Emit deposit event
OPB->>OPB: Process deposit event
OPB->>OPC: Relay deposit transaction
OPC->>R: Finalize deposit
R->>R: Mint tokens to user on L2
```
### Transfer Token from L2 to L1 (Withdrawal)
The token withdrawal process begins when a user submits a withdrawal transaction on the rollup. Once the transaction is confirmed, the Bridge Executor retrieves the latest block data (including the withdrawal) from the L2 node. It then submits a message to the Initia L1 node to finalize the withdrawal. After the L1 node confirms the finalized withdrawal, it burns the corresponding opINIT tokens on the specified rollup.
The withdrawal then enters a withdrawal period during which the transaction can be challenged and potentially canceled. If no challenge is submitted by the end of this period, the user can claim the withdrawal on Initia L1.
```mermaid
sequenceDiagram
participant User
participant R as Rollup
participant OPC as OPchild Module
participant OPB as OPinit Bot
participant OPH as OPhost Module
participant IL1 as Initia L1
User->>R: Initiate token withdrawal
R->>OPC: Process withdrawal request
OPC->>OPC: Lock tokens and emit event
OPC->>OPB: Notify of withdrawal event
OPB->>OPB: Update Merkle tree
OPB->>OPH: Submit updated L2 output root
OPH->>IL1: Store L2 output root
Note over OPB,IL1: Wait for finalization period
User->>OPB: Request withdrawal proof
OPB->>OPB: Generate Merkle proof
OPB->>User: Provide withdrawal proof
User->>IL1: Submit proof & finalize withdrawal
IL1->>OPH: Verify proof
OPH->>IL1: Approve token release
IL1->>User: Transfer withdrawn tokens
```
The withdrawal period is designed to allow for a challenge period during which any malicious activity can be detected and addressed. If a challenge is submitted, the withdrawal is canceled. If no challenge is submitted, the transaction is finalized and the tokens are released to the user on Initia L1.
### Oracle Updates
The executor process is, when enabled on the rollup, also responsible for relaying the latest [Connect](https://github.com/skip-mev/connect) oracle data to the rollup. When relayed, the bot submits a `MsgUpdateOracle` to the L2 node.
```mermaid
sequenceDiagram
participant SO as Connect Oracle
participant ORM as Oracle Module (L1)
participant IL1 as Initia L1
participant OPB as OPinit Bot
participant OPC as OPchild Module
participant R as Rollup
loop Continuous update cycle
SO->>ORM: Update oracle data
ORM->>IL1: Store updated data
IL1->>OPB: Emit oracle update event
OPB->>ORM: Read new oracle data
OPB->>OPC: Relay oracle data
OPC->>R: Update L2 oracle state
end
```
### DA Batch Submission
Lastly, the Executor is responsible for batching and submitting transaction data to Celestia.
```mermaid
sequenceDiagram
participant R as Rollup
participant OPC as OPchild Module
participant OPB as OPinit Bot
participant DA as Data Availability Layer
participant IL1 as Initia L1
loop For each L2 block
R->>OPC: Generate block
OPC->>OPB: Provide block data
OPB->>OPB: Compress and batch data
OPB->>DA: Submit batched data
DA->>DA: Store data and generate proof
OPB->>IL1: Submit DA proof (if required)
end
```
# Introduction
Source: https://docs.initia.xyz/home/core-concepts/interwoven-stack/opinit-framework/components/introduction
The OPinit Framework consists of three main components: the OPinit Bridge, the Executor, and the Challenger.
## OPinit Bridge
The [OPinit Bridge](/home/core-concepts/interwoven-stack/opinit-framework/components/opinit-bridge) is a set of Cosmos SDK modules that enable the transfer of INIT and other tokens between the Initia L1 and rollup L2 using an optimistic bridge model.
## OPinit Bots
The OPinit Bots are a set of processes responsible for executing and monitoring the various actions necessary to operate and secure the rollup. Currently, there are two bots in this system: the Executor and the Challenger.
### Executor
The [Executor](/home/core-concepts/interwoven-stack/opinit-framework/components/executor) is a set of processes responsible for executing the various actions necessary to operate and secure the rollup. These include:
* **Token Transfers**: The Executor handles the OPinit Bridge token deposits and withdrawals between Initia L1 and the various rollup.
* **Output Submission**: The Executor submits the rollup's transaction outputs to the Initia L1 to finalize the rollup's state.
* **DA Batch Submission**: The Executor submits the rollup's transaction batches to the Celestia DA layer.
* **Oracle Data**: The Executor can be configured to relay the Connect oracle price data on the Initia L1 to the rollup L2 for its applications to use.
### Challenger
The [Challenger](/home/core-concepts/interwoven-stack/opinit-framework/components/challenger) is a process separate from the Executor, responsible for monitoring the Executor's output proposals and challenging any invalid proposals. This helps maintain the integrity of the rollup's state and ensures that the Executor is not acting maliciously.
# OPinit Bridge
Source: https://docs.initia.xyz/home/core-concepts/interwoven-stack/opinit-framework/components/opinit-bridge
## Overview
The OPinit Bridge is an implementation of the optimistic rollup bridge, implemented as two Cosmos SDK modules; the **OPchild Module** and the **OPhost Module**.
## OPhost Module
The OPhost Module is integrated into the Initia L1 chain. This module is responsible for:
* **Bridge Management:** Creating, updating, and managing bridges between Initia L1 and rollups.
* **Output Proposal Handling:** Managing and finalizing L2 output proposals.
## OPchild Module
The OPchild Module acts as a counter-party to the OPhost Module and is integrated into all Interwoven Rollup implementations. This module is responsible for:
* **Operator Management:** Adding, removing, and managing operators for a given rollup.
* **Bridge Message Execution:** Processing messages received from the Initia L1.
* **Oracle Updates:** Managing oracle price feed updates relayed by the OPinit Executor.
Actions related to both of these two modules are normally handled by the [OPinit Bot Executor](/home/core-concepts/interwoven-stack/opinit-framework/components/executor).
# Minitswap Architecture
Source: https://docs.initia.xyz/home/core-concepts/minitswap/architecture
export const Flexibility = "A governance-controlled variable that modifies the Peg Keeper's tolerance towards imbalance. A higher flexibility means that a low target ratio can be maintained even with a high imbalance. When the flexibility is low, the Peg Keeper will interfere less frequently compared to high flexibility, ceteris paribus.";
export const MaxRatio = "A governance-controlled value that dictates the largest Fully Recovered Ratio value allowed.";
export const FullyRecoveredRatio = "Defines the ideal proportion of IbcOpInit vs. INIT in the virtual pool. For example, a ratio of 0.6 implies that the ratio of IbcOpInit to INIT is 6:4. When a user performs a swap, the pool ratio is compared to the Fully Recovered Ratio. If the current pool is greater, the Peg Keeper will swap the IbcOpInit tokens for INIT tokens.";
export const IbcOpINIT = "The variation of the INIT token that was bridged from Initia L1 to the rollup m through OP Bridge, then subsequently back to the L1 through IBC";
export const INIT = "The vanilla Initia INIT tokens on the Initia L1";
## Goals
* **Manipulation Resistance**: The architecture of the rollup and related systems themselves already has safeguards in place to prevent various forms of manipulation from malicious actors. The Minitswap DEX is further designed to ensure that, in unforeseen events, any subsequent damages are minimized.
* **Capital Efficiency**: As the number of rollups continue to increase, naively, the same number of DEX pairs must also exists. This results in liquidity fragmentation, high slippage and volatility, and subpar user experience.
## Design
Minitswap itself is designed as a virtual pool DEX between 
In this scenario, a user wants to efficiently bridge their $INIT$ tokens on the Initia L1 to a rollup $m$ and ends up with the $OpINIT_m$ token for that rollup.
And while bridging from Initia L1 to a rollup is instantaneous, users may occasionally be able to obtain a more favorable rate by utilizing Minitswap as part of the bridging process as shown below.
1. **Initiate Swap on Minitswap DEX**: The user sends a transaction to the Minitswap DEX to swap their $INIT$ tokens into $IbcOpINIT_m$ tokens.
2. **Simulate Swap**: The DEX simulates swapping the user’s $INIT$ tokens into $IbcOpINIT_m$ tokens.
3. **Compare Swap and Direct Bridging**: The DEX compares the simulated amount of $IbcOpINIT_m$ tokens with the amount the user would receive if they bridged directly through the OP Bridge.
4. **Perform Optimal Action**
* If the amount of $IbcOpINIT_m$ tokens from the swap is greater, the DEX performs the swap. The output $IbcOpINIT_m$ tokens are then bridged to the destination L2 through IBC.
* If the direct bridging through the OP bridge provides a better amount, the DEX initiates a direct transfer to the destination rollup $m$ for the user using the OP bridge.
5. **Minitswap Swap Process**
* **Calculate $IbcOpINIT_m$ Received**: Minitswap calculates how much $IbcOpINIT_m$ the user will receive based on the current Virtual Pool state, updating the state in the process.
* **Fee Deduction**: Minitswap deducts a fee based on a predefined value and an additional fee from any extra $IbcOpINIT_m$ that the user receives.
* **Peg Keeper Swap Check**: Once the user’s swap action and fee calculation are complete, Minitswap checks if a [Peg Keeper Swap](#peg-keeper-swaps) should be performed based on the latest Virtual Pool state.
* **Internal Rebalancing Check**: After completing the Peg Keeper Swap, Minitswap checks if [Internal Rebalancing](#internal-rebalancing) is possible based on the Peg Keeper’s $IbcOpINIT$ balance. If balancing is possible, it is initiated.
6. **Final Outcome**: In both cases, once the OP Bridge or IBC transfer is complete, the user receives the most amount of $OpINIT_m$ tokens in their wallet on the destination rollup possible.
### Rollup to Initia L1
When bridging from a rollup to Initia L1, the user is currently holding $OpINIT_m$ tokens on a rollup $m$ and would like to bridge it back to $INIT$ tokens on the Initia L1.
In this scenario, utilizing Minitswap will enable them to bridging their INIT back to the Initia L1 instantaneously without waiting for the challenge period to expire.
1. **Transfer to Initia L1 via IBC**: The user begins by transferring their $OpINIT_m$ tokens on the rollup $m$ back to Initia L1 using IBC. As a result, they receive $IbcOpINIT_m$ tokens on the Initia L1.
2. **Swap on Minitswap DEX**: Once the IBC transfer is complete and the user has $IbcOpINIT_m$ tokens on Initia L1, they initiate a swap transaction on the Minitswap DEX to convert their $IbcOpINIT_m$ tokens into $INIT$ tokens.
3. **Minitswap Swap Process**
* **Peg Keeper Swap Check**: Minitswap first checks if a Peg Keeper Swap can be performed. If this is possible, the swap is executed directly through the Peg Keeper.
* **Calculate $INIT$ Received**: If the Peg Keeper Swap is not applicable, Minitswap calculates the amount of $INIT$ the user will receive based on the updated state of the Virtual Pool.
* **Fee Deduction**: Minitswap deducts a predefined fee amount from the transaction.
* **Internal Rebalancing Check**: After completing the user’s swap transaction, Minitswap checks if [Internal Rebalancing](#internal-rebalancing) is possible based on the Peg Keeper’s $IbcOpINIT$ balance. If balancing is possible, it is executed to maintain market stability.
4. **Final Outcome**: If the swap is successful, the user receives $INIT$ tokens in their wallet on Initia L1.
### Direct Swap
In addition to the standard directional swap explained above, Minitswap also offers a unique **Direct Swap** option. As more [Peg Keeper Swaps](#peg-keeper-swaps) are performed, the Peg Keeper's $INIT$ balance decreases. The Direct Swap aims to incentivize users to help replenish the Peg Keeper's $INIT$ token balance, which gets depleted over time. This serves as an additional method of replenishing the Peg Keeper's $INIT$ balance alongside the [Internal Rebalancing](#internal-rebalancing).
The Direct Swap allows any user to directly exchange their $INIT$ tokens for the Peg Keeper’s $IbcOpINIT$ tokens. This exchange occurs at the average price at which the Peg Keeper has purchased $INIT$ tokens, which could sometimes be lower than the price obtained through the traditional swap process. Initially, the Direct Swap might not seem attractive due to the Target Ratio being close to 0.5. However, as the Peg Keeper’s balance of OP-bridged tokens increases, the Direct Swap option becomes more appealing to users.
## Swap Logic
### Parameters
* **Max Ratio**: The Max Ratio, $R_{max}$, is a Initia L1 governance-controlled parameter that dictates the maximum pool ratio between IbcOpINIT and regular INIT
* **Fully Recovered Ratio**: The Fully Recovered Ratio, $R_{fr}$ then uses the Max Ratio and the Flexibility to calculate the final target IbcOpINIT:INIT ratio for the pool. The ratio is calculated as follows
$$
R_{fr}=0.5+(R_{max}-0.5) \cdot \frac{(fI)^3}{(1+|fI|^3)}
$$
### Mechanisms
#### Peg Keeper Swaps
The Peg Keeper Swap is a mechanism designed to keep the exchange rate between $INIT$ and $IbcOpINIT$ close to 1:1. This ensures that users always receive the best swap rates.
When users move their INIT tokens from a rollup back to Initia L1 using Minitswap, they are essentially selling their $IbcOpINIT$ tokens for $INIT$ tokens. As more users do this, the supply of $IbcOpINIT$ increases relative to $INIT$, which raises the price of future rollup -> Initia L1 swaps.
To address this, the Peg Keeper Swap executes a ($INIT$ -> $IbcOpINIT$) swap to balance the effect. When a user makes a swap, Minitswap checks the Fully Recovered Ratio against the current pool ratio. If the current ratio exceeds the Fully Recovered Ratio, a Peg Keeper Swap is triggered to restore balance.
When run, the Peg Keeper swap follows the following procedure:
1. Calculate the current $R_{fr}$ and the `max_recover_amount`, which defines the maximum size of the Peg Keeper Swap that can be performed in this swap. This is to prevent a huge Peg Keeper Swap from happening.
2. Check if another Peg Keeper Swap has been run in the same block. Continue if no swaps have been run.
3. Calculate the $INIT$ amount the Peg Keeper needs to reach $R_{fr}$. Let's call this `swap_amount_to_reach_fr`.
4. Check if `swap_amount_to_reach_fr > max_recover_amount`
* If true, swap only `max_recover_amount`.
* If false, swap `swap_amount_to_reach_fr`
Note that the Peg Keeper Swap check is done
* *before* a L2 -> L1 swap to make sure the user gets the best rate possible
* *after* a L1 -> L2 swap to make sure the user's swap rate doesn't get affected by the Peg Keeper Swap
#### Internal Rebalancing
As more Peg Keeper Swaps are performed, the $INIT$ balance of the Peg Keeper gradually decreases. To replenish its $INIT$ balance, the system has an internal rebalancing procedure that converts the Peg Keeper's $IbcOpINIT$ back into $INIT$ using IBC and OP Bridge.
The rebalancing process follows these steps:
1. Bridge the Peg Keeper's $IbcOpINIT_m$ back to the rollup $m$ using IBC, converting it into $OpINIT_m$.
2. Use the OP Bridge to convert $OpINIT_m$ back into $INIT$.
This process, combined with the [Direct Swap](#direct-swap), ensures that the Peg Keeper's $INIT$ balance is replenished, allowing it to continue performing Peg Keeper Swaps.
# Minitswap Introduction
Source: https://docs.initia.xyz/home/core-concepts/minitswap/introduction
export const OPinitBridge = "Initia's implementation of an optimistic bridge to be used as the primary bridge between the Initia L1 and all rollups. Deposits into rollups are instantaneous, but withdrawals have a waiting period.";
export const IbcOpINIT = "The variation of the INIT token that was bridged from Initia L1 to the rollup m through OP Bridge, then subsequently back to the L1 through IBC";
export const OpINIT = "The variation of the INIT tokens bridged directly from the Initia L1 to the destination rollup m";
export const m = "The destination rollup that the user wants to bridge to";
export const INIT = "The vanilla Initia INIT tokens on the Initia L1";
Minitswap is Initia's proprietary solution to address the user experience challenges posed by the lengthy withdrawal [challenge periods](https://docs.optimism.io/builders/app-developers/bridging/messaging#understanding-the-challenge-period) of [optimistic bridges](https://medium.com/connext/optimistic-bridges-fb800dc7b0e0). Furthermore, while a longer challenge period increases the duration in which a challenge can be made, it simultaneously increases the wait time required for withdrawals.
## Motivation
While optimistic token bridges between a Layer 1 (L1) and a Layer 2 (L2) chain provides a secure way of transferring assets between chains, it comes with various downsides
* **Long Withdrawal Times**: Transferring tokens from L1 to L2 is usually instantaneous, but the reverse direction involves long wait times, often days, before receiving assets on L1.
* **Single Sequencer Risks**: Creating a DEX pair between the original token on L1 and the bridged tokens can mitigate long withdrawal times. However, most L2s currently operate with a single sequencer, raising security, reliability, and centralization concerns for liquidity providers.
* **Lack of Liquidity**: The sequencer risk issues can result in insufficient liquidity in the token pool, leading to unfavorable swap prices, high volatility, and significant [slippage](https://www.coinbase.com/learn/crypto-glossary/what-is-slippage-in-crypto-and-how-to-minimize-its-impact#:~:text=Understanding%20Slippage%20in%20Crypto\&text=It%20refers%20to%20the%20difference,placed%20and%20when%20it's%20executed.) for users bridging tokens back to L1.
## Solution
The Minitswap DEX is then to designed to allow users to freely, quickly, and efficiently bridge tokens between Initia L1 and rollups. Users looking to bridge back to Initia L1 from a rollup can simply utilize Minitswap (along with IBC) to swap their tokens back to INIT without waiting for the challenge period to expire.
The full architecture, design decisions, and how the above risks issues are mitigated are detailed in the following section.
# Minitswap Terminology
Source: https://docs.initia.xyz/home/core-concepts/minitswap/terminology
export const Flexibility = "A governance-controlled variable that modifies the Peg Keeper's tolerance towards imbalance. A higher flexibility means that a low target ratio can be maintained even with a high imbalance. When the flexibility is low, the Peg Keeper will interfere less frequently compared to high flexibility, ceteris paribus.";
export const MaxRatio = "A governance-controlled value that dictates the largest Fully Recovered Ratio value allowed.";
export const FullyRecoveredRatio = "Defines the ideal proportion of IbcOpInit vs. INIT in the virtual pool. For example, a ratio of 0.6 implies that the ratio of IbcOpInit to INIT is 6:4. When a user performs a swap, the pool ratio is compared to the Fully Recovered Ratio. If the current pool is greater, the Peg Keeper will swap the IbcOpInit tokens for INIT tokens.";
export const VirtualPoolImbalance = "This is defined to be the ratio of the Virtual Pool size V and the Peg Keeper balance B. The ratio measures how far the virtual pool currently deviates from the initial state. When there is a large volume of swaps in only one direction, the ratio increases.";
export const PegKeeperBalance = "Peg Keeper's IbcOpINIT token balance: This balance increases when a user swaps IbcOpINIT tokens for INIT and sometimes decreases when a transfer and swap in the opposite direction occurs.";
export const VirtualPoolSize = "Virtual Pool size: An on-chain governance-set parameter that defines the size of the virtual liquidity pool. A larger value increases the total available swap liquidity for Minitswap and helps facilitate a larger swap volume, all else being equal.";
export const User = "The end user using the Minitswap DEX who seeks to swap IbcOpINIT tokens into INIT.";
export const PegKeeper = "A virtual market participant implemented into the DEX that automatically swaps INIT tokens for IbcOpINIT tokens directly before or after all user swaps. The aim of the peg keeper is to maintain a swap price close to 1 before fees.";
export const LiquidityProvider = "A user that provides INIT token liquidity to the Minitswap DEX. Unlike conventional DEXes, Minitswap only allows for single-sided INIT token deposits.";
export const VirtualPool = "The liquidity pool used to facilitate the swaps. Initially, the pool starts at a size V, with a virtual IbcOpINIT balance of V and a virtual INIT balance of V. The exchange rate for swaps through the pool is determined by the StableSwap formula. The Virtual Pool does not allow the amount of IbcOpINIT tokens to be less than V because, in such cases, it is more economical for the user to use the OP Bridge directly.";
export const IbcOpINIT = "The variation of the INIT token that was bridged from Initia L1 to the rollup m through OP Bridge, then subsequently back to the L1 through IBC";
export const OpINIT = "The variation of the INIT tokens bridged directly from the Initia L1 to the destination rollup m";
export const m = "The destination rollup that the user wants to bridge to";
export const INIT = "The vanilla Initia INIT tokens on the Initia L1";
export const IBCBridge = "The Inter-Blockchain Communication Protocol used as a bridging solution between rollups. Bridging in both directions is instantaneous.";
export const OPinitBridge = "Initia's implementation of an optimistic bridge to be used as the primary bridge between the Initia L1 and all rollups. Deposits into rollups are instantaneous, but withdrawals have a waiting period.";
## INIT Token Variants
| Term | Definition |
| ----------- | ----------- |
| $INIT$ | {INIT} |
| $m$ | {m} |
| $OpINIT$ | {OpINIT} |
| $IbcOpINIT$ | {IbcOpINIT} |
## Bridges
| Term | Description |
| ------------- | -------------- |
| IBC Bridge | {IBCBridge} |
| OPINIT Bridge | {OPinitBridge} |
## Actors
| **Term** | **Description** |
| ---------------------- | ------------------- |
| **Virtual Pool** | {VirtualPool} |
| **Liquidity Provider** | {LiquidityProvider} |
| **Peg Keeper** | {PegKeeper} |
| **User** | {User} |
## Parameters
| Symbol | Term | Description |
| --------- | -------------------------------------- | ---------------------- |
| $V$ | Virtual Pool size | {VirtualPoolSize} |
| $B$ | Peg Keeper's $IbcOpINIT$ token balance | {PegKeeperBalance} |
| $I$ | Virtual Pool imbalance | {VirtualPoolImbalance} |
| $R_{fr}$ | Fully Recovered Ratio | {FullyRecoveredRatio} |
| $R_{max}$ | Max Ratio | {MaxRatio} |
| $f$ | Flexibility | {Flexibility} |
# VIP Architecture
Source: https://docs.initia.xyz/home/core-concepts/vip/architecture
At genesis, a portion of the total INIT token supply will be set aside as rewards for the VIP program, which will be distributed over several years. Let's call this portion of the supply $R$. These rewards are given out at regular intervals, or **stage** $t$, throughout the distribution period.
The total rewards are first distributed to each rollup, then subsequently to the rollup's users and operators.
These two pools aim to incentivize and reward different aspects of rollup operations. The ratio between $R_B$ and $R_W$, called `poolSplitRatio`, is set by the Initia L1 governance and can be changed through on-chain proposals. The sum follows the equation:
$$
R_t = R_B + R_W
$$
The rewards for each rollup $m$ are then calculated as follows:
$$
R_{m,t} = R_{B,m,t} + R_{W,m,t}
$$
Where:
* $R_{B,m,t}$ represents the portion of rewards from the Balance Pool $R_B$ allocated to rollup $m$ at stage $t$.
* $R_{W,m,t}$ represents the portion of rewards from the Weight Pool $R_W$ allocated to rollup $m$ at stage $t$.
#### Balance Pool
The Balance Pool aims to encourage rollups to find new and interesting uses for the INIT token by distributing rewards based on the proportion of INIT supply on the rollup. Specifically, at each stage $t$, the rewards are allocated according to the amount of INIT locked on each rollup's OPinit bridge address $m$ relative to the total amount locked across all rollups.
$$
R_{B,m,t} = R_{B,t} \frac{I_{m,t}}{\sum_{i=1}^{N,t} I_{i,t}}
$$
Where:
* $R_{B,t}$ is the total rewards from the Balance Pool for the stage.
* $I_{m,t}$ is the amount of INIT tokens locked by rollup $m$ during the stage.
* $N_{t}$ is the total number of rollups in the stage.
#### Weight Pool
The Weight Pool ($R_W$) rewards rollups based on their weight value, which is determined by a gauge weight voting process similar to protocols such as Curve's.
$$
R_{W,m,t} = R_{W,t} \frac{W_{m,t}}{\sum_{i=1}^{N,t} W_{i,t}}
$$
Where:
* $R_{W,t}$ is the total rewards from the Weight Pool for the stage.
* $W_{m,t}$ is the weight of rollup $m$ during the stage.
* $N_{t}$ is the total number of rollups in the stage.
### Distribution to Rollup Users
Once we know how much rewards each rollup receives for a given stage, we then further distribute these rewards to the users of the rollup. The amount of VIP rewards to each user is defined by a scoring methodology decided by the rollup team. The scoring method could be based on factors such as:
* Number of transactions a user makes on the rollup.
* Value of assets a user borrows.
* Trading volume or liquidity provided by the user.
At the end of each stage, the rewards for each user are calculated and stored. Once the rewards for each rollup are known, the rewards are then directly distributed to the users of the rollup.
If a user $u$ on rollup $m$ has a score of $S_{u,m,t}$, their rewards are:
$$
R_{u,m,t} = R_{m,t} \frac{S_{u,m,t}}{\sum_{i=1}^{N_{u,m,t}} S_{i,m,t}}
$$
Where:
* $R_{m,t}$ is the total rewards from the VIP program for the stage.
* $S_{u,m,t}$ is the score of the user on rollup $m$ during stage $t$.
* $N_{u,m,t}$ is the total number of users on rollup $m$ during stage $t$.
### Distribution to Rollup Operators
To ensure that rollup operators are also incentivized to keep their rollups active and useful, they can set an `operatorCommissionRate`, $c$. This rate allows them to take a portion of the rewards for their rollup.
The rewards for an operator $o$ of rollup $m$ during a stage are:
$$
R_{o,m,t} = R_{m,t} c_{m}
$$
The commission rate is set when the rollup is first approved for VIP rewards and can be changed later, but only by a fixed amount each stage to prevent abuse.
Taking into account the operator commissions, the total rewards distributed to a user on a rollup is then:
$$
R_{u,m,t} = (1-c_{m}) R_{m,t} \frac{S_{u,m,t}}{\sum_{i=1}^{N_{u,m,t}} S_{i,m,t}}
$$
## Rewards Vesting
Rewards from the VIP program are given in the form of escrowed INIT tokens (esINIT). These tokens are initially non-transferable and can be vested in multiple ways depending on whether the receiver is the user or rollup operator.
### User Vesting
These tokens are initially non-transferable and can be vested in two ways:
1. **Maintain a VIP Score:** Keep a certain score over a number of `vestingPeriod`, with each period lasting `stageDuration`.
2. **Convert into LP Lock-Staked Position:** Convert the escrowed tokens into a whitelisted INIT:TOKEN staking position.
#### Maintaining a VIP Score
**Vesting Process**
VIP esINIT rewards are converted into regular INIT tokens over multiple `vestingPeriod`, denoted as $p$, with each period lasting one stage. For instance, if the vesting period is 26 stages, the user will receive $\frac{1}{26}$ of their esINIT at each stage.
**Achieving the Required Score**
To fully convert their rewards into INIT tokens, users must maintain a certain score over the vesting periods, $p$, as determined by Initia L1 governance. The minimum required score is set by a `threshold` factor $f$, also determined by the L1 governance. The score calculation is as follows:
$$
S_{\text{target},m,t} = S_{u,m,t} \cdot f
$$
Where:
* $S_{u,m,t}$ is the user's score on rollup $m$ during stage $t$.
* $S_{\text{target},m,t}$ is the target score for rollup $m$ during stage $t$.
**Calculating the Target Score**
The target score $S_{\text{target},m,t}$ is the user's score for stage $t$ multiplied by the factor $f$. For example, if a user $u$ has a score of 100 at stage $t$, their target score to fully vest their esINIT after $p$ stages is $100 \cdot f$.
**Failing to Meet Target Score**
If a user fails to meet the target score at a certain stage $t$, they will only vest and receive a portion of their esINIT, calculated by the formula:
$$
c_{\text{user}} = \frac{S_{u,m,t}}{S_{\text{target},m,t}}
$$
For instance, if $f$ is 0.5, a user with a score of 100 must maintain a score of at least $S_{\text{target},m,t} = 100 \cdot 0.5 = 50$ for the next $p$ stages to fully vest their esINIT. If after $p$ stages, their score $S_{u,m,t}$ is only 30, their $c_{\text{user}}$ will be $\frac{30}{50} = 0.6$, and they will only be able to vest 60% of their esINIT.
**Example Scenario**
Parameters
* **Vesting Period ((p))**: 50 stages
* **Minimum Score Factor ((f))**: 0.5
Stage 1 ((t = 1))
* **User Score**: 100
* **esINIT Received for Stage 1**: 100
* **Vesting Rate**: $\frac{100 \text{ esINIT}}{50 \text{ stages}} = 2 \text{ INIT per stage}$
Stage 2 ((t = 2))
* **Minimum Score Needed from Stage 1**: $100 \times 0.5 = 50$
* **User Score**: 60
* **Vesting from Stage 1**: Since $60 \geq 50$, the user vests the full 2 INIT
* **Vesting Rate for Stage 2**: $\frac{60 \text{ esINIT}}{50 \text{ stages}} = 1.2 \text{ INIT per stage}$
* **esINIT Received for Stage 2**: 60
Stage 3 ((t = 3))
* **Minimum Score Needed from Stage 1**: $100 \times 0.5 = 50$
* **Minimum Score Needed from Stage 2**: $60 \times 0.5 = 30$
* **User Score**: 40
* **Vesting from Stage 1**: Since $40 < 50$, the user vests $\frac{40}{50} \times 2 = 1.6 \text{ INIT}$
* **Vesting from Stage 2**: Since $40 \geq 30$, the user vests the full 1.2 INIT
* **Total Vesting for Stage 3**: $1.6 \text{ INIT (from Stage 1)} + 1.2 \text{ INIT (from Stage 2)} = 2.8 \text{ INIT}$
Summary Table
| Stage | User Score | esINIT Received | Vesting Rate (per stage) | Min Score Needed | Actual Vesting |
| ----- | ---------- | --------------- | ------------------------ | -------------------------- | -------------------- |
| 1 | 100 | 100 | 2 INIT | - | - |
| 2 | 60 | 60 | 1.2 INIT | 50 (Stage 1) | 2 INIT |
| 3 | 40 | - | - | 50 (Stage 1), 30 (Stage 2) | 1.6 + 1.2 = 2.8 INIT |
Explanation
1. **Stage 1**: The user scores 100 and receives 100 esINIT, which will be unlocked at a rate of 2 INIT per stage over 50 stages.
2. **Stage 2**: The user needs to score at least 50 to unlock the full 2 INIT from Stage 1. They score 60, so they unlock the full 2 INIT and receive 60 esINIT for Stage 2, which will be unlocked at a rate of 1.2 INIT per stage.
3. **Stage 3**: The user needs to score at least 50 to unlock the full 2 INIT from Stage 1 and at least 30 to unlock the full 1.2 INIT from Stage 2. They score 40, so they unlock 1.6 INIT from Stage 1 and the full 1.2 INIT from Stage 2, totaling 2.8 INIT.
#### Converting to LP Lock-Staked Position
Maintaining the score over several periods can be challenging for some users. Therefore, VIP allows users to convert their esINIT into a locked, stake-locked INIT:TOKEN LP position on the InitiaDEX for pairs whitelisted on Enshrined Liquidity, with the user providing the TOKEN side of the pair.
When creating a lock-staked position, users can choose the duration for locking their LP position. The length of this lock will determine their voting power on VIP gauge votes. However, when lock-staking through VIP, a minimum lock duration of 26 weeks is enforced.
### Operator Vesting
Similarly, rollup operators' esINIT rewards are also vested, but the process is slightly different. Operator esINIT rewards are released linearly over a number of `operatorVestingStages`. For example, if the operator vesting period consists of 10 stages, the operator will receive $\frac{1}{10}$ of their esINIT at each stage.
# VIP Eligibility
Source: https://docs.initia.xyz/home/core-concepts/vip/eligibility
For a rollup and its users to be eligible for VIP rewards, they first need to be whitelisted. The whitelisting process comprises of 2 steps:
1. Reaching the minimum INIT TVL threshold
2. Whitelisting via Initia L1 governance
## Minimum INIT TVL Threshold
To be considered for whitelisting on VIP, rollups must first meet a minimum INIT TVL (Total Value Locked) threshold.
* Rollups that somehow manage to get whitelisted without reaching the minimum INIT TVL threshold will still not be eligible for rewards until they meet this requirement.
* Rollups that have been whitelisted and successfully reached the minimum INIT TVL threshold will forfeit any VIP rewards if their TVL subsequently falls below this threshold.
## Governance Whitelisting
Once the minimum INIT TVL threshold is reached, the rollup needs to then submit a whitelisting proposal to the Initia L1 governance. As with all governance proposals, the whitelisting proposal will be voted on by INIT and Enshrined Liquidity stakers.
# VIP Introduction
Source: https://docs.initia.xyz/home/core-concepts/vip/introduction
In an ecosystem with a growing number of rollups, aligning the incentives of all participants is crucial. Although there have been attempts to achieve this, most encounter a few common core problems:
* Misalignment of incentives for dApps that generate high levels of on-chain activity and value
* Economic underutilization of the native token
* Inefficient distribution of protocol-level grants and incentives to foster long-term value and alignment
Initia aims to address these issues for Interwoven Rollups through a novel incentive alignment mechanism known as the Vested Interest Program (VIP). This is done by programmatically rewarding valuable economic activities:
* Rollup receive reward allocations for creating innovative apps and new use cases for the INIT token
* Users earn INIT tokens from performing beneficial actions or meeting criteria set by the L2s.
Finally, by allocating a portion of the overall rewards directly to the rollups, the VIP program ensures that the rollup teams, its users, and INIT holders are long-term aligned with the success of the ecosystem.
# VIP Scoring
Source: https://docs.initia.xyz/home/core-concepts/vip/scoring
## Introduction
The VIP Program employs a scoring system designed to allocate esINIT rewards to users. This system evaluates users based on their activities and contributions within a specific rollup. The specific scoring policy varies between each rollup, and the scoring process is conducted on-chain directly by the respective rollup team.
### Scoring Phase
First, during each epoch, rollup teams score their users based on their activity through a `vip_score` contract.
To score users, the rollup operator must first register the `deployer` account on the `vip_score` contract using their operator key. Once registered, the deployer can add and remove user scores based on the determined criteria. See [this page](/developers/developer-guides/integrating-initia-apps/vip) for more information on how scoring works. All future scoring actions can only be performed by the deployer until they are changed or removed.
Once the scoring for an epoch is complete, the scores must be finalized by calling a function on the `vip_score` contract.
### Snapshotting Phase
Once finalized, the VIP Agent snapshots and submits the scores from all miniatures, storing them in the Initia L1 VIP module. The Agent is an actor selected through Initia L1 governance. After all snapshots have been taken and stored, the esINIT rewards are distributed to the users.
### Claiming Phase
Finally, the user can finally claim the distributed rewards.
### VIP Criteria & Scoring Policies
#### Transparency
1. All scoring methodologies must be clearly listed and published in the rollup's VIP whitelisting proposal in full detail, both on the forums and in the on-chain proposal.
2. VIP scoring details included in the proposal must include all eligible user actions, criteria, distribution methodologies, and any calculations involved.
3. All scoring methodologies need to be transparent and verifiable by anyone.
#### Scoring Criteria
4. Points may be allocated based on a user's usage of other chains within the Interwoven Economy, provided that the usage is relevant and beneficial to the rollup conducting the scoring.
5. VIP scores must only be allocated based on actions or metrics that are on-chain, such as users performing specific actions or transactions, holding assets, or other positions
6. Actions performed off-chain, such as referrals and social media posts or engagements, cannot be used for scoring. This also include incentivizing usages of specific tools, frontends, wallets, or other applications.
#### Restrictions
7. VIP scores can not be granted directly to rollup operators, team members, or their associated accounts.
8. Rollup teams cannot use VIP scores to incentivize users to vote for them on the VIP gauges.
9. Incentivizing users to hold naked assets such as BTC, ETH, USDC, and governance tokens, or to provide liquidity for any pair on any DEX, is prohibited
10. If a rollup wants to incentivize holding specific assets, those assets must be ones where the underlying token is used productively (for example, LST, staking token variants, yield-bearing assets, etc.).
All whitelisting proposal and scoring criteria are reviewed by the VIP Committee. This committee consists of stewards who uphold Initia VIP requirements and prioritizes the sustainable success of the Interwoven Economy.
Final approval for whitelisting rollups comes from Initia L1 governance through an on-chain vote. Any changes to a rollup's criteria must be submitted to the forums for review and approval by the VIP Committee before implementation.
**Any attempts to bypass, circumvent, or abuse the VIP scoring system may result in the removal of the offending rollup from the VIP Program.**
# VIP Timelines
Source: https://docs.initia.xyz/home/core-concepts/vip/timelines
## Timelines
### Gauge Voting Cycles
The Vested Interest Program always begins with a [gauge voting](/home/core-concepts/vip/gauges) cycle. During this cycle, Initia L1 stakers vote on the gauge weights that will determine the VIP [Weight Pool](/home/core-concepts/vip/architecture#weight-pool) rewards distribution for the next rewards stage.
### Reward Distribution Stages
After the first gauge voting cycle concludes, the first reward distribution stage begins. During a stage, the individual rollup teams will begin to keep track of scores for all of their users based on their scoring criteria.
During a stage, the snapshot of each rollup's INIT balance will also be taken and used to determine the VIP \[Balance Pool] rewards. There are two ways the snapshot is done:
1. **For Stage 1**: Two snapshots are taken: a single snapshot at the beginning of the stage to determine the VIP Balance Pool rewards for Stage 1, and multiple snapshots throughout the stage to determine the VIP Balance Pool rewards for Stage 2+.
2. **For Stage 2+**: Multiple snapshots are taken throughout the stage to determine the VIP Balance Pool rewards for the next stage.
At the end of the stage, the scores for each user on each rollup are finalized, and the final rewards are distributed to the users.
The combined timelines of the the gauge voting cycle and rewards distribution stage then as follows:
### Challenge Period
When a rollup finalizes its scores, it enters a **challenge period**. This period allows users and other parties to audit the scores submitted by the rollup, ensuring their accuracy and compliance with both the VIP scoring policy and the rollup's own scoring criteria. If someone finds an incorrect scoring, they can submit a challenge through an expedited or emergency governance proposal on Initia L1.
If a challenge succeeds, the following changes occur:
1. The system replaces the VIP scoring agent and transfers authority to a new agent.
2. The system recalculates rewards for the stage.
Note that the challenge period happens alongside the start of the next stage and does not delay its commencement, as seen in the timeline above.
# Welcome to Initia
Source: https://docs.initia.xyz/home/general/welcome
Initia's core philosophy is to make opinionated decisions on the underlying infrastructure such as data availability, interoperability, and oracles. By reducing decision fatigue, the Interwoven Stack empowers developers with the tools to craft application-specific environments while maintaining un-fragmented accessibility to the application ecosystem.
## Learn More About Initia