🤓How It Works
Paws up, Shiba Scout! 🐾 Please make sure to chew over these important points:
Avoid sending inscriptions to taproot addresses that aren't Doginal compatible. That's like sending your dog to fetch a ball you never threw!
Trading balances might not play well with existing marketplace infrastructures. Remember, under no circumstances does the transfer of a mint function result in a balance change.
Each transfer inscription is like a one-time fetch command; it can only be used once.
The first ticker to be deployed claims the name - like the fastest pup to the toy! Remember, tickers don't care about uppercase or lowercase (DRC = drc).
If two events happen in the same block, the order of confirmation in the block decides who fetched first.
Mint a transfer inscription to yourself first to secure your balance.
For public drc-20 mints, we're following the 'first fetch wins' approach, just like bitcoin punks / .sats names.
The mint function and the second step of the transfer function are the only actions that that cause changes in balances.
The first mint to go over the max supply gets the fraction that's within bounds. Imagine a 21,000,000 toy limit, 20,999,242 toys in circulation, and a 1000 toy mint inscription = 758 toys added to the game.
Mint function inscriptions don't need padding!
Spending a Doginal on transaction fees is like throwing a toy that doesn't exist. If it happens during the inscription process, we'll just ignore it. If it happens during the second phase of the transfer, it's like the toy comes back to the sender's pile.
You can't have more than 18 decimals (default), just like you can't split a dog toy into infinite pieces.
Our standard is limited to uint128.
The max supply can't go over uint64_max.
Last updated