Economics of DApps?

Say I create popular DApp on Ethereum. Only tokens issued by ICO are able to use the DApp smart contract.

Only those that participate in the ICO or purchase tokens sold on some exchange can interact.

If its a very popular app, how are customers suppose to pay? What will the market forces look like?

How often should new tokens be issued? What’s the way to peg token value to the chain?

Dapps on a blockchain seems like a wasteful idea to me. Better to use the chain for verification of computation rather than for the computation itself. Token issuance, on the other hand, can easily be done on a chain using something like http://peerassets.github.io/WhitePaper/ that is designed to be blockchain friendly and agnostic.

1 Like

Well, that leads to my next question. Say I really want to use ICO to issue tokens for someone to use my api.

I could

  1. Stick with a single blockchain. As a business of the maker of the DApp, would this even make sense? Wouldn’t I want as many people using my DApp and paying via some type of token?

Exceptions would be if the DApp was easily cloneable or I’m target the big whales.

  1. Say I wanted to support multiple blockchains. Any related blockchain tech could somehow interact with my DApp. How would this be possible? Either my DApp would have to do the conversion of tokens issued on other chains, there is a payment gateway, or something else?

What can peerassets do in this case? Can peerassets work across multiple chains? Or would that even make sense?

What would peerassets look like as blockchain agnostic? Can I shift at any given time to a new blockchain? Can I be on multiple chains at once?

You’re confusing DApps with tokens. Applications generally require some computation and serve some function. Depending on the purpose, this can be done off-chain and verified using messages on the chain in a very efficient manner. Token creation is a separate concern, and I’m somewhat confused why you want people to pay for your application using arbitrary tokens instead of just using a currently existing cryptocurrency, or even accepting a host of different cryptocurrencies.

Maybe DApp is not required.

Tokens can be the viewed the same points used in games for example. Or token that is traded by the BAT ICO.

BAT issued 1 billion tokens. . Maybe that is more than enough to prevent people from holding and encourage exchange between publisher and user? though there were many complaints about the 30 sec sold out sale.

The token supply is fixed. So why not capture all the tokens in the beginning then sell them over time as the price increases. The content will most likely be priced according to the quality, though the payout to the users might be variable, though there is an imbalance here waiting to be leveraged by the advertisers. Its kind of strange.

The game developers can accept any cryptocurrency they like at whatever rate they like and issue new game-credits at will using the PeerAssets protocol. The blockchain agnostic bit is useful for the case where the original blockchain fails or is suboptimal for some reason. Think of the blockchain as a public record, allowing the game developers to keep track of who they sold game-credits to (and who those people resold to, and so on) without needing to keep a central server that records every transaction and gives permission to resell (permissionless makes for a more fluid game-credit market). These credits can be consumed via custom rules or sent back to the issuer in order to trigger signals or functions in the game. If the tokens are issued on the Peercoin blockchain at first, but then the game developers decide that the Peercoin blockchain is now unstable, or blocks are full, or the fee is too high, then they can reissue the exact same distribution of game-credits on another blockchain, such as Bitcoin, or Dogecoin, or whatever they think is more stable and cheaper. Then, users can dump their private keys from their Peercoin wallet and import them on the new blockchain in order to recover their game-credits.

I don’t see a need here for an ICO or a fixed game-credits supply. The price is determined by the in-game functionality of the credits and the cryptocurrency rate which the game developers are charging for new credits (as well as speculation on the open market because PeerAssets makes resale permissionless).

In Peerassets the total number of cards issued is fixed, no? So isn’t the token supply fixed? The issuer must generate either a very large deck like with BAT 1 billion, or periodically generate new decks? Or is there another way to avoid the fixed number of cards?

There are several available issuing modes, and you can always invent new ones. If there’s a good reason and application for a new mode, the PeerAsset devs can update the protocol to include it. Currently, we have the following modes:

NONE   // No issuance allowed
CUSTOM // Not specified, custom client implementation needed
ONCE   // Only one issuance transaction from asset owner allowed
MULTI  // Multiple issuance transactions from asset owner allowed
SINGLET // Single (one) card issued from asset owner allowed
UNFLUSHABLE  // No card transfer transactions allowed except for the card-issue transaction
SUBSCRIPTION // An address is subscribed to a service for X hours since the first received cards, where X is the asset balance of the address.

You are thinking of the ‘once’ mode, which has fixed supply. ‘Multi’ would likely be good enough for what you want.

Not sure I saw this when reading the whitepaper. Though I see it in the RFCs.

Might be good to include a brief mention in the whitepaper that there are more than one mode of issue?

What is the difference between ONCE and SINGLET?

How would SUBSCRIPTON work? What service is responsible and where is it running to issue or transfer?

once can mean like i issue 1000 tokens. Single means only 1 token is issued (like for identity cards). Subscription is new, and doesn’t have any discrete applications quite yet. I suggest you try to restrict yourself to understanding ‘multi’ before you try to grasp the more advanced modes.

At most 1 token issued per particular address, not 1 token in total that can be created by asset creator? Is the 1 token transferable?

1 token total. There are a number of applications we have discussed. Again, i suggest you limit yourself to understanding the applications for ‘multi’ as it seems to be more up your alley.

Limit myself? I haven’t every heard anyone say that to someone asking questions about a new protocol before? What does that mean?

The white paper doesn’t mention these modes. The RFCS only provide additional details on subscription. So where is the details on multi that those interested in reading should go?

Not really a good way to promote or encourage use of this Peerassets, if that is the ultimate intention.

These modes have been added since the whitepaper was written and we have not hashed out all the details yet. You asked about a particular application and I proposed a solution that uses PeerAssets. Now you’re asking about these other modes that don’t have to do with the original post, and things that we are still developing. I believe I have already satisfactorily described the way to do an App token using the ‘multi’ mode. The ‘single’ mode is not what you are looking for, so I suggested you not try to focus on that mode when you clearly have a particular concept in mind. I’m sorry if you found that offensive.

‘once’ restricts a PeerAsset to only one card issuance transaction. ‘multi’ allows for multiple card issuance transactions. These modes are declared in the deck spawn transaction.