Add orderbook #1429

thea-leake · 2023-06-29T13:39:42Z

Description

Adds the orderbook pallet.

Changes and Descriptions

Adds pallet providing an orderbook to exchange assets.
Adds pallet to dev runtime, and dev runtime weights.

Checklist:

I have added Rust doc comments to structs, enums, traits and functions
I have made corresponding changes to the documentation
I have performed a self-review of my code -- in progress
I have added tests that prove my fix is effective or that my feature works

mustermeiszer

Looks good! Definitely going in the right direction.

mustermeiszer · 2023-07-15T06:48:36Z

pallets/order-book/src/lib.rs

+			ensure!(
+				T::ReserveCurrency::can_reserve(
+					&account_id,
+					T::Fees::fee_value(T::OrderFeeKey::get())


Could be a conflict if we allowed trading_curreny = reserve_curreny

Ah, yeah it does look like that could result in a failure later at the second reserve in the extrinsic if the asset out is also the reserve currency. Looking into that now.

It's updated to check the fee currency against the asset out currency, and consolidate the reserves when they match.

Currently updating other reserve/unreserve locations to make sure correct currency type is reserved/unreserved when the outgoing currency matches the fees so the mechanism is always consistent (i.e. so we don't have any reserves done through native balances trait impl that are undone via orml impl.)

All reserve/unreserve should be covered now, cleaning it up, adding additional coverage around this as well now.

Chralt98 · 2023-07-20T06:39:07Z

pallets/order-book/src/lib.rs

+		pub fn get_account_orders(
+			account_id: T::AccountId,
+		) -> Result<
+			sp_std::vec::Vec<(
+				T::Hash,
+				Order<T::Hash, T::AccountId, T::AssetCurrencyId, T::ForeignCurrencyBalance>,
+			)>,
+			Error<T>,
+		> {
+			Ok(<UserOrders<T>>::iter_prefix(account_id).collect())
+		}
+
+		/// Get all orders
+		/// Provided for frontend to grab all open orders
+		pub fn get_all_orders() -> Result<
+			sp_std::vec::Vec<(
+				T::Hash,
+				Order<T::Hash, T::AccountId, T::AssetCurrencyId, T::ForeignCurrencyBalance>,
+			)>,
+			Error<T>,
+		> {
+			Ok(<Orders<T>>::iter().collect())
+		}


You might want to use this for a RPC to let it be queried by the front end easier, right? But can't you just access the storage items Orders and UserOrders directly instead of using an RPC? I always think if you have complex computations, it's cool to provide a RPC for it, but just querying the storage might not be a big deal for the front end. In addition: If you access the functions inside the runtime, I think you know that iter...().collect() is a bad practice and usually leads to overweight of blocks. But I assume the functions will never be called inside the runtime.

That's a very good point, as it is only for frontend it won't be called in the runtime, and therefore won't affect blockweights, but definitely a good thing to check! :)

Agree with @Chralt98, I would remove these methods to avoid bad usage from the runtime. If they're needed for testing, the tester can call iter_prefix() or iter() directly.

Forcing to use iter or iter_prefix the user can see that this implies a lot of read accesses.

Chralt98 · 2023-07-20T06:45:59Z

pallets/order-book/src/lib.rs

+		#[pallet::call_index(2)]
+		// dummy weight for now
+		#[pallet::weight(10_000 + T::DbWeight::get().reads_writes(2, 2).ref_time())]
+		pub fn fill_order_full(origin: OriginFor<T>, order_id: T::Hash) -> DispatchResult {


Are there plans to partially fill orders? I mean assume one big ask order comes in at the best price (lowest ask). Now a small fish can't really buy at this price, because the order is too big for the small fish.

The other case is the trickier: Assume there are many small ask orders at the best price (lowest ask). Now a big whale places a market order and buys all small ask orders. First, this often creates slippage, as you might know already.. Second, there might be not enough open ask orders to fill the big bid of the whale. Third, the whale needs to transact with many small fish accounts to fulfil the small orders. This leads to a high computational demand and therefore high transaction costs.

So is your plan to just allow the orders to be filled 100% to mitigate this and sacrifice that a small fish can not fill the possible big order?

Chralt98 · 2023-07-20T06:51:57Z

pallets/order-book/src/lib.rs

+		<T as frame_system::Config>::Hash: PartialEq<<T as frame_system::Config>::Hash>,
+	{
+		/// Create an order, with the minimum fulfillment amount set to the buy
+		/// amount, as the first iteration will not have partial fulfillment


Oh I saw this after this message.

But what are your plans to realise not partial fulfillment, but the other way around: If a big order needs to eat many small orders?

Assume there are many small ask orders at the best price (lowest ask). Now a big whale places a market order and buys all small ask orders. First, this often creates slippage, as you might know already.. Second, there might be not enough open ask orders to fill the big bid of the whale. Third, the whale needs to transact with many small fish accounts to fulfil the small orders. This leads to a high computational demand and therefore high transaction costs.

Thats a good question. The initial plan was to match orders of corresponding currency pairs and compatible prices and min fulfillment amounts, however there was some concern with the weight of matching those up, it's something I believe we plan on revisiting in the future.

Chralt98 · 2023-07-20T07:07:24Z

pallets/order-book/src/tests.rs

+			})
+		);
+	});
+}


