Comment on page

Bronos Whitepaper


Blockchain History

Blockchain technology was first introduced in 2008 by the anonymous creator of Bitcoin, Satoshi Nakamoto. The original goal was to create a decentralized digital currency that could operate without a central authority. The first blockchain-based digital currency, Bitcoin, gained popularity as a new form of currency, and its blockchain became a model for other cryptocurrencies.
However, as the usage of blockchain technology has expanded, its limitations have become more evident. One of the main issues is the scalability problem. Blockchains operate in blocks, and it takes time to calculate each block. Furthermore, each block can only fit a limited number of transactions. When the number of transactions exceeds the capacity of a block, miners have to choose which transactions to process first, and they often prioritize those with higher fees. As a result, other transactions may need to wait for a long time to be processed, leading to slow transaction times and high fees.
The problem of scalability is particularly pressing when it comes to the global economy. Most existing blockchains are unable to handle the high volume of transactions required for widespread adoption in the world's financial systems. This is where Bronos comes in, offering a multichain solution that allows for horizontal scaling and interoperability between different blockchains. With its ability to handle a large number of transactions and provide fast confirmation times, Bronos is well positioned to meet the demands of the global economy while maintaining the security and decentralization that blockchain technology promises.

Alternate Blockchains

IOTA is a feeless Layer 1 blockchain primarily designed for IOT (Internet of Things) applications. IOTA network uses Tangle which is a distributed ledger. Tangle uses DAG (Directed Acyclic Graph) structure representation for consensus, a system of nodes that is not sequential. Thus, each node can be connected to multiple other nodes in a Tangle. But they are connected only in a particular direction, meaning that a node cannot refer back to itself. A standard blockchain is also a DAG because it is a sequential linked list. But IOTA's Tangle is a parallel system in which transactions can be processed simultaneously instead of sequentially. As more systems are attached to it, the Tangle becomes more secure and efficient at processing transactions. Full node miners are not required in Tangle. Each new transaction is confirmed by referencing two previous transactions, reducing the amount of time and memory needed to verify a transaction.
Assembly uses IOTA Smart Contract as its underlying Protocol which uses a two layer model. Layer 1 is IOTA Tangle and Layer 2 is IOTA smart contract chain. Each chain has its own state where state update (going from one block to another block) is hashed and published to the tangle which moves the state anchor on Layer 1. Layer 2 does bulk of the work and Layer 1 is used for communication and protection.
  • Zero-fee transactions: IOTA's feeless model is particularly attractive for microtransactions, making it ideal for IoT use cases.
  • Low resource requirements: Due to its unique consensus mechanism, IOTA requires less computational power compared to other blockchains, making it more energy-efficient.
  • EVM compatible: Assembly Chain supports Ethereum Virtual Machine (EVM) which allows developers to write smart contracts in Solidity and deploy them on the IOTA network.
  • High throughput: IOTA can process up to 1000 transactions per second, which is a significant improvement over other blockchains.
  • Centralization: IOTA is heavily centralized around one master "coordinator" run by the IOTA Foundation, which decides the priority of messages and serves as a single point of failure.
  • Unproven technology: Tangle is a relatively new and untested technology, and IOTA has been hacked in the past, causing the network to shut down for two months.
  • No incentives for validators: IOTA lacks a clear incentive mechanism for validators, which can discourage network participation and lead to centralization.
  • Limited interoperability: Assembly Chain is not compatible with non-EVM blockchains, limiting its ability to communicate and interact with other blockchain networks.
  • Limited customizability: Assembly Chain does not provide full flexibility to chain owners to customize the genesis block and other key parameters, which can limit its applicability in some use cases.

Polygon (Matic) - Plasma chain

Polygon is a Layer 2 scaling solution for Ethereum. Blocks are produced every 1 second and each plasma sidechain can handle upto 7000 tps. It works by users on Ethereum depositing funds to Matic Smart contracts deployed on Ethereum. Polygon Nodes listen to the events generated by those smart contracts and create those funds on Polygon chain. Plasma Checkpoint Nodes are responsible for consensus and creating checkpoints on Ethereum Chain. Consensus works by selecting a small group of Block producers through voting and after the blocks are validated the hash of the root of every block with the merkel proof is written to Ethereum at regular intervals.
Polygon (MATIC) Architecture
  • High scalability with 7k tps
  • Highly interoperable with Ethereum chain
  • EVM Compatible
  • High security with regular checkpoints written to Ethereum
  • Low gas costs
  • Centralization: While Polygon is designed to be a decentralized network, some critics argue that it is not truly decentralized due to the presence of centralizing elements, such as the network's validators and governance structure.
  • Security risks: Polygon has faced some security risks in the past, including a major hack in 2021 that led to the loss of $600,000 in user funds. While the network has since implemented upgrades to improve its security, the incident underscores the potential risks of using a relatively new and untested blockchain platform.
  • Limited interoperability: While Polygon supports interoperability with Ethereum, it is not yet compatible with other major blockchains. This could limit its appeal to developers and users looking for a more flexible and interoperable blockchain platform.
  • Reliance on Ethereum: While Polygon is designed to address some of the scalability challenges facing Ethereum, it remains heavily dependent on the Ethereum network for security and other key features. This could limit its ability to differentiate itself from Ethereum in the long run.
  • Limited decentralization: While Polygon uses a Proof-of-Stake (PoS) consensus mechanism, some critics argue that the network is not fully decentralized due to its reliance on a relatively small number of validators. This could raise concerns about the network's long-term sustainability and resilience.

