Programmability support in the Plasma Next Mainnet is currently under development. The contents of this document cannot be tested on the Mainnet at present. Please wait until the support is fully implemented.
In this example, we consider a scenario where Alice, who holds ETH on Plasma Next, conducts an Atomic Swap with Bob, who holds DAI on the same platform. The flow of ETH and DAI follows the diagram below.
Here, we discuss the ZKPTLC for transfers from Alice to the operator. The ZKPTLC for transfers from the operator to Bob is exactly the same. The ZKPTLC for transfers from Alice to the operator is conditioned on two airdrops: one is an airdrop of ETH from the operator to Bob, and the other is an airdrop of DAI from the operator to Alice. Illustrated, this would look as follows: compared to Plasma Next's Default ZKPTLC, there is one additional condition related to the airdrops.
The instance of the ZKPTLC must be bound to the transfer from Operator to Bob and the transfer from Operator to Alice. To generalize, let's call them transfer1 and transfer2, respectively. The instance should be the hash values of these two transfers.
We use the same _verifyExistence function as the default ZKPTLC. This internal function verifies that the given transfer exists in Plasma Next.
function_verifyExistence(ITransfer.Transfermemory transfer,IMerkleProof.EvidenceWithMerkleProofmemory proof) internalview {if (transfer.transferCommitment() != proof.leaf.transferCommitment) {revert("Transfer commitment does not match"); }IRootManager(rootManagerAddress).verifyEvidenceMerkleProof(proof);}
Let's implement VerifyCondition. The witness consists of transfer1, transfer2, and their corresponding settlement proofs proof1, proof2. Decode the witness from bytes, ensure it matches the instance, and then pass it through the _verifyExistence function we implemented earlier.