During the Status Townhall #21 in Prague, I announced two development bounties which I am personally funding. With these, I’m following Cryptowanderer’s proclamation of how Status should “buidl”: By building Status for ourselves, we create tools which are also useful for the people we connect to. Moreover, I see these bounties as a continuation of Oskar’s brilliant SITG series. I amended the series title from “Experiment” to “Implementation” to emphasize my longing for fast progress.
The intention behind the two development bounties is to improve the security and UX of the Status mobile app. The bounties are:
Password Bounty
Reward: 123’456 SNT
General use case (building for others): Implementation of an additional factor besides the current single password increases the security of the assets in the Status wallet.
Finance use case (building for us): The four-eye principle for payments is enforced. In specific, the first person records the payment in Status. The second person can quickly pick up the payment on a second device, review and approve.
Deliverable: Implement a user-friendly two-factor authentication in the Status mobile app, where the second person may control the second factor. At least ETH and SNT transfers need to be in scope. The solution should be pushed to a Status release and become available to everybody.
Subscription Bounty
Reward: 111’111 SNT
General use case (building for others): Subscription to services are enabled.
Finance use case (building for us): Repetitive payments can be automated.
Deliverable: Implement a user-friendly way to subscribe to services in the Status mobile app where the subscriber has to enter the payment information only once, and then payments go out periodically. The subscriber can cancel the subscription at any point in time. He can set the period between the payments by defining the number of days until the next payment. At least ETH and SNT transfers need to be in scope. The solution should be pushed to a Status release and become available to everybody.
If the above specifications cannot be met by the end of November 2019, the bounties are paid out to the creator(s) of the implementations which are closest to the specifications.
Please feel free to ask questions in this thread if you require more information.
Regarding the “Password Bounty”, it seems this can be done using a multisig wallet. Below are some screenshots that show how this works. Would like feedback on if this captures all the expected functionality.
Create a new wallet that will require two signatures for a transaction to be executed with two owners.
Ok great. The above functionality is already implemented in the Gnosis multisig wallet and audited smart contract as shown above.
I have uploaded a slightly modified version of the wallet which allows for better usability directly inside the Status app but still supports using it on it desktop and with hardware wallets.
This version of the multisig can currently be accessed here: Multisignature Wallet - by going to Open DApp in Status then pasting in the link or in any web3 enabled browser.
It supports Mainnet and Ropsten. I suggest the finance team try it out on Ropsten with some sample transactions to see if it meets the current needs. If you need some Ropsten ETH and SNT (STT), you can get it from the faucet by going to: DAPP and clicking on the assets tab.
The wallet supports all ERC20 tokens so using DAI as well should not be an issue.
After trying it out we can discuss if there is anything that should be changed and once it’s in a good place we can have it moved to a more accessible place.
Regarding the subscription bounty, while not mentioned explicitly it seems a key component of subscriptions is being able to target a fiat value such as USD, as requesting the same nominal amount of ETH or SNT sent out periodically seems to have a limited use case. One way to do this is to implement a price oracle for the exchange rates and have that targeted in subscriptions. This will likely be the most complex part of implementation and the most prone to errors as well as being the centralization vector in the design. Another approach is to use DAI in subscriptions which leverages Maker solving for this issue.
Ultimately both can be implemented, but curious to hear finance’s thoughts on this aspect of subscriptions.
Finance has tested the Gonosis multisig wallet as per the description. Person 1 implementing a multisig wallet and having Person 2 access it works. However, after Person 1 implements a transaction, Person 2 does not succeed to retrieve the transaction and thus cannot approve it. The reason is unclear, but it could be due to the fact that the Gnosis multisig was not optimised to fit the small screen of the smart phone and the transaction remains hidden on the screen of Person 2. Let’s schedule a call for a joint review.
Regarding subscriptions, a price oracle would be generally very helpful indeed. A solution could be that the subscriber can set the price himself which is being used as a reference for all of his subscriptions until robust decentralised price oracles become available. The option to set the reference price is also essential as Finance does not rely on a single price but calculates an average of several data points. Is a reference price setting reasonably simple to implement?
Apart from the bounties in place, ideally the password and the subscription functions can be combined at some stage. Additional complexity may arise like the requirement of multi signatures to set the reference price, where one person enters the new reference price and the second person approves it.
It seems possible to have salary or subscriptions accrue on per second, minute, day, whatever time period and the receiving person/organization can withdraw whenever they like as long as Status has funded it’s own account in the contract with enough funds to cover the total accrued.
Status can stop and start a subscription by toggling a recipient status, ACTIVE or INACTIVE.
In this sense, Finance does not need to worry about processing individual invoices monthly, it just needs to set the annual salary and ensure there is enough funds in the contract to meet the accrued obligations. It also benefits the recipients in that they have flexibility in timing payment however they choose.
This is perfectly in line with the Subscription Bounty!
In reference to the use cases defined in the original bounty text, the next steps could be be to:
Support the Finance to implement this subscription function to pay the Status team. The target would be that an ‘average accountant’ is able to handle the function in a meaningful way.
Assess how this function can be generalised to make it available to all users of the Status mobile app and implement the solution.
I suggest to split the Subscription Bounty 50%/50% between the two milestones above.
Again, adding DAI as a payment option is very welcome.
I think this could be a powerful appeal for DApp developers as well as existing apps, relying on a monthly subscription model and wanting to accept crypto. Do you have any specific use cases in mind? Something like Primalbase comes to mind, getting a monthly subscription to a co-working space. I ask because it could help give the implemented bounty an actual use case to demo the work.
This would be awesome, and I think would help drive crypto-adoption as it’s a significant improvement on the traditional “pay monthly” model that most companies use.
What would the average accountant need in an interface? I imagine there should be some kind of export of the data that they can import into their accounting system?
Tools like https://blox.io/ help to pull the required data for accounting directly from the blockchain. This supports the automation of the accounting.
The focus should be on the development of a user-friendly interface to input and manage the payments. Salary payments (subscriptions) may change over time and have to be easily adjustable (or cancelled and re-entered). Ideally, payments could be entered by adhering to the four-eye principle, where one person enters the payment and another one approves it (also see the Password Bounty). Another way to solve the four-eye principle would be to have one person to enter the salary payments which are subsequently funded by a multisig after review and locking of the salary payment entries.
