# Comparisons

BitBadges is its own Cosmos SDK Layer 1 with a token standard that works like an API: the logic is implemented once in the module, and each collection customizes it through messages. This page compares that design to other protocols and to ERC-3643 (T-REX), a standard for permissioned security tokens.

## BitBadges L1 Versus Other Protocols

### Chain Architecture

BitBadges is a Layer 1, not a Layer 2 or a sidechain. It is built with the Cosmos SDK, which provides the foundation for its configured Cosmos modules and IBC support. The native token standard has its own balances and approval model. EVM contracts can access it through precompiles; ERC-compatible wrappers require explicit integration. A native collection is not automatically an ERC-20 contract or a Bitcoin Ordinal.

### Security Model

BitBadges is less decentralized today than the largest protocols, and decentralization grows over time. The intended role is one part of an application stack rather than the whole of it. An application can use BitBadges for authentication and gating while accepting payments in its native currency.

### Cross-Chain Interoperability

IBC connects BitBadges through configured channels and supported routes. Wrapper paths expose compatible bank denoms; integration depends on the destination chain and application. See [IBC](https://docs.bitbadges.io/token-standard/ibc).

### Token Standard

Protocols such as Ethereum rely on ERC-20 and ERC-721, which need a smart contract deployment per token. That approach grows complex, adds a new attack surface per contract, and does not model the structure most use cases need. On BitBadges, everything is implemented natively and a collection customizes the requests, which is why the BitBadges site is no-code by default.

### Smart Contract Support

Ethereum and Solana have broad smart contract support. BitBadges supports EVM contracts, including contract-based token implementations. Its native collections use `x/tokenization`; contracts can access that module through precompiles. The goal remains a standard where custom contracts are never needed. See [EVM](https://docs.bitbadges.io/chain/evm).

## BitBadges and ERC-3643

ERC-3643 and BitBadges are not competing standards. They operate at different layers. The BitBadges standard enforces compliance at the protocol level, and ERC-3643 can serve as a Solidity interface that calls into it through EVM precompiles. A Solidity developer keeps the ERC-3643 API and gets protocol-level enforcement behind it.

### Overview

ERC-3643 (T-REX, Token for Regulated EXchanges) is an Ethereum standard for compliant security tokens. The [ERC-3643 Association](https://www.erc3643.org/) reports more than $32 billion in tokenized assets on its website (checked 7 September 2026); this is an association-reported adoption figure, not a measure of technical compatibility.

BitBadges enforces compliance rules, transfer restrictions, and approval logic in the chain itself. No contract deployment is needed. For EVM developers, precompiles expose the native standard through Solidity interfaces such as ERC-3643.

### Feature Comparison

| Feature | BitBadges protocol standard | ERC-3643 interface (through precompiles on BitBadges, or natively on Ethereum) |
| --- | --- | --- |
| Enforcement layer | Protocol level; the chain enforces the rules | Contract level; Solidity contracts enforce the rules |
| Smart contracts required | No; collections are configured through transaction messages | Yes; each token deploys several contracts (token, identity registry, compliance module, claim topics) |
| Deployment experience | No-code site, CLI template builders, or MCP builder tools | Developer only; needs Solidity expertise and contract deployment |
| Multi-chain support | IBC over configured, supported routes | Requires a supported cross-chain transport or wrapper |
| Identity and compliance | Built-in approval criteria: ownership requirements, merkle proofs, signature challenges, on-chain queries | ONCHAINID identity framework with claim topics and trusted issuers |
| Transfer restrictions | Per-approval rules: address lists, time windows, amount limits, tracker-based caps, 2FA gating, coin payment requirements | Compliance modules with rule contracts (country restrictions, investor limits, time locks) |
| Permissioning | Granular, lockable permissions; each field can be frozen or left manager-controlled independently | Owner and agent roles with recovery mechanisms |
| Token types | Fungible tokens, NFTs, subscriptions, vaults, prediction markets, bounties, and more from one standard | Primarily fungible equity and security tokens |
| Forced transfers | Admin override approvals | Recovery and forced transfer functions |
| Supply control | Configurable mint and burn rules with lockable permissions | Mint and burn controlled by token agents |

### ERC-3643 Strengths

- Institutional tooling: an established implementation and identity framework designed for permissioned tokens.
- Regulatory track record: purpose-built for securities compliance with established legal frameworks.
- Ecosystem maturity: identity providers, compliance modules, and institutional tooling.
- ONCHAINID: a mature decentralized identity framework for KYC and AML.

### BitBadges Strengths

- No smart contract development: a compliant token is configured through transaction parameters or the no-code site.
- Shared enforcement: native transfers are checked by the module even when initiated through a precompile. Security still depends on the module, configured approvals, manager permissions, and any application contracts.
- Broader token types: subscriptions, prediction markets, vaults, auctions, bounties, and NFTs from the same standard.
- Agent friendly: MCP builder tools and CLI template builders let AI agents create and manage compliant tokens.
- Cosmos ecosystem: IBC connectivity through supported channels and routes. Destination support and enabled channels determine where an asset can move.
- Lower barrier: no Solidity, gas optimization, or contract auditing.

### How They Work Together

Through EVM precompiles, a Solidity contract calls the native token standard with the ERC-3643 function signatures developers already know. The precompile bridges the call; the chain enforces the transfer rules, identity checks, and compliance logic, not the contract. The ERC-3643 interface is optional: the no-code site, the CLI builders, and the MCP builder tools talk to the protocol standard directly. See [Tokenization Precompile](https://docs.bitbadges.io/chain/evm/tokenization-precompile) and the [ERC-3643 specification](https://www.erc3643.org/).

## Related

- [Why BitBadges](https://docs.bitbadges.io/about)
- [Transferability](https://docs.bitbadges.io/token-standard/concepts/transferability)
- [Permissions](https://docs.bitbadges.io/token-standard/concepts/permissions)
- [EVM](https://docs.bitbadges.io/chain/evm)