stellar-protocol
stellar-protocol copied to clipboard
stellar
Feature request: Enhanced conditional logic for multisig and transactions
feature request
My startup is trying to build licensed securities as smart contracts on Stellar. We have a working proof-of-concept for an asset-backed-loan on the Stellar test net. However before we can move to the livenet there are a number of features not currently available that we need to figure out a way to provide.
In the recent Stellar 2018 roadmap post it was mentioned that one of the top priorities is SDEX and getting more financial instruments like the ones I am trying to build onto stellar. During the process of building our POC I found that there are a number of features currently missing that prevent Stellar from fully being used for this purpose.
I'm willing to help contribute to the development of these features but I've only been working with the Stellar api a few weeks so I would really appreciate some guidance so that I can contribute in a way that is in harmony with the current spirit of the stellar codebase.
I see a lot of potential in stellar with trustlines, the ability for anybody to issue an asset, and pathfinding. Stellar can be much more than just a cryptocurrency. With the changes I am requesting Stellar will be able to support a much wider ranger of financial instruments and I am hoping I can get some assistance and advice in how to implement them.
Things I am looking for:
-
More granularity with the security thresholds. For example I can set different thresholds for different operations, but all payments count under the same operation. So I can't for example authorise an employee to be able to sign transactions up to a total of 10k usd per month, and if he wants to go above that he needs another sig. Or another usecase would be to authorise the employee to make any transaction that exchanges btc for usd, but if he wants to transfer usd out of the account he needs to get another sig. I know some of this functionality can be approximated by using multiple accounts. But I think this is not a great solution, as for non developers it is very hard for them to keep track of all these accounts, especially if you are trying to sell a security on stellar and every time you transfer a security you transfer 4-5 accounts at the same time and the amounts in those accounts are all changing programatically over time.. it is not ideal.
-
Right now you can make an offer that exchanges one asset for another asset, but you cannot make an offer for a transaction that contains multiple operations. Jed talks about one way to implement securities in his blog (http://jedmccaleb.com/blog/bonds-on-stellar/) and in this blog he talks about "signing and making public a transaction" but not submitting it yet. AFAIK there isn't really a marketplace for transactions yet? Maybe that is already on the roadmap for SDEX? The ability to make an offer for a transaction instead of just a basic token swap would be very useful for many types of financial instruments. This part doesn't necessarily have to be on chain but I think it would be nice for SDEX to be able to provide this functionality.
-
Right now you have to specify the amounts that are to be transferred in the transaction at the time that the transaction is created and signed, not at the time that the transaction is submitted. So for example if I want to sell a bond that contains eth-backed tokens as collateral, and it's supposed to make monthly repayments of usd based on the exchange rate between eth and usd at the time of the payment, there isn't really a way to do that. Another example use case is if I have a financial instrument that is supposed to pay out based on a floating rate based on some index.
-
Also while there is some conditional logic that is possible by creating multiple transactions with the same sequence number, currently whichever transaction gets submitted first is the one that gets accepted. It would be nice to be able to specify more conditional logic on what allows a transaction to be submitted other than the time bounds. An example would be a transaction that can only be submitted if the eth/usd exchange rate goes below a certain threshold.
Let's wait for core team comments but I added a few now.
More granularity with the security thresholds. For example I can set different thresholds for different operations, but all payments count under the same operation. So I can't for example authorise an employee to be able to sign transactions up to a total of 10k usd per month, and if he wants to go above that he needs another sig. Or another usecase would be to authorise the employee to make any transaction that exchanges btc for usd, but if he wants to transfer usd out of the account he needs to get another sig. I know some of this functionality can be approximated by using multiple accounts. But I think this is not a great solution, as for non developers it is very hard for them to keep track of all these accounts, especially if you are trying to sell a security on stellar and every time you transfer a security you transfer 4-5 accounts at the same time and the amounts in those accounts are all changing programatically over time.. it is not ideal.
Why not create an application that checks these conditions and if everything's correct it appends another signature? I wouldn't say whole world needs to know what are your conditions for making transfers and this would be true if all of them are on chain. Your clients/users just want to have money in their accounts.
You can pick weights so that transaction will be fully signed when exactly X employees and the signing app add their signatures. Looking at your conditions (amount limits, time limits, permission to transfer certain assets) it seems that it can complicate the thresholds model substantially.
Right now you can make an offer that exchanges one asset for another asset, but you cannot make an offer for a transaction that contains multiple operations.
I don't understand. Do you mean exchanging asset A to B, B to C and C to D atomically within a single operation? We have path payments, wouldn't it help?
So for example if I want to sell a bond that contains eth-backed tokens as collateral, and it's supposed to make monthly repayments of usd based on the exchange rate between eth and usd at the time of the payment, there isn't really a way to do that.
I need more information about this but wouldn't market-buy/market-sell help here? The offer can be posted at a specific time (time bounds on a transaction) and will be executed at the market price.
It would be nice to be able to specify more conditional logic on what allows a transaction to be submitted other than the time bounds. An example would be a transaction that can only be submitted if the eth/usd exchange rate goes below a certain threshold.
Why not post an offer that will execute when such condition occurs?
You can pick weights so that transaction will be fully signed when exactly X employees and the signing app add their signatures. Looking at your conditions (amount limits, time limits, permission to transfer certain assets) it seems that it can complicate the thresholds model substantially.
This is a solution that I have not considered before and I will think about it, it does solve many problems but not all.
The basic issue is that the signing app is not on the blockchain, hence it does not have the honesty guarantee that comes with being on the blockchain. Since the signing app is just regular code, there is nothing that prevents the app from getting hacked or me from being a malicious actor and just stealing my client's assets and transferring out. If the signing app doesn't have enough of a threshold to send the payments by itself, you just have to hack it and also bribe an employee.
I don't understand. Do you mean exchanging asset A to B, B to C and C to D atomically within a single operation? We have path payments, wouldn't it help?
No, I am referring to the "Manage Offer" operation. Right now that can only be used for situations exchanging 1 token for another token. It would be nice to be able to create a complex transaction involving many operations and multiple parties, and then offer it. Since payments is only one operation out of many, and a transaction can contain many operations that are not payments, path payments is not applicable in this case.
I need more information about this but wouldn't market-buy/market-sell help here? The offer can be posted at a specific time (time bounds on a transaction) and will be executed at the market price.
If you look at Jed's blog about one possible way to implement bonds at http://jedmccaleb.com/blog/bonds-on-stellar/ basically the only way to do it right now you have to create all the transactions at the time the bond starts operating. After the bond is sold, the signing rights to the account are destroyed so you cannot make any other transactions. This is the way to guarantee that the conditions of the bond will be fulfilled and nothing else can be done with the assets in the account. If you think of an alternate way to implement this though please let me know, your idea about the the signing app isn't bad and I am going to think about more ways to use that.
The basic issue is that the signing app is not on the blockchain, hence it does not have the honesty guarantee that comes with being on the blockchain. Since the signing app is just regular code, there is nothing that prevents the app from getting hacked or me from being a malicious actor and just stealing my client's assets and transferring out. If the signing app doesn't have enough of a threshold to send the payments by itself, you just have to hack it and also bribe an employee.
The same things could happen if this was on-chain. In your first message you said:
So I can't for example authorise an employee to be able to sign transactions up to a total of 10k usd per month, and if he wants to go above that he needs another sig.
So there will be another person with more power and there are many bad things that can happen to him/her too. How would you know how much 10k USD is really worth in terms of BTC - you'd need an oracle that also can be hacked (more later in my comment). What I'm trying to say is that moving everything on-chain for the sake of being on-chain if you can have hybrid solution which is also decentralised but more flexible doesn't always make sense to me.
No, I am referring to the "Manage Offer" operation. Right now that can only be used for situations exchanging 1 token for another token. It would be nice to be able to create a complex transaction involving many operations and multiple parties, and then offer it.
I'm still not following (sorry). Why not add multiple manage_offer ops to a transaction? Can you elaborate?
If you look at Jed's blog about one possible way to implement bonds at http://jedmccaleb.com/blog/bonds-on-stellar/ basically the only way to do it right now you have to create all the transactions at the time the bond starts operating. After the bond is sold, the signing rights to the account are destroyed so you cannot make any other transactions. This is the way to guarantee that the conditions of the bond will be fulfilled and nothing else can be done with the assets in the account.
I read your first message once again and the only difference I see between "Jed's bonds" and your solution is that you want to make the amounts dynamic (based on eth/usd price). This means you need an oracle /external data source that will feed your contract with current eth/usd market rate. This is (IMHO) equally safe as multisig account that will be used to send payments because oracle(s) can also be hacked.
On Fri, Feb 9, 2018 at 3:27 AM, Bartek Nowotarski [email protected] wrote:
So there will be another person with more power and there are many bad things that can happen to him/her too. How would you know how much 10k USD is really worth in terms of BTC - you'd need an oracle that also can be hacked (more later in my comment). What I'm trying to say is that moving everything on-chain for the sake of being on-chain if you can have hybrid solution which is also decentralised but more flexible doesn't always make sense to me.
Not necessarily. For example I might want a manager who has no power to make payments at all, but can authorise the employee to make payments after exceeding a total transaction volume of 10k a month. So the employee could have a security weight of 2 and it takes a threshold of 2 to be able to make payments at all, but a threshold of 3 to make payments after exceeding the 10k limit, and the manager has a weight of 1. But this just highlights another weakness of the existing system, because I would probably want the manager to be able to change the quantity of the limit, it might even be a dynamically changing number based on a margin value calculated by the current value of the securities that are being held, and that is an operation that should probably be a high threshold operation but I still don't want the manager to be able to make any payments by himself at all.
I'm still not following (sorry). Why not add multiple manage_offer ops to a transaction? Can you elaborate?
If you look at Jed's example of the bond, I am saying I would like a way to offer the bond for sale. And given the list of operations that are required in the transaction that would create the bond and create the monthly payment transactions and then transfer ownership to the buyer of the bond, that cannot be satisfied by multiple manage offer ops. You can't offer the monthly payment transaction either. Even if you could, that's not what you would want to do in this particular use case.
I read your first message once again and the only difference I see between "Jed's bonds" and your solution is that you want to make the amounts dynamic (based on eth/usd price). This means you need an oracle /external data source that will feed your contract with current eth/usd market rate. This is (IMHO) equally safe as multisig account that will be used to send payments because oracle(s) can also be hacked.
Yes pretty much the only difference is I want to make the amounts dynamic, so it is something that is doable and also needs to be done, because the vast majority of securities that matter will need this ability to make the amounts dynamic.
I don't know if oracles are necessarily the only solution. I like stellar so far because it is full of simple elegant solutions to complex problems. Maybe if we think about it a bit more we can find a better solution than oracles. But even if we have nothing better to go with than oracles, oracles are still an improvement. The reason is that the liability for getting hacked will be on the owner of the oracle, not on the smart contracts developer. The oracle code for let's say the eth/usd market rate will be it's own contained thing, it can be vetted by a highly skilled security expert, and it probably doesn't have to change very often. The oracle could be owned by an organisation large enough to handle the liability issues, like an exchange, a bank, or a high profile anchor. This lowers the barrier to entry for newer programmers to start using stellar for smart contracts.
Hey @LoganGoh,
If you're still interested in pushing this forward, I'd suggest reviving the thread on our public dev mailing list, and submitting a draft proposal. If you're not, let us know and we'll close this out.
Hi I've moved on to a different job and currently I don't have the time to work on this. I really do hope someone takes on this project though as it would greatly increase the range of what can be done with stellar.
On Tue, 12 Mar 2019, 6:01 AM Johnny Goodnow, [email protected] wrote:
Hey @LoganGoh https://github.com/LoganGoh,
If you're still interested in pushing this forward, I'd suggest reviving the thread on our public dev mailing list, and submitting a draft proposal. If you're not, let us know and we'll close this out.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stellar/stellar-protocol/issues/77#issuecomment-471753698, or mute the thread https://github.com/notifications/unsubscribe-auth/AiNDJl7SC5s27RPsf_GCvnsjEp858n-Gks5vVtIsgaJpZM4Rxty3 .