Add ledger_entry options for fee, amendments, NUNL, and hashes by ximinez · Pull Request #5644 · XRPLF/rippled

ximinez · 2025-08-01T19:41:45Z

High Level Overview of Change

Adds ledger_entry functionality for global record-keeping objects, with some flexibility.

Also will always return the hash for any valid ledger_entry request, even if the object is not found or valid.

Context of Change

While doing some analysis, I was annoyed that I couldn't look up these records without computing their indexes or finding them on the ledger_entry documentation page.

Type of Change

New feature (non-breaking change which adds functionality)
Tests (you added tests for code that already exists, or your new feature included in this PR)

API Impact

Public API: New feature (new methods and/or new fields)

Before / After

Affects the Amendments, FeeSettings, NegativeUNL, and LedgerHashes objects.

Before:

These objects could only be found using, for example, "index" : "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4" for Amendments.

Additionally, if an object is not found, only the error is returned.

After:

These objects can be found in multiple ways:

Using the format of other ledger objects, like accounts, but the only valid value is true or the valid index of the object: "amendments" : true. e.g. "amendments" : true.
1. Amendments: "amendments" : true
2. FeeSettings: "fee" : true
3. NegativeUNL: "nunl" : true
4. LedgerHashes: "hashes" : true (For the "short" list. See below.)
Using special case values to "index", such as "index" : "amendments". Uses the same names as above. Note that for "hashes", this option will only return the recent ledger hashes / "short" skip list.
LedgerHashes has two types: "short", which stores the recent hashes since the last flag ledger, and "long", which stores the flag ledger hashes for a particular ledger range.
1. To find a "long" LedgerHashes object, request "hashes" : <ledger sequence>. <ledger sequence> can be integer value that evaluates to an unsigned integer.
2. To find the "short" LedgerHashes object, request "hashes": true as with the other fixed types.

The following queries are all functionally equivalent:

"amendments" : true
"index" : "amendments"
"amendments" : "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4"
"index" : "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4"

Finally, whether the object is found or not, if the query results in a valid index, that index will be returned. This can be used to confirm the query was valid, or to save the index for future use.

mvadari · 2025-08-04T14:38:35Z

Some thoughts on the fixed ledger entries:

Should the value be truthy?
If a string hash is provided, shouldn't that be checked for correctness?

ximinez · 2025-08-04T21:19:19Z

Some thoughts on the fixed ledger entries:

* Should the value be truthy?

* If a string hash is provided, shouldn't that be checked for correctness?

@mvadari Could you clarify what you mean for both of these questions? Maybe with examples? Or the updated description may answer them.

mvadari · 2025-08-04T21:22:16Z

