Introduction:
I am looking to get feedback on the idea of implementing the Payment Stream Contract into the Livepeer Explorer when submitting a new Treasury proposal.
Currently, there are two SPEs using the payment stream contract.
The contract has been audited and was built to accommodate specific features for the Livepeer Treasury, most notably, the ability for two elected guardians to terminate the payment stream and return any remaining funds back to the Treasury in a trust-less and transparent way.
The goal of this forum post is the gauge interest in updating the UI of the explorer to include a seamless interaction with the payment stream contract for both proposers and guardians.
Implementation:
1. Add button to switch to Payment Stream option
2) On the Payment Stream tab, add three additional fields and modify the Create Proposal button
When the create proposal button is clicked, it would prompt two transactions.
First, it would call the createStream function to deploy the stream using the Payment Stream Factory Contract.
Params would include the five fields that the user inputted.
- payee = LPT Receiver Field
- duration (in seconds) = Duration Field x 24 x 60 x 60
- termSigner1 = Guardian 1 Field
- termSigner2 = Guardian 2 Field
- paymentAmount = Amount Field x 1000000000000000000
The two last params would be static.
- paymentToken = 0x289ba1701C2F088cf0faf8B3705246331cB8A839
- termReceiver (Livepeer Treasury) = 0xf82C1FF415F1fCf582554fDba790E27019c8E8C4
Once the transaction is complete, the logs will contain the paymentStream address.
The second transaction would use the newly created payment stream address and submit a regular treasury proposal.
3) Add claim button for receiver
Upon opening the specific treasury proposal, we can check if the proposal is using a payment stream contract, if so, we can read the contract and see if the payee is the current logged in user.
We can then display a claim button for that user which would write to the contract the claim function.
We can also display stats like claimedAmount and getClaimableAmount.
4) Add terminate for guardians
Again check if the proposal is using a payment stream, we can query termSigners with the current logged in user. If the user is a guardian then we can display a terminate button that calls the terminate function. We can also display termConfirmations.
Conclusion:
I believe this could be an elegant way to include a payment stream option directly into the explorer.
As a final thought, there could be a discussion of the downsides of using a streaming contract. For instance, if you have a one year stream, you will lose out on the staking rewards that a lump sum proposal would get. With the current rate of return nearing 50%, I think as a community we might consider the loss of staking rewards as a sacrifice for enabling all the benefits of using a stream contract (ie Accountability, Voter fatigue, Price impact etc). Maybe we could offset that loss with a premium on the asking amount. Just some thoughts to help prompt discussion.
As always, thank you for reading and contributing to the most powerful open and decentralized video infrastructure in the world!
Titan