docs: refactor technical doc

[smol-ninja]

Refactors technical doc in line with #312.

[smol-ninja]

@andreivladbrg so after the new update, the unlock interval takes into account the last withdraw time ($wt$) and not snapshot time ($st$) anymore. Thats what the PR is about.

I've updated the content. Without changing the numbers we can say that time values are considered since last withdraw time and not the last snapshot time. This will require updating the charts with the new labels.

Alternatively, I am in favour of removing the numbers and charts and only keep the theory part in brief to understand the precision problem. This is due to the fact that with numbers and charts, the cost of maintenance of the technical doc is non-zero. The purpose of the doc is to explain delays and precision issues in calculations of withdrawn amount which imo is already well explained. What do you think?

[andreivladbrg]

the unlock interval takes into account the last withdraw time ($wt$) and not snapshot time ($st$) anymore. Thats what the PR is about.

I don’t understand this very well. Can you please rephrase it?
As far as I can see, I think you wanted to change how we refer to the moment in time t. Changing st to wt is not precisely correct. For example, these constant intervals are not correct, as the constant interval starts from st up to the moment the withdrawal happened:

flow/TECHNICAL-DOC.md

Lines 393 to 395 in cf2a59f

	1. $[wt, wt + 86]$
	2. $[wt + 87, wt + 172]$
	3. $[wt + 173, wt + 259]$

Without changing the numbers we can say that time values are considered since last withdraw time and not the last snapshot time

The number shouldn’t be changed—the delay in the current example (rps = 0.000000_011574e18) should remain the same.

This will require updating the charts with the new labels

correct, will do

This is due to the fact that with numbers and charts, the cost of maintenance of the technical doc is non-zero. The purpose of the doc is to explain delays and precision issues in calculations of withdrawn amount which imo is already well explained.

The fact that the maintenance is non-zero is correct. I believe having concrete examples and clear graphs in our theory section will help external readers understand the delay issue more quickly and effectively. For us, it took a while to precisely understand what was actually happening, so I believe the cost is worth it to minimize future questions about the technical part.

[smol-ninja]

@andreivladbrg do you remember what we discussed about it last week? I forgot to make notes and now can't recall what we decided about this doc.

[andreivladbrg]

@andreivladbrg do you remember what we discussed about it last week? I forgot to make notes and now can't recall what we decided about this doc.

the most important thing we have discussed about was to we could define "withdraw previous time" and use the abbreviation $wpt$ instead of simple withdraw time. and in our specific example we can still use $st$ as we isolate the scenario to only withdrawals

flow/TECHNICAL-DOC.md

Lines 388 to 389 in b01cc2d

	We will now explain delay using an example of `withdraw` function. As defined previously, $[t_0,t_1]$ represents the
	timestamps during which ongoing debt remains constant. Let $t$ be the time at which the `withdraw` function is called.

that's what i remember

[smol-ninja]

@andreivladbrg I have made the suggested changes. Let me know if it looks good now.

[andreivladbrg]

@smol-ninja as discussed on slack, we should remove everything from this line and below

flow/TECHNICAL-DOC.md

Line 215 in 4c19888

### Problem 2: Minimum Transferable Value

since there is no more delay due to sd in 18 decimals, also it can be proved by these equality checks in the PR: #320

[smol-ninja]

Not that line. MVT is one of the two problems that led us to use 18-decimal fixed-point number for rps and sd. Everything from here should be deleted.

[smol-ninja]

looks good to me now.

[andreivladbrg]

lessss gooo, no more delay 🚀🚀