Add RSKIP432

IPs/RSKIP432.md

@@ -0,0 +1,69 @@
+---
+rskip: 432
+title: RbtcSwap
+description:
+status: Draft
+purpose: Usa
+author: (@rmoreliovlabs)
+layer: Core
+complexity: 2
+created: 2024-05
+---
+# RbtcSwap
+
+
+|RSKIP          | 432 |
+| :------------ |:-------------|
+|**Title**      |RbtcSwap|
+|**Created**    |MAY-2024 |
+|**Author**     |@rmoreliovlabs |
+|**Purpose**    |Usa |
+|**Layer**      |Core |
+|**Complexity** |2 |
+|**Status**     |Draft |
+
+# **Abstract**
+
+This RSKIP proposes a mechanism for users to issue normal transactions that pay their own gas but do it at the end of transaction execution, instead of at the beginning.
+
+## Motivation
+
+Often, users receive stablecoins and wish to transact on the Rootstock network but face a challenge: they lack RBTC, needed for transaction fees. Although they may be willing to exchange some stablecoins for RBTC on a DEX, this solution is also hindered because the exchange transaction itself requires payment in RBTC.
+
+This can be solved using RIF Relay, which allows a third party to pay for the transaction. However, this solution requires the use of a special smart-contract wallet that accepts encapsulated commands, so it’s not compatible with any EOA-based wallet.
+
+Another use case is when users receive a signed message or certain message which entitles them to withdraw some RBTC from a certain contract. This is the case of the Boltz Exchange. However, they cannot collect it without issuing a new transaction, and they cannot issue a transaction without RBTC.
+
+Both of these functionalities are considered part of the Account Abstraction meta-proposals, but we aim to address a narrower use case. This RSKIP only solves how to bootstrap a wallet without RBTC. It doesn't solve how to use a different signature scheme for safekeeping the wallet, nor how to use a multi-signature scheme, nor how to do social recovery, nor how to set withdrawal limits, nor any functionality that restricts how the user spends their funds.
+
+## Specification
+
+We could create our own contract, be it native or using Solidity, or we could deploy one that already exists like for
+example the Boltz EtherSwap contract.
+
+Regardless of the choice the contract to use should have the following methods:
+
+Lock: This method should create a claim record by generating a hash using the arguments it recieves and some information from the transaction. The arguments should at least include the claimer address, a preimage hash, the amount to lock and a timelock (a numeric value that indicates the amount of time the funds will be locked, represented in block height). The claim record hash would be generated by using the afore mentioned argument and the depositor address which would be the msg.sender and the amount to be locked sent in the msg.value. The claim record would be stored as a mapping from the claim hash to a boolean.
+
+Claim: This method transfer the funds locked in a claim record after verifying that said actually exist. I would do this by generating a hash that must match the has generated by the Lock method for that record. To generate this hash the method should receive at least these arguments: the preimage hash provided by the depositer, the amount locked in the record, the refund address which is the despositor's and the timelock of the record, the claimer address could be obtained from msg.sender. If a matching hash is found among the claim records stored in the contract, the corresponding amount would be transferer to the claimer account and the claim record would be deleted. On the contrary if not record that matches the hash is found then the method reverts.
+
+Refund: This method would transfer the funds back to the depositor if a record matching the hash generated by it is found and if the timelock has exipired. The arguments for this method should at least include the preimage hash, the amount locked in the record, the claimer address and the timelock, the despositer address could be obtained from msg.sender. If a record with a matching hash is found and the corresponding timelock has expired then the funds are transfered to the despositer account. In case no record is found or the timelock hasn't expired yet then the method reverts.
+
+Before adding the claim transaction to the mempool the mechanism should check if the funds it tries to claim do indeed exist. To do so it would generate a hash using data from the transaction and use it to look for a claim record with a matching hash. If a record is found it would then verify that the amount locked is enough to pay for the transaction, in case it is then the transaction would be included in the mempool but if any of these conditions are not fulfilled then the transaction would be discarded.
+
+The next check would happen during the claim transaction execution, here the mechanism would check again if the funds corresponding the the claim transaction still exists, this validation would cover cases when the claimer manages to get the locked funds by other means (like the ones described in the last section). If the claim record still exists the transaction would be executed but the payment logic would be delayed until after the execution when the funds would have been transfered to the claimer.
+
+## Rationale
+
+The mechanism would only trigger if a claimer tries to send a transaction that calls the Claim method from the contract and doesn't have enough balance in their account to pay for said transaction. This means that regular/funded transactions would not be affected by the changes introduced for this feature.
+
+## Backwards Compatibility
+
+This feature would not be backwards compatible, it would need a hardfork and activation block height defined for each network.
+
+# **Copyright**
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+
+

README.md

@@ -228,6 +228,7 @@ You can find an easily browseable version of this information [here](https://ips
 | 415 |[Fix pegnatories address derivation from public keys](IPs/RSKIP415.md)| 30-JAN-24 | MI | Usa | Core | 1 | Adopted |
 | 417 |[Avoid transactions to be reverted when Bridge method calls from smart contracts return an empty response](IPs/RSKIP417.md)| 28-FEB-24 | MI | Usa | Core | 1 | Adopted |
 | 419 |[Powpeg Spendability Validation Protocol](IPs/RSKIP419.md)| 31-AUG-23 | JD, JZ | Sec | Core | 2 | Draft |
+| 432 |[RbtcSwap](IPs/RSKIP432.md)| 24-MAY-24 | RM | Usa | Core | 2 | Draft |
 
 (*) Under evaluation to be implemented in the next reference client release
 
@@ -265,6 +266,7 @@ You can find an easily browseable version of this information [here](https://ips
 | SM       | Shreemoy Mishra              | [email protected]   |
 | SMS      | Sebastian Matias Sicardi     |                        |
 | VK       | Volodymyr Kravets            | [email protected]  |
+| RM       | Reynold Morel                | [email protected]  |
 
 ## Build locally