src/xrpld/rpc/handlers/LedgerEntry.cpp

 static std::optional<uint256>
 parseIndex(Json::Value const& params, Json::Value& jvResult)
 {
+    std::string const index = params.asString();


I think I may have miscommunicated my suggestion - I was suggesting that
amendments: "01234...." should only accept the actual amendments key, and not other values.

Only the correct key will give you the Amendments object. Anything else will give you objectNotFound or unexpectedLedgerType.

I disagree with supporting these strings. Currently index only supports uint256s and nothing else, and this feels like a breaking change to that API to me.

Yes, I see your point. I have counterpoints

Technically, index only supports strings, which are then parsed into uint256. Since we're parsing anyway, why not parse a few special-case strings into other uint256s?

I was modelling the behavior on the ledger_index parameter, which normally takes numbers, but can also take the special-case values of "open", "closed", and "validated".

I usually think of breaking changes as things that move or remove an input or output value, such that an existing integration that's expecting something to be in a certain place can't find it anymore. This is more like an addition. It can be completely ignored, and nothing will suffer for it.

I'm willing to take it out or gate it on API version if you still think it's breaking. Thoughts?

It would be a breaking change in xrpl4j: https://github.com/XRPLF/xrpl4j/blob/main/xrpl4j-core/src/main/java/org/xrpl/xrpl4j/model/client/ledger/LedgerEntryRequestParams.java#L71

It would be a breaking change in xrpl4j: XRPLF/xrpl4j@main/xrpl4j-core/src/main/java/org/xrpl/xrpl4j/model/client/ledger/LedgerEntryRequestParams.java#L71

I think I missed this comment before now. I definitely don't want to break libraries. I will change this special case to be gated on API version 3, so that libraries will have a chance to catch up.

I was wrong about this, though I still don't like it - #5644 (comment)

- Request format for fee, amendments, and nunl is "fieldName":<any valid json>, including null. Because these types have no inputs to the index computation, any value works. - Request format for hashes is "hashes":<uint value or any valid json>. If the value is numeric, and evaluates to a uint, return the hashes history page for that ledger sequence. (AKA "long" skip list.) Any other valid json value will return the "short" skip list.

- For example "index":"amendments" will return the amendments object as if the request was "index":"7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4" - Works for amendments, fee, nunl, and hashes (for the recent history list only). - Always returns the valid computed index, even if the object is not found.

mvadari · 2025-08-04T21:25:39Z

Should the value be truthy?

Instead of accepting all bools provided into the amendments field, only accept true. Or don't accept 0 or negative numbers, only positive numbers. I thought the concept of "truthiness" was a general programming thing, but it seems to only be in JS: https://www.geeksforgeeks.org/javascript/explain-the-concept-of-truthy-falsy-values-in-javascript/

Edit after reading the description: I think passing in null and expecting not-an-error to be returned is rather confusing.

If a string hash is provided, shouldn't that be checked for correctness?

You can provide amendments: "01234...". Shouldn't that string be required to only be the actual fixed key, rather than accepting any value?

- Specifically #5237

codecov · 2025-08-04T21:59:59Z

Codecov Report

❌ Patch coverage is 94.73684% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.3%. Comparing base (96d17b7) to head (4ba63d0).
⚠️ Report is 1 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/xrpld/rpc/handlers/LedgerEntry.cpp	94.7%	3 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           develop   #5644   +/-   ##
=======================================
  Coverage     79.3%   79.3%           
=======================================
  Files          839     839           
  Lines        71607   71630   +23     
  Branches      8307    8272   -35     
=======================================
+ Hits         56768   56802   +34     
+ Misses       14839   14828   -11

Files with missing lines	Coverage Δ
src/xrpld/rpc/handlers/LedgerEntry.cpp	`83.9% <94.7%> (+1.6%)`	⬆️

... and 7 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ximinez · 2025-08-04T22:04:09Z

Thank you for explaining!

My main goal with this change, aside from just getting something I could use myself, was to make it as easy as possible to get the information I wanted. I avoided doing any validation of the input value, because it makes absolutely no difference to the lookup functionality.

Should the value be truthy?

Instead of accepting all bools provided into the amendments field, only accept true. Or don't accept 0 or negative numbers, only positive numbers. I thought the concept of "truthiness" was a general programming thing, but it seems to only be in JS: geeksforgeeks.org/javascript/explain-the-concept-of-truthy-falsy-values-in-javascript

Edit after reading the description: I think passing in null and expecting not-an-error to be returned is rather confusing.

Ah. I see. I was loosely familiar with "truthiness", but I didn't see how it applied here, since I didn't care about the value, only they key. That was partially informed by the implementation, where the first matched key is the one used for the query. To me it would be nonsensical to request { "account_root" : false, "check" : "ABCD..." }, because it'll only process the first hit (account_root), which will fail, because false is an invalid input. Further, it would be absurd to expect a Check in the result.

Given that, and given that the input doesn't need to be parsed, and given that I want it to be easy, I opted to do no validation of any kind.

It could be added, but my attitude is that nobody is going to complain about not getting an error, right?

If a string hash is provided, shouldn't that be checked for correctness?

You can provide amendments: "01234...". Shouldn't that string be required to only be the actual fixed key, rather than accepting any value?

Ah. I understand. This question basically has the same answer as the first. Aside from the fact that passing a key would be silly, since you can just use "index":"01234...", if I'm not doing any validation of the input, then they just get the Amendment object back, and if that's not what they expect, they need to write a better request.

ximinez · 2025-08-04T22:29:08Z

my attitude is that nobody is going to complain about not getting an error, right?

On second thought. I forgot my old maxim that "a wrong answer is worse than no answer". And if someone passes some other index as the value for "amendments":value, expecting the entry at that index, then returning the Amendments object is, arguably, a wrong answer.

I'm rewriting it now so that true is the only valid value for all these queries, with the addition of a "ledger indexy" value for hashes.

Edit: true or an index key.

mvadari · 2025-08-04T22:51:05Z

my attitude is that nobody is going to complain about not getting an error, right?

On second thought. I forgot my old maxim that "a wrong answer is worse than no answer". And if someone passes some other index as the value for "amendments":value, expecting the entry at that index, then returning the Amendments object is, arguably, a wrong answer.

I'm rewriting it now so that true is the only valid value for all these queries, with the addition of a "ledger indexy" value for hashes.

Edit: true or an index key.

I would perhaps accept all non-null, non-string values (plus the actual key string). null because I hate how Json::Value treats null as a real value and I don't want to support it here as a real value, especially since Json::Value will automatically add a null value if you do obj[key] before checking membership.

- True or a ledger index for those that can't parameters - Number, true, or a ledger index for "hashes".

ximinez · 2025-08-04T23:27:47Z

I would perhaps accept all non-null, non-string values (plus the actual key string). null because I hate how Json::Value treats null as a real value and I don't want to support it here as a real value, especially since Json::Value will automatically add a null value if you do obj[key] before checking membership.

I decided to limit it to true or the key string for simplicity, both for the user, and for documentation. Also because a number has meaning to hashes, but it otherwise follows the same rules, so this gives consistency.

tequdev · 2025-08-05T13:21:07Z

How about supporting amendment: {}?
This would be consistent with other non-fixed types.

mvadari · 2025-08-05T13:36:12Z

I decided to limit it to true or the key string for simplicity, both for the user, and for documentation. Also because a number has meaning to hashes, but it otherwise follows the same rules, so this gives consistency.

This seems fine to me, mostly because it's easier to start narrow and expand than the reverse. Worst case we revisit this in a few months and decide to expand the number of inputs we support here.

ximinez · 2025-08-08T17:37:18Z

How about supporting amendment: {}? This would be consistent with other non-fixed types.

It wouldn't be all that consistent, IMHO. First json objects are used to pass additional parameters. There are no additional parameters needs here. Second, not all of the other types accept objects. AccountRoot and Check are two examples

…r-entries * XRPLF/develop: test: add more tests for `ledger_entry` RPC (5858) refactor: Rename `rippled.cfg` to `xrpld.cfg` (6098) Revert "chore: Pin ruamel.yaml<0.19 in pre-commit-hooks (6166)" (6167) chore: Pin ruamel.yaml<0.19 in pre-commit-hooks (6166) fix: Remove cryptographic libs from libxrpl Conan package (6163)

pratikmankawde · 2026-01-13T15:18:11Z

src/xrpld/rpc/handlers/LedgerEntry.cpp

+static FunctionType
+fixed(Keylet const& keylet)
+{
+    return [&keylet](


Capturing keylet by reference here might cause issues if lifetime of passed Keylet object is limited to the call to fixed() or in any way not guaranteed to surpass the point where the returned lambda is called. Consider following call:

auto returnedLambda = fixed(Keylet()); // or fixed({<parameters passed to the Keylet constructor>}); returnedLambda(); // This might fail or not give correct results, since at this point the Keylet object was destroyed.

Although in current scenario, the Keylet objects retrieved using keylet::* and passed to fixed(..) are returning static objects. So should be fine for now.

Although in current scenario, the Keylet objects retrieved using keylet::* and passed to fixed(..) are returning static objects. So should be fine for now.

I don't want to have to rely on these parameters being static forever, and this is RPC code that isn't highly performance-sensitive, so I think it'll be safer in the long run to make the copy.

Fixed in 41d222c

pratikmankawde · 2026-01-13T15:23:38Z

src/xrpld/rpc/handlers/LedgerEntry.cpp

+parseIndex(
+    Json::Value const& params,
+    Json::StaticString const fieldName,
+    unsigned apiVersion)


Minor: apiVersion can be const. Same comment for other functions where apiVersion is being passed.

const unsigned apiVersion

Minor: apiVersion can be const. Same comment for other functions where apiVersion is being passed.

const unsigned apiVersion

const isn't super important for non-reference function parameters, because there are no external consequences if the function changes it, but I went ahead and added it in 41d222c

Yes true. Sometimes though a developer can change the value of the passed in param (intentionally or un-intentionally when local variables have similar name), and then(same or another dev.) mistakenly assume at a later stage that the variable still holds original passed value. Making this const reduces chances of such issues.

pratikmankawde · 2026-01-13T15:35:53Z

src/xrpld/rpc/handlers/LedgerEntry.cpp

+parseBridge(
+    Json::Value const& params,
+    Json::StaticString const fieldName,
+    unsigned apiVersion)


Minor: apiVersion could be tagged with [[maybe_unused]] incase we activate the unused-param warning in the future.

Minor: apiVersion could be tagged with [[maybe_unused]] incase we activate the unused-param warning in the future.

Added in 41d222c

pratikmankawde

Left a-few comments.

- Variable lifetime correctness - const correctness and [[maybe_unused]] for apiVersion

- Scope `params` instead of clearing it between each test. - Add a test to ensure "index: field" does not work with API < 3

pratikmankawde · 2026-01-14T11:23:23Z

src/xrpld/rpc/handlers/LedgerEntry.cpp

+parseFixed(
+    Keylet const& keylet,
+    Json::Value const& params,
+    Json::StaticString const& fieldName,


Suggested change

Json::StaticString const& fieldName,

[[maybe_unused]] Json::StaticString const& fieldName,

When params is bool type, fieldName will be unused.

When params is bool type, fieldName will be unused.

I think the maybe_unused attribute only applies at compile time, not run time. Since it's referenced in the function, it's used, regardless of the parameter at runtime.

pratikmankawde

Looks good.

@Tapanito

refactor: Update Conan dependencies: protobuf and grpc (#5589) This PR updates protobuf and grpc to their latest versions. The latest protobuf version no longer requires patches, so we can use it directly from the official Conan Center Index, while the latest grpc still needed a patch, which was added to our own Conan Center Index fork in XRPLF/conan-center-index#8. cleanup docs: Infer version of Conan dependency to export (#6112) This change updates a script in the documentation to automatically infer the version of a patched Conan dependency from the conan.lock file. chore: Use updated secp256k1 recipe (#6118) This change updates the secp256k1 recipe that defines the SECP256K1_STATIC, so it no longer needs to be defined in the code here. Running the Conan update script also updated two other recipes in the lock file. chore: Clean up .gitignore and .gitattributes (#6001) The .gitignore and .gitattributes files contain references to files and directories that the current build no longer produces, so this change removes obsolete entries in these files, and does some general reorganizing of the remaining entries. chore: Fix docs readme and cmake (#6122) This change removes the unused `with_docs` option and fixes the README instructions on how to build the `docs` target. removed amendment changes added limit to reply size Signed-off-by: Pratik Mankawde <3397372+pratikmankawde@users.noreply.github.com> minor clean-up Signed-off-by: Pratik Mankawde <3397372+pratikmankawde@users.noreply.github.com> refactor: clean up `RPCHelpers` (#5684) This PR cleans up `RPCHelpers.h` and `RPCHelpers.cpp`. It splits out all the fetch-ledger functions to a new set of files, `RPCLedgerHelpers.h`/`RPCLedgerHelpers.cpp`, and moves the general-API functions to `ApiVersion.h`. There is no functionality change. refactor: rename `LedgerInfo` to `LedgerHeader` (#6136) This PR renames `LedgerInfo` to `LedgerHeader`. Namely, `LedgerInfo` was already an alias for `LedgerHeader`, and the comments next to the alias suggested that it would make sense to rename it, since that makes it clearer what it is. refactor: rename info() to header() (#6138) This change renames all the `info()` functions to `header()`, since they return `LedgerHeader` structs. It also renames the underlying variables from `info_` to `header_`. refactor: Rename `rippled` binary to `xrpld` (#5983) Per [XLS-0095](https://xls.xrpl.org/xls/XLS-0095-rename-rippled-to-xrpld.html), we are taking steps to rename ripple(d) to xrpl(d). This change modifies the binary name from `rippled` to `xrpld`, and creates a symlink named `rippled` that points to the `xrpld` binary. Note that #5975 renamed any references to `rippled` in the CMake files and their contents, but explicitly maintained the `rippled` binary name by adding an exception. This change now undoes this exception and adds an explicit symlink instead. subscription test was failing, so trying with longer timeout, Signed-off-by: Pratik Mankawde <3397372+pratikmankawde@users.noreply.github.com> Update src/xrpld/overlay/detail/PeerImp.cpp update comparison operator. Co-authored-by: Ed Hennis <ed@ripple.com> Update src/xrpld/overlay/detail/PeerImp.cpp combine strings Co-authored-by: Ed Hennis <ed@ripple.com> refactor: Move JobQueue and related classes into xrpl.core module (#6121) refactor: Rename `ripple` namespace to `xrpl` (#5982) This change renames all occurrences of `namespace ripple` and `ripple::` to `namespace xrpl` and `xrpl::`, respectively, as well as the names of test suites. It also provides a script to allow developers to replicate the changes in their local branch or fork to avoid conflicts. chore: Fix some typos in comments (#6082) ci: Update shared actions (#6147) The latest update to `cleanup-workspace`, `get-nproc`, and `prepare-runner` moved the action to the repository root directory, and also includes some ccache changes. In response, this change updates the various shared actions to the latest commit hash. refactor: remove `Json::Object` and related files/classes (#5894) `Json::Object` and related objects are not used at all, so this change removes `include/xrpl/json/Object.h` and all downstream files. There are a number of minor downstream changes as well. Full list of deleted classes and functions: * `Json::Collections` * `Json::Object` * `Json::Array` * `Json::WriterObject` * `Json::setArray` * `Json::addObject` * `Json::appendArray` * `Json::appendObject` The last helper function, `copyFrom`, seemed a bit more complex and was actually used in a few places, so it was moved to `LedgerToJson.h` instead of deleting it. Set version to 3.2.0-b0 (#6153) ci: Remove superfluous build directory creation (#6159) This change modifies the build directory structure from `build/build/xxx` or `.build/build/xxx` to just `build/xxx`. Namely, the `conanfile.py` has the CMake generators build directory hardcoded to `build/generators`. We may as well leverage the top-level build directory without introducing another layer of directory nesting. fix: Remove cryptographic libs from libxrpl Conan package (#6163) * fix: rm crypto libs and fix protobuf path * update/rm comments chore: Pin ruamel.yaml<0.19 in pre-commit-hooks (#6166) See pre-commit/pre-commit-hooks#1229 for more details. Revert "chore: Pin ruamel.yaml<0.19 in pre-commit-hooks (#6166)" (#6167) This reverts commit 0f23ad8. refactor: Rename `rippled.cfg` to `xrpld.cfg` (#6098) This change renames all occurrences of `rippled.cfg` to `xrpld.cfg`. It also provides a script to allow developers to replicate the changes in their local branch or fork to avoid conflicts. For the time being it maintains support for `rippled.cfg` as config file, if `xrpld.cfg` does not exist. test: add more tests for `ledger_entry` RPC (#5858) This change adds some basic tests for all the `ledger_entry` helper functions, so each ledger entry type is covered. There are further some minor refactors in `parseAMM` to provide better error messages. Finally, to improve readability, alphabetization was applied in the helper functions. ci: Use ccache to cache build objects for speeding up building (#6104) Right now, each pipeline invocation builds the source code from scratch. Although compiled Conan dependencies are cached in a remote server, the source build objects are not. We are able to further speed up our builds by leveraging `ccache`. This change enables caching of build objects using `ccache` on Linux, macOS, and Windows. ci: Move variable into right place (#6179) This change moves the `enable_ccache` variable in the `on-trigger.yml` file to the correct location. refactor: Fix typos in comments, configure cspell (#6164) This change sets up a `cspell `configuration and fixes lots of typos in comments. There are no other code changes. refactor: Fix spelling issues in private/local variables and functions (#6182) This change fixes several typos in private/local variables and private functions. There is no functionality change. refactor: Fix spelling issues in all variables/functions (#6184) This change fixes many typos in comments, variables, and public functions. There is no functionality change. refactor: Remove unused credentials signature hash prefix (#6186) This change removes the unused credentials signature hash prefix from `HashPrefix.h`. fix: Reorder Batch Preflight Errors (#6176) This change fixes #6058. refactor: Fix typos, enable cspell pre-commit (#5719) This change fixes the last of the spelling issues, and enables the pre-commit (and CI) check for spelling. There are no functionality changes, but it does rename some enum values. ci: Use updated prepare-runner in actions and worfklows (#6188) This change updates the XRPLF pre-commit workflow and prepare-runner action to their latest versions. For naming consistency the prepare-runner action changed the disable_ccache variable into enable_ccache, which matches our naming. docs: Fix minor spelling issues in comments (#6194) fix: Truncate thread name to 15 chars on Linux (#5758) This change: * Truncates thread names if more than 15 chars with `snprintf`. * Adds warnings for truncated thread names if `-DTRUNCATED_THREAD_NAME_LOGS=ON`. * Add a static assert for string literals to stop compiling if > 15 chars. * Shortens `Resource::Manager` to `Resource::Mngr` to fix the static assert failure. * Updates `CurrentThreadName_test` unit test specifically for Linux to verify truncation. VaultClawback: Burn shares of an empty vault (#6120) - Adds a mechanism for the vault owner to burn user shares when the vault is stuck. If the Vault has 0 AssetsAvailable and Total, the owner may submit a VaultClawback to reclaim the worthless fees, and thus allow the Vault to be deleted. The Amount must be left off (unless the owner is the asset issuer), specified as 0 Shares, or specified as the number of Shares held. chore: Change `/Zi` to `/Z7` for ccache, remove debug symbols in CI (#6198) As the `/Zi` compiler flag is unsupported by ccache, this change switches it to `/Z7` instead. For CI runs all debug info is omitted. fix: Inner batch transactions never have valid signatures (#6069) - Introduces amendment `fixBatchInnerSigs` - Update Batch unit tests - Fix all the Env instantiations to _use_ the "features" parameter. - testInnerSubmitRPC runs with Batch enabled and disabled. - Add a test to testInnerSubmitRPC for a correctly signed tx incorrectly using the tfInnerBatchTxn flag. - Generalize the submitAndValidate lambda in testInnerSubmitRPC. - With the fix amendment, a transaction never reaches the transaction engine (Transactor and derived classes.) - Test submitting a pseudo-transaction. Stopped before reaching the transaction engine, but with different errors. - The tests verify that without the amendment, a transaction with tfInnerBatchTxn is immediately rejected. Without the amendment, things are safe. The amendment just makes things safer and more future-proof. chore: Pin pre-commit hooks to commit hashes (#6205) This change updates and pins the Black and CSpell pre-commit hooks. refactor: Remove unnecessary version number and options in cmake find_package (#6169) This change removes unnecessary version numbers in the OpenSSL and Boost `find_package` CMake statements. An unnecessary OpenSSL definition is removed, while Conan options for SSL are updated to disable insecure ciphers. Moreover, the statements are now ordered alphabetically and more logically. ci: Update actions/images to use cmake 4.2.1 and conan 2.24.0 (#6209) fix: Update Conan lock file with changed OpenSSL recipe (#6211) This change updates the `conan.lock` file with a changed OpenSSL recipe that contains a fix regarding options passed to the compiler Improve and fix bugs in Lending Protocol (#6102) - Spec: XLS-66 Fix overpayment asserts (#6084) MPTTester::operator() parameter should be std::int64_t - Originally defined as uint64_t, but the testIssuerLoan() test called it with a negative number, causing an overflow to a very large number that in some circumstances could be silently cast back to an int64_t, but might not be. I believe this is UB, and we don't want to rely on that. Review feedback from @Tapanito: overpayment value change - In overpayment results, the management fee was being calculated twice: once as part of the value change, and as part of the fees paid. Exclude it from the value change. Fix Overpayment Calculation (#6087) - Adds additional unit tests to cover math calculations. - Removes unused methods. Review feedback from @shawnxie999: even more rounding - Round the initial total value computation upward, unless there is 0-interest. - Rename getVaultScale to getAssetsTotalScale, and convert one incorrect computation to use it. - Use adjustImpreciseNumber for LossUnrealized. - Add some logging to computeLoanProperties. Fix LoanBrokerSet debtMaximum limits (#6116) Fix some minor bugs in Lending Protocol (#6101) - add nodiscard to unimpairLoan, and check result in LoanPay - add a check to verify that issuer exists - improve LoanManage error code for dust amounts Check permissions in LoanSet and LoanPay (#6108) Disallow pseudo accounts to be Destination for LoanBrokerCoverWithdraw (#6106) Ensure vault asset cap is not exceeded (#6124) Fix Overpayment ValueChange calculation in Lending Protocol (#6114) - Adds loan state to LoanProperties. - Cleans up computeLoanProperties. - Fixes missing management fee from overpayment. fix: Enable LP Deposits when the broker is the asset issuer (#6119) * Replace accountHolds with accountSpendable when checking for account funds in VaultDeposit and LoanBrokerCoverDeposit Add a few minor changes (#6158) - Updates or fixes a couple of things I noticed while reviewing changes to the spec. - Rename sfPreviousPaymentDate to sfPreviousPaymentDueDate. - Make the vault asset cap check added in #6124 a little more robust: 1. Check in preflight if the vault is _already_ over the limit. 2. Prevent overflow when checking with the loan value. (Subtract instead of adding, in case the values are near maxint. Both return the same result. Also add a unit test so each case is covered. Add minimum grace period validation (#6133) Fix bugs: frozen pseudo-account, and FLC cutoff (#6170) refactor: Rename raw state to theoretical state (#6187) Check if a withdrawal amount exceeds any applicable receiving limit. (#6117) Fix overpayment result calculation (#6195) Address review feedback from Lending Protocol re-review (#6161) --------- Co-authored-by: Gregory Tsipenyuk <gregtatcam@users.noreply.github.com> Co-authored-by: Bronek Kozicki <brok@incorrekt.com> Co-authored-by: Vito Tumas <5780819+Tapanito@users.noreply.github.com> Co-authored-by: Shawn Xie <35279399+shawnxie999@users.noreply.github.com> Co-authored-by: Jingchen <a1q123456@users.noreply.github.com> Expand Number to support the full integer range (#6025) - Refactor Number internals away from int64 to uint64 & a sign flag - ctors and accessors use `rep`. Very few things expose `internalrep`. - An exception is "unchecked" and the new "normalized", which explicitly take an internalrep. But with those special control flags, it's easier to distinguish and control when they are used. - For now, skip the larger mantissas in AMM transactions and tests - Remove trailing zeros from scientific notation Number strings - Update tests. This has the happy side effect of making some of the string representations _more_ consistent between the small and large mantissa ranges. - Add semi-automatic rounding of STNumbers based on Asset types - Create a new SField metadata enum, sMD_NeedsAsset, which indicates the field should be associated with an Asset so it can be rounded. - Add a new STTakesAsset intermediate class to handle the Asset association to a derived ST class. Currently only used in STNumber, but could be used by other types in the future. - Add "associateAsset" which takes an SLE and an Asset, finds the sMD_NeedsAsset fields, and associates the Asset to them. In the case of STNumber, that both stores the Asset, and rounds the value immediately. - Transactors only need to add a call to associateAsset _after_ all of the STNumbers have been set. Unfortunately, the inner workings of STObject do not do the association correctly with uninitialized fields. - When serializing an STNumber that has an Asset, round it before serializing. - Add an override of roundToAsset, which rounds a Number value in place to an Asset, but without any additional scale. - Update and fix a bunch of Loan-related tests to accommodate the expanded Number class. --------- Co-authored-by: Vito <5780819+Tapanito@users.noreply.github.com> Change LendingProtocol feature and dependencies to supported (#6146) minor code review changes Signed-off-by: Pratik Mankawde <3397372+pratikmankawde@users.noreply.github.com> test: Replace `failed` string in Vault test case (#6214) The word `failed` in the test case makes it hard to search through the test logs when an actual test failure occurs, so this change renames the word to just `fail` instead. test: Suppress "parse failed" message in Batch tests (#6207) test: Use gtest instead of doctest (#6216) This change switches over the doctest framework to the gtest framework. ci: Add sanitizers to CI builds (#5996) This change adds support for sanitizer build options in CI builds workflow. Currently `asan+ubsan` is enabled, while `tsan+ubsan` is left disabled as more changes are required. added unit test Signed-off-by: Pratik Mankawde <3397372+pratikmankawde@users.noreply.github.com> updated levelization Signed-off-by: Pratik Mankawde <3397372+pratikmankawde@users.noreply.github.com> Improve ledger_entry lookups for fee, amendments, NUNL, and hashes (#5644) These "fixed location" objects can be found in multiple ways: 1. The lookup parameters use the same format as other ledger objects, but the only valid value is true or the valid index of the object: - Amendments: "amendments" : true - FeeSettings: "fee" : true - NegativeUNL: "nunl" : true - LedgerHashes: "hashes" : true (For the "short" list. See below.) 2. With RPC API >= 3, using special case values to "index", such as "index" : "amendments". Uses the same names as above. Note that for "hashes", this option will only return the recent ledger hashes / "short" skip list. 3. LedgerHashes has two types: "short", which stores recent ledger hashes, and "long", which stores the flag ledger hashes for a particular ledger range. - To find a "long" LedgerHashes object, request '"hashes" : <ledger sequence>'. <ledger sequence> must be a number that evaluates to an unsigned integer. - To find the "short" LedgerHashes object, request "hashes": true as with the other fixed objects. The following queries are all functionally equivalent: - "amendments" : true - "index" : "amendments" (API >=3 only) - "amendments" : "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4" - "index" : "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4" Finally, whether the object is found or not, if a valid index is computed, that index will be returned. This can be used to confirm the query was valid, or to save the index for future use. ci: remove 'master' branch as a trigger (#6234) This change removes the `master` branch as a trigger for the CI pipelines, and updates comments accordingly. It also fixes the pre-commit workflow, so it will run on all release branches.

ximinez added the DraftRunCI Normally CI does not run on draft PRs. This opts in. label Aug 1, 2025

ximinez force-pushed the ximinez/fixed-ledger-entries branch 2 times, most recently from 611b562 to 522a7b5 Compare August 4, 2025 20:59

ximinez added the Will Need Documentation label Aug 4, 2025

mvadari reviewed Aug 4, 2025

View reviewed changes

ximinez added 2 commits August 4, 2025 17:23

ximinez force-pushed the ximinez/fixed-ledger-entries branch from 522a7b5 to fc929ab Compare August 4, 2025 21:25

Refactor a little bit to reduce future conflicts

cf80710

- Specifically #5237

Restrict which values are valid for fixed types.

0c147a8

- True or a ledger index for those that can't parameters - Number, true, or a ledger index for "hashes".

ximinez marked this pull request as ready for review August 4, 2025 23:44

ximinez requested a review from a team August 4, 2025 23:44

ximinez added 2 commits August 5, 2025 21:17

Merge branch 'develop' into ximinez/fixed-ledger-entries

3152f22

Merge branch 'develop' into ximinez/fixed-ledger-entries

cd58f63

ximinez added 5 commits August 8, 2025 18:23

Merge branch 'develop' into ximinez/fixed-ledger-entries

ed1d477

Merge branch 'develop' into ximinez/fixed-ledger-entries

7059126

Merge branch 'develop' into ximinez/fixed-ledger-entries

e6e1e4f

Merge branch 'develop' into ximinez/fixed-ledger-entries

2fda101

Merge branch 'develop' into ximinez/fixed-ledger-entries

9f0e159

ximinez added 8 commits December 17, 2025 12:12

Merge branch 'develop' into ximinez/fixed-ledger-entries

6009636

Merge branch 'develop' into ximinez/fixed-ledger-entries

2993f18

Merge branch 'develop' into ximinez/fixed-ledger-entries

3022652

Merge branch 'develop' into ximinez/fixed-ledger-entries

7c0f49a

Merge branch 'develop' into ximinez/fixed-ledger-entries

4ff4009

Merge branch 'develop' into ximinez/fixed-ledger-entries

ed2e661

Merge branch 'develop' into ximinez/fixed-ledger-entries

d1e2123

pratikmankawde reviewed Jan 13, 2026

View reviewed changes

ximinez added 3 commits January 13, 2026 15:02

Merge branch 'develop' into ximinez/fixed-ledger-entries

4a54f59

Merge branch 'develop' into ximinez/fixed-ledger-entries

8a6e999

Review feedback from @pratikmankawde:

41d222c

- Variable lifetime correctness - const correctness and [[maybe_unused]] for apiVersion

ximinez requested a review from pratikmankawde January 13, 2026 21:05

Review feedback from @mvadari: Tests

b165fd0

- Scope `params` instead of clearing it between each test. - Add a test to ensure "index: field" does not work with API < 3

mvadari approved these changes Jan 13, 2026

View reviewed changes

Merge branch 'develop' into ximinez/fixed-ledger-entries

8541f48

pratikmankawde reviewed Jan 14, 2026

View reviewed changes

pratikmankawde approved these changes Jan 14, 2026

View reviewed changes

ximinez added 2 commits January 15, 2026 12:05

Merge branch 'develop' into ximinez/fixed-ledger-entries

d960f75

Merge branch 'develop' into ximinez/fixed-ledger-entries

4ba63d0

ximinez merged commit 00d3cee into develop Jan 16, 2026
45 of 47 checks passed

ximinez deleted the ximinez/fixed-ledger-entries branch January 16, 2026 17:26

	Json::StaticString const& fieldName,
	[[maybe_unused]] Json::StaticString const& fieldName,

Conversation

ximinez commented Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

High Level Overview of Change

Context of Change

Type of Change

API Impact

Before / After

Before:

After:

Uh oh!

mvadari commented Aug 4, 2025

Uh oh!

ximinez commented Aug 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mvadari commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ximinez commented Aug 4, 2025

Uh oh!

ximinez commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mvadari commented Aug 4, 2025

Uh oh!

ximinez commented Aug 4, 2025

Uh oh!

tequdev commented Aug 5, 2025

Uh oh!

mvadari commented Aug 5, 2025

Uh oh!

ximinez commented Aug 8, 2025

Uh oh!

pratikmankawde Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pratikmankawde Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pratikmankawde left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pratikmankawde left a comment

Choose a reason for hiding this comment

ximinez commented Aug 1, 2025 •

edited

Loading

mvadari commented Aug 4, 2025 •

edited

Loading

codecov bot commented Aug 4, 2025 •

edited

Loading

ximinez commented Aug 4, 2025 •

edited

Loading

pratikmankawde Jan 13, 2026 •

edited

Loading

pratikmankawde Jan 13, 2026 •

edited

Loading