今日の午後、TermMaxダッシュボードでその問題に気づきました。

先ほどの小さなミスのあと、素早くエグジットして少し悪い約定になってしまったので、その後に小さな固定金利の借入をテストしていました。担保を固定してGTを鋳造し、さらに金利をロックするだけです。リクエストは通常より数秒長く引っかかってから、リトライを促されました。

私はキャパシティのせいだと思いました。紙の上ではそれが明白に見えたのです。

でも、それほど単純ではありませんでした。

それが最初の不一致です。

遅延スパイクとして見えていたものは、実際には「Confirmation ≠ Completion」でした。見えているクオートはライブで、パスも開いているように見えますが、全体のシーケンスはまだ完了していなかったのです。

リクエストはまずルーティングを通過し、その後、現在のレンジのオーダーカーブに対してモデルの利用可能性を確認し、担保の支払いロックを解除し、GT鋳造とFT/XT分割の検証を通過し、決済します。そしてその後になって初めて、繰り返しの利用が筋が通ってくる。

多くの人は、そうしたライブの金利がチェーン間で一貫している状態を保つキャッシュの判断を無視します。あるいは、カーブを維持しているキュレーターたちの背後にある静かな資本要件。

私は、その薄い層に何度も戻ってきます。

スパイクが孤立したものなのか、決済経路のどこか静かな部分を指していたのか、まだ分かっていません。

本当の需要スパイクの最中、またはコールドスタートによる混雑のあとに、同時リクエストがぶつかったらどうなるのでしょうか？

@TermMax #TermMax