Basics:

A standard for fungible tokens using ethereum blobs. The "blobbed tokens" should start a new era for Ethereum blob's mass adopation approach.

Simple Summary

A standard protocol under the blobscriptions for fungible tokens.

Abstract

The following standard allows for the implementation of a standard API for fungible tokens within blobscriptions. This standard provides basic functionality to deploy, mint, and transfer tokens.

Motivation

The Ethscriptions protocol inspires us with another approach for creating and sharing digital objects on Ethereum using transaction calldata. By embedding content directly on-chain, these assets challenge the conventional reliance on off-chain storage, introducing a novel approach to blockchain philosophy.

blobs are the moment where Ethereum scaling ceased to be a "zero-to-one" problem, and became a "one-to-N" problem

With the activation of the Dencun upgrade, this approach heralds a new era. Thanks to Ethscriptions creator Tom's ESIP-8 proposal, we now have another option to utilize blobs for DApp implementation, making it cheaper and more efficient.

Over the past few weeks, the Blobscriptions protocol has emerged a cultivated vibrant communities. Individual developer WGW drafted blob20, while community devs contributed open-sourced code for blob20 indexer and simple wallet manages blob20 assets. We adhere to standardize and finalize the blob20 protocol for further functionality and integrity with the community together, aiming to substantially grow the Blobscriptions ecosystem.

Specification

Metadata Structure

The Blobscriptions protocol is an extension of the Ethscriptions protocol utilizing ESIP-8, this also applies to blob20 protocol. Below is the principle for a valid Blobscription creation.

If an ethscription's creation transaction does include blobs and the ethscription was created via calldata (i.e., not via an event emission), its blobs are concatenated and interpreted as an untagged CBOR object (as defined by RFC 8949) that decodes into a hash with exactly these keys:

• content

• contentType

If the concatenated data is a valid CBOR object, and that object decodes into a hash with exactly those two fields, an attachment for the ethscription is created.

Following this standard, the contentType field of Blobscriptions/blob20 should be application/json. And the content is a CBOR object that's interpreted by the indexer.

For example:

CBOR({
  content: {
    "protocol": "blob20",
    "token": {
        "operation": "transfer",
        "ticker": "BLOB",
        "transfers": [
            {
                "to": "0x0A681F5023de77c24842e7512Ca9b5DA0dE495e6",
                "amount": "10000"
            }
        ]
    }
  },
  contentType: 'application/json'
})

Note: For compatibility with certain older blob20 records, the contentType: 'text/plain' is also accepted by the indexer. However, this usage is deprecated and will be rejected by indexers in the future.

Account-Balance Model

The blob20 protocol employs an account-balance model to track the balance of addresses for each token ticker. For mint operations, the minted amount of tokens is added to the minter's address balance corresponding to the ticker. For transfer operations, the amount of tokens is subtracted from the sender's balance and added to the receiver's balance.

A concept of total_balance and transferable_balance might be applied for future advanced abilities to support DEX usage.

Fungible Token Model

Unlike the Ethscriptions/erc20 protocol, where each erc20 inscription represents "1000" tokens and is tracked by its unique ethscriptionId generated by the mint operation's transaction hash, the erc20 protocol technically underlies a "NFT" or "Semi-FT" model. Each token is unique, yet they all hold the same value of the asset.

The Blobscriptions/blob20 protocol practices the Fungible Token model, allowing you to transfer or sell any amount of tokens you own. Taking $BLOB as an example, regardless of the fact that each minted amount was 1000, you can purchase 300 $BLOB from others and transfer 100.5 $BLOB to your friend.

Decimal

The decimal precision for blob20 tokens is set at 8, which is friendly for development across various programming languages. The deploy operation includes a key for decimals to describe the token's decimal precision; however, this key is actually ignored by the indexer. Regardless of the input value, the indexer will always set the token's decimal precision to 8.

Unique Ticker Rule, FCFS

The indexer permits ticker names to range from 1 to 20 alphabetic letters and is case-insensitive. Setting this upper limit of 20 letters helps avoid some edge-case handling issues, such as potential storage disruptions caused by exceedingly long ticker names in the indexer. If you deploy a token with the ticker BLOB, any subsequent tokens deployed with variations like blob or BLOb will be considered invalid and rejected by the indexer.

Configuration

Token settings should remain as straightforward as possible. Unnecessary complexities can hinder the ecosystem's growth and only serve to confuse developers and communities, especially without comprehensive open-source tools provided.

For potential future protocol expansions, operations like deploy-v2 or deploy-v3 could be implemented and integrated into the indexer to accommodate evolving business logic requirements.

Therefore, we do not currently consider adding settings like start_block or end_block to avoid introducing unnecessary complications to token rules.

Operations

• Deploy

• Mint

• Transfer

Reference Links

Ethereum has blobs. Where do we go from here?

ESIP-6

ESIP-8

Blobscriptions/blob20 draft

Blobscriptions/blob20 open-sourced code