Skip to content

Latest commit

 

History

History
36 lines (35 loc) · 4.34 KB

checklist.md

File metadata and controls

36 lines (35 loc) · 4.34 KB
Raw

BRC-20 indexing checklist

  • Inscriptions must have a MIME Type of "text/plain" or "application/json". To check this, split the mime type from ";" and check the first part without strip/trim etc.
  • Inscription must be a valid JSON (not JSON5). Trailing commas invalidate the function.
  • Leading or trailing spaces/tabs/newlines are allowed (and stripped/trimmed).
  • JSON must have "p", "op", "tick" fields where "p"="brc-20", "op" in ["deploy", "mint", "transfer"]
  • If op is deploy, JSON must have a "max" field. "lim" and "dec" fields are optional. If "dec" is not set, it will be counted as 18. If "lim" is not set it will be equal to "max".
  • If op is mint or transfer, JSON must have an "amt" field.
  • All op and field names must be in lower case.
  • ALL NECESSARY JSON FIELDS MUST BE STRINGS. Numbers at max, lim, amt, dec etc. are not accepted. Extra fields which haven't been discussed here can be of any type.
  • Numeric fields are not stripped/trimmed. "dec" field must have only digits, other numeric fields may have a single dot(".") for decimal representation (+,- etc. are not accepted). Decimal fields cannot start or end with dot (e.g. ".99" and "99." are invalid).
  • Empty string for numeric field is invalid.
  • 0 for numeric fields is invalid except for the "dec" field.
  • If any decimal representation have more decimal digits than "dec" of ticker, the inscription will be counted as invalid (even if the extra digits are 0)
  • The Maximum value of "dec" is 18.
  • Max value of any numeric field is uint64_max.
  • "tick'' must be 4 bytes wide (UTF-8 is accepted). "tick '' is case insensitive, we use lowercase letters to track tickers (convert tick to lowercase before processing).
  • If a deploy, mint or transfer is sent as fee to miner while inscribing, it must be ignored
  • If a transfer is sent as fee in its first transfer, its amount must be returned to the sender immediately (instead of after all events in the block).
  • If a mint has been deployed with more amt than lim, it will be ignored.
  • If a transfer has been deployed with more amt than the available balance of that wallet, it will be ignored.
  • All balances are followed using scriptPubKey since some wallets may not have an address attached to bitcoin.
  • First a deploy inscription is inscribed. This will set the rules for this brc-20 ticker. If the same ticker (case insensitive) has already been deployed, the second deployment will be invalid.
  • Then anyone can inscribe mint inscriptions with the limits set in deploy inscription until the minted balance reaches to "max" set in deploy inscription.
  • When a wallet mints a brc-20 token (inscribes a mint inscription to its address), its overall balance and available balance will increase.
  • Wallets can inscribe transfer inscriptions with an amount up to their available balance.
  • If a user inscribes a transfer inscription but does not transfer it, its overall balance will stay the same but its available balance will decrease.
  • When this transfer inscription is transferred (not sent as fee to miner) the original wallet's overall balance will decrease but its available balance will stay the same. The receiver's overall balance and available balance will increase.
  • If you transfer the transfer inscription to your own wallet, your available balance will increase and the transfer inscription will become used.
  • A transfer inscription will become invalid/used after its first transfer.
  • Buying, transferring mint and deploy inscriptions will not change anyone's balance.
  • “fee” and “to” keys were for demo indexing purposes only. Inclusions have no effect on the function nor do they invalidate it.
  • Cursed inscriptions including brc-20 data are not recognized as valid.
  • Brc-20 employs the ord client version 0.14 definition of an inscription with the following stipulations: vindications (new inscription types introduced at the Jubilee are ignored for now) and delegation/encoding features are ignored.
  • Balances sent to unspendable outputs are not returned to sender like with the fee instance. They can practically be considered burnt (notwithstanding a bitcoin update that enables transactions to be created with these keys in the future)

Source: BRC-20 indexing