Approve the Operations Workstream with the creation, control, and oversight of a new multi-sig wallet created for recieving payments for the new exchange api.
Abstract:
With the focus of Engineering and Product turning to to the new exchange api service, the DAO will need to be able to receive payments for tiered usage of the api. Consumers will be able to pay the DAO in crypto for their usage. It is not ideal to have all of these payments be made directly to the treasury. A 2 of 3 multi-sig controlled by Operations would allow the DAO to receive funds across multiple chains and to periodically send collected funds to the treasury at appropriate intervals.
Motivation:
Specification:
This proposal seeks community support in authorizing Operations to generate a multi-sig ETH address via Gnosis Safe that will be a 2 of 3 multi sig wallet, of which the signers will be @Tyler | ShapeShift , @Tshifty, and @MBMaria. This wallet will be ETH based for now but should be updated and optimized for multi currency payments for the exchange api services. This new address would be na addendum to the current DAO multi-sig addresses that can be found here: https://forum.shapeshift.com/thread/dao-treasuries-and-multisigs-43646
Budget:
No budget increases are being asked for with this proposal, If passed, the administration of this multi-sig will become another responsibility of the Operations Workstream.
Drawbacks:
Introduces an additional address to the DAO’s growing list of public addresses/multi-sigs. Requires continued trust in the Operations Workstream being good actors with DAO funds.
Benefits:
Allows a separate address for exchange api payments that can be transferred to the DAO and removes complication of all payments being sent directly to the main treasury address.
I support this. Operations is the best owner for this new multi-sig. As I understand it, funds will be regularly transferred to the main DAO wallet, and there will be few funds in this wallet at any given time.
Ok, so metaforo is super buggy today, I’ve hard reset, and I just posted this with three questions and no spaces in between and it posted it with a ton of weird spacing.
Should we have multiple workstreams involved in this?
How will we handle if a multi-sig needs to be replaced?
How often will the periodic sends be to the treasury? I think that laying this out explicitly will help the DAO better track revenues here, as we run into the issue with other revenue streams that aren’t consistently being sent, IE: onramping. Once a month? Once a week? Once a Quarter? At a certain Dollar threshold?
Should we have multiple workstreams involved in this?
Heh, I was about to post this idea, without getting too fancy with this, spreading the trust/concerns over the multiple Workstreams seems like a good idea as long as people are available when needed of course.
When I heard about it in the call yesterday it also reminded me of SCP-135, which has not been followed by actions after it passed the vote (as far as I know). The TSSC (Treasury Signer Selection Committee) we were meant to establish could maybe do this task in interim, until the actual signers for the DAO are selected?
EDIT: Oh and I forgot, Thanks @TylerShapeShift for putting this proposal together so quickly and opening the discussion!
I’m in favor of the operations workstream spinning up new multisigs to receive revenues generated from the ShapeShift API (worth calling it the ShapeShift API instead of exchange API to make it clear that this includes unchained and potentially other services as well). I suggest specifying some additional authorities for the Ops workstream so consent is clear and additional proposals aren’t required:
Authority to create and manage these ⅔ safes on any EVM on which the API generates revenues
Authority to convert earned revenues into stablecoins or FOX
Authority to transfer a percentage of revenues generated from an integration to the corresponding integration partner (ie. in the case of the exchange API where one possible business model is to give partners the ability to add fees and retain a % for ShapeShift)
One other potential thing to consider to future proof this, which I hope isn’t necessary, is to give the Operations workstream leader the authority to replace a signer that leaves the operation workstream with a new contributor to the operations workstream. While I can see some of the pros of having this responsibility spread across multiple workstreams, I think the benefit of keeping this responsibility within a single, tight-knit workstream is worth the tradeoff, and until the revenue numbers are significant, any risk is limited.
One idea to mitigate this risk that could also be specified is for the Ops workstream to commit to transferring revenues to a DAO Treasury on either a monthly basis or within 48 hours of the balance of a safe exceeding $10,000, whichever comes first.
@Fireb0mb1 SCP-135 is making good progress. the TSSC was formed, deliberated, and last Friday elected the new signers. The current signers are in the process of onboarding and transferring responsibilities to the new signers. to your point though, the community should be updated with progress and given a heads up that the owners of each safe/multisig will soon be updated
Oh wow, awesome to hear about the progress! Yeah updates are welcome for sure, since the identities of signers are kept secret it makes sense to only announce it when it’s done.
Do you think these signers could/should be involved this current idea for the multisig? Or maybe just one of them that isn’t related to the Operations WS? I’d like to be clear that I don’t mind Ops having full power over this, I trust them, I’m thinking about attack scenarios and mitigation of trust through separation of concerns as a general principle.
If it’s too impractical (frequent operations would be the main factor in my opinion) then I’d totally understand if that route wasn’t chosen though.
I appreciate all of the feedback and questions presented so far. I’ll address them in the order they were posted.
I am not opposed to it but I don’t think that would be the most expedient answer or one that is necessary for this specific task. I believe this multi-sig should have a streamlined process that does not further incumber the DAO with another group requiring meetings like many of the committees currently formed. Keeping the multi-sig with all Operations contributors allows the coordination of sends to be just an additional responsibility of current contributors that are already familiar with gnosis safe, and have already been handling DAO assets in testing since the formation of the DAO without incident.
This question is also lightly addressed later by @willy in his response and might be more fully answered later in my responses to his. At a high level, multi-sigs can be adjusted by the address that created them through the Gnosis safe interface. This can allow for changes in the amount of required signatures or the addition or removal of any other signers. If the the wallet is compromised, a new wallet can be spun up at only the cost of gas for the generation of the new multi-sig.
Good call out, I think having both a monthly or quarterly send and/or a ‘send when wallet balance exceeds x’ rule in place here make the most sense. Initially there will not be much funds being sent in to this address, and all funds will be transferred to the treasury regularly.
I am unsure of the current intended ShapeShift API tier pricing and the amount of initial consumers that we have lined up to pay for it, but feel that any USD$ amount thresholds for sending to the treasury should be in line with maintaining all monthly payments made for API usage to the DAO are accounted for in the treasury address for monthly revenue measurements in accordance with SCP-142
@Fireb0mb1 - I do not believe decentralizing the multi-sig among other workstreams makes this process any more efficient and does not suit the need/priority of this flow here. There is a lot already being asked of treasury signers and I don’t feel this multi-sig is of the same level of importance and ask of focus and attention like the tasks required of signers in [SCP-135]. If the DAO feels the TSSC should be the ones to additionally decide on the multi-sig signers for this address, I will support that decision, but ultimately I believe this feels like an Operational task and is best performed within the workstream.
I believe we may want to make this language chain agnositic so all forms of multi-sig addresses can be spun up for any type of crypto paid for services. great addition.
Authority to convert earned revenues into stablecoins or FOX
I would prefer a direct base asset for all payments to be received/sent to the treasury as. I do not know what has been established for our payment requirements for the API but a specific asset expected as received by the treasury can be converted before sent if desired by the DAO, additionally all assets could be transferred as received if preferred or the process becomes cumbersome. )
-Authority to transfer a percentage of revenues generated from an integration to the corresponding integration partner (ie. in the case of the exchange API where one possible business model is to give partners the ability to add fees and retain a % for ShapeShift))
All that would be required to make this an additional responsibility for Operations here would be the tools to monitor consumption of the api and the outlined %s set in any usage agreements.
One idea to mitigate this risk that could also be specified is for the Ops workstream to commit to transferring revenues to a DAO Treasury on either a monthly basis or within 48 hours of the balance of a safe exceeding $10,000, whichever comes first.
I like how monthly lines up with the monthly revenue goals we are trying to hit and agree that a balance threshold for transferring should be enacted. Without knowing what the pricing for usage is, it’s hard for me to know what this number should be but some amount in the $5-10k seems reasonable to me.
Thanks for the answer, somehow I had missed it in my email notifications. I now understand the more operational nature of this process, and agree that in this case it might not be useful to involve the TSSC.