
New Public Chain Nibiru Mainnet to Launch: An Analysis of Its Technical Features and Secure Development Practices
TechFlow Selected TechFlow Selected

New Public Chain Nibiru Mainnet to Launch: An Analysis of Its Technical Features and Secure Development Practices
As a new blockchain that has raised over $20 million in funding, Nibiru Chain focuses on addressing the security and speed of DeFi applications.
Author: Beosin
Layer 1 blockchain Nibiru Chain launched an airdrop incentive at the end of January 2024. After one month of airdrop activities, its community grew over threefold, with Twitter followers exceeding 500,000. As a new public chain that has raised over $20 million in funding, Nibiru Chain focuses on addressing security and speed challenges in DeFi applications and is poised to become a potential competitor to dYdX.
Currently, Nibiru Chain plans to launch its mainnet this week. As a rapidly growing Layer 1, what are Nibiru Chain's technical features and competitive advantages? What security issues should developers pay attention to when building on its ecosystem? Today, Beosin will break it all down.
Nibiru Chain Protocol Overview
Nibiru Chain primarily focuses on DeFi trading. Its core components include the following four:
1. Nibi-Perps
An on-chain perpetual contracts trading platform allowing users to trade popular crypto assets such as BTC, ETH, and ATOM with up to 10x leverage. $NIBI stakers gain governance rights over Nibi-Perps and receive trading fee discounts.
2. Nibi-Swap
Nibiru’s automated market maker (AMM) protocol, planned to support two types of liquidity pools: stablecoin swap pools and standard constant product pools.
3. $NUSD
A fully collateralized stablecoin within the Nibiru ecosystem. Initially, Nibiru plans to allow users to mint $NUSD using $USDC and $NIBI, with specific ratios determined by the Collateral Ratio (CR). For example, if CR = 80%, minting 100 $NUSD requires 80 $USDC and $NIBI equivalent to 20 $NUSD.
In the future, Nibiru Chain will support additional collateral types. Currently, $NUSD resembles Cosmos-based $FRAX.
4. Nibi-Oracles
Nibi-Oracles is Nibiru’s native oracle solution, enabling validator operators to actively participate in oracle consensus voting, faithfully integrating off-chain data onto the blockchain and providing low-latency feedback from external APIs and smart contracts.
In 2024, Nibiru Chain will focus on expanding its ecosystem through several initiatives, including integration with major DeFi projects across multiple chains, listings on top-tier centralized exchanges, completion of parallel optimistic execution, and achieving full EVM compatibility.
Secure Development Practices
Developing applications on Nibiru Chain follows nearly identical processes and uses the same languages as other Cosmos-based blockchains. Following these security guidelines can enhance contract security:
Smart Contract Security
1. Prepare for Attacks
Similar to developing contracts with Solidity, developers must consider how to respond to attacks and fix vulnerabilities. Therefore, developers should build upgradeable smart contracts and establish risk response plans.
2. Standardize Address Validation
Any valid Cosmos SDK address has two valid representations: all lowercase and all uppercase. For example, both cosmos1uzwqa88hcqe5gs7u7lgjxekz7xc6sm0f7xwp6a and COSMOS1UZWQA88HCQE5GS7U7LGJXEKZ7XC6SM0F7XWP6A represent the same address—this applies to Nibiru as well. When handling addresses in contracts, developers must account for this characteristic.
pub fn valid_transfer (
deps: DepsMut,
info: MessageInfo,
amount: Uint128,
dest: String ,
) -> Result <Response, ContractError> {
// Check if address is blacklisted
if let Some (is_in_blacklist) = BLACKLIST. may_load (deps.storage, &dest.to_string ( )? {
if is_denied {
return Err (ContractError::DeniedRecipient);
}
} else if let Some (is_in_blacklist) = BLACKLIST.may_load ( deps.storage , &info.sender.clone ( ) )? {
if is_denied {
return Err (ContractError::DeniedSender);
}
......
};
As shown above, because "dest" is not standardized, attackers can bypass the blacklist by providing an uppercase address, even though lowercase addresses are typically used.
3. Prevent Arithmetic Overflows
In CosmWasm contracts, developers must be cautious about integer overflows or division-by-zero risks. It is recommended to use CosmWasm’s Uint256 and Uint512 types along with overflow-safe math functions like full_mul().
4. Access Control Issues
Access control is one of the primary security concerns. Countless security incidents stem from access control flaws, which must also be taken seriously in CosmWasm contracts. The following is a typical case:
fn update_config(
deps: DepsMut,
msg: UpdateMsg
) -> Result<Response, ContractError> {
let config = CONFIG.load(deps.storage)?;
let new_config = Config {
rewards_vault_contract: msg.vault_address
.map(|human| deps.api.addr_validate(&human))
.transpose()?
.unwrap_or(config.rewards_vault_contract)
};
CONFIG.save(deps.storage, &new_config)?;
Ok(Response::new().add_attribute("action", "update_config"))
}
The above code lacks caller address validation, allowing anyone to call update_config() and set their own address as the vault address, thereby receiving all rewards generated by the contract.
5. Avoid Infinite Loops
CosmWasm contracts have a high gas limit, but improper usage can exhaust gas. A CosmWasm contract might fall into an infinite loop by recursively calling itself within an ACK handler. If developers pass packets between two CosmWasm contracts, they must be cautious, as this could trigger infinite loops and consume excessive gas fees.
Project Security Best Practices
1. Smart Contract Audits
Smart contract audits involve systematic testing and reviewing of contract code to identify potential security vulnerabilities, eliminate risks, ensure there are no logical flaws, and confirm that the code behaves as intended. Regularly auditing project smart contracts is crucial, ideally after development completion and before mainnet deployment.
2. Use Multi-Signature Wallets
Projects should consider using multi-signature wallets to manage treasury funds and smart contracts. Multi-sig accounts should be held by multiple entities to minimize access control risks and prevent internal malfeasance. Nibiru Chain already uses the Nomos multisig solution, and projects may consider adopting Nomos for asset management.
Conclusion
As a brand-new Layer 1 blockchain, Nibiru Chain provides an innovative platform for DeFi, gaming, RWA, and other sectors, aiming to solve issues related to accessibility, security, and performance in Web3 applications, delivering comprehensive and high-quality services for both developers and everyday users.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














