Vessel

Vessel brings smart contract functionality to the XRP CBDC suite to enable asset tokenization for XRP-based CBDCs. Demonstrated in a deliver-vs-payment contract between XRP tokens and XRPL.

Comment

Inspiration

We wanted to bring the ability to tokenize assets to the XRP CBDC toolkit. Currently, this is not possible, because XRPL does not provide the ability to have Turing complete smart contracts. Our solution, based on a combination of Trusted Execution Environments and a layer of oracle nodes solves this.

What it does

We cater for two key use cases to solve the delivery of a token launched on the XRP CBDC toolkit vs. a payment in XRP CBDC numeraire or in XRPL. Specifically, we implement two use cases.

User Story 1: Create Trusted Contract

As a Trusted Contract Creator, I want to facilitate a secure trade between a Seller and a Buyer on the XRPL, So that I can help them solve the delivery versus payment problem.

Scenario:

  1. The Seller and Buyer agree on an XRPL denominated price for the token and share it with me.
  2. I access the web interface of the Orchestration Service.
  3. I click on "Create Escrow Account" and enter the agreed-upon price.
  4. The Orchestration Service communicates with the Oracle Node to initiate the "Create Escrow Account" flow.
  5. The Oracle Node communicates with the Signing Enclave, creating an XRPL wallet representing the escrow account and keeps the signing key secret using the protected sgx file system.
  6. The Signing Enclave returns the wallet address to the Oracle Node.
  7. The Oracle Node adds the wallet address to its list of monitored addresses.

Result: I receive a success message containing the wallet address of the "Escrow Account," enabling a secure trade setup for the Seller and Buyer. User Story 2: Delivery versus Payment

As a Seller or Buyer, I want to ensure a simultaneous exchange of token and payment on the XRPL, So that I can minimize settlement and credit risks in the trade.

Scenario:

  1. The Seller and Buyer agree on an XRPL denominated price for the token and share it with the Trusted Contract Creator.
  2. The Seller sends the token to the Escrow Account wallet address.
  3. The Oracle Node registers the receipt of the token.
  4. The Oracle Node informs the Execution Enclave about the received token, which the Execution Enclave securely stores and seals with its private key.

Once Payment is Received:

  1. The Oracle Node registers the receipt of payment.
  2. The Oracle Node informs the Execution Enclave about the payment received and the wallet address it was sent to.
  3. The Execution Enclave verifies that a token has been received for the given wallet address.
  4. The Execution Enclave securely constructs the signed transactions using the Signing Enclave.
  5. The Oracle Node receives the signed transaction, from the signing enclave, and appends it to the XRPL, completing the delivery versus payment process.

Result: The trade is successfully executed with simultaneous delivery of the token and payment, reducing risks and ensuring a secure transaction for the Seller and Buyer.

How we built it

We built the app mainly using Rust and Javascript, as well as the Angular framework for the frontend. The deployment is done using Netlify.

Challenges we ran into

Trusted Execution Environments do not have a state, i.e. they cannot natively know the current state of a blockchain. We overcome this challenge by introducing a set of oracle nodes that tell the TEE the ledger, as well as a Byzantine Fault Tolerant protocol within the TEE that ensures that our system is trustless outside of the TEE itself.

Accomplishments that we're proud of

We managed, for the first time, to bring smart contract like functionality to the XRP ledger. Since the Codius project, which was stopped several years ago, this has been a key missing piece for the creation of value chains on top of XRPL. In particular for a CBDC toolkit this is critical, though, since applications like asset tokenization require the functionality of smart contracts to realize the efficiency gains and cost savings relative to traditional securitization.

What we learned

Mainly how to ensure that a TEE trustlessly communicates with the XRP ledger. This has been a substantial technological challenge, but now that we have solved it, nothing prevents us creating a platform for Turing complete code execution on the XRP CBDC toolkit.

What's next for Vessel

Now that we have demonstrated the feasibility of our approach, we aim to demonstrate Turing complete code execution within our setup during Phase II of the CBDC Challenge to bring the full power of trusted contracts to the XRP CBDC ecyosystem.

Share this project:

Updates