Skip to content
This repository has been archived by the owner on Aug 1, 2023. It is now read-only.

App Stacking #229

Open
njordhov opened this issue Jan 28, 2020 · 10 comments
Open

App Stacking #229

njordhov opened this issue Jan 28, 2020 · 10 comments

Comments

@njordhov
Copy link

njordhov commented Jan 28, 2020

Financing development of Blockstack apps through bitcoin payouts from Stacking.

This proposal introduces a major leap from the current app mining, funding app development from the App Mining treasury by leveraging the proposed Stacking algorithm with its PoX transfer of Bitcoin, while creating a decentralized economy where the funding gets directed to the most promising projects:

  1. Stacks holders invest in the progression of promising apps by Stacking their holdings with the team, locking up their Stacks for a limited duration.
  2. App developers receive regular Bitcoin payouts from the Stacking.
  3. Investors get rewarded through bounties from the App Mining treasury when milestones are achieved.

Qualifying apps compete for funding; The amount each app team receives for each monthly tranche depends on how many Stacks holders they can attract to fund their progress and the risk taken by these investors. Qualifying apps obviously can't be evil and may also have to satisfy other requirements to participate.

Mechanism

  1. The Blockstack ecosystem announces bounties for reaching defined app/business milestones.
  2. App teams register their intent to reach the milestone by a determined time limit.
  3. Stacks holders commit to Stacking their holdings to fund a qualifying app for the milestone.
  4. Each reward period the app team receives the Stacking bitcoin payouts.
  5. When the app team completes the milestone, their investors divide the bounty.
  6. Investors regain control of their Stacks upon completion or timeout.

The core of this process would be implemented as a Clarity smart contract.

Exit Events

As illustration, here are some examples of potential bounties for reaching milestones:

  • $2K for apps that achieve a TMUI average of at least 80%;
  • $3K for apps that get a cumulative 200K Reach score from credible press;
  • $10K for apps with TBD evidence of early product-market fit.
  • $20K for app teams getting accepted for an interview by Y Combinator;
  • $30K for app teams achieving seed funding of $100K or more;

Bounties can be paid out in Stacks and/or Bitcoin.

Describe your long term considerations in proposing this change.

App teams don't get the bounties directly, but depends on Stacks holders in effect voting for them through App Stacking, providing regular bitcoin payout to fund their progress.

The Stacks holders take a risk in not getting the bounty if the team fails to reach the milestone, and thus have incentive to be selective and supportive. This makes Stacks holders vested in the quality and progress of the apps, creating an economy where the funding gets directed to the most promising projects. It may also provide an additional incentive to participate in Stacking, providing a stabilizing effect.

Additional context

This proposal is blocked by SIP-007 not yet being implemented.

#227 App Mining by Work and Investment
#222 Deployment of capital via world's best investors
#174 Release Notes Reviewer
#169 Proof of evolution/activity
#138 Proof of progress reviewer

@pstan26
Copy link
Contributor

pstan26 commented Jan 28, 2020 via email

@lrettig
Copy link

lrettig commented Mar 11, 2020

I wonder if the DAICO model could be relevant here. In particular, the idea that the backers of a project have the ability to reduce the "tap" amount, or turn it off completely, if they are dissatisfied with the progress.

@pstan26
Copy link
Contributor

pstan26 commented Mar 15, 2020

Coming back to this with a different spin:

  • Extend Proof of Transfer to App Chains (forward STX to mine App Coins with their own respective App Chains).
  • Foundation uses App Mining treasury to pay apps that hold the most STX (could be ok to have some human judgment involved)
  • Pay the Apps via quadratic funding Switch App Mining to Quadratic Funding model #236

Bonus: what if we incorporate this as a game on testnet? Could imagine a fun names like “Stacking Web 3”

@njordhov
Copy link
Author

njordhov commented Mar 15, 2020

Foundation uses App Mining treasury to pay apps that hold the most STX (could be ok to have some human judgment involved)

Note that the App Stacking proposal creates a market that encourages human judgment by Stackers in deciding which app projects to fund. The core idea of App Stacking can be applied in many ways, but will work best when there is a designed mechanism/market and a resulting economy that align incentives to create positive outcomes.

@pstan26
Copy link
Contributor

pstan26 commented Mar 15, 2020

Perhaps my only issue with your original proposal (which I really loved) is that the incentive of investors is not to pick projects carefully, but rather to define the bounties and whether they are hit or not. This creates a “playing for the test” dynamic happening at the investor level if governance is compromised, perhaps even a little.

Perhaps the most objective way to do that is to fund Stable coins first.

@pstan26
Copy link
Contributor

pstan26 commented Mar 15, 2020

Something @jcnelson has suggested regarding App Chains and their processes that I think are related and interesting here:

Thought 1
Open-source projects use an app chain to:

  • maintain a record of who's a developer and can sign releases
  • maintain a record of who's willing to pay XXX for a PR to be accepted, or an issue to be addressed
  • offer a project-specific payment medium (i.e. the app chain token), which only the developer(s) can mint.

