Transaction Lifecycles
Deposits from L1
Depositing L1 funds to Spark is straight-forward. The SE and user collaborate to generate an aggregate public key and derive a pay-to-taproot address from it. They then work together to create and sign two transactions: an exit transaction, and an intermediate branch transaction before it that triggers the exit transaction’s relative timelock. Once these transactions are both signed, the user can finally broadcast the deposit transaction to the pay-to-taproot address. Note that the inputs to the funding transaction should be segwit inputs. The user will now have a leaf in Spark.
Steps-by-Step Process
-
Key Generation:
- The user and SE work together to generate an aggregate public key, which is the sum of the user’s public key and the SE’s public key (which itself is derived from the individual SO public keys). They then derive a pay-to-taproot address for this key.
- where
- and is the Lagrange Coefficient on for
-
Setup and Signing:
- User constructs a deposit transaction sending their funds to the pay-to-taproot address, but doesn’t broadcast it.
- User and SE collaboratively create and sign two transactions:
- An intermediate branch transaction (not broadcasted) with no timelock that spends from the deposit transaction. This transaction triggers the relative timelock of leaves under it.
- An exit transaction that spends from the intermediate transaction. This transaction is broadcasted if the user wants to unilaterally exit Spark.
- Both transactions are signed by all parties involved in order to provide a unilateral exit path. Spark-compatible wallets should verify the transaction validity of all transactions involved.
-
Storage:
- User and SE securely store the signed transactions
-
User Deposit and Confirmation:
- User broadcasts the deposit transaction created in step 2. Once the L1 transaction has been confirmed, the funds are available to transfer within Spark.