BurnMaxxing and animalCards updates: Card-deck transparency, minimum burn values, and scheduling of rule/parameter changes

TL;DR by Claude AI: This week's animalCards updates: trimmed the card deck from 128 to 64 cards to speed up rollout, added a test suite to lock in historical card distributions, and built a new page showing the full deck. Added rarity-tiered minimum burn requirements (going live at block #108,954,600) with block-based scheduling so future changes won't disrupt past distributions, plus a table showing current minimums.

Also putting out a call for Steem-based wildlife photographers to contribute public-domain-licensed photos to the card collection, with a possible beneficiary-reward angle for contributors.

---

This week, I extended the animalCards collectibles game that serves as a demo for the "Proof of Burn++ (PoB++)" protocol, aka "BurnMaxxing". Today's post will describe the updates.

Overview

For readers who may be new to the topic, before we get to the updates, we need a short summary of what PoB++ and animalCards are. So let's start with that.

PoB++ / BurnMaxxing

PoB++ / BurnMaxxing is best understood by the catch phrase, "Every block is a bidding war". The "BurnMaxxer" title and corresponding in-game assets for any game can be minted for the account that burns the most in any particular block on the Steem chain.

This can be accomplished by transferring the most STEEM to the null account, transferring the most SBD to the null account, or delivering the most beneficiary rewards to null in a single block. The unique aspect of this system is that each new game that makes use of the protocol adds, without limit, to the gaming benefits that players might accumulate throughout the ecosystem.

Steem produces 28,800 blocks per day, so that's 28,800 opportunities per day for players to compete to receive in-game assets.

animalCards

The animalCards collectible card game attempts to demonstrate this concept with a leaderboard, a profile search page, and a new page showing the complete card deck that's currently being distributed.

The image to the right shows today's leaderboard.

Right now, the idea is just a collectible card game for collecting cards and displaying them, but the eventual hope is to make it into a trading card game with a variety of gameplay scenarios. Here is the animalCards repo.

The game also includes a Visibility as a Service (VaaS) module from a separate repo that lets Steem authors and account holders gain additional visibility on the site by burning STEEM or SBD.

Two notes for the current implementation

1. animalCards is only distributing cards for transfers of STEEM and SBD. It is not configured to distribute cards for beneficiary payouts, although that could be added in the future.
2. As long as the generation is labeled: unstable-test, past distributions might still be reshuffled. At this point in the game's lifecycle, card distributions should not be considered permanent. Eventually, that should change.

Recent animalCards updates

With that overview in place, let's review this week's updates to the animalCards game.

Reduced the card deck from 128 cards to 64 cards

The bottom line is that it will take me too long to find and configure images for 128 cards, so I decided that 64 is enough for the first go-around. As a result of the accompanying block-based scheduling change (below), this can be extended again in the future without affecting past card distributions.

Unfortunately, this is very much a "learn as you go" project, so implementing this change made it necessary to reshuffle the cards that were previously distributed. Hopefully, with scheduling now available, this will be the last time that happens, but the current generation is still labeled unstable-test until the deck is fully populated and I'm certain that everything has stabilized.

Added a test suite to verify card stability

"In theory, there is no difference between theory and practice. In practice, there is." -Benjamin Brewster

After everything stabilizes, it will be an ongoing requirement that the past cannot be changed. Up until now, I've been trying to verify that changes were safe by thinking through the impact and spot-checking some cards, but that method is obviously time consuming and inadequate.

Accordingly, this week I created a test suite that can verify that historical card distributions remain unchanged whenever future code changes are made.

Added a page displaying the full card deck that's being distributed

As the json file containing the cards has grown, I'm already starting to see that it's difficult to mentally capture what slots have been filled and what slots are still needed. I was thinking I'd store the current state in a spreadsheet, but that doesn't help the players at all.

So, instead, I created this page to show all of the cards that are currently being distributed.

Added minimum burn requirements and block-based scheduling for backward compatibility

After last week's post, @michelangelo3 raised the possibility of minimum burn requirements in order to prevent bots from dominating the card distribution (as we already see from the remlaps2 post promotion activity).

I had already considered the possibility of implementing minimum burn values and decided against it. My reasoning was that blocks are being produced every 3 seconds anyway, so the storage cost is negligible for dust transfers, and that card scarcity could be managed by retiring cards and replacing them.

However, as I thought through it again, I reconsidered. With cards awarded for STEEM and SBD transfers, there are 57,600 potential cards per day. If there are no minimum burn values, even the rarest of cards might not be very rare. So, while I'm not yet ready to set any minimum burn values, I wanted the capability to be ready. Instead of having a single minimum, however, I decided on a minimum burn value for each of the rarity levels: Common, Rare, Epic, Legendary, and Mythic.

My first (and preferred) minimum burn value mechanism was to track the overall burn history and set the minimum requirements weekly automatically using a Bitcoin style difficulty mechanism. However, I don't think that's really possible if I'm implementing a GitHub Pages-style interface, so I shelved that topic for another day.

Instead, I configured it to be manually scheduled to take effect at a certain block number. This preserves backward compatibility because the program behavior changes before and after the scheduled block number (inspired by blockchain hard-fork mechanisms). So now, the first minimum is scheduled to go into effect at block #108,954,600 - about 9¹/₂ hours from now.

The minimums are set to 0.001 STEEM and SBD for all rarities, so if all goes well, this will not change the cards that would be distributed, but the app will be ready to implement minimums in the future if it becomes necessary.

Added a table showing the current minimum burn requirements

Finally, with the minimum requirements now in place, players need a way to see what they are, so I added a new table in the search page and leaderboard showing the current minimums and the block number of the next adjustment that's scheduled.

One thing to note is that the card distribution is set to cascade, although I haven't tested this, yet. If a player lands in a slot that's eligible for a Mythic card, but they only transfer enough to qualify for a Rare card, they're going to receive a Rare card, not a Mythic. If the player does not transfer enough to qualify for a Common card (or the lowest minimum), then they will be awarded a Generic card.

The current minimum table can be seen in this image.

Call for photos

If any Steem-based photographers want your photos included in the animalCards collection, please let me know. The photos would need to be licensed for public domain usage. However, if you visit the site and mouse over the photographer, it suggests a beneficiary reward to the photographer if people blog about a specific card. In this way, it may be possible for photographers to create new reward streams for their work.

Whatever I can't fill from Steem-based photographers will be collected from public domain sources.

Conclusion and looking ahead

I think that covers all of the major updates from this week.

As detailed in last week's post, I expect to continue expanding this demo application in four phases: 1.) Filling out the card deck and enhancing core functionality; 2.) Integrating with Steem blogging & communities; 3.) Developing a social economy, including card trading; and 4.) Adding an opt-in Wild mode: Possibilities added to expand collections by "breeding" their cards along with risks like virtual forest fires, hurricanes, tornadoes, and floods. Finally, it would be good to extend beyond wildlife and develop a generic card library that developers could use to implement BurnMaxxing based card collections on any topics.

IMO, the big opportunity for Steem here is not the animalCards game, but rather the BurnMaxxing/PoB++ concept that can be deployed by any developer for any game. I invite developers to explore the animalCards site and ask themselves the question, "How could I do it better with my own app?"

Thank you for your attention!