0079 XLS-79d: Transaction Fee RPC #225
tequdev
started this conversation in
Standard Proposals
Replies: 2 comments 2 replies
-
|
Beta Was this translation helpful? Give feedback.
0 replies
-
IMO this should follow the same parameter style as |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
1. Abstract
Fees required for a transaction to be accepted into the network depends on the type of transaction and network conditions.
Currently some client libraries such as xrpl.js calculate Fees based on the type of transaction and its fields, but this proposal extends Fee RPC to provide a specification for calculating the Fee required by a transaction without a client library.
Furthermore, in a multi-chain ecosystem with the XRPL protocol, it would be ideal to have multiple networks available in one client library, and even if the network's own transactions require special fees (e.g, for Memo fields or other dynamic fields), it should be possible to obtain the fee.
2. Overview
Add a
tx_blob
field to the already existingfee
RPC request and modify it to return the Fee information required for transactions in this field to be accepted into the network.This change does not require an Amendment because it is only an RPC change that does not affect consensus or transaction processing.
3.Fee RPC Specification
3.1. New Request Fields
Add a new optional field to the existing Fee RPC request:
tx_blob
string
If
tx_blob
is not included, the RPC behaves as per the existingfee
RPC specification.Requirements for the
tx_blob
:SigningPubKey
field is required but can be empty(""
).Fee
field is required but can be zero("0"
).TxnSignature
field is optional and should preferably be omitted.3.2. New Response Fields
No change in the response field.
However, if the request field contains
tx_blob
, fields inresult.drops
will be values to which the following are taken into accountAccountDelete
,AMMCreate
,LedgerStateFix
)Fulfillment
field ofEscrowCreate
3.3. Error Cases
The RPC should return appropriate error messages for invalid or malformed
tx_blob
inputs.4. Example
4.1. Request
Decoded tx_blob
4.2. Response
5. Backwards Compatibility
This proposal is backwards compatible as it only extends the existing
fee
RPC without modifying its current behavior whentx_blob
is not provided.Beta Was this translation helpful? Give feedback.
All reactions