feat(xrpl): custom definitions support #2683
Conversation
|
Hey there, did you also check #2214 |
| `Invalid field TransactionType: ${tx.TransactionType}`, | ||
| ) | ||
| if (!customDefinition) | ||
| throw new ValidationError( |
There was a problem hiding this comment.
Can this check the list of transactions in customDefinition instead of never erroring?
There was a problem hiding this comment.
Or maybe validate should be skipped entirely in the custom definition case?
There was a problem hiding this comment.
Can this check the list of transactions in
customDefinitioninstead of never erroring?
I like this idea. I will add it.
There was a problem hiding this comment.
Or maybe
validateshould be skipped entirely in the custom definition case?
I thought about it, but then I thought there were other checks that might be useful.
There was a problem hiding this comment.
Or maybe
validateshould be skipped entirely in the custom definition case?I thought about it, but then I thought there were other checks that might be useful.
True, but there may be new transactions that break those checks.
Just a thought - I don't have a strong preference on this.
Co-authored-by: Mayukha Vadari <[email protected]>
High Level Overview of Change
In previous versions, custom definition support was added to the
ripple-binary-codecmethods but not the proxy ones in thexrplpackage.This PR adds support for Custom Definitions to the following
xrplmethods:utils.encodeutils.decodeutils.encodeForSigningWallet.signContext of Change
When using custom definitions, you had to directly use the
encode,decode, andencodeForSigningmethods fromripple-binary-codec. Those features can now be used via the proxy methods in thexrplpackage.Custom definition support has also been added to the
Wallet.signmethod which wasn't the case before.Type of Change
Did you update HISTORY.md?
Test Plan
Added 2 unit tests for:
Wallet.sign(single signature)Wallet.sign(multisignature)