doc readme

pallets/duniter-account/README.md

 # Duniter account pallet
 
-Duniter customizes the `AccountData` of the `Balances` Substrate pallet. In particular, it adds a field `RandomId`.
+Duniter customizes the `AccountData` of the `Balances` Substrate pallet. In particular, it adds the fields `random_id` and `linked_idty`. 
 
 ## RandomID
 
@@ -15,3 +15,7 @@ DuniterAccount defines a creation fee that is preleved to the account one block
 ## Sufficient 
 
 DuniterAccount tweaks the substrate AccountInfo to allow identity accounts to exist without existential deposit. This allows to spare the creation fee.
+
+## Linked identity
+
+Duniter offers the possibility to link an account to an identity with the `linked_idty` field. It allows to request refund of transaction fees in `OnChargeTransaction`.
\ No newline at end of file

pallets/quota/README.md

@@ -5,7 +5,25 @@ Duniter identity system allows to allocate quota and refund transaction fees whe
 ## General behavior
 
 Quota system is plugged to transactions fees which is a rather critical aspect of substrate.
-That's why in quota pallet `OnChargeTransaction` implementation, the default behavior is preserved, and refunds are added to a queue handeled in `on_idle`.
+That's why in `duniter-account` pallet `OnChargeTransaction` implementation, the default behavior is preserved, and refunds are added to a queue handeled in `on_idle`.
+
+## Path for a refund
+
+This is what happens on a transaction:
+
+- `frame-executive` calls `OnChargeTransaction` implementations
+- `duniter-account` `OnChargeTransaction` implementation is called, and if an identity is linked to the account who pays the fees, `request_refund` is called
+- `request_refund` implementation of `quota` pallet determines whether the fees are eligible for refund based on the identity and then call `queue_refund`
+- `queue_refund` adds a refund to the `RefundQueue` which will be processed in `on_idle`
+- during `on_idle`, `quota` pallet processes the refund queue within the supplied weight limit with `process_refund_queue`
+- for each refund in the `RefundQueue`, `try_refund` is called
+- it first tries to use quotas to refund fees with `spend_quota`
+- if a certain amount of quotas has been spend, it actually performs the refund with `do_refund`, taking currency from the `RefundAccount` to give it back to the account who paid the fee
+
+The conditions for a refund to happen are:
+
+1. an identity is linked to the account who pays the fees
+1. some quotas are defined for the identity and have a non-null value after update
 
 
 ## TODO