System Architecture The version of Emerald that was performance tested has three components in a given deployment in a bank: • ISO Broker - this is a java-based module that accepts payment requests either over 10 RabbitMQ or REST. It converts these to an internal representation and sends them over RabbitMQ to the Payment Service using JSON-RPC. 11 • The Payment Service used for the performance testing was written in NodeJS . In the latest version this has been re-written using Java. This decision was made so that 12 ConsenSys’ Truffle and EtherPudding libraries could be used to deploy and provide a promisified proxy to the solidity13 contract, enabling us to focus on the contract. • The Solidity contract - this contained the data of the creditline model, and allowed for transactional payments to be processed. 14 All the components were containerised using Docker so that it was relatively easy to deploy many stacks of components representing each bank. Emerald is now a private, shared source project. Implementation Learnings Ethereum was chosen as the distributed ledger because it is one of the most established smart contract platforms that is live in the public domain. The developers liked the idea of the freedom of a smart contract platform, where the smart contract defines the functionality, over a specific product which is well suited to this application but has less inbuilt flexibility. It should be noted that a consortium Ethereum network was used in preference to the public Ethereum network which is aimed at a very different use case (public Ethereum is tuned to have relatively long lived blocks and the volume of transactions is currently not of the same scale as a payments system). The contract was written in a language called Solidity. Some of the methods in the contract were transactional - e.g. sendPayment. Transactional methods, which change the state of the data, only return a transaction id when run. To get 4