Yonatan Sompolinsky and Michael Sutton gave back-to-back talks on 26 October at the Mid-Chain DeFi Conference, hosted by Ben-Gurion University of the Negev in Israel. Sompolinsky, a co-author of GHOSTDAG, the consensus protocol Kaspa runs on, presented new research on orders that carry themselves out while their owners are offline. Sutton, a Kaspa core developer, explained DAGKnight, the consensus design he and Sompolinsky have worked on for years. It aims to keep a proof-of-work network safe without deciding in advance how slow the network is allowed to get.
Both talks are in the event recording that Web3 Devs Underground posted on YouTube, and each player below starts where the speaker begins. Sutton shared the live stream with his followers on X.
Orders that run while their owners sleep
Sompolinsky opened by thanking Aviv Zohar, who spoke earlier that day and whom he called "my academic father". The research began a few years ago with his Harvard advisor David Parkes and Xintong Wang of Rutgers University. Kaspa core developer Ori Newman joined later and, in Sompolinsky's words, "has contributed basically to the main results". The four have published it as a paper on arXiv.
He started with the crypto crash of 10 October 2025. His slide put it at about $19 billion liquidated in 24 hours, $3.2 billion of it in a single minute. Traders in the West could at least try to protect themselves, for example by moving funds from one exchange to another. Traders who were asleep, typically in Asia, were at a big disadvantage, he said. Even traders at their screens struggled. Some systems were overloaded, some fee systems broke down under the strain, and getting a transaction through meant paying ever higher fees.
He also recalled the FTX collapse, when an insider pulled funds out while ordinary users who wanted to do the same could not.
His idea is to let people set up their reaction before the shock. You would hand the engine a condition and an action in advance, such as "If Bitcoin crashes more than 10% within two minutes, please move my funds to USDT." In his words, "It's basically on-chain, if this, then that service." Automation like this already exists, but it usually runs off-chain through brokers and third-party networks. When it does run on-chain, it handles only simple logic such as stop-loss orders.
He was careful about where such an engine could run. "It can be a blockchain engine. It can be a centralized engine. The decentralization here is not a primary element of the system." His slide framed it as an open question for DeFi, whether actions committed in advance could change liquidation races and cascades, and added "No prevention claim."
Why it is a Pandora's box
The hard part is deciding what the engine should check first. Checking whether a condition is true only reads the state, and reads can happen in any order. Acting on the result is different. Only one order gets the next slot to change the state, and "When Alice does this before Bob, she benefits more." Every extra check also delays that next trade, so the engine can't simply check everything.
The team found that this matches a classic puzzle known as Pandora's box. You face several boxes, each with a different chance of holding a prize of a different size, and opening a box costs something. His example was one box with a 10% chance of holding $50 and another with a 2% chance of holding $1 million. The skill is opening the right boxes in the right order. Here the boxes are the users' conditions, and the prize is the right to trade first.
Then real people enter the picture. Users can send dishonest reports about how likely their condition is to trigger and, in the fuller model, how much the trade is worth to them. Nobody shares one agreed view of the odds either, so the researchers could not simply measure which design leaves everyone better off.
He gave a famous example from economics, with himself and Newman in it. The two argue over whether a pillow hides a gold brick, bet $10,000 on it and tear the $50 pillow open to settle it. Each of them believes he has won, yet together they destroyed $50. Economist Itzhak Gilboa and colleagues proposed a rule, called no-betting Pareto dominance, so that bets like this don't count as a gain. The paper argues that this rule doesn't fit mechanism design and builds a new yardstick, which it calls dynamic No-Betting Revenue.
What the research solves and what it leaves open
The main results are two mechanisms, which the paper calls RW and RWSP. Under the conditions the paper sets out, both earn a constant fraction of that yardstick. Sompolinsky was frank about the limits. "We have solved the one-shot game, and this creates more problems than it solves."
The next step is the "dynamic game" that follows once an if-this-then-that engine runs on-chain and people no longer need brokers. He called the open problems a "Pandora box of questions", a roadmap the team hopes will let them prove what such a system can guarantee. He hopes to have more clarity "in the next year or so" and invited other researchers to help him and Newman finish the project. He did not link the design to Kaspa or announce plans to build it there.
DAGKnight and the delay problem
Sutton introduced his talk as joint work with Sompolinsky, then added, "Maybe I should say a joint adventure, because it's quite a few years." DAGKnight is a proof-of-work consensus protocol that stays secure as long as attackers hold less than half of the hash rate and, as he put it, "does not require an embedded a priori delay assumption".
The delay he means is the time a new block takes to reach the other miners. He used Bitcoin to show why it matters. With 65% of the hash rate honest and delays of about one minute, four hours of honest blocks line up into one chain of 16. If an attacker can stretch delays to 30 minutes, the same blocks only make a longest chain of 6 and the rest are left behind. A 35% attacker with 9 blocks then wins, and "this cannot be remedied by waiting". Bitcoin's 10-minute blocks, he said, quietly assume delays of one or two minutes at most.
Theory seems to rule out a fix. A known result says a protocol that doesn't know the delay can't survive attackers who hold more than a third of the votes, and researchers later extended it to proof of work. DAGKnight gets around this by splitting the job. Miners keep mining and ordering blocks without knowing any delay. Each user, when deciding whether a payment is final, plugs in their own assumptions, how much of the hash rate an attacker might control and the longest delay they believe the network could have. In Bitcoin, plugging in 30 minutes means you can never be sure. In DAGKnight, the risk still falls toward zero for any delay you choose, as long as it is finite.
From GHOSTDAG to DAGKnight
In a blockDAG, each new block points to every block its miner has seen, not just one parent. That record shows how well connected the honest miners are. GHOSTDAG, the protocol Kaspa uses today, has a setting called K that limits how many parallel blocks count as normal. K is really a built-in guess about the delay. If the network ever gets slower than that guess, GHOSTDAG can break the way Bitcoin does. If the guess is generous, confirmations are paced by that worst case rather than by how fast the network really is.
In his example K was 5 while the honest network was running with delays of about one second. A hidden attacker with just five blocks could build a group the rule counted as just as large as the honest one, and could win, even though it was "very, very clear to the eye that the honest side is much more connected".
DAGKnight flips the question. Instead of taking K as a fixed setting, it searches for the smallest K at which a group of blocks connected that tightly, called a K-cluster, covers at least half of the DAG. Sutton compared it to a detector that finds the most connected group still holding a majority and orders the ledger around it.
He said "the protocol itself is way more involved" and zoomed in on one rule, which he called uniform majority coverage. A winning group must cover at least half of the blocks overall, and it must also cover at least half of the blocks that came after each of its own blocks. Without that second test, an attacker could borrow honest blocks to build a rival group, bank a lead over time and lean on it when the network hits a bad stretch, keeping it from making decisions. With it, the rule "keeps all K-clusters on the verge of losing", so no group can bank an advantage. The full design is in the DAGKnight paper.
Where DAGKnight stands
Neither talk gave a launch date. The code is being built on a separate dagknight branch of Rusty Kaspa, the Rust node software. That branch holds 129 commits that are not in the main branch yet, including code for uniform majority coverage. Nothing new has been merged into it since 8 September. Bigger pieces are still open, such as a rewrite of how DAGKnight resolves conflicts, where reviewers have asked for changes. The branch already has settings for a dedicated DAGKnight testnet (earlier coverage), and DAGKnight is not part of any Rusty Kaspa release yet.
The 31 October remark
Sompolinsky came back on stage later as a surprise guest on the closing panel, which featured cryptographer Yehuda Lindell. Near the end, the host reminded everyone that next week is 31 October and asked what that means. "White paper," came the answer from the panel, meaning the Bitcoin white paper, published on 31 October 2008. Sompolinsky then raised his microphone and said he thought they had released DAGKnight around that time. The DAGKnight paper did first appear on the IACR ePrint archive on 31 October 2022.
One viewer on X asked whether it was a hint, but nothing in the exchange gave a launch date.
