Think of the following scenario: developer A writes a piece of code to be executed as a "smart contract" (distributed, trust-minimized computation). That means redundant execution, or else the "trust minimization" part disapears and then it's just a piece of code like the current-day apps using Hive as blockchain back-end.
The piece of code is advertised by developer A as doing ... something ... However, it is its users who are able to say whether indeed that piece of code does indeed what it claims to be doing ... or whether there has been a misrepresentation (whether accidental or intended) by developer A of its code's utility ...
Yet that "reconciliation" between "what developer A claims" and "what the users experience" can be done only after the code has been executed on several nodes (which has costs). This introduces a notion of "credit".
Normally the users should pay for the code execution. It is up to them to decide how much "trust minimization" they need, i.e. on how many machines the code should run. Perhaps it's just one (as in the current Hive and Steem apps) or perhaps it's 20 machines - knowing that the price will increase proportionnally ...
The price for running the code on a machine should be asked by the machines offering to run it ... so ideally you'll need a market where people with VMs ask various prices to run any given piece of code and then users who want to have that code run come and "bid" for those runs at their respective prices ... or less (the principle of a market ... perhaps the code is not well written and consumes too much machine resources with respect to the perceived utility it provides to users).
Indeed these markets (one per smart contract) should be quoted in a stable coin such as the HBD.
So what I would suggest is to create a "factory" that can instantiate an "internal market", like in bitShares. In hive we only have Hive <-> HBD but here instead of "Hive" anyone would be able to bid and ask for "runs of a given smart contract".
What do you think ?