Thought 2:
Sustainable [app] token-incentivized operation of a Radiks server could look like a combination of the following:

  • An app creates a smart contract for registering radiks servers. Anyone can run a radiks server, so long as they (1) register the IP address in the smart contract, (2) put a security deposit down, which can be stoken if the server equivocates about state, and (3) structures its index as an append-only merkle tree out of hashed indexed data (so, the leaves are hashes of the things getting indexed). Then, if the server equivocates -- i.e. it serves Alice one view of the index and Bob a different, conflicting view of the index -- then if Alice and Bob figure this out, they can steal and split the security deposit by submitting the merkle proofs from the index that show that the Radiks server equivocated (i.e. there is a fork in the append-only merkle tree). This keeps Radiks servers honest. Radiks servers can get their deposits back after a time-out if they are honest.

  • This can be combined with an encrypt-and-sell scheme, whereby a Radiks server operator makes money via a (separate) smart contract by (1) building up the index, (2) encrypting series of it (e.g. every hour's indexed data; ever 100 entries; whatever), and (3) allowing anyone to buy the encryption key via the smart contract. The smart contract would act as an escrow -- (1) the radiks server would post the hash of the encryption key, (2) the user would post the payment, and (3) in order to claim the payment, the radiks server submits the key. The contract ensures that the user's funds are only given to the server operator if the key hashes to the on-chain hash (or, the user can claw the funds back after a timeout).

  • By doing these two things, we can make it so any app can have an open-membership fleet of radiks servers working to index users' gaia-hosted content, we can make it so those radiks servers can be discovered automatically by the app client (i.e. by querying the smart contract), we can make it so radiks servers can be kept honest, and we can make it so radiks server operators can make money.

@njordhov
Copy link
Author

njordhov commented Mar 15, 2020

Perhaps my only issue with your original proposal (which I really loved) is that the incentive of investors is not to pick projects carefully, but rather to define the bounties and whether they are hit or not. This creates a “playing for the test” dynamic happening at the investor level if governance is compromised, perhaps even a little.

@pstan26 The app stacking design provides incentive for investors to pick projects carefully, but there will always be a risk that black hats rig a system in their favor if they have the opportunity. The ground mechanism should thus be resistant to being gamed.

In the App Stacking proposal, if a bounty is overly easy to reach, more investors will stack on the app developer until their share of the bounty reflects the risk.

Hence, assuming governance is somewhat compromised, developers more than investors have reason to influence the choice of milestones so they give out larger bounties than deserved for the efforts. This could be countered with a mechanism instituting that multiple teams divides the bounty for a milestone, causing the bounty share for each app to adjust until it better reflects the risk, payout and effort.

Perhaps the most objective way to do that is to fund Stable coins first.

What do you have in mind? Tell more!

@dantrevino
Copy link

Blockstack announces bounties for reaching defined app/business milestones.

How do we do this without needing a centralized entity defining what is desirable?

@njordhov
Copy link
Author

njordhov commented Mar 16, 2020

How do we do this without needing a centralized entity defining what is desirable?

Good question. I'll change blockstack to blockstack ecosystem in the proposal as defining what is desirable shouldn't have to be centralized.

@pstan26
Copy link
Contributor

pstan26 commented Mar 28, 2020

Perhaps my only issue with your original proposal (which I really loved) is that the incentive of investors is not to pick projects carefully, but rather to define the bounties and whether they are hit or not. This creates a “playing for the test” dynamic happening at the investor level if governance is compromised, perhaps even a little.

@pstan26 The app stacking design provides incentive for investors to pick projects carefully, but there will always be a risk that black hats rig a system in their favor if they have the opportunity. The ground mechanism should thus be resistant to being gamed.

That is a big should . Potentially not easy, I saw App Mining turn normal community members into folks looking to game (fine), so I'd expect this adversarial behavior here as well.

In the App Stacking proposal, if a bounty is overly easy to reach, more investors will stack on the app developer until their share of the bounty reflects the risk.

This still assumes somehow enforcement (policing bad actors) is obvious and easy. Because the award is not coming directly from the stacker, folks are still incentivized to direct as much of the award into their own pocket in ways that are more and more clever...

Hence, assuming governance is somewhat compromised, developers more than investors have reason to influence the choice of milestones so they give out larger bounties than deserved for the efforts. This could be countered with a mechanism instituting that multiple teams divides the bounty for a milestone, causing the bounty share for each app to adjust until it better reflects the risk, payout and effort.

Whether you have multiple teams or just one, the game can still be compromised. Also developers can and likely would be "investors" on eventually(even immediately), which makes no difference how many teams need to exist..the sybil persists.

Perhaps the most objective way to do that is to fund Stable coins first.

What do you have in mind? Tell more!

Yea so I wouldn't encourage this and don't think we should do this, but if you said you're looking to track one objective measure and reward its growth, a set of stablecoins would be a fairly objective thing to measure and reward. The rewards could create a competition for most value a stablecoin could represent/hold.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants