Як підписані транзакції призвели до втрати $285M в Solana

Останні новини знову розганяють тезу «Solana зламали». Звучить гучно, але якщо дивитись на факти — проблема не в самому блокчейні.

Це історія про те, як правильно підписані транзакції можуть виглядати легітимно... і при цьому вивести сотні мільйонів.

Що реально сталося

У випадку з одним із великих DeFi-протоколів в екосистемі Solana (йдеться про ~$285 млн збитків) атака не ламала мережу.

Було використано:

• попередньо підписані транзакції
• доступ до multisig
• логіку відкладеного виконання

Ключова ідея проста:

транзакції підписали заздалегідь, а виконали пізніше, коли умови стали вигідними для атакера.

І саме це виглядає як «магія» для тих, хто не заглиблювався в механіку Solana.

Як працює ця схема

У Solana транзакція — це не «переказ», а набір інструкцій, які користувач підписує.

Спрощено:

const transaction = new Transaction().add(
  someProgramInstruction(...)
);
transaction.feePayer = userPublicKey;
transaction.recentBlockhash = blockhash;
const signedTx = await wallet.signTransaction(transaction);

Після підпису транзакція вважається валідною.

Але є нюанс.

Durable Nonce

Solana дозволяє використовувати так званий durable nonce, щоб транзакція залишалась валідною довше, ніж стандартний blockhash.

const nonceAccount = await connection.getNonce(noncePubkey);
transaction.recentBlockhash = nonceAccount.nonce;

Це означає, що транзакцію можна:

• підписати зараз
• виконати через хвилини або навіть пізніше

Де саме відбулася атака

1. Атакер отримує довіру або доступ до multisig

(через соціальну інженерію або інші методи)

2. Учасники підписують транзакції

Вони виглядають як звичайні операції:

• оновлення параметрів
• управління ліквідністю
• технічні дії

3. Транзакції не виконуються одразу

Вони «чекають» свого моменту

4. Атакер змінює умови (ціни, collateral, ліквідність)

Наприклад, через штучний актив або маніпуляцію ринком

5. Виконує вже підписані транзакції

І тут найцікавіше:

система сама виконує валідні підписані інструкції

Результат — масове виведення коштів (~$285M) за лічені хвилини.

Чому це не «злам блокчейну»

Solana спрацювала правильно:

• підпис є → транзакція валідна
• nonce актуальний → транзакція приймається
• інструкції коректні → виконуються

Проблема — не в криптографії.

Проблема — в логіці системи навколо.

Ще одна слабка точка — permission model

Багато протоколів використовують делеговані дозволи.

Наприклад:

const approveIx = createApproveInstruction(
  tokenAccount,
  delegate,
  owner,
  amount
);

Користувач або multisig може:

• надати доступ
• не повністю розуміти наслідки

👉 І цей доступ потім використовується в іншому контексті.

Де помилилися розробники

Типові проблеми:

1. Відсутність «time-aware» логіки

Система не перевіряє:

• коли була підписана транзакція
• чи змінились умови з того часу

2. Надмірна довіра до підпису

Підпис = істина

Але в реальності:

• підпис може бути отриманий за інших умов
• або без повного розуміння наслідків

3. Відсутність перевірок стану перед виконанням

if (collateralValue > threshold) {
  execute();
}

👉 Але якщо collateral штучний або маніпульований — ця перевірка нічого не варта.

4. Слабка сегментація доступу

Multisig ≠ абсолютна безпека

Якщо всі підписують «на автоматі» — це просто формальність.

Висновок

Це не історія про те, що «зламали Solana».

Це історія про те, що:

• користувачі підписують те, що не до кінця розуміють
• системи не перевіряють контекст
• логіка безпеки відстає від складності атак

У 2026 атаки — це вже не brute force.

Це:

• експлуатація логіки
• робота з поведінкою людей
• використання дозволених механізмів проти самих систем

І якщо дивитись чесно — це набагато складніше виправити, ніж баг у коді.