# Understanding RUJI Token RUJI is the native token for the THORChain App Layer. Staking RUJI allows users to earn fees generated across the App Layer, benefiting from THORChain’s high liquidity. Staking is available on the [Staking page](https://rujira.network/strategies/staking/RUJI). ## Tokenomics ### Total supply 100M RUJI ### Inflation No inflation, supply is capped at 100m RUJI. ### Utility RUJI will serve as the fee-switch token for Rujira core products, enabling stakers to capture the revenue generated by applications that join the Rujira Alliance, after accounting for the portion shared with THORChain Base Layer to cover security costs. As outlined in the initial partnership announcement, the standard revenue split between core applications and the Base Layer is 50/50. However, any economic activity that already contributes value to the Base Layer, such as applications built on top of the Rujira primitives, will not be required to pay for security twice.

### Allocations

* Kujira & Merged Ecosystem Apps (50%) * Levana (5%) * Ecosystem Fund (7.5%): To be used at the discretion of the Rujira team for protocol-own liquidity, incentives, airdrops and other activities aimed at attracting users, builders and stimulating economic activity. * Builders Incentive Pool (7.5%): To be allocated as performance bonuses to apps, builders, and other Rujira Alliance contributors based on revenue contribution over four years, to ensure that the verticals that contribute the most value to RUJI are rewarded for it. * Operations (15%): To be used at the discretion of the Rujira team to fund operational expenses, developers' grants, Centralized Exchanges listings, provision Market Makers liquidity, and engage in value-added on-chain activities such as building up long-term protocol-own liquidity (e.g. to make market on the Rujira orderbook DEX via RUJI Pools or invest in ecosystem projects). * New investors (15%): Raised in a single rounds to capitalize the Operations treasury. ## Conversion Process (closed) {% hint style="info" %} *The merge period terminated on 5th April 2026. Merging legacy tokens is no longer possible.* {% endhint %} RUJI was born from the merger of 6 projects where holders of KUJI, FUZN, NSTK, WINK, LVN, and NAMI were able to convert their tokens into RUJI. There were two different merge processes that completed: 1. **The Merge:** Holders of KUJI, FUZN, NSTK, WINK, and LVN tokens had 12 months from the merger date (05 April 2025) to convert their tokens to RUJI. The conversion rate started to decay after 4 weeks and decreased linearly over the 12-month period, with early converters receiving the best rates. Key details:

2. **The NAMI Merge:** NAMI token holders had six months from the merger date (22 September 2025) to convert their tokens into RUJI. For the first four weeks, the conversion rate remained fixed at 0.013 RUJI per NAMI. After this period, the rate declined linearly over the remaining five months, incentivizing early participation. Maximum merge supply was capped at 74 million NAMI. Users could choose to keep their RUJI in the merger contract during the conversion period to earn additional rewards. Users could withdraw their RUJI at any time, but once withdrawn, they were not able to deposit back into the merger contract, leading to more rewards for the ones who stayed. #### Bonding Curve & Decay Starting from the merger date, users had 12 months (6 months for NAMI) to convert their tokens into RUJI. During the first 4 weeks, the conversion rate was 1:1\*, after which it gradually decreased on a linear scale, reaching 1:0 by the end of the 12-month period. *\*Note: The conversion rate shown in the table above is considered 1:1 in instances where 1 merge token does not equate to 1 RUJI.*

#### Token Bonus As not all tokens were converted, and part was converted late at less than a 1:1 ratio, there were an accumulation of excess RUJI tokens. These excess tokens were distributed as rewards to users who chose not to withdraw their RUJI immediately. The share of excess tokens a user earned depend on when they initiated the conversion and how long they held their RUJI before withdrawing. Users could withdraw both their converted and reward tokens at any time without any unbonding period, but they could not redeposit to earn additional rewards. Partial withdrawal from the merger contract were possible.

## Merge Flow The Switch Handler on THORChain facilitated the migration of assets from external chains (e.g. Gaia) to THORChain’s native assets. Originally, it enabled users to convert RUNE tokens from Binance Chain (BEP2) to native RUNE on THORChain. The process involved sending BEP2 RUNE to a designated address with a SWITCH memo, triggering the handler to mint an equivalent amount of native RUNE to the user’s THORChain address. We used this Switch Handler for all the Kujira and Levana tokens to migrate and become THORChain-native assets. These assets comprised two categories: * Tokens migrating and merging into $RUJI: $KUJI, $rKUJI, $FUZN, $NSTK, $WINK, $LVN, $NAMI * Tokens migrating but not merging: $AUTO, $LQDY (ex. $MNTA) The process for switching above tokens to become THORChain-native assets involved: 1. Reinstating the Switch Handler: Removing the previous kill switch logic to allow new migrations. 2. Configuring On-Chain Parameters: Defining source assets, target denominations, and burn addresses in an on-chain configuration. For example for $KUJI: 1. source\_asset: `GAIA.KUJI-XXXXXXXXX` 2. target\_asset: `kuji` 3. burn\_address: `cosmos100000000000000000000000000000000708mjz` 3. Executing the Switch: Users send their external assets to the THORChain GAIA.ATOM vaults, node operators validate the deposit and the network (a) mints a native token on THORChain and (b) sends the external asset on Gaia to the burn address. 4. Asset Purging: Transferred assets are sent to the designated burn address and removed from system accounting to prevent double-spending.

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rujira.network/understanding-ruji-token.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.