Routing accounts

[shortthefomo]

Take a step back from smart contracts and their core function is logic routing at the payment level. 2% here and 98% there.

Request is simple and straightforward. Allow a special type of account on XRPL to define 2 payment addresses and a % for sum of 100%. A extra nice to have would be allow 1 x token and 5 of y.

These optionally can be blackholed and be permanent. But now one can chain payment flows, with no user interaction except the up front logic set.

The cost of such an account could also be reduced or not.

[shortthefomo]

To be clear 100% of funds hitting this account are forwarded on arrival to specified addresses at the %'s defined up front.

[shortthefomo]

An example usecase

1. A simple donation to an entity that needs to pay a fee to someone else.

2. A legal contract that defines payment %'s say for business owners.

3. Royalty payouts. Could be used as efficient token distribution mechanism. Every XRP routed sends x of token. (Not a requirement to the initial routing request but a nice small enhancement)

4. Paying members of a DAO. Here we simply chain multiple routing addresses together to get a % payment to each member.

Payments with out routing is difficult todo without self custodial issues. A locked logic gate makes auto payments simple.

[nixer89]

this can be achieved through Hooks, as far as I know. (splitting a incoming payment). Looping in @RichardAH

[RichardAH]

These are some of the common usecases for Hooks indeed.

[shortthefomo]

While I like hooks and the possibilities it will bring to the table. The reality is, they are a long way off, there is additional risk in that proposal with the programmability aspect. So the review and timeline to something like hooks is going to be a long road.

Here we get some of that program ability through a simple up front lock. Much simpler to review and get into the current code stack.

[wojake]

I would like to see this feature as well but I don't see a need to rush this, there's no large demand for such feature on a protocol-layer (since it's easy to program this feature on a hook). I think we can wait for the Hooks amendment to pass for this functionality to be a reality on the XRPL as per the demand for it is very low. Unless, there's a sudden influx of demand for it (unlikely) and the Hooks amendment is not ready, then go for it.

But I think this feature is more suitable on Hooks, as they're flexible: What if the entities involved in a routing account only want a 20% cut for payments above 100 XRP? What if they don't want any cut for payments below 1 XRP? What if they don't want any cut in accounts that are on a whitelist/blacklist?

there is additional risk in that proposal with the programmability aspect - lathan

Well, we could create standards (e.g: ERC20). If the native escrow feature isn't introduced to IOUs on the XRPL, we could create a standard for that as well. I could accualty see a future where the XRPLF would create/maintain standards for functionality on Hooks, maybe call them XSP (XRPL Standard Protocol)

[nbougalis]

This is an interesting proposal but there are a LOT of quirks to work around/think about.

Interaction of these "routing" accounts with things like offer crossing, for example.

[shortthefomo]

Idea is to make this simple as possible for the current code stack. If that means a new account type or reuse the existing one that decision is up to the implementation.

Having ability to lock up front a payment out to two set addresses. Is very rudimentary routing, but a very useful building block for anyone on the network. It's rudimentary nature is what's great.

It could also be a totally new account type created and locked forever, aka seed gets mutated by chain to lock user out once routing is defined. Or possibly this could even be it's own object type... really the option to define the route and have the ledger execute it is all that is needed.

Maybe this could be thought about when looking at the light accounts?