I know this is wip, but I assume you know that a fill_order_full test is missing.

Yes, I had not gotten to that test by then. I was aware and it is added now, but thanks for looking out for that! :)

lemunozm

I think the error from this slack issue comes because cfg-mocks and/or cfg-test-utils dont have their runtime-benchmarks feature added

pallets/order-book/Cargo.toml

thea-leake · 2023-07-25T13:49:56Z

Still reviewing on my end, but putting it in review now as it would be good to get it merged sooner if possible to have available for frontend. I would like to extend tests and benchmarks more, but that might be better to do in second PR.

lemunozm

Fast first review with some nitpick comments and questions to understand this better. I would make a second deep review focusing in the main methods and implementation logic.

But everything seems clear and well structured!

lemunozm · 2023-07-25T13:59:30Z

libs/traits/src/lib.rs

+	/// be inmediately and completelly fullfilled. If there was already an
+	/// active order with the same account currencies, the order is
+	/// increased/decreased and the same order id is returned.


Then, why do we need an update_order()?

update_order allows accounts to update active orders they have, and can also be used when we add partial fulfillment.

But given that comment, it seems like place_order does the same if the order already exits.

Ah, the current place_order creates a new order instead of updating the order, the docstring wasn't updated to match the behaviour, but it might be better to have behaviour match docstring.
@wischli would it be better for place_order to update an existing order for an account/currency pair?
If that's the case it would make sense to switch order id back to hash, but without nonce--this should be a simple change though.

Verified current behaviour is good, and updated docstring to make sure it's accurate.

pallets/order-book/src/benchmarking.rs

pallets/order-book/src/mock.rs

lemunozm · 2023-07-25T14:04:05Z

pallets/order-book/src/mock.rs

+cfg_test_utils::mocks::orml_asset_registry::impl_mock_registry! {
+		RegistryMock,
+		CurrencyId,
+		ForeignCurrencyBalance,
+		CustomMetadata
+}


Could this be migrated to a pallet mock?
cc @mustermeiszer

of course. Was the old approach before we had your mock builder.

pallets/order-book/src/lib.rs

lemunozm · 2023-07-25T14:34:20Z

pallets/order-book/src/lib.rs

+		pub fn get_account_orders(
+			account_id: T::AccountId,
+		) -> Result<
+			sp_std::vec::Vec<(
+				T::Hash,
+				Order<T::Hash, T::AccountId, T::AssetCurrencyId, T::ForeignCurrencyBalance>,
+			)>,
+			Error<T>,
+		> {
+			Ok(<UserOrders<T>>::iter_prefix(account_id).collect())
+		}
+
+		/// Get all orders
+		/// Provided for frontend to grab all open orders
+		pub fn get_all_orders() -> Result<
+			sp_std::vec::Vec<(
+				T::Hash,
+				Order<T::Hash, T::AccountId, T::AssetCurrencyId, T::ForeignCurrencyBalance>,
+			)>,
+			Error<T>,
+		> {
+			Ok(<Orders<T>>::iter().collect())
+		}


Agree with @Chralt98, I would remove these methods to avoid bad usage from the runtime. If they're needed for testing, the tester can call iter_prefix() or iter() directly.

