Skip to content

Instantly share code, notes, and snippets.

@blue-santa
Created October 11, 2018 15:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save blue-santa/c3fecee0656e4f8cad78060b51a6e168 to your computer and use it in GitHub Desktop.
Save blue-santa/c3fecee0656e4f8cad78060b51a6e168 to your computer and use it in GitHub Desktop.
KMD AC Use Case

In the marketing meeting today, we were trying to create a narrative to visualize what our customers will be doing with CC.

There were a few areas where we ran to the edge of my understanding.

Can one of the devs please help correct this visualization wherever it is inaccurate?

Let's say that I'm a dApp dev and I want to make a card game.

I have my main asset chain. It serves as the underlying currency for performing transactions on the chain. It is not designed to be a high-market cap coin, by itself.

First, a user will install my software, create a pubkey, do a faucetget cc command to get just a small amount of my base currency.

With that, they will then perform a transaction on the network that broadcasts their chosen pubkey (and base58 address), and also the CC-address pairing for that pubkey. This is AddressA-on-MY-asset-chain.

For the player to really get started, they first need to pay me, so they can enter my ecosystem, and for that we uses MoMoM and a CC-based STABLE coin. For players to pay me, and to enter my gaming community, I require that they send me $10 USD worth of a KMD-based STABLE coin. They'll send this from a transparent address, AddressA-on-STABLE, on the STABLE coin blockchain.

Using MoMoM, my blockchain can detect that my address on the STABLE coin received the correct amount. One of my nodes will then automatically send to AddressA-on-MY-asset-chaina starter kit. The starter kit will include X amount of the asset chain currency.

It will also an assortment of tokens. The tokens are like cards in a character, RPG-based card game.

Each token has a set of descriptions and properties, like STRENGTH, STAMINA, BASE-HEALTH, et.c, that affect the token's ability to play against other players.

Now, my user wants to start playing against other players online.

He and another player connect to one of my nodes, and they also connect to each other. My node is acting as an Oracle.

The two players place certain items into a CC-based smart contract (yet to be written?), where the person who wins will receive these items.

Now, they play the card game, broadcasting the data of their decisions to each other. My node simply observes and records the information into my asset chain, making sure all proceeds smoothly.

The game lasts for one hour. During that time, several notarizations of my data make it into KMD, and then into Bitcoin. At the conclusion of the game, all three of the nodes (mine, and both of the playing users), calculate the results and payout the CC smart contract according to the winner.

The player who won now has a collection of new tokens that they can use to play again, while the other player has to start over (and perhaps the payout of items is varied across the game, so it's not just winner-take-all, but rather winner-take-more, and loser-take-less). Out of the technologies above, dPoW is working fairly reliably, MoMoM is online but not thoroughly tested yet, STABLE is still in testing, Oracle is also in testing, Tokens are not in testing, and there is a CC smart contract required to manage the payout according to the results.

Those are the aspects that KMD and the open-source KMD-ecosystem community want to provide to our users.

In addition, the dApp developer will want to write their own unique software to make a beautiful dApp game.

How are we doing in understanding?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment