Amendment: featureRemit

[dangell7]

High Level Overview of Change

Context of Change

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Tests (you added tests for code that already exists, or your new feature included in this PR)
• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)

[tequdev]

Is it expected that the transaction will succeed if none of the fields sfAmounts, sfURITokenIDs, or sfMintURIToken are specified?

From the code it looks like it will succeed, but it may be appropriate that it will be an error.

It's okay if success is expected.

[dangell7]

Is it expected that the transaction will succeed if none of the fields sfAmounts, sfURITokenIDs, or sfMintURIToken are specified?

From the code it looks like it will succeed, but it may be appropriate that it will be an error.

It's okay if success is expected.

It will create the account if the account does not exist.