Forcing to use iter or iter_prefix the user can see that this implies a lot of read accesses.

pallets/order-book/src/lib.rs

lemunozm · 2023-07-25T14:42:13Z

pallets/order-book/src/lib.rs

+			ensure!(
+				T::ReserveCurrency::can_reserve(
+					&account,
+					T::Fees::fee_value(T::OrderFeeKey::get())
+				),
+				Error::<T>::InsufficientReserveFunds,
+			);


I think you could reserve directly without this check. If you can not reserve, you will get an error

I was thinking it would be cheaper in cases where reserve was not available to try and check before reserve, but we can also remove if wanted as well.

No strong opinion here 👍🏻. It's just I'm always checking lines that could be removed 😆.

To give my reasoning, I think in case of an error, the weight of this call will be the same, which is higher than the computation time the node wasted on it for an error. The weight will be added to the current block weight as if the call was ok. So, from my understanding, we would not be saving computation or making it cheaper.

All of the reserve checks except the reserve check before the transfers to ensure enough funds can actually be transferred were removed. Also just Found/fixed an error with fund check & added tests when double checking again for extra superfluous checks.

pallets/order-book/src/lib.rs

lemunozm

Second review round, mostly questions to understand it better and some suggestions. I would appreciate another eyes on this 🙌🏻.

Thanks for your work on this! It's pretty complex and seems like you've thought in weird border cases.

runtime/development/src/lib.rs

lemunozm · 2023-07-27T17:36:17Z

pallets/order-book/src/lib.rs

