Reference
Limitations & Risks
An honest overview of the current constraints, known trade-offs, and risks of using the Monadinals protocol.
Protocol limitations
Read before using
No on-chain balance proofs
Token balances are not stored on-chain. You cannot write an EVM smart contract that reads a MON-20 balance — there is no Solidity interface for it. Balances exist only as derived state in the indexer. This limits DeFi composability compared to native ERC-20 tokens.
Indexer is a centralization point
The official Monadinals indexer is operated by the team. If the indexer goes down, balances and explorer data will be unavailable until it recovers. Anyone can run their own indexer from the raw events, but the UI depends on the official instance.
No fee refunds for invalid inscriptions
If you pay 10 MON and the inscription is rejected by the indexer (malformed JSON, supply exhausted, insufficient balance), the fee is not returned. The contract has no knowledge of indexer-level rules.
No partial mints
If a ticker has 500 tokens remaining in supply and you try to mint 1,000, the entire mint is ignored — you don't receive 500. Always check remaining supply before minting.
Ticker squatting is possible
Any address can deploy any ticker that hasn't been registered yet. There is no DNS-style authority mechanism — if someone deploys 'usdc' before you, it's taken. Check the Explorer before deploying.
Transfers to wrong addresses are irreversible
MON-20 transfers cannot be undone. If you send to a typo'd address, the tokens are permanently inaccessible if the recipient has no private key access.
Testnet risks
Monadinals currently runs on Monad Testnet. Users should be aware of the following testnet-specific constraints:
- Testnet can be reset at any time by the Monad team, wiping all inscriptions and balances
- Testnet MON has no monetary value and can be obtained from the Monad faucet
- Contract addresses will change when moving from testnet to mainnet
- The indexer may experience gaps or delays during testnet instability
- Protocol rules and fee structures are subject to change before mainnet launch
This is testnet
Compared to ERC-20 tokens
MON-20 inscription tokens are fundamentally different from ERC-20 tokens. If you are coming from an ERC-20 background, be aware of these differences:
| Feature | MON-20 | ERC-20 |
|---|---|---|
| DeFi composability | None (no Solidity interface) | Native |
| Balance proof on-chain | Not available | Available |
| DEX trading | Requires marketplace layer | Works natively |
| Wallet display | Manual import required | Auto-detected |
| Contract upgrades | New contract address | Proxy possible |
| Indexer dependency | Required | Optional |
| Transfer cost | 10 MON + gas | Gas only |
Known issues
The following known issues exist in the current v0.1 protocol and are planned for resolution before mainnet:
- No EIP-712 structured data signing — payloads are submitted as raw calldata strings
- No batch inscription support at the contract level — repeat minting sends N separate transactions
- Explorer may show stale data for up to 2 seconds after a block is confirmed
- My Inscriptions page requires manual refresh to show newly received transfers
- No ENS or Monad Name Service resolution — only raw hex addresses