The Analysis of Nibiru Chain

Forward the Original Title：新公链 Nibiru 主网将上线，解析其技术特点与安全开发实践

Layer1 public chain—-Nibiru Chain launched an airdrop incentive at the end of January 2024. After a month of airdrop activities, its community grew more than threefold, with over 500,000 followers on Twitter. With over $20 million in funding secured, Nibiru Chain is poised to address the security and speed of DeFi applications, potentially competing with dYdX. Currently, Nibiru Chain plans to launch its Mainnet this week. As a rapidly growing Layer1 solution, what are Nibiru Chain’s technical features and competitive advantages? What security considerations should developers keep in mind when developing projects within its ecosystem? Today, Beosin will provide a detailed analysis.

Nibiru Chain Protocol Analysis

Nibiru Chain primarily focuses on DeFi transactions as its core business. It comprises four main components:

1. Nibi-Perps

On-chain perpetual contract trading, allowing users to engage in leveraged trading of popular crypto assets such as BTC, ETH, and ATOM, with leverage of up to 10x. Holders of $NIBI tokens will have governance rights over Nibi-Perps and enjoy trading fee discounts.

1. Nibi-Swap

Nibiru’s automated market maker protocol is designed to support two types of liquidity pools: stablecoin exchange pools and regular constant product pools.

1. $NUSD

A fully collateralized stablecoin within the Nibiru ecosystem. Nibiru plans to initially support the minting of $NUSD using $USDC and $NIBI, with the specific ratio determined by the Collateral Ratio (CR). For example, if CR=80%, it means to mint 100 $NUSD, the user needs to provide 80 $USDC and the equivalent of 20 $NUSD in NIBI. In the future, Nibiru Chain will support more types of collateral, and currently, $NUSD is more like the $FRAX in the Cosmos ecosystem.

1. Nibi-Oracles

Nibi-Oracles is Nibiru’s native oracle solution, allowing validator operators to actively participate in oracle consensus voting. It integrates off-chain data high-fidelity onto the blockchain, providing low-latency feedback from external APIs and smart contracts.

In 2024, Nibiru Chain will focus on expanding the ecosystem, with major developments including multiple plans such as integrating with major DeFi projects on multiple chains, listing on top-notch centralized exchanges, completing parallel optimistic execution, and achieving comprehensive EVM compatibility.

Secure Development Practices

If you develop an application on Nibiru Chain, the development process and required languages ​​are almost identical to those on other Cosmos public chains. Following the security guidelines below can improve the contract security of the project:

Contract Development Security

1. Be Prepared to Address Attacks

Similar to developing contracts using Solidity, developers need to consider how to address attacks and fix vulnerabilities. Therefore, developers should build upgradable smart contracts and formulate risk response plans.

1. Pay Attention to Address Validation Standardization

Any valid Cosmos SDK address has two valid representations: all lowercase and all uppercase, such as:

cosmos1uzwqa88hcqe5gs7u7lgjxekz7xc6sm0f7xwp6a vs.

COSMOS1UZWQA88HCQE5GS7U7LGJXEKZ7XC6SM0F7XWP6A

They are at the same address, as Nibiru. When dealing with addresses in contracts, we need to consider this characteristic of addresses.

pub fn valid_transfer (

deps: DepsMut,

info: MessageInfo,

amount: Uint128,

dest: String,

) -> Result <Response, ContractError> {

// Check if the address is in the blacklist

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 in the code above, since dest is not standardized and the addresses commonly used are lowercase addresses, anyone can bypass BLACKLIST by providing an uppercase address.

1. Pay Attention to Arithmetic Operations and Overflow

In CosmWasm contracts, developers should be mindful of integer overflow risks or situations like division by zero. It’s recommended that developers use CosmWasm’s Uint256 and Uint512 types and employ mathematical functions like full_mul() that won’t cause overflow.

1. Access Control Issues

Access control is one of the primary security concerns in program security, and numerous security incidents have been caused by access control issues. It’s equally important to address access control issues in Cosmwasm contracts.

Here’s a typical example:

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”))

}

Due to the lack of checks and restrictions on the caller’s address, the above code allows anyone to call update_config(), set their own address as the vault address, and receive all rewards generated by the contract.

1. Beware of Infinite Loops

Cosmwasm contract operation sets a high gas limit, but improper use will exhaust gas. The CosmWasm contract may get stuck in an infinite loop by calling itself back in the ACK handler. If developers transfer data packets between two CosmWasm contracts, they should be aware that this may lead to an infinite loop and consume a large amount of gas fees.

Project Safety Practices

1. Smart Contract Auditing

Smart contract auditing involves systematically testing and reviewing smart contract code to identify potential security vulnerabilities, mitigate security risks, and ensure that the code has no business logic flaws, and conforms to expected operational processes and outcomes. It’s crucial to conduct regular security audits of smart contracts for projects. Audits are recommended to be performed after the completion of contract development and before Mainnet deployment.

1. Use of Multisig Wallets

Project teams should consider using multi-sig wallets to manage project treasuries and smart contracts. Multisignature accounts should be held by multiple entities to mitigate potential access control risks and internal malfeasance. Nibiru Chain has already adopted the Nomos multi-sig solution, and project teams may consider using Nomos for asset management purposes.

Summary

As a new Layer1 public chain, Nibiru Chain provides an innovative platform for DeFi, games, RWA and other fields. It aims to solve the accessibility, security and performance issues of Web3 applications and provide developers and ordinary users with comprehensive and excellent services. Services.

Disclaimer：

1. This article is reprinted from [Techflow]. *Forward the Original Title‘新公链 Nibiru 主网将上线，解析其技术特点与安全开发实践’.All copyrights belong to the original author [Beosin]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.