Developers — building on Coinbosa Chain

Getting started

Three fields, and the network is reachable.

An EVM network is described by a handful of values. They are not intentions: they apply to every block and can be read back on the chain.

Field	Value to enter
Network name	Coinbosa Chain
New RPC URL	https://explorer.coinbosa.com/rpc
Chain ID	26262 — 0x6696 in hexadecimal
Currency symbol	BOSA
Decimals	18
Explorer URL	https://explorer.coinbosa.com

Opening manual entry

Open the network selector, then “Add network” and “Add a network manually”. Coinbosa Chain is entered by hand: that is the normal route for a network the wallet does not know in advance.

Copying the fields

The wallet queries the endpoint and refuses to register it if the identifier returned by the node does not match the one entered. This check protects against an endpoint passing itself off as another network.

Verifying before signing

Balances are displayed in BOSA and the latest block advances at the pace of the Parlia consensus — target of 5 s, measured at 5.018 s over 500 consecutive blocks.

The 18 decimals are not a setting. The base unit of an Ethereum virtual machine is the wei, a value hard-wired into gas accounting as well as into every wallet. No field allows it to be changed.

Connection

Add the network from code.

An application can offer to add the network in a single prompt, without the user copying anything.

wallet_addEthereumChain

await window.ethereum.request({
  method: 'wallet_addEthereumChain',
  params: [{
    chainId: '0x6696',
    chainName: 'Coinbosa Chain',
    nativeCurrency: { name: 'Coinbosa', symbol: 'BOSA', decimals: 18 },
    rpcUrls: ['https://explorer.coinbosa.com/rpc'],
    blockExplorerUrls: ['https://explorer.coinbosa.com']
  }]
});

The identifier is passed in hexadecimal

26262 is written here as 0x6696, prefixed and with no leading zero. This is the most common mistake at this step: an identifier passed in decimal is rejected, often without an explicit message. eth_chainId returns the same form.

The prompt is not a guarantee

Any site can request that a network be added, under the name and symbol of its choice. What identifies a chain is its identifier, the hash of its block 0 and the address of the endpoint.

Tooling

Configuring Hardhat and Foundry.

No specific plugin is required: to these tools, Coinbosa Chain is an EVM network like any other. Only the targeted EVM version calls for attention.

hardhat.config.js

module.exports = {
  solidity: {
    version: '0.8.26',
    settings: { evmVersion: 'shanghai' }
  },
  networks: {
    coinbosa: {
      url: 'https://explorer.coinbosa.com/rpc',
      chainId: 26262,
      accounts: [process.env.CLE_PRIVEE]   // never in plaintext in the repository
    }
  }
};

foundry.toml

[profile.default]
solc_version = "0.8.26"
evm_version = "shanghai"

[rpc_endpoints]
coinbosa = "https://explorer.coinbosa.com/rpc"

# forge script script/Deploy.s.sol \
#   --rpc-url coinbosa --broadcast

Compile for Shanghai, not for Cancun. Solidity targets Cancun by default: without evmVersion: 'shanghai'

A private key never goes into a configuration file. It is read from an environment variable or an encrypted store, and its file stays out of the repository. No member of the Coinbosa team will ever ask you for your key or your recovery phrase.

DeFi & DEX

A native DeFi and DEX suite.

The Coinbosa Chain embeds a native DeFi & DEX suite: developers issue smart contracts on it, create liquidity pools and deploy BRC20 tokens without restriction.

Issuing smart contracts

Deployment goes through the usual EVM tools, the ones configured above. A signed transaction is enough: nothing to request, nothing to have approved beforehand.

Creating liquidity pools

Pools are deployed like ordinary contracts and rest on the BRC20 tokens of the chain, whose interface is described below.

Deploying tokens without restriction

Issuing a BRC20 token is not subject to any authorization. The only convention to respect is that of the interface, in order to stay compatible with the wallets and services that speak ERC-20.

Tokens

The BRC20 standard.

BRC20 — Bosa smart contract 20 — is the token standard of the chain. Its interface is ERC-20 compatible: any wallet, any bridge, any service that speaks ERC-20 works without adaptation.

IBRC20.sol — minimal interface

interface IBRC20 {
    function name()        external view returns (string memory);
    function symbol()      external view returns (string memory);
    function decimals()    external view returns (uint8);
    function totalSupply() external view returns (uint256);
    function getOwner()    external view returns (address);

