| rskip | title | created | author | purpose | layer | complexity | status | description |
|---|---|---|---|---|---|---|---|---|
385 |
Bridge method `getEstimatedFeesForNextPegOutEvent` improvement |
12-MAY-23 |
MI |
Usa |
Core |
1 |
Adopted |
| RSKIP | 385 |
|---|---|
| Title | Bridge method getEstimatedFeesForNextPegOutEvent improvement |
| Created | 12-MAY-23 |
| Author | MI |
| Purpose | Usa |
| Layer | Core |
| Complexity | 1 |
| Status | Adopted |
This RSKIP proposes an improvement to how the estimated fee for the next pegout event is calculated in the Bridge contract.
As described in RSKIP271 [1], along with the peg-out batching functionality new methods were added to the Bridge contract. One of these new methods is getEstimatedFeesForNextPegOutEvent(), created so that users can estimate the peg-out fees. This method returns the fees of a peg-out transaction containing (N+2) outputs and 2 inputs, where N is the number of peg-outs requests waiting in the queue. (N+2) because it considers one extra output for the change and one extra output for the peg-out the user would potentially include in the queue.
With the current implementation, when 0 peg-out requests are waiting in the queue getEstimatedFeesForNextPegOutEvent() always returns 0. This can be misleading to users since it is not the correct value.
When there are 0 peg-out requests in the queue, the method getEstimatedFeesForNextPegOutEvent() should return the fees of a peg-out transaction containing 2 outputs (one for the pegout and one for the change) and 2 inputs.
This change is a hard fork and therefore all full nodes must be updated.
[1] RSKIP 271
Copyright and related rights waived via CC0.