Call this a thought experiment.
The concept of the ‘SCP Foundation’ contains a numerical reference to paranormal stories/entities. This feels like it could easily be tokenized using crypto, but to what end? Are we just basically talking NFT-like trading cards? Let’s see what properties we have available on blockchains.
In order to keep the user interface extremely simple, we want to avoid using any custom OP_RETURN code. This is appropriate for a goofy, just-for-fun kind of project like this. This means we want to use either PeerAssets-like functionality, or just use the bare transaction to signal what we want.
#PeerAssets
With deck creation under PeerAssets, you have a lot of room for innovation. You can use a central server to issue SCP tokens when any desired user behavior is achieved. Or you can codify it into a new issuance mode. But let’s try to do it permissionlessly without creating new modes. Well, anyone can create a PeerAsset, it’s only validation (i.e. a sense of authority) that requires the central validation server. Again, this is very NFT-like.
#Bare Transaction
A transaction (no OP_RETURN) has a few pieces of data that can be used for games like this.
- Input Addresses
- Input Amounts
- Output Addresses
- Output Amounts
Note that the fee can be calculated from 2 and 4. Each of these values is an array, with the first two and the last two being the same size. We want to avoid demanding anything too stringent, like there must be only 1 input address or the number of outputs must match the inputs, otherwise it’s confusing to the user.
P2TH with a publicly known private-key makes for an underused and still extremely valuable method of hijacking the functions of the standard client for data processing. So one of the outputs goes to a P2TH address, cool. One of the inputs must be a personal address with some coin on it to pay the fee. Leave the rest of the txn open to interpretation, then say that any fee paid over the minimum fee required will generate SCP. But at what address, and how?
One of the complicated bits here is that we are trying to use the output for two things simultaneously. Ideally, it would both trigger an action as well as name the target of that action. We cannot assume anything about ordering or amount of inputs without loss of generality, so we are focused on the outputs. We could use two outputs, but that costs more fee. As such, it seems that OP_RETURN is our only good option.
#Back to PeerAssets
So what if instead of a central entity issuing tokens, we have the individual users issue tokens via PeerAssets, but state that it only ‘counts’ if more than the minimum fee was burned in the txn. In fact, we don’t even have to make a statement of amount in the issuance, as it can be calculated from the bare portions of the txn.
This is, of course, a perversion of PeerAssets and would require some doing. However, the result would be the ability to self-issue a token. The power of an issuance mode like that is intriguing.
#Self-issuance
Any individual broadcasts a spawn txn for a deck type of self-issuance. From then on, anyone may create an issuance transaction without an amount. The amount is calculated using the excess fee of the txn. This can be combined with other limitations, such as ‘once’ or an amount cap to create some interesting paradigms.
The end situation:
The SCP Foundation (or individuals roleplaying as such) spawn decks with variable amounts of rarity. Individuals who want that playing card sacrifice Peercoin to issue themselves the tokens. Eventually, some entities will be bought out and some will not. This could be tied back via user-written stories or rules for a trading card game or what have you.
This type of issuance mode would make fully decentralized PeerAssets issuance possible.