Polkadot - Para chain

Polkadot unites and secures a growing ecosystem of specialized blockchains called parachains. Parachains are custom, project-specific blockchains that are integrated within the Polkadot (DOT) and Kusama (KSM) networks. Parachains can be customized for any number of use cases and feed into the main blockchain, called the Relay Chain, considered to be the heart of the Polkadot and Kusama networks. The Relay Chain is responsible for the network’s shared security, consensus and transaction settlements, and thus, by being integrated into the Relay Chain, all parachains benefit from the Relay Chain’s base features. It uses a modern concern protocol in the Nominated Proof of Stake (NPoS) algorithm. This is designed to maximize the network’s shared security so that no users’ parachain is corruptible. Nominated proof of stake allows those staking DOT tokens to nominate validators they feel will best serve and secure the network. Unlike the similar delegated-proof-of-stake system, NPoS makes it possible for nominators to be subjected to a loss of stake if they nominate a bad actor.
  • Allows developers to launch chains & applications leveraging shared security model without having to worry about attracting enough miners or validators to secure their own chains.
  • modular framework offers developers the flexibility to select specific components that best suit their application-specific chain.
  • Max tps of 1000
  • WASM Compatible & allows self upgrades without the need to fork
  • Need to go through parachain Auction system to secure a slot to connect the parachain to relay chain
  • Limited number of slots available
  • Each slot has a definite validity period and need to go through the auction again which is not convenient for every use case
  • Each parachain need to run its own bridges to connect to other blockchains


Bronos is a hub of blockchains that are originated from its root blockchain Bronos. It is built using the Cosmos SDK and Tendermint, hence it uses PoS consensus protocol. Each chain in bronos is a multi chain that is connected to the chain it is originated from. All the chains are EVM & WASM compatible which allows instant porting of dAPPs from other EVM chains like Ethereum for developers looking for scalable, flexible and interoperable chain according to their requirements.
Bronos Node


All bronos family of blockchains uses account module from cosmos sdk to manage its users

Messages & Transactions

State Transition Function



Storage on most popular blockchains like Ethereum, Polygon is often very expensive due to the gas costs to write to those chains. Some of these offer alternatives like providing bridges to store data on alternative blockchains like Filecoin but their model has failed eventually. Today many other alternatives have come up that claim to offer free storage on (IPFS + Filecoin) upto 1 TB but going to charge eventually. Most of these alternatives only replicate the data upto 6 times and there is a chance that data could still be lost. To reduce the pain for dAPP developers in deciding where to store their huge data like NFTs Bronos is building the solution right into its network. Data is replicated across all of the Bronos nodes running with IPFS enabled as storage providers. Each Node operator can chose variety of options from S3, Disks, IPFS Nodes, Filecoin or just the tendermint DB and they get incentivised for it. For users who want to use Bronos storage it is completely free but need to stake tokens for using the storage. you can free up the storage anytime and unstake the tokens. Hence your data is safely stored and always available as long as Bronos blockchain lives on.
IPFS module on bronos is responsible for handling the storage on bronos. It allows two types of transactions. 1. stake tokens and store the data 2. delete the data and unstake the tokens. It also allows querying the data with the CID hash to retrieve it. Max limit of file size per upload is 2 GB.


