Overview
Welcome to the Relics Protocol (⟁), an attempt to enable AMM (automated market making) directly on the Bitcoin L1.
The Case for Relics
On EVM chains and Solana, Automated Market Making (AMM) protocols provide a seamless way to trade fungible tokens on-chain. However, the two major fungible token standards on Bitcoin, BRC-20 and Runes, don’t have in-protocol support for AMM trading or didn’t have from the beginning, what makes bootstrapping liquidity very difficult. They trade similar to NFTs, so that each trade requires a buyer to actively accept a seller's listing, and vice-versa.
This may be sufficient for large cap tokens which are listed on centralized exchanges and have market makers, but for medium and smaller tokens it is hard to bootstrap reasonable liquidity and trading them comes with meaningful friction.
Relics' solution approach
The relics protocol is an attempt to solve this challenge and to enable true AMM directly on Bitcoin L1 by creating a native liquidity metaprotocol for tokens and NFTs.
Main Protocol Pillars
Relics: Fungible tokens on the relics protocol.
$MBTC*: The base token for liquidity pools.
Bonding curve mints: Capture more "value" in liquidity vs. gas fees.
Pools: Once a Relic mints out, an on-chain swap pool MBTC/<RELIC> is created.
Tradable tickers: Tickers like e.g. DOG•TO•THE•MOON are inscriptions itself.
Relics vs. Runes
Runes is a great and simple protocol for fungible tokens on Bitcoin, similar to how ERC-20 is a good token standard for fungible tokens on Ethereum. Relics is more like a mix between a token standard and some application logic.
The Relics indexer is based on the ordinals and runes codebase. We'd like to thank Casey and all Ordinals devs for such a great piece of software!
*$MBTC, a fair trade-off?
MBTC stands for Meme Bitcoin. The name was chosen humorously because MBTC isn’t real Bitcoin. Think of it more as a fungible collectible. Some may argue that using real BTC to bootstrap liquidity would be preferable, but that isn’t possible on Bitcoin L1 right now. Let’s see if it becomes feasible in the future once new OP codes (like OP_CAT) are merged. If so, that would be exciting. Until then, we’re happy to accept the trade-off.
Last updated