The Lifecycle of a Scuba Transaction

To acquaint you with the different elements comprising the Scuba protocol, we'll take you through the transaction process step by step. This journey begins with a client generating a signed transaction and culminates in its confirmation on layer 1.

We'll also incorporate "finality checks" along the way, clarifying the assurances the client has regarding the finality of their transaction. These checks provide guarantees that the transaction's outcome is secure and will not be modified at a later stage throughout the transaction's progress.

To gain a better understanding of any unfamiliar terminology, please refer to our glossary.

1. Scuba Bundler Receives Operations from Client

Typically, a transaction's lifecycle starts with the Bundler after receiving a Send Operation from a client (the operation is different from a standard L1 transaction or a Scuba transaction (i.e. not compatible with either Host Network or Scuba) it only includes a data structure we use on Scuba for proof verification).

The Bundler receives Send Operations from clients, wraps and submits it to the Contracts in the next step. Note that the Bundler packages the Send Operation to be compatible with Scuba Protocol or Host network.

The Bundler also helps users pay fees. It also allows for custom fee types while avoiding revealing user addresses when paying for tx fee on Host Network.

2. Scuba Node Submits Scuba Block (Merkle Tree Update) to the Host Network

Upon receiving the “Bundle Operation”, the Scuba Node will:

• verifies Operations from the contracts

• submits the Merkle Update in the form of Scuba block (i.e. batch of Bundle Operation verify result) to the Scuba Contract onto the Host network. The Block is added to the Merkle Tree maintained in the Scuba Contract.

• The verification work on the Host Chain is very lightweight since most work is done by the node off-chain already (i.e. instead of replaying each transaction in the transaction history)

• "Instantly" gives a transaction receipt to the client ("instant" in that it doesn't require any additional on-chain conformations, and typically shouldn't take more than a second or two).

1. Scuba Contract Updates Merkle Tree

Upon receiving the “Merkle Update”, the Scuba Contract will:

• update the ledger with the new transfers within the Merkle Update. Note that the Merkle update is encrypted in the format of “ABAR”

1. Challenger Initiates a Challenge (before the transfer is finalized)

What if the transfers in the Merkle Update are questionable? Here is where the challenger comes into place:

• If a challenger finds a fraud transfer submitted by the Node, it will initiate a challenge on the Host network.

• If proven right (transfer is fraudulent) the dishonest Node’s staked tokens will be slashed to punish it for dishonest behavior.

1. New Merkle State is Confirmed on the Host Chain.

Once any and all disputes have been resolved and sufficient time has passed, the new Merle State can be confirmed on L1 and got updated.