Bitseed Protocol
Bitseed aims to extend the capabilities of the Ordinals protocol, making Inscriptions more conveniently applicable in Fully On-Chain Games and Autonomous Worlds. The Bitseed protocol is inspired by various inscription protocols, including but not limited to BRC20, BRC420, BRC1024, CBRC-20, etc., paying homage to the pioneers.
- Bitseed is a extension framework for the Ordinals metaprotocol.
- Bitseed is also an SFT (Semi-Fungible Token) asset format standard.
- Bitseed is also an asset protocol that supports the leaping between Bitcoin and L2.
The World Originates from a Seed
We believe that any game world can be generated through a Generator and a Seed. This Seed, formed by the hash values of Bitcoin blocks and transactions, ensures that each generated world is unique. Moreover, Bitcoin's UTXO mechanism guarantees that this Seed can only be used once. We can leverage the Seed provided by Bitcoin to generate assets, props, characters, and worlds within the game.
SFT (Semi-Fungible Token) is the Best Representation of Assets in Autonomous Worlds
We consider SFTs to be the best representation of assets in autonomous worlds because they possess the characteristics of both NFTs and FTs, allowing different types of assets to be expressed in the same format. The Inscription format of the Ordinals protocol is highly extensible, and we can define the format of SFTs on Inscription.
The field mapping from Bitseed SFT to Ordinals Inscription is as follows:
| SFT | Ord Inscription | Type | Range | Required |
|---|---|---|---|---|
| protocol | metaprotocol | String | metaprotocol name, eg. bitseed | true |
| op | metadata.op | String | deploy, mint, split, merge | true |
| tick | metadata.tick | String | printable ASCII char | true |
| bid | metadata.bid | String | 32 bytes hash | true |
| amount | metadata.amount | u64 | 1-u64::max() | true |
| attributes | metadata.attributes | Map | false | |
| content.content_type | content_type | String | false | |
| content.body | body | Bytes | false |
Protocol Features
The Bitseed protocol possesses the following features:
- Enhanced Extensibility: Developers can define their own asset generation and issuance rules by writing generators, without needing to hard-code logic within the protocol and indexers.
- Utilization of Bitcoin Block Hash for Randomness: The Bitseed protocol uses the hash values of Bitcoin blocks and transactions as seeds, providing a globally unique random seed that can make applications more engaging. It offers two methods of randomness: one that occurs at the time of inscribe and another within the indexer, enabling gameplay mechanics similar to mystery boxes.
- Higher Block Utilization Rate: Bitseed utilizes the metaprotocol and metadata provided by the Ordinals protocol for data storage, ensuring structured data fields. This approach allows for higher utilization of block space, saving on user fees.
- Richer Asset Representation: The Bitseed protocol can express a wider range of assets.
- An empty
contentandattributesindicate a typical FT (Fungible Token). - If
contentis an image, anamountof 1 signifies an NFT (Non-Fungible Token), while anamountgreater than 1 represents stackable NFTs. attributescan store developer-defined properties, such as the attributes of game props.
- An empty
- Reuse of Ordinals Protocol Infrastructure: The Bitseed protocol extends the Ordinals protocol and can reuse its infrastructure.
Generator
The generator provides developers with a universal extension mechanism. Developers can define their own generation rules by writing a generator, making the Bitseed protocol a versatile inscription protocol. For the working principle of the generator, see Generator.
Protocol Operations
The Bitseed protocol's operations for assets include: Deploy, Mint, Transfer, Merge, Split. For details, see protocol_operation.
How It Works
User Operation Process
- Users select one of their UTXOs to inscribe as the input for the inscription transaction. This input serves as the Satpoint for Ordinals and also as the seed for the transaction.
- The inscribe application call the corresponding tick's generator, with the seed passed as a parameter to the generator, which then generates an output.
- The output is inscribed on Bitcoin according to the standard of Inscription and Bitseed.
Indexer Execution Process
- Indexers listen for Deploy transactions and pre-download the generator program.
- Indexers monitor Mint transactions, verify the content inscribed by the user with the generator to ensure its correctness.
- Validate the total supply and repetition count according to the settings of the Deploy.
- Verify the legality of Merge and Split transactions.
- If the generator provides an
indexer_generatefunction, the Indexer needs to call this function to generate additional off-chain attributes.
Optimization of Indexer Verification through ZK
If the generator is ZK-proofable, users can inscribe their zk-proof after minting, and the generator only needs to verify the zk-proof.
Application Cases
- bits: The first fungible token (FT) of the Bitseed protocol, where the amount obtained for each mint is random based on the Seed,
generator = random(seed,[1000,10000]). - seed: The first textual NFT of the Bitseed protocol, which directly outputs the Seed as attributes.
- A name service based on user input, where the user's input name is output as attributes. By setting the
repeatparameter to 1 during deployment, the uniqueness of the name is ensured. - Whitelist minting based on a Merkle tree, with the root of the Merkle tree provided at the time of user inscription deployment. Users need to provide Merkle proof when minting, and the generator can verify the Merkle proof.
- PoW-based minting, where users need to calculate the PoW result according to the difficulty setting at deployment, and the generator verifies the PoW result.