Proposal: SetFreezeTransferRate

[whotooktwarden]

Please see https://forum.ripple.com/viewtopic.php?f=1&t=18307

Please discuss why specifically this may not be feasible due to technical & legal reasoning.

[nbougalis]

The linked page has the following post:

I propose that the next amendment for the RCL be an upgrade to rippled that allows Ripple Gateway Operator(s) to send an AccountSet transaction which will freeze the ability of the Gateway to change its TransferRate. This would allow Ripple Users to know if the Ripple Gateway intends to choose to have the choice of changing their fee structure for trades and payments sent over the Ripple Consensus Ledger in which an issuance is used within one of the aforementioned transactions. This would allow Gateways to choose to guarantee to their clients that if they choose to perform their business under such a fee structure that it cannot change from that issuing address ever.

If such an account setting was implemented, then for a Gateway to reasonable change their fee structure when/if it becomes either too expensive for Ripple Users to consider using the Gateway's IOUs due to the set TransferRate or if the Gateway notices that the revenue stream is no longer feasible with this issuer then they may choose to allow their Ripple Users to transfer their balances to a new issuing account with a new issuing address. I am not proposing that the rippled team of developers at this time consider creating a method that allows their Ripple Users to transfer their IOUs to a new issuer as this may have complications in some legal jurisdictions.

Therefore, I propose that if a Gateway were to choose to change their TransferRate fee schedule, then they would require their Ripple Users to KYC themselves, transfer the balances to the 'old' issuer, and then have the operator send the same asset class redeemed to the client over the new issuing account. It is noteworthy that some Ripple Users may wish to keep their issuances on the 'original Gateway' and perhaps attempt to build paths to the new issuing account's/accounts' issuances.

Please tell me that this is not a viable proposal...I want to hear someone tell me one good reason why to not implement this feature within the next major release. Discuss.

I don't see why such an amendment would not be technically possible, although I'd relax the requirements: this flag, if set, I prevent the gateway from increasing the transfer rate. But I don't know that any gateway would set this flag (see TickSize).

If someone wishes to do a PR for this, that's awesome; we'd review and, if it passes muster, we'd merge it. But I don't see Ripple's team investing development resources to code this up.

P.S.: For future reference, to ensure that the relevant information is easily available, please outline your actual request here instead of linking to a third-party resource.

[whotooktwarden]

It is a shame to hear that the team will not have the time to investigate this for the time being. If I had the skills to pull this off, I would devote the time to do so, I am just not up for the task unfortunately.

I hope this stays on your guys' radar because it is so very important to have this feature available if I were ever to follow through with the idea of creating a Ripple-based Real Cash Economy Game (please Google Mindark and Entropia Universe for the best reference within the genre) I would require that I could promise to players that there are rules for when the operator of an address may change their TransferRate.

I would also like to propose now that you brought up the mention of the TickSize setting to also consider a Freeze flag for this as well...I need it too for my use case to ever become viable.

Thanks for your time and for your consideration at least. I will be sure to link and share the content next time I raise an issue. I would like it if this could not be closed though and say "this is not happening because of resources" so that others may have the opportunity to lend there voice to this discussion.

[nbougalis]

I've tagged this as a "Feature Request" and I'm happy to leave it open if anyone wishes to discuss this feature.

[whotooktwarden]

I would also like to make the assertion that I support the original concept within my proposal. I do not think I have to explain why, I believe you may come to the same conclusions I do if you think about why I would require such a "draconian feature" to be available.

EDIT: Sorry for the moodiness. The avatar rubs off on you... https://i.imgur.com/fhJMQ0x.gif

[nbougalis]

I would require that I could promise to players that there are rules for when the operator of an address may change their TransferRate.

You can make the promise today if you are content with having a fixed maximum supply and don't require deflationary semantics. Let's say the IOU is FOO and the maximum amount is 100,000,000.

1. Create two accounts A and B.
2. Have B trusts A for 100,000,000 FOO.
3. Have A send 100,000,000 FOO to B.
4. Have A set its RegularKey to rrrrrrrrrrrrrrrrrrrrrhoLvTp or some other "special" address for which no associated secret key is known to exist; and finally
5. Have A disable its master key by doing an AccountSet and specifying the asfDisableMaster flag.

At that point the A account can no longer be used and so no more FOO can ever be issued. The B account can be used to distribute FOO in accordance with whatever model you want or need.

[MarkusTeufelberger]

I'd rather see currency specific objects (#2609) implemented first, before overloading AccountRoot objects even more (these settings really are not a property of an account, but of an issued currency!), but I see the appeal for such a solution.

[whotooktwarden]

No, I am not happy with a fixed maximum supply for this specific use case, but thanks for providing me with this idea as an option in the meantime. The only thing I care about is that the setting of this flag is absolute just like it is with SetNoFreeze so that an issuer promises it will never be able to freeze a trust-line's issuance(s).

[intelliot]

Closing due to inactivity. If anyone is still interested in this, please re-open, or open a new issue.