And the async communication nature of a separate relay server for txs. However, I believe our novel solution comes close to doing so. 2.) The Solution: Epicbox Protocol Tx Cancellation Extensions & Reflection At their most reduced, a mimblewimble transaction has essentially 3 steps: Step 1: Sender chooses blinding factor, selects inputs to spend + change ouputs, and sends partially constructed tx to receiver Step 2: Receiver adds their blinding factor, and constructs their partial signature on kernel Step 3: Sender finalizes the tx by completing tx kernel signature, resulting tx satisfies mimblewimble balancing equation and posts to network. Our solution allows for tx cancellation to be automatic (understood by Epicbox Relay Server, sender, and receiver), and works reliably at any state of this transaction negotiation prior to "post to network" step. We accomplish this by adding the following: 1.) A cancelledSlates database for tombstones of sender or receiver requested cancellation of a slate in progress 2.) Protocol extensions for CancelTransaction requests to Epicbox Server (may come from either sender or receiver, for an in-process tx) 3.) TxCancelled protocol response messages to sender/receiver wallets (an echo of successful slate cancellation from epicbox) 4.) Automatic local cancellation via BOTH sender and receiver wallets, after receiving the TxCancelled message over epicbox relay protocol 5.) Persistent cancelledSlates DB, persistent removal from slates DB via epicbox. Queued delivery to each wallet at least once for cancelled transactions. 6.) A persistent EpicboxTxId identifer (32 hexadecimal characters) for use within all steps above as a tracking ID. In the coming upgrade (Epicbox Protocol v3.1.0), we will have compatibility for all of these features. I wrote things such that they are 100% backwards compatible with our existing Epicbox Protocol v3.0.0 and below. This will be available in all of Epic Wallet CLI, Stack Wallet, and Epicbox Server. The mechnism is wired together as follows: 1.) Sender chooses an EpicboxTxId upon sending tx 2.) Sender or receiver requests a transaction to be cancelled via ProtocolRequestV2::CancelTransaction to epicbox relay by EpicboxTxId 3.) Relay removes the slate in question from slates DB. A tombstone for the cancelled slate is added to cancelledSlates DB 4.) Relay then sends ProtocolResponseV2::TransactionCancelled to both sender and receiver 5.) Sender and receiver both field this response, and automatically call local tx cancellation These steps are gated by a signature over our new EpicboxTxId type, which is a 32-character UUIDv4, and completely distinct from local UUIDs and/or epicboxmsgid. The EpicboxTxId is strictly a stable identifier that persists over the 7-day TTL of a slate. We expect to update this design further once all epicbox relay servers are upgraded, and wallets are upgraded as well - with plans to deprecate the old protocol messages altogether, in time.