Add new float host functions and versioning rules by sappenin · Pull Request #504 · XRPLF/XRPL-Standards

sappenin · 2026-03-23T23:53:57Z

Updated §5.8 (Floats) preamble to describe a general-purpose 12-byte buffer (4-byte exponent + 8-byte mantissa), document the rounding_modes values.
Added new host functions to §5.8.
Added §5.11 Host Function Versioning Rules, covering the immutability of deployed host functions and the requirement to introduce new function names if buffer layouts change
Added FAQs to help explain design rationale.

- Updated §5.8 (Floats) preamble to describe OpaqueFloat as a general-purpose 12-byte buffer (4-byte exponent + 8-byte mantissa), document the rounding_modes values, and drop the IOU-specific framing - Added six new host functions to §5.8 (all at 1000 gas, consistent with existing float operations) - Added §5.11 Host Function Versioning Rules, covering the immutability of deployed host functions and the requirement to introduce new function names if buffer layouts change Signed-off-by: David Fuelling <sappenin@gmail.com>

Signed-off-by: David Fuelling <sappenin@gmail.com>

pwang200 · 2026-03-24T15:50:19Z

Because a smart escrow should store the mantissa and exponent as separate integers in a contract-defined format if the smart escrow needs to persist the opaque float in the ledger. It needs a way to get the mantissa and exponent, through a new host function:

float_to_mantissa_and_exponent(
opaque_float_in_buf: i32,
opaque_float_in_len: i32,
mantissa_out_buf: i32,
mantissa_out_len: i32,
exponent_out_buf: i32,
exponent_out_len: i32,
)

Does it need a rounding mode? Not, right?

Signed-off-by: David Fuelling <sappenin@gmail.com>

sappenin · 2026-03-24T21:39:17Z

@pwang200 I addressed your comment above via e56c1b9

Signed-off-by: David Fuelling <sappenin@gmail.com>

sappenin · 2026-04-14T19:17:22Z

@pwang200 said:

Does it need a rounding mode? Not, right?

We decided that we don't, because the float is already rounded.

Signed-off-by: David Fuelling <sappenin@gmail.com> # Conflicts: # XLS-0102-wasm-vm/README.md

Signed-off-by: David Fuelling <sappenin@gmail.com>

…dards into df/update-host-functions

Signed-off-by: David Fuelling <sappenin@gmail.com>

mvadari · 2026-08-17T21:38:55Z

-| `float_div(`<br/>&emsp;`in_buf1: i32,`<br/>&emsp;`in_len1: i32,`<br/>&emsp;`in_buf2: i32,`<br/>&emsp;`in_len2: i32,`<br/>&emsp;`out_buf: i32,`<br/>&emsp;`out_len: i32,`<br/>&emsp;`rounding_modes: i32`<br />`)`  | Divide two floats in rippled format.                                | 300      |
-| `float_pow(`<br/>&emsp;`in_buf: i32,`<br/>&emsp;`in_len: i32,`<br/>&emsp;`pow: i32,`<br/>&emsp;`out_buf: i32,`<br/>&emsp;`out_len: i32,`<br/>&emsp;`rounding_modes: i32`<br />`)`                                  | Compute the nth power of a float in rippled format.                 | 5500     |
-| `float_root(`<br/>&emsp;`in_buf: i32,`<br/>&emsp;`in_len: i32,`<br/>&emsp;`root: i32,`<br/>&emsp;`out_buf: i32,`<br/>&emsp;`out_len: i32,`<br/>&emsp;`rounding_modes: i32`<br />`)`                                | Compute the nth root of a float in rippled format.                  | 5500     |
+Helper functions for performing floating point arithmetic via rippled. These are used for any calculation requiring XRPL's decimal floating point format — including IOU amounts, lending protocol math, fee calculations, or arbitrary numeric operations within a smart contract.


Suggested change

