An update on the yesterday's PacaSwap incident: On August 24, an attacker exploited a flaw in Tessellation's fee-transaction accounting to create SWAP tokens that were never backed by deposits, then sold them into the SWAP/DAG liquidity pool. The pool's DAG reserves were drained as a result. I want to be direct about what happened, what we've done, and how we're handling the impact on liquidity providers. What happened. The attacker submitted a batch of fee transactions with amounts chosen to force an underflow, a subtraction that drops below zero and wraps the result around to a large positive number. The amounts also made the batch settle on figures that all looked correct: every balance finished valid and non-negative, and the totals reconciled, so inspecting the end state would not have found the problem. Catching this requires checking each transaction in the sequence rather than the result. The flaw was in one Tessellation code path, the one that applies fee transactions to balances. It was not a flaw in PacaSwap's logic, and not a compromise of any key, node, or wallet. The flaw was specific to metagraph fee transactions, which exist only where a metagraph runs both a Data layer and a Currency layer. No DAG was created, and DAG's supply is unchanged. Hypergraph consensus was never interrupted. The DAG that left the pool was real DAG contributed by liquidity providers. That is why we are replacing it. The attacker minted SWAP in a single snapshot, sold it into the pool over the following hours, and moved approximately 12.1 million DAG to exchange addresses. Those addresses are identified and have been shared with the relevant exchanges. PacaSwap's three other pools were unaffected and required no intervention. We halted the metagraph roughly four hours after the mint, which stopped further extraction. What we've fixed. Fee transactions are now applied one at a time through checked arithmetic that rejects any operation which would overflow or underflow a balance. The validation happens per transaction, not on the total. This shipped in Tessellation v3.5.26 and is live across the network. That release also activated stricter cryptographic verification of fee-transaction signatures and tightened validation on adjacent code paths. Hardening work in this area continues and is under independent review. Liquidity providers. Liquidity providers in the SWAP/DAG pool took a real loss when the pool's DAG reserves were drained. That loss is being covered. We reconstructed every trade in the affected window from on-chain data, all 132 transaction legs across 60 snapshots. - The pool will be restored. Constellation is injecting 11,974,147.51 DAG from treasury to return the SWAP/DAG pool to the reserves and price it would have held had the mint never occurred. That figure is sized to the pool's restored state, not to the amount the attacker took, because it also accounts for the DAG that buyers paid in during the window and the DAG still in the pool. Liquidity providers do not absorb this loss. - Users who bought SWAP during the window keep fair value. Ten addresses paid real DAG at prices the compromised pool was quoting. Rather than reversing those purchases, we replayed each one against the pre-incident price curve and each buyer keeps exactly what they would have received at a fair price. They are victims here, and they are not being penalized for trading during a window they had no way to identify. - The minted SWAP is being removed from circulation. The wallets that received the minted tokens, and the wallets that received those tokens onward without paying for them, are being reduced by the amount that was created. This is not a roll back, and no transaction history is being altered. The correction applies going forward, at a single future snapshot. The result will be fully visible one chain. Every figure above was derived from mainnet snapshots and is independently verifiable on-chain. Timing. The remediation is a single coordinated change across Tessellation and PacaSwap, and it has to land correctly the first time. It is in review now. We will not restart PacaSwap until that review is complete and verified, and we will announce the restart before it happens rather than after. What changes. The specific bug is closed, but the more useful question is why this path validated an end state instead of each operation that produced it. We are auditing the arithmetic across every balance-mutating path in the protocol on that basis, and expanding external review of this code. The bridge was closed as a precaution and will reopen when PacaSwap does. We'll post the restart plan and timeline as soon as the review clears. If you hold SWAP or provided liquidity, you do not need to do anything. There is nothing to claim, migrate, restore, or approve. No action on your part is required at any point in this process. Be careful of scams that claim otherwise. @conste11ation $DAG $SWAP