when a node receives upload transaction, it checks if the user has enough staked tokens for the storage cost of the data, it is calculated as follows
tokens_required = size of data to store * tokens cost per byte.
token_balance = total tokens staked - storage utilised * tokens cost per byte
if token_balance < tokens_required {
return nil, errors.New("insufficient storage")
if user has enough storage, data is stored into the distributed datastore and an event is logged with the CID hash of the data and the user address. There is no gas cost for storing into this distributed datastore but a small gas fee is charged for storing its metadata into the blockchain.


To delete ipfs data, user need to create another transaction with the CID hash of the data that needs to be deleted. once the transaction is received, it validates the CID and checks if the user can delete it. On successful validation the data is deleted and the corresponding tokens are unlocked for user to unstake.


A query request can be made to the blockchain node to retrieve data based on CID hash. if the CID hash is found then data is returned.


Bronos is a multi chain designed for scalability. Each chain in bronos can generate more chains from it and it allows cross chain communication among them. Chain module is responsible for creating new chains, tracking their consensus states, validators details, IBC connections and also slashing/deactivating them when chains misbehave.
Create Chain
New chains are created in this transaction. The transaction takes genesis file as input allowing the developers to have full control of their chain. Then the genesis file is validated to ensure few mandatory fields are set correctly. For all valid genesis files the file is stored in IPFS datastore and its CID along with some other metadata are written to bronos blockchain. This ensures the genesis file is immutable and every node validator of the chain can fetch the genesis file from its parent and start validating the blocks.
Register Chain
Register chain allows an existing chain that is compatible with bronos to be registered and connected to the bronos network. Any existing Cosmos IBC or EVM chains can implement the bronos modules or its features and be anchored to one of the bronos chain. Detailed steps on integration will be shared later.
Chain Validators
Anyone can run validator node for chains that is created in bronos root chain. you can do so by using the bronosd cli and specifying the chain id and the parent chain RPC endpoint. The CLI will fetch the genesis file from parent chain and also the peers if exist and start the node. The node will catch up with the peers by downloading the snapshot and start validating the blocks. Each validator also notifies parent that they are validator node for the chain. parent chain keeps track of all the validator nodes of all the chains created in it and slashes their funds if any of the validator node acts mischief or fail to do their duties. To run a validator node it should posses the native tokens of the parent chain on parent network and also native tokens of the chain itself.
The chain will periodically commits its block hashes to parent chain for additional security. All the validator nodes of the chain will commit blocks of fixed size from last commit to the parent chain. It requires 2/3rd of the validator nodes of the child to commit only then the parent node will include this commit to its blockchain. These checkpoints acts as a safeguard or save point for the child chains.
IBC Connection
When a chain is created a new IBC connection & channel is created in parent by default for the chain. when a chain node is started an IBC connection on that channel to the parent is started. A light client on the chain will start listening to the parent chain for the packets sent on that channel and vice versa on parent.


Bronos module is responsible for token mappings, token conversions between cosmos and EVM, token proposals. By default any token received through IBC is of the form ibc/<hash> . The hash will contain the full ibc trace from where the token is originated from and all the chains it has travelled until reaching the current chain. for more details on IBC token format standards refer here . Bronos module will automatically convert the new IBC token to EVM token of BRC20 format by deploying a new smart contract. Inbuilt bridge can be used to convert this foreign token to native EVM tokens provided there is liquidity.
Token mapping
Token mapping is done to convert tokens between Cosmos and EVM. Token mapping will contain the Cosmos denom and its associated EVM smart contract to allow conversions between cosmos and EVM seamlessly. token mapping can be done by submitting a transaction either by the chain admins or through token mapping proposals by anyone. Once the proposal is passed the token mapping will be updated automatically.

Smart Contracts


All chains on Bronos are EVM compatible. It uses the ethermint evm module for EVM compatibility. When a node is started a JSON RPC server on port 8385 is started automatically. It is compatible with all EVM wallets like Metamask, Trust wallet, Wallet Connect etc., During the genesis the base denom for EVM can be defined. All tokens are of BRC20 format which is a modified version of ERC20 with roles, access control and ownership. Any ERC20 compatible token can be easily wrapped to BRC20 token.


Bronos also supports CosmWasm smart contracts. CosmWasm contracts are written in Rust and are designed to be chain agnostic. With inbuilt support for IBC and chain agnostic smart contracts dApp developers can easily build a scalable cross chain dApp on bronos.

Cross Chain


For IBC to work, two blockchains need a channel to communicate and the channel needs to be pre configured on both chains. When a chain A wants to send funds to other chain B it will burn the tokens on the chain A and sends an IBC packet to the destination chain B using the channel. Here send means it doesn't have any socket connection to the other chain instead it will commit the IBC packet transaction in to its blockchain. A relayer node listens to those transactions and relays it to the other chain by creating special message types. A light client on chain B process these messages and verifies the proof. chain B will process the transaction and transfer the funds to the destination account. for a chain to connect to n chains it requires n relayers which is not scalable and relayer is single point of failure.
In bronos, relayer is inbuilt in every node and listens to its parent and to all the sub chains which has a node connected to it. when an IBC packet is committed and included in the parent blockchain on its channel relayer sends the message for that IBC packet and the light client verifies it and moves it to voting phase with a vote from this node. when the packet receive 2/3rd votes from all the nodes the packet is processed and the funds are minted and transferred to the destination account on its chain. The major difference compared to above approach is an IBC packet requires votes from 2/3rd of the relayers from peers before it is considered for processing which gives more security instead of trusting only one relayer. A relayer could get slashed and lose it tokens if its submits vote for some unrecognised messages.
For cross chain transfer between two chains we use common ancestor algorithm in trees. After an IBC packet is selected for processing, If the destination of the packet is not the current chain it will check for the destination route and send IBC packet either to its parent or to the relevant child chain. Every chain knows the list of child chains created under it as mentioned in Chain Creation flow. if the destination chain is found in its KVStore then the IBC packet is sent to the immediate child chain along the path to the destination. if destination chain is not found the IBC packet is always sent to parent chain. If the node doesn't have any parent and the destination is not found then the packet is dropped.
Cross Chain Transfer
Hence max delay for Cross Chain transfers in bronos can be 2 * max distance of chains from the root chain * avg IBC confirmation time between child and parent. This can be used to determine the IBC timeout for every node.
A relayer needs to pay gas fee to both blockchains. hence while running the node ensure the relayer address has enough balance on both chains for the initial period. A relayer also gets rewards for doing its work on both the chains according to the chains configuration.

Gravity Bridge

Gravity Bridge is a cosmos module developed by Althea to connect cosmos with Ethereum. It is a bridge that listen to events generated by its smart contract on Ethereum and produce them on cosmos side via the gravity bridge module. for more info on how gravity bridge works refer here.
Gravity bridge is integrated with all bronos chains. This allows all bronos chains to bridge with any EVM chain that is not part of bronos family or to short circuit the chains within bronos which require low latency cross chain transfers.


Token utility

File storage

With bronos inbuilt support for IPFS storage, it can act as another option for storing immutable public files to blockchain with high redundancy which is not provided by other providers. Bronos replicates data across all nodes and each node writes data to a variety of destinations like S3, IPFS Gateway, Filecoin network, File servers etc.,

Blockchain as a Service (BaaS)

Bronos can be used as BaaS platform for users who don't want to manage the validator nodes for their chains. Users can visit the platform and create new chains by editing the default genesis file and customise it and deploy the chain. Once the chain is created they can either provide the validator address to run the node or let the platform create new account. the user can backup the validator private key. user can also chose to create new nodes for an existing bronos chain by providing the chain id and the parent node url on which it was created. User gets charged every day/week/month for the hosting costs. User can copy the EVM RPC url for the chain and deploy their apps.
In future when bronos support consensus as a pluggable protocol, user can chose which consensus they want to use while creating their chain. The platform will use the binary of the respective consensus to start the node.

Chain Registry

Chain Registry is a common problem in today's blockchain where these are managed by some centralised github repo and multiple of them exist today. With Bronos chain creation process where every new chain created ends up getting stored in root chain which can be used as a decentralised chain registry for claiming chain names and updating validator nodes etc.,


Like any blockchain, Bronos faces security concerns that must be addressed to ensure the safety and integrity of the network. Some of the key security concerns of Bronos blockchain are:
  1. 1.
    51% Attack: A 51% attack happens when a single entity or group of entities controls more than 50% of the network’s computing power. This would allow them to control the network and potentially make fraudulent transactions.
  2. 2.
    Smart Contract Vulnerabilities: Smart contracts are a fundamental part of blockchain technology, but they can be vulnerable to bugs or coding errors that can be exploited by attackers.
  3. 3.
    Sybil Attacks: A Sybil attack occurs when an attacker creates multiple fake identities or nodes to control the network.
  4. 4.
    Distributed Denial of Service (DDoS) Attacks: A DDoS attack occurs when an attacker floods the network with traffic, making it difficult for legitimate users to access the network.
To mitigate these security concerns, Bronos employs various security measures such as consensus algorithms, smart contract auditing, and network monitoring to ensure the safety and integrity of the network. Additionally, Bronos regularly conducts security audits and vulnerability assessments to identify and address any potential vulnerabilities or weaknesses in the system.


Bronos is a next-generation multichain blockchain platform that provides developers with the necessary tools to build scalable and decentralized applications. Its multichain architecture allows for horizontal scaling, while its support for EVM and WASM compatibility ensures that developers have a familiar environment to work with. Additionally, Bronos’ cross-chain communication capabilities enable interoperability between different chains, further expanding the possibilities for decentralized applications.
While security concerns are always present in the blockchain space, Bronos has implemented several measures to address these risks. The use of a multichain architecture, sharding, and other scalability solutions also add to the overall security of the platform.
Bronos’ mission is to provide a robust and reliable infrastructure for decentralized applications to thrive. With its advanced features, support for multiple programming languages, and commitment to innovation, Bronos is well-positioned to become a leading blockchain platform for developers and users alike.
Last modified 9mo ago