Helper functions for performing floating point arithmetic via rippled. These are used for any calculation requiring XRPL's decimal floating point format — including IOU amounts, lending protocol math, fee calculations, or arbitrary numeric operations within a smart contract.

Helper functions for performing floating point arithmetic via xrpld. These are used for any calculation requiring XRPL's decimal floating point format, including IOU amounts, lending protocol math, fee calculations, or arbitrary numeric operations within a smart contract.

Can you update all other instances of rippled to xrpld in this doc?

mvadari · 2026-08-17T21:40:04Z

+
+Smart contracts SHOULD NOT inspect, decode, or construct XFloat bytes directly. All operations should instead go through the host functions defined in [§5.8](#58-floats). Bypassing host functions is gas-inefficient — each host call is priced to amortize the cost of the operation, and hand-rolling arithmetic in WASM bytecode incurs more gas for less precision. A contract that reads or writes the individual bytes of an XFloat buffer is also relying on an implementation detail that may change, and could produce incorrect or undefined behavior if it does. The buffer should be allocated, passed to a host functions, and discarded — nothing else.
+
+**Warning — do not persist XFloat bytes:** Contracts MUST NOT write XFloat buffers into contract storage (e.g., the `data` field of a smart feature). The 12-byte encoding is an in-memory convention tied to today's float host functions. Per [§5.11](#511-host-function-versioning-rules) rule 3, that encoding can never change for these functions — but a future need for a different layout would ship as a new host function under a new name, and bytes persisted under today's convention would not be readable by it.


You can use the Github warning block if you want here

mvadari · 2026-08-17T21:41:12Z

+
+#### 5.8.2. XFloat Serialization Format
+
+This section documents the XFloat encoding for **rippled implementers and tooling authors**. Contracts must not use this information to construct or decode buffers — they must use the host functions in [§5.8](#58-floats) exclusively.


This section seems unnecessary, I don't really think we need to assert literally everywhere that contracts shouldn't decode themselves

mvadari · 2026-08-17T21:41:35Z

+
+#### 5.8.3. XFloat Motivation
+
+XRPL Smart Contracts running in WebAssembly need to perform correct decimal arithmetic. This need arises in many contexts: computing with fungible token amounts (IOUs), implementing lending protocols with interest and collateral ratios, calculating fees, and more.


Smart Contracts implies not Smart Escrows etc

mvadari · 2026-08-17T21:42:07Z

+
+The 12-byte XFloat format is strictly an in-memory buffer convention for passing values to and from WASM host functions. Values stored in ledger objects continue to use their existing serialization formats; the host function `float_from_iou_value` bridges the IOU amount format to WASM floating point numbers. `STNumber` values are decoded in Rust by `xrpl-wasm-stdlib` — for the IOU-precision case, the decoded 8-byte value is layout-identical to an `IouNumber` and is passed to `float_from_iou_value` directly, without a dedicated host function.
+
+#### 5.8.3. XFloat Motivation


This section should be higher up

mvadari · 2026-08-17T21:42:33Z

+
+Implementing xrpld floating-point arithmetic correctly is genuinely hard. Correct rounding, normalization, overflow handling, and edge-case behavior require a carefully engineered implementation. Implementing this correctly in WASM from scratch is not a reasonable expectation for contract developers, and cannot be practically verified or guaranteed. By delegating all arithmetic to rippled's `Number` class via host functions, contracts get a battle-tested implementation that is known to be correct for XRPL's numeric domain, even across amendment changes.
+
+Note that the XRPL WASM VM does not enable the WASM floating-point instruction set (i.e., `f32`/`f64` ops are unavailable to contracts). This means native IEEE 754 arithmetic is not an option regardless of determinism concerns. Contracts that need fixed-point arithmetic independent of the `XFloat` host functions — for example, to work with integer ratios or basis points — should consider crates like the [`fixed`](https://crates.io/crates/fixed) Rust crate, which performs fixed-point math entirely in integer instructions and is fully compatible with the `no_std`, `wasm32v1-none` build target.


nit:

Suggested change

Note that the XRPL WASM VM does not enable the WASM floating-point instruction set (i.e., `f32`/`f64` ops are unavailable to contracts). This means native IEEE 754 arithmetic is not an option regardless of determinism concerns. Contracts that need fixed-point arithmetic independent of the `XFloat` host functions — for example, to work with integer ratios or basis points — should consider crates like the [`fixed`](https://crates.io/crates/fixed) Rust crate, which performs fixed-point math entirely in integer instructions and is fully compatible with the `no_std`, `wasm32v1-none` build target.

Note that the XRPL WASM VM does not enable the WASM floating-point instruction set (i.e., `f32`/`f64` ops are unavailable to contracts). This means native IEEE 754 arithmetic is not an option regardless of determinism concerns. Contracts that need fixed-point arithmetic independent of the `XFloat` host functions (for example, to work with integer ratios or basis points) should consider crates like the [`fixed`](https://crates.io/crates/fixed) Rust crate, which performs fixed-point math entirely in integer instructions and is fully compatible with the `no_std`, `wasm32v1-none` build target.

mvadari · 2026-08-17T21:42:48Z

+
+#### 5.8.5. XFloat Binary Format Reference
+
+> **For implementers and tooling authors only.** Contracts must never decode or construct `XFloat` bytes directly. This section exists to support rippled development, debuggers, explorers, and spec verification — not contract authors.


mvadari · 2026-08-17T21:43:50Z

+
+1. **New host functions MAY be added** at any time without breaking existing contracts. Contracts that do not call a new function are unaffected.
+2. **Host functions MAY be deprecated** with appropriate notice, but deprecated functions MUST remain callable for backward compatibility. Deployed contracts may rely on any host function that was available at deployment time. Deprecation does not remove or change the function — it signals to new contract authors that a function is discouraged, so documentation and tooling (e.g. `xrpl-wasm-stdlib`) can steer new development away from it even though it remains available for existing contracts.
+3. **Host functions MUST NOT ever be changed.** Once a host function is deployed — its name, parameter types, parameter order, and observable behavior are permanently immutable. This includes buffer sizes, since contracts hardcode allocation sizes (e.g., 20 bytes for an account ID, 12 bytes for an `XFloat`). If a buffer size changes, a new host function with a different name MUST be introduced.


Suggested change

3. **Host functions MUST NOT ever be changed.** Once a host function is deployed — its name, parameter types, parameter order, and observable behavior are permanently immutable. This includes buffer sizes, since contracts hardcode allocation sizes (e.g., 20 bytes for an account ID, 12 bytes for an `XFloat`). If a buffer size changes, a new host function with a different name MUST be introduced.

3. **Host functions MUST be permanently backwards compatible.** Once a host function is deployed — its name, parameter types, parameter order, and observable behavior are permanently immutable. This includes buffer sizes, since contracts hardcode allocation sizes (e.g., 20 bytes for an account ID, 12 bytes for an `XFloat`). If a buffer size changes, a new host function with a different name MUST be introduced.

If a buffer size changes, a new host function with a different name MUST be introduced. - did we agree on this? I thought it was fine as long as you still support old behavior, but I might be misremembering.

mvadari · 2026-08-17T21:43:58Z

+3. **Host functions MUST NOT ever be changed.** Once a host function is deployed — its name, parameter types, parameter order, and observable behavior are permanently immutable. This includes buffer sizes, since contracts hardcode allocation sizes (e.g., 20 bytes for an account ID, 12 bytes for an `XFloat`). If a buffer size changes, a new host function with a different name MUST be introduced.

-### 6.1. Consensus
+These rules ensure that smart contracts compiled and deployed today will continue to execute correctly on future versions of the platform.


mvadari · 2026-08-17T21:44:13Z

+
+## 6. Rationale
+
+This section summarizes the main design decisions in this specification and why they were made. The appendices contain the full analysis of the alternatives that were considered.


This para is unnecessary, that's the objective of the Rationale section

mvadari · 2026-08-17T21:44:31Z

+
+This section summarizes the main design decisions in this specification and why they were made. The appendices contain the full analysis of the alternatives that were considered.
+
+- **Interpreted Wasmi runtime.** Different WASM runtimes meter gas differently, so the same code can produce different gas costs across implementations — a consensus hazard. Fixing the runtime (Wasmi), its version, and an interpreted compile mode guarantees identical, deterministic gas costs on every validator. Interpretation also avoids the larger attack surface and platform-dependent behavior of JIT/AOT compilation. See [Appendix A](#appendix-a-other-wasm-vms-considered) for the full comparison of runtimes and compilation modes.


nit: use : instead of . at the end of each bullet's heading (even better would be a subsection)

mvadari · 2026-08-17T21:46:12Z

+
+### C.5: Why not use native WASM floating point?
+
+WebAssembly's native `f32` and `f64` types are IEEE 754 binary floating-point. One might ask whether those could be used directly for numeric operations in smart contracts, perhaps with NaN canonicalization to address the one known source of non-determinism in the WASM spec (NaN bit-payload variation when inputs are non-canonical). In practice this would be insufficient for two independent reasons.


nit:

Suggested change

WebAssembly's native `f32` and `f64` types are IEEE 754 binary floating-point. One might ask whether those could be used directly for numeric operations in smart contracts, perhaps with NaN canonicalization to address the one known source of non-determinism in the WASM spec (NaN bit-payload variation when inputs are non-canonical). In practice this would be insufficient for two independent reasons.

WebAssembly's native `f32` and `f64` types are IEEE 754 binary floating-point. While they could be used directly for numeric operations in smart contracts, perhaps with NaN canonicalization to address the one known source of non-determinism in the WASM spec (NaN bit-payload variation when inputs are non-canonical), in practice this would be insufficient for two independent reasons:

mvadari · 2026-08-17T21:47:08Z

+
+### C.6: Why not provide a Rust implementation of Number arithmetic in `xrpl-wasm-stdlib`?
+
+For reasons related to C.5, `xrpl-wasm-stdlib` deliberately does not ship a Rust implementation of `Number` arithmetic. Such an implementation would face the same amendment-drift problem defined in C.5: it would be frozen at the version of the logic that existed when it was written. The correct abstraction boundary is the host function interface — contracts call into rippled, rippled's `Number` class does the math, and the contract receives the result as an opaque 12-byte buffer. This keeps the arithmetic logic in exactly one place.


This should also mention that it would be more gas/performance-efficient to do it in C++

sappenin requested a review from mvadari March 23, 2026 23:54

Update comment

e56743b

Signed-off-by: David Fuelling <sappenin@gmail.com>

sappenin commented Mar 23, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin commented Mar 24, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin commented Mar 24, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin added 2 commits March 24, 2026 14:28

Add OpaqueFloat details

1bd5c3b

Signed-off-by: David Fuelling <sappenin@gmail.com>

Update C.9

fc2d661

Signed-off-by: David Fuelling <sappenin@gmail.com>

sappenin commented Mar 24, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md

sappenin commented Mar 24, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

Add float_to_mantissa_and_exponent

e56c1b9

Signed-off-by: David Fuelling <sappenin@gmail.com>

Merge branch 'master' into df/update-host-functions

669e9c5

sappenin assigned pwang200 and sappenin Mar 24, 2026

sappenin commented Mar 24, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin commented Mar 24, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin commented Mar 24, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

pwang200 reviewed Mar 27, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

pwang200 reviewed Mar 27, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin added 3 commits March 27, 2026 13:42

Update spec gas costs

4083600

Signed-off-by: David Fuelling <sappenin@gmail.com>

Update normalization rules.

19b88f2

Signed-off-by: David Fuelling <sappenin@gmail.com>

Fix formatting

d70bbb1

Signed-off-by: David Fuelling <sappenin@gmail.com>

gip reviewed Mar 30, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin commented Apr 14, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin commented Apr 14, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin commented Apr 14, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin commented Apr 14, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

Merge branch 'master' into df/update-host-functions

eb12272

Signed-off-by: David Fuelling <sappenin@gmail.com> # Conflicts: # XLS-0102-wasm-vm/README.md

sappenin requested a review from pwang200 July 24, 2026 21:10

TimothyBanks reviewed Jul 28, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md

TimothyBanks reviewed Jul 28, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md

TimothyBanks reviewed Jul 28, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md

TimothyBanks reviewed Jul 28, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md

Merge branch 'master' into df/update-host-functions

85530fa

sappenin commented Aug 11, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

Comment thread XLS-0102-wasm-vm/README.md Outdated

Comment thread XLS-0102-wasm-vm/README.md Outdated

sappenin added 4 commits August 11, 2026 15:33

Misc updates

1a2c4c9

Signed-off-by: David Fuelling <sappenin@gmail.com>

Merge branch 'df/update-host-functions' of github.com:XRPLF/XRPL-Stan…

4e93970

…dards into df/update-host-functions

Merge branch 'master' into df/update-host-functions

b84324f

Misc cleanup

2730411

Signed-off-by: David Fuelling <sappenin@gmail.com>

pwang200 reviewed Aug 11, 2026

View reviewed changes

Comment thread XLS-0102-wasm-vm/README.md Outdated

Rename float_from_iou_number_amount to float_from_iou_value

d1213ed

Signed-off-by: David Fuelling <sappenin@gmail.com>

TimothyBanks approved these changes Aug 11, 2026

View reviewed changes

Add Rationale section

443e530

Signed-off-by: David Fuelling <sappenin@gmail.com>

sappenin mentioned this pull request Aug 12, 2026

New Amount/Issue/Asset Design ripple/xrpl-wasm-stdlib#64

Draft

7 tasks

mvadari reviewed Aug 17, 2026

View reviewed changes

	Helper functions for performing floating point arithmetic via rippled. These are used for any calculation requiring XRPL's decimal floating point format — including IOU amounts, lending protocol math, fee calculations, or arbitrary numeric operations within a smart contract.
	Helper functions for performing floating point arithmetic via xrpld. These are used for any calculation requiring XRPL's decimal floating point format, including IOU amounts, lending protocol math, fee calculations, or arbitrary numeric operations within a smart contract.


		Smart contracts SHOULD NOT inspect, decode, or construct XFloat bytes directly. All operations should instead go through the host functions defined in [§5.8](#58-floats). Bypassing host functions is gas-inefficient — each host call is priced to amortize the cost of the operation, and hand-rolling arithmetic in WASM bytecode incurs more gas for less precision. A contract that reads or writes the individual bytes of an XFloat buffer is also relying on an implementation detail that may change, and could produce incorrect or undefined behavior if it does. The buffer should be allocated, passed to a host functions, and discarded — nothing else.

		Warning — do not persist XFloat bytes: Contracts MUST NOT write XFloat buffers into contract storage (e.g., the `data` field of a smart feature). The 12-byte encoding is an in-memory convention tied to today's float host functions. Per [§5.11](#511-host-function-versioning-rules) rule 3, that encoding can never change for these functions — but a future need for a different layout would ship as a new host function under a new name, and bytes persisted under today's convention would not be readable by it.


		#### 5.8.2. XFloat Serialization Format

		This section documents the XFloat encoding for rippled implementers and tooling authors. Contracts must not use this information to construct or decode buffers — they must use the host functions in [§5.8](#58-floats) exclusively.


		#### 5.8.3. XFloat Motivation

		XRPL Smart Contracts running in WebAssembly need to perform correct decimal arithmetic. This need arises in many contexts: computing with fungible token amounts (IOUs), implementing lending protocols with interest and collateral ratios, calculating fees, and more.


		The 12-byte XFloat format is strictly an in-memory buffer convention for passing values to and from WASM host functions. Values stored in ledger objects continue to use their existing serialization formats; the host function `float_from_iou_value` bridges the IOU amount format to WASM floating point numbers. `STNumber` values are decoded in Rust by `xrpl-wasm-stdlib` — for the IOU-precision case, the decoded 8-byte value is layout-identical to an `IouNumber` and is passed to `float_from_iou_value` directly, without a dedicated host function.

		#### 5.8.3. XFloat Motivation


		Implementing xrpld floating-point arithmetic correctly is genuinely hard. Correct rounding, normalization, overflow handling, and edge-case behavior require a carefully engineered implementation. Implementing this correctly in WASM from scratch is not a reasonable expectation for contract developers, and cannot be practically verified or guaranteed. By delegating all arithmetic to rippled's `Number` class via host functions, contracts get a battle-tested implementation that is known to be correct for XRPL's numeric domain, even across amendment changes.

		Note that the XRPL WASM VM does not enable the WASM floating-point instruction set (i.e., `f32`/`f64` ops are unavailable to contracts). This means native IEEE 754 arithmetic is not an option regardless of determinism concerns. Contracts that need fixed-point arithmetic independent of the `XFloat` host functions — for example, to work with integer ratios or basis points — should consider crates like the [`fixed`](https://crates.io/crates/fixed) Rust crate, which performs fixed-point math entirely in integer instructions and is fully compatible with the `no_std`, `wasm32v1-none` build target.


		#### 5.8.5. XFloat Binary Format Reference

		> For implementers and tooling authors only. Contracts must never decode or construct `XFloat` bytes directly. This section exists to support rippled development, debuggers, explorers, and spec verification — not contract authors.


		## 6. Rationale

		This section summarizes the main design decisions in this specification and why they were made. The appendices contain the full analysis of the alternatives that were considered.


		This section summarizes the main design decisions in this specification and why they were made. The appendices contain the full analysis of the alternatives that were considered.

		- Interpreted Wasmi runtime. Different WASM runtimes meter gas differently, so the same code can produce different gas costs across implementations — a consensus hazard. Fixing the runtime (Wasmi), its version, and an interpreted compile mode guarantees identical, deterministic gas costs on every validator. Interpretation also avoids the larger attack surface and platform-dependent behavior of JIT/AOT compilation. See [Appendix A](#appendix-a-other-wasm-vms-considered) for the full comparison of runtimes and compilation modes.


		### C.5: Why not use native WASM floating point?

		WebAssembly's native `f32` and `f64` types are IEEE 754 binary floating-point. One might ask whether those could be used directly for numeric operations in smart contracts, perhaps with NaN canonicalization to address the one known source of non-determinism in the WASM spec (NaN bit-payload variation when inputs are non-canonical). In practice this would be insufficient for two independent reasons.


		### C.6: Why not provide a Rust implementation of Number arithmetic in `xrpl-wasm-stdlib`?

		For reasons related to C.5, `xrpl-wasm-stdlib` deliberately does not ship a Rust implementation of `Number` arithmetic. Such an implementation would face the same amendment-drift problem defined in C.5: it would be frozen at the version of the logic that existed when it was written. The correct abstraction boundary is the host function interface — contracts call into rippled, rippled's `Number` class does the math, and the contract receives the result as an opaque 12-byte buffer. This keeps the arithmetic logic in exactly one place.

Uh oh!

Conversation

sappenin commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pwang200 commented Mar 24, 2026

Uh oh!

Uh oh!

Uh oh!

sappenin commented Mar 24, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sappenin commented Apr 14, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mvadari Aug 17, 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!

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 Aug 17, 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

sappenin commented Mar 23, 2026 •

edited

Loading

mvadari Aug 17, 2026 •

edited

Loading

mvadari Aug 17, 2026 •

edited

Loading