    function balanceOf(address compte) external view returns (uint256);
    function allowance(address proprietaire, address delegue) external view returns (uint256);

    function transfer(address vers, uint256 montant) external returns (bool);
    function approve(address delegue, uint256 montant) external returns (bool);
    function transferFrom(address de, address vers, uint256 montant) external returns (bool);

    event Transfer(address indexed de, address indexed vers, uint256 montant);
    event Approval(address indexed proprietaire, address indexed delegue, uint256 montant);
}

Ownership is transferred in two steps

This is the only notable difference in behavior from a common ERC-20. transferOwnership designates a pending recipient, without giving anything up; ownership only changes when that recipient calls acceptOwnership from their address.

Why this detour

A one-step transfer to a mistyped address is irreversible: nobody holds the key, no owner-reserved function can be called any more, the contract stays orphaned forever. The second step proves that the recipient controls the address.

What BRC20 adds

getOwner exposes the owner in a standardized way. mint is reserved for the owner and is closed permanently by finishMinting; burn is open to the holder. Finally, increaseAllowance and decreaseAllowance avoid the race condition of approve.

A standard of the same name exists on Bitcoin, with no technical relation. The BRC-20 of Ordinals inscriptions shares nothing with this one but the name: writing “Coinbosa BRC20” removes the ambiguity.

Exposed surface

What the public endpoint accepts.

The public node is there to read the chain and to submit signed transactions to it. What would allow it to be inspected or driven is closed, and expensive requests are bounded: without bounds, a two-hundred-byte request can require scanning the entire chain.

Family	Status	What this covers
eth	open	Blocks, balances, storage, gas estimation, logs, submission of signed transactions.
net	open	Network identity — what a wallet needs in order to add the chain.
web3	closed	Publishes the exact client version and its commit hash — a ready-to-use list of targets.
personal, admin	closed	Node keystore keys, peers, services, file writes.
debug, txpool, miner	closed	Internal state, transaction queue, block production.

Transport	HTTPS, POST only — any other method is refused.
Request size	Capped; a heavier request is rejected before processing.
Batched calls	Capped per HTTP request.
Log range	Bounded per call to eth_getLogs; long histories are read in slices.
Log filters	Number of addresses and alternative topics bounded per search position.
Browser origin	explorer.coinbosa.com only; server-to-server calls are not affected.

This endpoint is made for reading and for submitting. It does not expose a WebSocket subscription: an application polls the node rather than subscribing to it. And reading a state back at an old block requires an archive node, which anyone can run from the repository.

Verification

The foundation can be read back on the chain.

The values below are those of the whitepaper. They do not ask to be taken on trust: two requests are enough to find them again.

Consensus and block time	Parlia — Target: 5 s \| Measured: 5.018 s over 500 blocks
Chain ID	26262 — EIP-155 replay protection
Epoch rollover	Validator intervals fixed — verified at blocks 200, 400, 600, 800
Consensus system contract	Custom-written (Solidity / Go-Ethereum), running directly on the chain
Native token standard	BRC20, ERC-20 compatible — automated test suite
BOSA supply	700,000,000, 18 decimals
Block 0 hash	0x8dcdadc247a98f33728cae944e20ce7c49c74b35cfba31495f85e98979018da6
Block 0 state root	0x93682eb9182a55531d47014b76a285b45d3e720a2951f9ffbdc67f52995f8c03
Production deployment	August 7, 2026

Verify the chain identity

# doit renvoyer "0x6696" — soit 26262
curl -s -X POST https://explorer.coinbosa.com/rpc \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

# doit renvoyer l empreinte 0x8dcdadc2... publiee plus haut
curl -s -X POST https://explorer.coinbosa.com/rpc \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,
       "method":"eth_getBlockByNumber","params":["0x0",false]}'

The code is public

The client, the contracts, the genesis and the deployment scripts are published on the Coinbosa repository. Recompiling the genesis must give back exactly the block 0 hash published above.

What identifies the chain

A name and a symbol can be copied; a chain identifier and a block 0 hash cannot. Those are what must be compared before sending a transaction, and the explorer displays them in plain sight.

Who publishes this networkThe publisher, the ecosystem built around the chain and the breakdown of the BOSA supply.

Open the About page

Build on Coinbosa Chain