- Document Information
- Digital Pound Lab Infrastructure Integration Proposal
Phase 1 initiative
Version Control
| Version | Release Date | Pages |
|---|---|---|
| 1.0 | Jun 2, 2025 | 18 |
Document Information
Abbreviations
| Abbreviation | Meaning |
|---|---|
| API | Application Programming Interface |
| BoE | Bank of England |
| Corda | Corda is the open, permissioned distributed application platform developed by R3, powering the tokenization of assets and currencies in regulated markets. R3’s Corda leverages cloud-native technologies for scalable and configurable app deployments. |
| Gevamu | Gevamu is an Exactpro Group business unit focused on technology innovation in payments. Gevamu’s first product is a bridge between existing payment infrastructures and DLT platforms. It is accompanied by deployment, monitoring and testing tools, leveraging Exactpro’s AI capabilities, allowing for better reliability, operability, and adoption. |
| DLT | Distributed Ledger Technology |
| EVM | Ethereum Virtual Machine |
| KYC | Know Your Customer |
| PoS | Point of Sale: a system where retail transactions are completed, involving a merchant interface and a customer payment method |
| PSP | Payment Service Provider |
| UI | User Interface |
| CBDC | Central Bank Digital Currency. It is a digital version of a country's official currency, issued and controlled by its central bank. |
| QR code | Quick Response code. It is a type of two-dimensional barcode that stores information and can be quickly scanned using a smartphone or another QR reader. |
| PoC | Proof of Concept |
Related Documentation
Digital Pound Lab Infrastructure Integration Proposal
Introduction to the Proposal
This document provides a high-level Proposal for a solution integrated with the Digital Pound Lab Infrastructure to support three use cases selected for the Digital Pound Lab – Phase one participation. As a part of the Digital Pound Lab initiative, the selected use cases for Phase one will be developed as a proof of concept to showcase the workflows starting from registering on the platform, selecting items for purchase and checkout, payment QR code generation, ability to define cashback events and term, ability to issue cashback tokens, ability to define by the business owners the terms and conditions for the atomic swaps, ability for the delivery participant to add the respective transaction updates and ability to monitor transactions by their participants. The smart contracts will be developed in the local blockchain for initial testing and demonstrations with a design supporting transferability to the Bank of England Smart contract platform (ability to be deployed there and be settled).
Exactpro plans to utilise the Digital Pound Lab’s Smart contract platform (blockchain) and its respective components, as described in the corresponding section of the Lab documentation: Digital Pound Lab section. The goal is to evaluate how the developed smart contracts can be deployed (re-created) and executed within the Smart contract platform. Exactpro also intends to explore the atomic swap functionality provided by the platform. The built-in explorer functionality will be used for double-checking the transactions that took place on the platform.
The selected use cases for exploration and development in Phase 1 of the Digital Pound Lab are:
- Case 1: Enabling digital pound payments at point of sale, including cash-back,
Case 2: Enabling micro merchants to accept payments in digital pounds, - Case 4: Enabling conditional business-to-business payments.
Key Concepts of the Solution Design
| Term | Definition |
|---|---|
| Solution provider platform | A platform consisting of a set of interacting components and smart contracts, which are orchestrated to support the selected use cases. |
| BoE Smart contract platform | The smart contract platform provided by the Bank of England within the Digital Pound Lab. It is built using Hyperledger Besu and provides a secure environment for participants to test interoperability of the digital pound with digital assets and programmable ledgers. |
| Seller/ Supplier’s App | A web-based application designed to help sellers and suppliers manage their business operations. It enables tasks like inventory management, order processing, payment handling, QR code generation and communication with buyers and delivery companies. It integrates with blockchain for secure transactions and smart contracts. |
| Buyer/ Business owner’s WalletApp | A web-based application that enables users to store, manage, and use digital pounds for purchasing goods or services on a blockchain network. It securely holds private keys, facilitates transactions, and interacts with smart contracts within the integrated EVM blockchains. The intention would be to use well-known wallet apps. |
| Delivery App | A web-based application that enables the Delivery agents to either scan QR codes or update the package delivery states without QR codes. Therefore, it interacts with smart contracts within the integrated EVM blockchains. |
| WebApp | A software program accessed through a web browser, communicating with WebServer and delivering interactive functionality over the internet, enabling tasks such as online shopping, checkout, and wallets management. |
| WebServer | A software program that stores, processes, and delivers web content – such as web browsers – to clients, over the internet. |
| Smart Contract | A self-executing program stored on a blockchain that automatically enforces and executes the terms of an agreement when predefined conditions are met. |
| EVM blockchain | A blockchain network compatible with the EVM, Ethereum's core computing environment. It enables decentralized applications and supports features like token creation and programmable transactions. |
Table 1. Key Concepts
Solution High-Level Design
The platform will consist of 3 main parts: the WebApp, the WebServer and the EVM blockchain. This allows users to follow their workflows, including management of the transactions and their reporting.
The Smart contract platform will allow the creation and execution of smart contracts. The solution design will also comprise a set of the smart contracts that will be focused on the functionality for the buyer to transfer the digital form of money to the points of sale and for the buyer as a business owner to be able to set conditions for the payments for the selected goods. These conditions are meant to ensure that the suppliers are paid once the goods are delivered – and not in advance. In addition, we propose the design for cashback token definition, where the seller defines the event and terms for their issuance and redemption.
In order to support the completeness of the workflow, the solution will be enhanced with an ability for the suppliers and sellers to allow checkouts for the list of goods selected by the buyer and QR code generation for money transfer at the points of sale. Notably, it can also be extended to the digitalised form of purchase of a simple service acquired by the business owners. The buyer (business owner) will be able to set the conditions for the contract where we purchase tangible goods, which can be also reviewed by the supplier as part of the workflow before it takes place. The solution might also support the basic ability to manage the goods, the digital form of money for each of the platform profiles (Seller/Supplier and Buyer/Business owner). Our intention is to use existing wallet applications for this purpose. We may show the balance in the Solution applications as well.
The initial demonstration of the solution will be focused on the local Besu blockchain network, however, the suggested set of smart contracts will be compatible with other EVM blockchains.
Figure 1. Solution High-Level Design and Digital Pound Lab Infrastructure Integration
Users will be accessing the platform via feature-rich web interfaces.
Assumption: The BoE Smart contract platform either provides the Ethereum JSON-RPC service for public use or allows a Solution provider to install nodes to the blockchain. The Digital Pound is modelled as an ERC-20 token. It may or may not be backed by digital pounds on the API platform.
The initial implementation will be carried out on a local EVM blockchain platform, and then the smart contracts can be transferred to BoE’s Smart Contract platform.
Use Case #1 and Use Case #2
Case 1: Enabling digital pound payments at point of sale, including cash-back
Case 2: Enabling micro merchants to accept payments in digital pounds
These use cases aim to assess the practical application of the digital pound in everyday retail transactions. We will explore the feasibility of instant and secure payments using CBDC, with a focus on improving accessibility for small-scale merchants and maintaining features familiar to consumers. One of the main features will be the ability to generate unique and secure QR codes to facilitate the rapid and seamless exchange of the transactional information in machine-readable form.
The use cases scenario illustrated on a high level involves the 4 key stakeholders (Buyer, Seller, Solution provider, and BoE) and their respective applications and platforms (Buyer's WalletApp, Seller's App, Solution provider platform and BoE Smart Contract platform (blockchain-based)), and will look as the following set of steps:
- Buyer would like to buy a latte;
- Seller uses Seller’s App to generate a QR code for accepting the payment for a latte in digital pounds;
- Buyer scans the QR code from the Seller’s App and is redirected to the transfer confirmation page in the WalletApp;
- Buyer confirms the payment;
- Buyer's WalletApp transfers digital pounds from Buyer to Seller (via Smart Contract platform);
- If the cashback event exists, the cashback tokens are minted on the platform in accordance with the defined terms and transferred to Buyer;
- Solution provider platform forwards transfer notification from the BoE Smart Contract platform to the Seller's App;
- Buyer enjoys the latte.
Figure 2. Solution Design Supporting the Use Case #1 and Use Case #2 Flows
Buyer can then use the received cashback tokens to pay for goods or services in the original store or at the event’s partner locations. The only difference to the flow is that cashback tokens are used instead of digital pounds.
There is no limit on the number of different cashback tokens. Each Seller can define and issue tokens specific to a marketing event.
After Seller receives the cashback tokens as payment for goods or services, they may redeem these tokens and exchange them (when applicable) for digital pounds from the token issuer:
- Seller decides to redeem cashback tokens and does so from the Seller's App.
- Solution provider platform initiates a smart contract on the BoE Smart Contract platform to redeem cashback tokens for Digital Pounds. Digital pounds are transferred to Seller, and cashback tokens are burned.
Implementation Details for Use Case #1 and Use Case #2
Seller's App – Basic PoS
Initial setup: Seller opens the Seller's App in the browser and clicks on the “Register” link. On the next screen, they enter the email/password and an Ethereum address where digital pounds will be received. Seller receives a registration email and clicks on the confirmation link to confirm their email address.
Note: KYC, additional security, and goods management are out of scope but can be added to the solution later.
The email/password hash and the Ethereum address are stored off-chain in a relational database operated by the Solution provider. If/when KYC is implemented, the KYC status for the Ethereum address and the hash of KYC data are stored on-chain.
As part of the account creation process, the Ethereum address managed by the Smart contract platform is also created. Seller can instruct the Seller’s App to transfer money to this address or to a private address defined during account creation.
Seller’s private key isn’t needed and isn’t requested by the application for the Basic PoS scenario.
Start of day: Seller logs into the Seller's App on the phone or another compatible device at the PoS.
Purchase
Seller enters the amount to pay in the Seller's App, presses the “Generate QR Code” button and presents the generated QR code to Client. If Seller participates in one or more events, it’s also presented with the choice of digital pounds / cashback tokens to nominate the payment amount. The generated QR Code represents the URL in the ERC-681 format. The destination Ethereum address is one of the addresses from a pool managed by the Solution provider platform on the Smart contract platform. It allows for anonymization of the Seller’s address and uniquely identifies the transaction. Buyer scans the QR code that leads to opening the WalletApp installed on the Buyer’s phone. Buyer verifies the payment information and confirms the transfer of Digital Pounds. Buyer's WalletApp connects to the BoE Smart contract platform via a blockchain client and sends instructions for the transfer.
When the transfer is complete, the BoE blockchain emits a Transfer event. The Solution provider platform monitors the BoE blockchain for Transfer events. Once the event related to the ongoing transaction is seen, the successful payment confirmation is communicated to the Seller's App.
A contract installed on the destination Ethereum address forwards the transferred money to the Seller’s address.
The initial implementation won’t provide full anonymity, as both transfers (Buyer -> Contract -> Seller) happen in one Ethereum transaction. A more robust implementation may transfer the money to the Solution provider’s liquidity pool first. Then the Solution provider platform will initiate a transfer to the Seller as a separate transaction. Such transfers can be netted.
PoS with Cashback
We propose to use cashback tokens instead of direct cashback. Cashback tokens can be used for payments at partner businesses' PoS. Partner businesses may then exchange Cashback tokens to Digital Pounds at the Cashback event organizer.
Initial setup is the same as for the Basic PoS.
Cashback event preparation: The Seller creates a new cashback token in the Seller's App. The seller defines the event period, how many tokens are received per pound spent, how much will be paid to a partner business when they redeem the Cashback token.
Purchase for Digital Pounds
Same as the Basic flow, with the exception of the last step: the Solution provider’s Contract that received a money transfer from the Buyer also mints Cashback tokens specific to the current Cashback event and transfers them to the Buyer’s address.
In the initial implementation, minting and transferring will be done in the contract. It implies that token parameters (cashback percentage and the redemption price will be stored on the chain and visible to all BoE’s blockchain participants). In a more robust implementation, it can be done by an off-chain service that monitors transfer events and sends instructions for minting and transferring on chain.
Purchase for Cashback Tokens
Same as the Basic flow, with the exception that the Cashback token is used instead of the Digital Pound. Seller determines the price of goods or services in Cashback tokens. The received Cashback tokens are stored at the Seller’s address.
Redemption of Cashback Tokens
If Cashback tokens are stored on the private address, they should be transferred to the Seller’s address on the Solution provider platform.
After Seller logs into the Seller’s App, they have an ability to redeem the Cashback tokens stored on the account managed by the Solution provider platform. When Seller redeems the Cashback tokens, the Seller’s App initiates a redemption contract on the BoE chain via the Solution provider platform by transferring tokens to it. If the Event organizer has enough money on the account managed by the Solution provider platform and has enabled automatic redemption, Digital Pounds are transferred to the Seller’s account, and the Cashback tokens are burned. Otherwise, a redemption request is recorded on the chain.
The Event organizer can view redemption requests in the Seller’s App. To fulfill the request, it should have enough money on the account managed by the Solution provider platform. When the Event organizer confirms redemption, the Seller's App instructs the Solution provider platform to transfer Digital Pounds to the redemption contract. When the redemption contract receives Digital Pounds from the Event organizer, it forwards the money to the Seller and burns the Cashback tokens.
Use Case #4
Case 4: Enabling conditional business-to-business payments
The use case is focused on a business, where it should be possible to set conditions for the payments to ensure that the business’s suppliers only get paid once the goods are received. As per the functions of the use case, the parties agree the payment terms, and funds are transferred accordingly. In order to support the use cases, we see a need to introduce an additional participant here with a “delivery” profile, that acts as an oracle for this flow.
The use case scenario presented on a high level involves the 5 key stakeholders (Buyer, Seller, Delivery, Solution Provider and BoE) and their respective applications, and platform (Buyer's WalletApp, Seller's App, Delivery App, Solution provider platform, and BoE’s Smart Contract platform (blockchain-based)) and will look as the following set of steps:
- Buyer selects goods and adds them to the shopping cart on a web storefront of the Seller's App;
- Buyer proceeds to the checkout page and is then redirected to the payment page of the Seller's App;
- Buyer confirms the payment from the WalletApp;
- On the platform, Buyer’s confirmation is registered as approval for the DvP contract to withdraw the agreed-upon amount from the Buyer’s wallet;
- Seller receives confirmation from the Solution provider platform that Buyer has authorized the payment;
- Seller sends shipping details to the delivery company;
- Seller packages the goods;
- Delivery agent picks up the package from Seller and transports the package to Buyer;
- Delivery agent updates the delivery status upon delivery, using the Delivery App;
Note: We assume that for the Delivery App, when the delivery state is updated, the following information is recorded: IP address, browser information, and geolocation. This information doesn’t directly impact the money transfer for the DvP flow, however, it can be used in the event of conflicting situations (for instance: if the package is delivered to the wrong address or lost).
- The Solution provider platform updates the DvP contract with the delivery state;
- The DvP contract transfers the payment from the Buyer to itself, then releases the funds to the Seller, and sends a notification via the Solution provider platform to Seller confirming the transaction.
Figure 3. Solution Design Supporting the Use Case #4 Flow
Implementation Details for Use Case #4
Seller’s App with Conditional Business-to-business Payments
Initial Setup is the same as for the Basic PoS.
Seller integrated the “Digital Pounds” payment option into their web storefront application.
Note: In the PoC, it will be showcased as a simple storefront application with a “Digital Pounds” payment option, the development of a Digital Pound payment gateway API is out of scope of this work.
Purchase for Digital Pounds
Buyer visits the Seller's App, puts goods in the shopping cart, and proceeds to the checkout. During the checkout, Buyer is asked for a delivery address and is then redirected to the payment portal provided by the Solution provider platform. That, in turn, redirects Buyer to the WalletApp to confirm the allowance.
As in the Basic PoS scenario, the allowance is confirmed to one of the addresses provided by the platform. When it’s confirmed, Buyer is redirected back to the Seller’s storefront application. In contrast to the PoS scenario, money isn’t immediately transferred from the Buyer’s address. Instead, the Buyer grants permission to make an automated transfer of the specified amount.
Delivery Request
Seller logs into the Seller's App and navigates to the list of purchases awaiting delivery. Once Seller is ready to ship, it requests shipping label creation and parcel pickup via the Seller's App. The Platform forwards this request to one of the postal providers supported by the platform.
Note: Payment between the Seller and the Postal service is out of scope of this work. In our exploration, we did not come across a UK postal service API aligned with our needs, so we will use the DHL US API as an illustrative example.
Delivery
The Solution provider platform receives delivery status updates from the postal service provider. Once a delivery notification is received (or some period is passed), the platform notifies the DvP contract that the digital pounds can be transferred to Seller. The contract transfers money from Buyer to its address first, then forwards it to Seller.
As part of the work, we'll provide a simple web UI to change the delivery status on behalf of the Delivery service provider.
Client Application (UI) – High-Level Design
The solution is enhanced with three main participant profiles (might be extended later): Supplier/Seller, Business Owner/Buyer, and Delivery in order to support the selected use cases’ flow.
Registration / Authorisation / Landing pages are similar for each participant (this functionality can be extended later with the proper identification components such as KYC).
Figure 4. UI Wireframes for Authorisation
Supplier/Seller profile – the profile allowing to maintain and manage the goods, monitor the transfers from the Business owners/ Buyers. Seller can also approve/decline the DvP requests for the goods collected by the business owners/buyers for checkout. The functionality is also enhanced with generation of a unique QR code for the payments using the Digital pound.
Figure 5. UI Wireframe for Seller Dashboard View
Figure 6. UI Wireframe for Seller QR code Payment View
Business Owner/Buyer profile – the profile allowing to track DvP requests of the set conditions for the selected goods, to transfer, top up, and monitor the transactions with the counterparties. This profile is enhanced with a feature of confirming the QR code-originated transfers.
Figure 7. UI Wireframe for Buyer QR code Payment Confirmation
Delivery profile – a simple profile allowing the delivery service to make additional state changes to the transactions, for the completeness of the workflow (in more robust implementations, it can be enhanced with an ability to scan the QR code on delivery).
It should also be noted that it’s not required for each participant to host and maintain a separate node/ platform in order to participate within the blockchains. The solution platform will be built in such a way that it’s a multi-tenant.
The Development Environment
Initial development and testing of the solution (including the initial demonstrations) are planned within the in-house blockchain with an intention that the smart contracts will be transferable and capable of settling the transactions between different blockchain platforms. It will also be part of the scope to test the interoperability of the designed smart contracts with the digital pound infrastructure – the smart contract platform.
We would also be happy to comply with the Bank of England’s recommendations regarding the physical location of the development and testing environments.
Solution design for Selected Use Cases: #1, #2 and #4