+		/// amount, as the first iteration will not have partial fulfillment
+		#[pallet::call_index(0)]
+		#[pallet::weight(T::Weights::create_order_v1())]
+		pub fn create_order_v1(


Curious about why _v1() here

Ah, the initial orders are pretty simple, it's currently just specifying a buy price with full fulfillment, but we're going to have partial fulfillment as well in the future, so I wanted to make sure that we could add that functionality in the future without having to modify an existing extrinsic.

Ok 👍🏻 . Anyways, from my understanding, I think it's not a problem if the existing extrinsic is modified later, communicating a break API change (or internal change)

I would also change that. We could rather have another create_order_with_partial or so in the future

lemunozm · 2023-07-27T17:38:42Z

pallets/order-book/src/lib.rs

+		///  Cancel an existing order that had been created by calling account.
+		#[pallet::call_index(1)]
+		#[pallet::weight(T::Weights::user_cancel_order())]
+		pub fn user_cancel_order(origin: OriginFor<T>, order_id: T::Hash) -> DispatchResult {


Maybe cancel_order without user_ prefix (?). Is it added because of name collision with the trait?

Yeah, it's the name collision with the trait, so wanted to specify that this would be the one callable by users.

I think it is totally fine having both names at the same time. If the user wants to call the trait once, they can use <Self as Trait>::cancel_order(). I would also say that user_ is a generic word, it changes depending on the context: every call has a "user" who calls it. So not sure if it express the idea you want.

Anyway, nitpick things not mandatory!

lemunozm · 2023-07-27T17:44:08Z

pallets/order-book/src/lib.rs

+				&account_id,
+				sell_amount,
+			)?;
+			Self::remove_order(order.order_id)?;


It's probable the front-end wants, sooner or later, to show the closed orders. We should probably add a new "closed orders" storage to allow front-end people to fetch it and show the user that a previous order was already fulfilled and closed.
cc @mustermeiszer @wischli

Anyways, not blocking, I think it's something we can add later in case of needing it.

I am a little concerend about storage in this case. But I agree, that it would be nice.

lemunozm · 2023-07-27T17:55:04Z

pallets/order-book/src/lib.rs

+			T::TradeableAsset::unreserve(
+				order.asset_out_id,
+				&order.placing_account,
+				order.max_sell_amount,
+			);


Out of curiosity, why reserve/unreserve and not hold/release?

I was using reserve/unreserve as those where provided by orml via MultiReservableCurrency, which seemed the safest bet for foreign asset trades. But hold/release do seem more preferable here.

Not sure exactly what the difference is, TBH. Is it the same thing, or one of them does some transfer under the hood?

pallets/order-book/src/lib.rs

lemunozm · 2023-07-27T18:08:33Z

pallets/order-book/src/lib.rs

+				Error::<T>::InvalidAssetId
+			);
+			<NonceStore<T>>::try_mutate(|n| {
+				*n = n.ensure_add(T::Nonce::one())?;


Totally nitpick: there is a ensure_add_assign for these cases

lemunozm

Approved! We can merge it to unlock Apps team. Thanks for your work on this Thea! 🙌🏻

Anyways, I would love to have other eyes on it, because I'm not fully inmersed in this topic. Would be great to have a postmorten review maybe from @mustermeiszer @wischli

mustermeiszer

Maybe I am missing something, but I think we are missing some essential decimal conversion.

Furthermore, I am not understanding sell_price_limit. ^^ I need an example with numbers here. @thea-leake

mustermeiszer · 2023-08-08T07:46:19Z

libs/traits/src/lib.rs

+	/// Returns the order id created with by this buy order if it could not
+	/// be immediately and completely fulfilled.


This is misleading. IF the order is to be fulfilled directly, we can not return an OrderId but the return type is Result<OrderId, DispatchError>. We should either change the docs or change the return type.

mustermeiszer · 2023-08-08T07:47:06Z

libs/traits/src/lib.rs

+	/// `sell_price_limit` defines the lowest price acceptable for
+	/// `currency_in` currency when buying with `currency_out`. This


Would love to have an example here with numbers. ^^

mustermeiszer · 2023-08-08T07:48:44Z

pallets/order-book/src/mock.rs

+cfg_test_utils::mocks::orml_asset_registry::impl_mock_registry! {
+		RegistryMock,
+		CurrencyId,
+		ForeignCurrencyBalance,
+		CustomMetadata
+}


of course. Was the old approach before we had your mock builder.

mustermeiszer · 2023-08-08T11:10:41Z

pallets/order-book/src/lib.rs

+		/// amount, as the first iteration will not have partial fulfillment
+		#[pallet::call_index(0)]
+		#[pallet::weight(T::Weights::create_order_v1())]
+		pub fn create_order_v1(


I would also change that. We could rather have another create_order_with_partial or so in the future

mustermeiszer · 2023-08-08T11:15:53Z

pallets/order-book/src/lib.rs

+		/// Fill an existing order, fulfilling the entire order.
+		#[pallet::call_index(2)]
+		#[pallet::weight(T::Weights::fill_order_full())]
+		pub fn fill_order_full(origin: OriginFor<T>, order_id: T::OrderIdNonce) -> DispatchResult {


@Chralt98 do you have an idea on how to realise the whale-eat-small situation?

I am curious what thoughts you already had on this and what is to be considered to make this efficient?

Do you think a fill_orders(origin: OriginFor<T>, order_ids: Vec<T::OrderIdNonce>) would be sufficient? The whale could compute off-chain what is the best. We could even do fill_orders_partial(origin: OriginFor<T>, order_ids: Vec<(T::OrderIdNonce, Perquintill)>) allowing to partially fulfill orders.

A dedicated runtime api for computing the needed T::OrderIdNonces could provide an easy and long lasting API for front-ends/

mustermeiszer · 2023-08-08T11:32:51Z

libs/traits/src/lib.rs

+	/// Swap tokens buying a `buy_amount` of `currency_in` using the
+	/// `currency_out` tokens. The implementator of this method should know
+	/// the current market rate between those two currencies.
+	/// `sell_price_limit` defines the lowest price acceptable for


Shouldn't this be the hightest accetable price?

mustermeiszer · 2023-08-08T11:57:11Z

libs/traits/src/lib.rs

+	/// Swap tokens buying a `buy_amount` of `currency_in` using the
+	/// `currency_out` tokens. The implementator of this method should know
+	/// the current market rate between those two currencies.
+	/// `sell_price_limit` defines the lowest price acceptable for


I think I am not understanding the sell_price_limit. Would this be the minimum amount of currency_in a user wants to get for 1 unit of currency_out?

I understand sell_price_limit as a way of protecting my order against a big conversion ratio.

So, if I want to buy 10 selling 20, it will be ok if sell_price_limit is 30, but if the conversion drops to 0.25, then I would not sell 40 to buy 10. (double-check this @thea-leake)

Would this be the minimum amount of currency_in a user wants to get for 1 unit of currency_out?

I understand define it as the maximum amount of currency_out I would give for getting the buy_amount of currency_in

as we use it as buy_amount.ensure_mul(sell_price_limit) I think it is not as you described it above, right? In your example it would rather be

buy_amount = 10.00

sell_price_limit = 0.5

But I think we are having a logical bug here.

mustermeiszer · 2023-08-09T06:49:16Z

pallets/order-book/src/lib.rs

+		type TradeableAsset: MultiReservableCurrency<
+			Self::AccountId,
+			Balance = <Self as pallet::Config>::ForeignCurrencyBalance,
+			CurrencyId = Self::AssetCurrencyId,


I think this should be a Substrate native trait instead of orml one.

mustermeiszer · 2023-08-09T06:49:42Z

pallets/order-book/src/lib.rs

+		/// Type for currency orders can be made for
+		type TradeableAsset: MultiReservableCurrency<
+			Self::AccountId,
+			Balance = <Self as pallet::Config>::ForeignCurrencyBalance,


The Balance type should be equal for Reservable and ForeignCurrency

mustermeiszer · 2023-08-09T06:51:41Z

pallets/order-book/src/lib.rs

+			// might need decimals from currency, but should hopefully be able to use FP
+			// price/amounts from FP balance
+
+			let sell_amount = order.buy_amount.ensure_mul(order.price)?;


IIUC we are missing decimal conversion here. WDYT?

Yes... I think you're right. If used Balance here have different decimal representation, we should unify them.

Yeah, I think you're right, as we're dealing with the overall balances and not the adjusted precision from the registry.

Regarding the conversions, in the Oracle PR, I add a module to perform that kind of conversions. Maybe you can extend that module @thea-leake
with a balance_to_balance() conversion: https://github.com/centrifuge/centrifuge-chain/pull/1474/files#diff-833d286c0e9655fa1b12da1bceabc7ff8988d1c74b7149be553320af61b78b54

Hopefully this PR is merged today or tomorrow

mustermeiszer · 2023-08-09T07:04:26Z

I also think we should make sell_price_limit a FixedPointType and name it sell_rate_limit. @lemunozm or do you think this is misusing Rate where we need a Balance?

If I get it right, this limit is saying. I want at least $x\frac{CurrencyOut}{CurrencyIn}$

lemunozm · 2023-08-09T07:31:10Z

From my understanding of this:

I would define it as a Rate and name it sell_rate_limit if it is defined as: $\frac{CurrencyOut}{CurrencyIn}$
I would define it as a Balance and name it sell_price_limit (as it is) if it is defined as: $x\frac{CurrencyOut}{CurrencyIn}$

mustermeiszer · 2023-08-09T07:49:29Z

Agreed! I think we use as $\frac{DecimalAdjustedCurrencyOut}{DecimalAdjustedCurrencyIn}$. In my head it speaks as

sell_rate_limit = I want to pay at most sell_rate_limit of CurrencyOut for each unit of CurrencyIn

thea-leake · 2023-08-09T10:46:24Z

Yeah, I agree it should be a rate; I think having the prices as Fixed Points would be much easier to reason about from a usage perspective.

lemunozm · 2023-08-09T11:10:09Z

The Rate/Balance issue greets again 😆. Yes, I thought about that too, maybe from the perspective of this pallet, prices should be Rate, but the issue is that the current accounts for the currencies are Balance, so you are tied to use Balance and add the conversions inside this pallet...

mustermeiszer reviewed Jul 15, 2023

View reviewed changes

Chralt98 reviewed Jul 20, 2023

View reviewed changes

lemunozm reviewed Jul 24, 2023

View reviewed changes

pallets/order-book/Cargo.toml Outdated Show resolved Hide resolved

thea-leake force-pushed the add_orderbook_from_zg_ref branch from 0e66add to 6df9f8d Compare July 25, 2023 13:13

thea-leake marked this pull request as ready for review July 25, 2023 13:50

thea-leake requested review from mikiquantum, branan, NunoAlexandre, wischli and cdamian as code owners July 25, 2023 13:50

thea-leake changed the title ~~WIP Add orderbook~~ Add orderbook Jul 25, 2023

lemunozm reviewed Jul 25, 2023

View reviewed changes

lemunozm reviewed Jul 27, 2023

View reviewed changes

pallets/order-book/src/lib.rs Show resolved Hide resolved

lemunozm reviewed Jul 27, 2023

View reviewed changes

pallets/order-book/src/lib.rs Outdated Show resolved Hide resolved

lemunozm reviewed Jul 27, 2023

View reviewed changes

thea-leake force-pushed the add_orderbook_from_zg_ref branch from 0a2ea5a to fd754cc Compare July 28, 2023 11:20

thea-leake added 10 commits August 1, 2023 12:35

Init work on new orderbook pallet

106004d

Add more needed currency and storage types

21abbe5

Fix types for registry, nonce, assets. Fix toml imports.

b4bb281

Fix types for registry, nonce, assets. Fix toml imports.

d8c73a4

Add extrinsics sigs for now.

4447cc6

Add orderbook order creation extrinsic

2c8e472

Add asset order pair vec

721f2da

Add cancel order

daae3b3

Add partial fill

27e7070

Add rest of claim order.

c8ca7ff

thea-leake added 17 commits August 1, 2023 12:35

Format orderbook Cargo.toml

cac7d2b

Fix clippy warnings, remove FE order getting fns

be5c435

Add AssetPairOrders docstring

350ea8e

Update docstrings and formatting

b07c947

Remove superfluous struct.

4f6f6e9

Consolidate reserve when asset out is fee currency.

8baf5eb

Add test for consoldated reserve

d50dc72

Switch reserve consolidation to use native balances

23c9f9b

Removed type/reserve calc dup code

7a7b949

Update reserve/unreserve uses native when outgoing asset native

2bf7260

Switch orderpair vec size to pallet::const

8da79b2

Switch to Nonce for Orderbook OrderIds

7c82219

Add tests for updated reserve/unreserve with same out/fee currency

c7403d4

Update fill_order_full for consolidates reserve/unreserve

51915a6

Consolidate shared unreserve functionality.

7d1c618

Remove superfluous asset checks

e629e83

Add unreserve order docstring

31e65bf

thea-leake force-pushed the add_orderbook_from_zg_ref branch from 8696ba5 to 31e65bf Compare August 1, 2023 10:36

Fixed err in transferable funds check for full fullfillment.

880f439

lemunozm previously approved these changes Aug 1, 2023

View reviewed changes

Update trait docstring for place_order

74ec895

thea-leake dismissed lemunozm’s stale review via 74ec895 August 1, 2023 16:13

lemunozm approved these changes Aug 1, 2023

View reviewed changes

thea-leake merged commit 7b57d77 into centrifuge:main Aug 2, 2023
11 checks passed

mustermeiszer reviewed Aug 9, 2023

View reviewed changes

		/// Returns the order id created with by this buy order if it could not
		/// be immediately and completely fulfilled.

		/// `sell_price_limit` defines the lowest price acceptable for
		/// `currency_in` currency when buying with `currency_out`. This

Add orderbook #1429

Add orderbook #1429

Conversation

thea-leake commented Jun 29, 2023 • edited Loading

Description

Changes and Descriptions

Checklist:

mustermeiszer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Chralt98 Jul 20, 2023 • edited Loading

Choose a reason for hiding this comment

Chralt98 Jul 20, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lemunozm left a comment

Choose a reason for hiding this comment

thea-leake commented Jul 25, 2023

lemunozm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thea-leake Jul 26, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lemunozm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lemunozm Jul 28, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lemunozm Jul 27, 2023 • edited Loading

Choose a reason for hiding this comment

lemunozm left a comment • edited Loading

Choose a reason for hiding this comment

mustermeiszer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mustermeiszer commented Aug 9, 2023

thea-leake commented Jun 29, 2023 •

edited

Loading

Chralt98 Jul 20, 2023 •

edited

Loading

Chralt98 Jul 20, 2023 •

edited

Loading

thea-leake Jul 26, 2023 •

edited

Loading

lemunozm Jul 28, 2023 •

edited

Loading

lemunozm Jul 27, 2023 •

edited

Loading

lemunozm left a comment •

edited

Loading

mustermeiszer commented Aug 9, 2023 •

edited

Loading