You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
People can't pay for things that Stackerstan has created.
Solution:
Implement the revenue distribution parts of the protocol.
The Mindmachine SHOULD provide the next payment address on request, and then update it's state when paid.
It's probably easiest/simplest to just implement this as part of the Shares Mind.
For on-chain payments this is relatively straight forward. For Lightning this could be done with NIP57 or possibly just a LNBits API.
Here's how things should work according to the protocol
Goal: There are no financial honeypots for charismatic personalities to exploit. 5fd7d6
Goal: Participants who decide to become Shareholders are not motivated to do so by an expectation of value derived from a Cantillion effect. cf1374
Goal: Revenue is distributed to Shareholders in the most fair and honest manner possible. 8da28d
Search the Stackerstan Superprotocolo for 8f326926d15fc8dbc5ea26e6ef0e05881fac7f8bd452db11fd906be91bbb3ae6.
Stackerstan generates revenue by creating Products and Services that solve valuable problems such that there is a market for their use.
Any fees charged by Stackerstan Product(s) MUST be denominated in Satoshi and paid in a form of Bitcoin that can be settled as a UTXO (on-chain or LN).
Participants with Shares own ALL revenue generated by Stackerstan Products.
Revenue generated by Stackerstan MUST be immediately distributed to Participants. Revenue MUST NOT be retained by Stackerstan.
Stackerstan MUST NOT raise any funds.
Revenue is distributed to Participants with Shares and Expenses in the most fair and honest manner possible.
Every Participant with Shares or Expenses MUST specify at least one Bitcoin payment address and one LNBits type endpoint which can be used to request an Invoice and poll for a completed payment.
Payment for Stackerstan products/services goes to the next-payment-address - this is the next Bitcoin address, LNBits endpoint (or later maybe a BOLT-12 offer) selected by the algorithm described below.
The user who is making a payment for a Stackerstan product/service is presented with the next-payment-address. Depending on the amount this will be a lightning invoice or a Bitcoin address.
Payment is distributed to Participants by algorithmically rotating through the global set of payment addresses to find the next-payment-address.
The idea is the payments will be relatively small and increasingly frequent, so by iteratively selecting the next payment address we end up with a situation that is similar to splitting all payments but without requiring any custody of the funds.
At present, there's reason to hope that Stackerstan will at some point generate revenue, but this is 100% hypothetical and unknown. Let's take a hypothetical situation where Stackerstan starts generating revenue in 2 years time:
Some people have been working on the project for the previous 2 years to get it to this point, holding onto their shares the whole time. They need to agree that the payment algorithm is fair for them.
Other people will have only just heard of the project, and start making their first contributions and begin accumulating their first Shares only after the model has been proven to work. They also need to agree that the payment algorithm is fair.
To be fair to people in both situations, we have created an algorithm that repays Expenses in order of oldest to newest Expense, as well as paying dividends to Shareholders in the order that they aquired the Shares, but also mixes this in with evenly distributed dividends to Shareholders regardless of the age of a Share so that it's still fun for newcomers.
There are three modes of Revenue distribution:
Repayment of Expenses: Revenue is directed to the Account with the oldest Expense that has not yet been repaid.
Untimed Dividends: Revenue is directed to the Account with the least amount of Dividends paid per Share thus far.
Timed Dividends: Revenue is directed to the Accout with the oldest Share that has recieved less than the average dividend per share so far.
All revenue is directed to repayment of Expenses unless >50% of all Expenses have been repaid.
If >50% of all Expenses have been repaid, incoming payments round robin between repaying Expenses (3 times), Untimed Dividends (1 time), and Timed Dividends (1 time).
The text was updated successfully, but these errors were encountered:
Problem:
People can't pay for things that Stackerstan has created.
Solution:
Implement the revenue distribution parts of the protocol.
The Mindmachine SHOULD provide the
next payment address
on request, and then update it's state when paid.It's probably easiest/simplest to just implement this as part of the
Shares
Mind.For on-chain payments this is relatively straight forward. For Lightning this could be done with NIP57 or possibly just a LNBits API.
Here's how things should work according to the protocol
Goal: There are no financial honeypots for charismatic personalities to exploit. 5fd7d6
Goal: Participants who decide to become Shareholders are not motivated to do so by an expectation of value derived from a Cantillion effect. cf1374
Goal: Revenue is distributed to Shareholders in the most fair and honest manner possible. 8da28d
Search the Stackerstan Superprotocolo for
8f326926d15fc8dbc5ea26e6ef0e05881fac7f8bd452db11fd906be91bbb3ae6
.Stackerstan generates revenue by creating Products and Services that solve valuable problems such that there is a market for their use.
Any fees charged by Stackerstan Product(s) MUST be denominated in Satoshi and paid in a form of Bitcoin that can be settled as a UTXO (on-chain or LN).
Participants with Shares own ALL revenue generated by Stackerstan Products.
Revenue generated by Stackerstan MUST be immediately distributed to Participants. Revenue MUST NOT be retained by Stackerstan.
Stackerstan MUST NOT raise any funds.
Revenue is distributed to Participants with Shares and Expenses in the most fair and honest manner possible.
The text was updated successfully, but these errors were encountered: