Payment Forwarding to improve Security between Hot and Cold Wallets

[GAFO]

Summary

The payment forwarding feature should make it possible to automatically forward a percentage of incoming payments to another wallet. This would require 3 new flags/parameters:

• destination address of forwarding (FA)
• amount in percent for each incoming payment (FP)
• enabled

Motivation

This feature would enable exchanges and FIs to directly forward a part of incoming transactions from a hotwallet to a coldwallet without the need to access the keys through a extern solution. This would also simplify security to a new level.

Solution

An example would be: User A, B and C send 1000 XRP to an exchange by a given hotwallet address X. A -> 1000XRP @ Dtag: 0123 -> X, recv: 1000 B -> 1000XRP @ Dtag: 0124 -> X, recv: 1000 C -> 1000XRP @ Dtag: 0125 -> X, recv: 1000

Based on those transactions the exchange can credit the amounts to the specific users as usual. But as we have seen in the past, many exchanges got hacked in some way and funds within their hotwallets were partially or fully lost because they didnt send parts of incoming payments directly to an coldwallet.

Thatswhy X has now set Y as a forwarding coldwallet with a percentage of 60. Then the flow of each transaction would look like the following: A -> 1000XRP @ Dtag: 0123 -> X (FA=Y, FP=60), recv: 1000, fwd: 600 -> Y, recv:600 B -> 1000XRP @ Dtag: 0124 -> X (FA=Y, FP=60), recv: 1000, fwd: 600 -> Y, recv:600 C -> 1000XRP @ Dtag: 0125 -> X (FA=Y, FP=60), recv: 1000, fwd: 600 -> Y, recv:600

That would mean that on each incoming transaction 60% of the amount is automatically sent to the coldwallet Y. By implementing this feature the exchange can scan incoming transactions like usual on X and the XRPL takes care of the security.

This would simplify a natural security need for every participant on the XRPL. Be it the big exchange/FI based on the example above or the regular user who just wants to use the feature to redirect a percentage of his incoming payments to a savings wallet/account.

Greetings GAFO

[WietseWind]

Heads up / FYI: @RichardAH built an example Hook to do this with Hooks :)

[GAFO]

Heads up / FYI: @RichardAH built an example Hook to do this with Hooks :)

That’s interesting, but still - correct me if I’m wrong - way more complex and work reliant than submitting one transaction with 3 parameters & done. Surely hooks have their use cases but the suggestion above is more of an addition of a basic security need as simple as possible so anyone can use it effortlessly without knowledge reliant steps.

Nonetheless I will check the possibilities with the hooks. :)

[ximinez]

The enabled flag is redundant. If a user wants to disable forwarding, they can remove the info entirely. Alternately, they can set the FP percentage to 0.

[GAFO]

The enabled flag is redundant. If a user wants to disable forwarding, they can remove the info entirely. Alternately, they can set the FP percentage to 0.

Yes that makes sense, a null check regarding the FA or a zero check of the FP would end up being the same. Good point.

[intelliot]

This feature would enable exchanges and FIs to directly forward a part of incoming transactions from a hotwallet to a coldwallet without the need to access the keys through a extern solution. [...] But as we have seen in the past, many exchanges got hacked in some way and funds within their hotwallets were partially or fully lost because they didnt send parts of incoming payments directly to an coldwallet.

Actually, the best practice would be to have all deposits sent directly into the cold wallet. You can learn more here:

A cold wallet to securely hold the majority of XRP and customers' funds. For exchanges, this is also the address to which its users send deposits. To provide optimal security, this account's secret key should be offline.

https://xrpl.org/list-xrp-as-an-exchange.html

[GAFO]

This feature would enable exchanges and FIs to directly forward a part of incoming transactions from a hotwallet to a coldwallet without the need to access the keys through a extern solution. [...] But as we have seen in the past, many exchanges got hacked in some way and funds within their hotwallets were partially or fully lost because they didnt send parts of incoming payments directly to an coldwallet.

Actually, the best practice would be to have all deposits sent directly into the cold wallet. You can learn more here:

A cold wallet to securely hold the majority of XRP and customers' funds. For exchanges, this is also the address to which its users send deposits. To provide optimal security, this account's secret key should be offline.

https://xrpl.org/list-xrp-as-an-exchange.html

The „best“ practice is not something which works the „best“. It’s just something theorists come up with. - You need to consider several things like maintaining liquidity for withdrawals which would not work well in reality due to (heavy) market movements. If you would send all directly to an coldwallet and a lot of users want to withdraw you run into troubles. Means you then have to bring a part of all the money which goes directly to an coldwallet back to the hotwallet. And ofc we know that it’s better to access coldwallets as less as possible. So you need to find a balance between both of them e.g. by percentage forwarding which can be dynamically adjusted depending on the market conditions.

Also do not forget that crypto is a fast developing market which leads to many exchanges open. Providing a simple way of security benefits not only the exchanges/FIs but also regular people who use them and in private as well.

All IMO of course.

[intelliot]

Agreed. However, some exchanges have also lost funds by losing access to their cold wallet. You always want to have access to the cold wallet and to have a robust and secure procedure for moving funds from the cold wallet to the hot wallet. A good practice would be to keep track of your exchange's typical withdrawals in a specific timeframe, e.g. 1 week, and project the anticipated needs for the upcoming week. Once per week, you move funds from the cold wallet in order to meet anticipated withdrawals for 1 week. If the hot wallet is compromised, you cannot lose any more funds than what is needed for 1 typical week of withdrawals. Also, if the hot wallet is compromised, you really want users to be making their deposits directly into the cold wallet, so that no further funds can be lost. (Popular exchanges have a steady inflow of deposits, so a system that automatically sends funds to a hot wallet could potentially result in higher losses if the hot wallet is compromised.)

Of course, you can include a modest buffer (e.g. keep 50% more than what you need for a typical week's withdrawals) to avoid running out of hot wallet funds. You should also have alerting in place so that you'll know when funds are low, before they actually run out. If the hot wallet does run out of funds, it may indicate a compromise, in which case you should audit your transaction history to ensure that it matches with your internal database and does not contain any suspicious activity. In this case, you want withdrawals to be paused, because there is some kind of unusual activity. If the issue is caused by a legitimate increase in withdrawal demand, you can top up the hot wallet and take that growth into account when projecting the next week's withdrawals.

That said, I am in favor of this feature request. It sounds useful, albeit potentially dangerous if misused.

[GAFO]

Agreed. However, some exchanges have also lost funds by losing access to their cold wallet. You always want to have access to the cold wallet and to have a robust and secure procedure for moving funds from the cold wallet to the hot wallet. A good practice would be to keep track of your exchange's typical withdrawals in a specific timeframe, e.g. 1 week, and project the anticipated needs for the upcoming week. Once per week, you move funds from the cold wallet in order to meet anticipated withdrawals for 1 week. If the hot wallet is compromised, you cannot lose any more funds than what is needed for 1 typical week of withdrawals. Also, if the hot wallet is compromised, you really want users to be making their deposits directly into the cold wallet, so that no further funds can be lost. (Popular exchanges have a steady inflow of deposits, so a system that automatically sends funds to a hot wallet could potentially result in higher losses if the hot wallet is compromised.)

Of course, you can include a modest buffer (e.g. keep 50% more than what you need for a typical week's withdrawals) to avoid running out of hot wallet funds. You should also have alerting in place so that you'll know when funds are low, before they actually run out. If the hot wallet does run out of funds, it may indicate a compromise, in which case you should audit your transaction history to ensure that it matches with your internal database and does not contain any suspicious activity. In this case, you want withdrawals to be paused, because there is some kind of unusual activity. If the issue is caused by a legitimate increase in withdrawal demand, you can top up the hot wallet and take that growth into account when projecting the next week's withdrawals.

That said, I am in favor of this feature request. It sounds useful, albeit potentially dangerous if misused.

The more you explain the more features I would come up with, like a rebalancing feature in set intervals which considers the percentage in both hot and cold wallet. (naturally with a safety mechanism that a hacked hot wallet can’t empty out the cold wallet by rebalancing) That said this would get out of hand so better stick with the suggestion above. ;)

As for the actual suggestion I’ve just noticed the obvious with your explanation aka FA needs to be excluded from the forwarding scan on incoming payments. Otherwise payments from the cold to hot wallet would go partially back.

Regarding the misuse (e.g. the hot wallet gets hacked) it would eventually make sense that a enabling is bound to a ledgerwide timeframe of 1-3 days. Then the attacker can’t change the forwarding fast enough before the exchange/FI/person notices a FA set transaction & can counter with measures that way. Aka no funds can be falsely forwarded to a shady actor.