Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Impel's solution offerings resource overview and technical information guide
Impel is a fintech innovator with Layer 2 solution offerings built on top of the XDC Network’s blockchain DLT for forward-facing banks, FIs, and corporates. The robust solutions include an ISO 20022 financial messaging API with optional instant settlement capability using digital assets such as Fluent Finance’s US+ stablecoin, as well as providing a bridge to the R3 Corda private DLT platform from the XDC Network’s public blockchain, so entities can settle contracts and agreements in seconds using digital assets rather than using traditional banking systems that take much longer to process payments.
Cross-border and domestic payment rails leveraging blockchain DLT
Impel provides an ISO 20022 compliant financial messaging API that can be used by any institution anywhere (almost) in the world, such as a bank or corporate to send and receive financial data for either cross-border or regional payments. Our functionality can be used for bank to bank, bank to corporate or vice versa, or even corporate to corporate financial messaging.
Users of Impel's ISO 20022 API would still use nostro/vostro accounts and the Central Banking system to settle-up at the end of the day. The API is designed to be agnostic, allowing it to be a "plug and play" option to be plugged into core-banking systems.
Additionally, Impel takes it to the next level by allowing for optional instant settlement capability by including the functionality to add digital assets (cryptocurrency) such as a stablecoin like Fluent Finance's US+ or other asset types like XDC, the native coin on the XDC Network in the message's payload for instant settlement. This method adds tremendous value by eliminating the need for traditional nostro/vostro accounts and the Central Banking system. Settlement can take place in mere seconds 24x7x365, adding a significant time-advantage benefit for all involved.
Impel's ISO 20022 API uses the XDC Network's blockchain DLT protocol, an enterprise-grade, EVM-compatible Layer 1 network equipped with interoperable smart contracts. A highly optimized, bespoke fork of Ethereum, the XDC Network reaches consensus through a delegated proof-of-stake (XDPoS) mechanism, which allows for two-second transaction time, near zero gas fees, and over 2,000+ transactions per second (TPS). Secure, scalable, and highly efficient, the XDC Network powers a wide range of novel blockchain use cases. Learn more at the community-driven XDC Community, XDC Foundation, or at XinFin, the organization that created and maintains the XDC Network's protocol.
Right from the start, Impel's ISO 20022 API solution has been designed with great care and concern for delivering a high-level of security, as well as for being a fast and cost-efficient solution, and most importantly, to keep confidential transaction data private. The use of blockchain technology allows for a public recording of the transaction's date and timestamp, but keeps the actual financial message's data private.
An overview of Impel's ISO 20022 architecture and components can be found here.
Universal financial industry message scheme
The financial messaging standard can be defined as a set of messages that are used for exchanging a vast range of financial information data between organizations using:
A modelling methodology that captures, in a syntax-independent way, financial business areas, business transactions, and associated message flows
A central dictionary of business items used in financial communications
A set of XML and ASN.1 design rules to convert the message models into XML or ASN.1 schemas, whenever the use of ISO 20022 XML or ASN.1-based syntax is preferred
Impel offers a self-paced ISO 20022 API demo that anyone can try
Anyone interested in seeing Impel's ISO 20022 financial messaging API operate in realtime over the XDC Network's blockchain DLT mainnet, can try a self-paced demo at anytime they choose.
An educational demnistrational environment has been setup to represent two pretend organizations, Bank A and Bank B that allows the user free-rein to create and send the financial message of their choice, allowing them the choose their own options that utilize the ISO 20022 PACS-009 and PACS-002 payment instructions.
To access Impel's self-paced demo, register for access first, then an email will be sent containing a non-sharable access link that can be used as many times as desired, so be sure to store the link in a safe memorable place for future access.
User creates and sends an ISO 20022 standard (PACS 009) payment instruction from a pretend Bank A to a pretend Bank B counterparty.
View the transaction history of all the ISO 20022 financial messages that have been created by every registered demo user.
Reporting screen displays historical message data and the connected XDC Wallet(s) account balance.
The describes its purpose as "A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives".
Impel's API platform offers all of the current 733 message definition version types, as well as all of the older versions too. Find the complete ISO 20022 message definitions schema list .
Each demo user can create their own financial message with or without attaching a digital asset, such as XDC (the native coin to the XDC Network) or an XRC-20 token like Fluent Finance's US+ stablecoin in the messages payload for .
To register for demo access, click .
Field | Description |
---|
To BIC* | Destination Bank Identification Code receiving financial message |
To IBAN* | Destination International Bank Account Number |
From IBAN* | Sending party's International Bank Account Number |
Special Instructions | Text field for detailed commentary |
Amount | Fiat amount to be transferred and currency type (USD, GBP, EUR) |
Instant Settlement | Allows digital assets to be transferred in the ISO 20022 message's payload as collateral. Note: Price quote is good for 30 seconds, then refreshes based on current market value of the chosen digital asset. On the XDC Network's blockchain, funds are transferred from sender's digital asset wallet to the receiver's digital asset wallet. |
Impel's API allows for instant settlement using digital assets
Impel's ISO 20022 API provides optional functionality that can instantly send a payment in the form of a digital asset "cryptocurrency" attached to the financial messages payload, at almost zero cost, to any counterparty's XDC Network wallet address.
Instant Settlement can be sent alongside a financial transaction and is used to instantly settle any accrued balance(s) as part of that transaction.
The instant settlement option uses the XDC Network's native coin XDC or XRC-20 tokens such as Fluent Finance's US+ stablecoin as a medium of value.
Impel's ISO 20022 API uses Smart Contracts on the XDC Network
Because the XDC Network is a fork of Ethereum, it is EVM compatible and also allows for smart contract functionality. Impel's ISO 20022 API's smart contract. The smart contract stores all of the committed proofs and acts as an escrow until every participant approves the terms of the proof.
(1) When a proof is to be committed, one party gathers all info, requests signatures, and creates and commits a proof proposal (1), attaching collateral (if required).
(2) Then an event is published by the contract. Other participants can listen to this event and validate the proof proposal.
(3) If the validation is successful they can approve (2) the proposal, attaching collateral (if they should). If validation fails they can reject it.
(4) If the agreement is not met at specific designated time (defined by the creator) or if transaction is rejected, the attached collateral will be returned back to the sender.
Financial messages exchanged between parties may contain digital assets in the messages payload, therefore only the net settlement amount is exchanged between participants.
Impel's ISO 20022 platform architecture explained in detail
Main components of Impel's ISO 20022 API:
Gateway Service
Identity Service
Smart contract functionality
Multiple messaging protocols
Together, all of these form a distributed, permissioned topology that leverages the XDC Network's blockchain DLT capabilities to meet modern application development requirements for financial messaging.
A Client is a software application's coding languages include Java, Typescript, C#; and uses Impel's ISO 20022 API to send and receive messages via a Gateway Service node. The Client sends a message to a Gateway Service node and then receives a responding message about subsequent processing events.
A Gateway Service is an Impel ISO 20022 platform node that is dedicated to and used by a single client application to process messages and events. The Gateway Service processes incoming and outgoing messages to/from a Client.
Messages are shared between Impel ISO 20022 Gateway Service nodes through message channels. A message channel is created for each Gateway Service node pair; exchanging messages with each other, in order to apply collateral netting on a Proof.
Message is one of the core domain models that holds information about financial messages like ISO 20022, and can optionally attach digital assets as collateral in the message's payload.
A Proof is a core domain model of Impel ISO 20022 platform and is used to group messages from a Message Channel between two platform nodes and to commit them onto the XDC Network's blockchain DLT in batches as a Proof.
The Identity Service is a service used as a registry of Impel's ISO 20022 platform nodes.
Impel's ISO 20022 API platform Smart Contract stores information about all the Proofs committed to the XDC Network's blockchain's DLT. It is also responsible for settling digital asset collateral between participants and acts as an escrow account.
A Client XDC Network wallet address is an account that stores digital assets (XDC or XRC-20 tokens like the US+ stablecoin) and used to send or receive the Proof's digital asset(s) as collateral.
Overview and schema of the ISO 20022 API's identity service
The identity service holds information about all of the gateway nodes operating on Impel's ISO 20022 API platform.
Operating as the brains of the ISO 20022 API, the identity service allows very gateway node the ability to accurately and securely route financial messages through Impel's platform from point A to point B by requesting data from other parties, like their BIC (Bank Identification Code), gateway URL, XDC wallet address, certificate, as well as providing the ability to move digital asset collateral from wallet to wallet.
When new gateway node is added to Impel's ISO 20022 API platform, it will be registered via the identity service.
Party | Description |
---|---|
BIC
Business Identifier Code
Name
Name of the entity
Gateway URL
The node's gateway URL
Certificate
Used when signing gateway messages
Address List
List of XDC wallet addresses
Network
The blockchain network where the wallet addresses reside, e.g. XDC Network)
Impel's ISO 20022 API is an event driven system that contains defined events
An event represents a lifecycle state of a message and proof object. Learn more about event (computing) here on Wikipedia.
Description | |
---|---|
id
Platform identifier
type
Type of an event e.g. (MESSAGE_CREATED, MESSAGE_SENT, etc.)
timestamp
Date/time event was created
subjectId
Identifier of a subject of the event
subjectType
Type of a subject of the event
data
Platform event serialized to JSON
The key aspects and components of Impel's ISO 20022 API
Send and receive financial messages between clients and other gateways
Committing message proofs onto the XDC Network's blockchain
Allowing digital assets such as the XDC Coin or US+ stablecoin to be included in the message's payload for instant settlement, without the need for traditional nostro/vostro accounts, nor the Central Banking system
Message
Proof
Event
A gateway service processes messages and proofs. Upon lifecycle state change, a new event message is generated. Clients retrieve events from the gateway service endpoint which is polled periodically by a Client:
GET /api/gateway/iso20022/gateway/event
Event Types are defined in API definition
MESSAGE_CREATED
Description: Triggered by a sender node when message is successfully created.
MESSAGE_SENT
Description: Triggered by a sender node when message is sent to a counterparty node.
MESSAGE_RECEIVED
Description: Triggered by a recipient node when a message is received and successfully created on a counterparty node.
MESSAGE_ACKNOWLEDGED
Description: Triggered by both (sender/recipient) nodes when a message is acknowledged by a counterparty node.
MESSAGE_NOT_ACKNOWLEDGED
Description: Triggered by both (sender/recipient) nodes when a message is not acknowledged by a counterparty node
PROOF_CREATED
Description: Triggered by a sender node when a proof is successfully created.
PROOF_SENT
Description: Triggered by a sender node when proof was sent to a counterparty.
PROOF_RECEIVED
Description: Triggered by a recipient node when a proof is received and successfully acknowledged by a counterparty node.
PROOF_ACKNOWLEDGED
Description: Triggered by both nodes when a proof is acknowledged by counterparty node.
PROOF_NOT_ACKNOWLEDGED
Description: Triggered by both nodes when a proof is not acknowledged by a counterparty node.
PROOF_COMMITTED
Description: Triggered by both nodes when a proof is successfully committed.
PROOF_APPROVED
Description: Triggered by both nodes when a proof is successfully approved.
PROOF_REJECTED
Description: Triggered by both nodes when a proof is rejected.
Detailed explanation of Impel's ISO 20022 API message confirmation
A Proof is a confirmation of a received message that has been validated, acknowledged (signed) by counter party, before it will be committed as a transaction on the XDC Network.
Messages received through the gateway service will be committed to the blockchain after successful proof validation via the following procedure:
Selects a batch of uncommitted messages
Creates a proof
Collects signatures
Commits proof
Approves/Rejects proof
The mechanics of Impel's ISO 20022 financial message
Impel's ISO 20022 API was designed to be message agnostic, meaning that it will house and send whatever data type the sender wants to send, MT or XML. The origination and fundamentals of the message that the client creates and sends to the gateway service that will be sent to the recipient that will be committed as a proof.
The data required to route message between gateways (sender, receiver).
SendMessageRequest data field requirements:
Sender
Recipient
Payload
Collateral (optional)
Validation
head.001.001.01
head.001.001.02
head.001.001.03
AppHdr element:
The Document element is the actual ISO 20022 message e.g. PACS or PAIN.
The document schema attribute that points to the ISO 20022 schema type: urn:iso:std:iso:20022:tech:xsd:${MESSAGE_TYPE}
Example:
The ability to add a digital asset to the message's payload allows for instant settlement capability to where traditional nostro/vostro accounts and settling up at the end of the day with the Central Banking systems is no longer required.
Collateral is defined in SendMessageRequest by the optional collateral field.
Digital assets types supported:
NATIVE (XDC, the native coin to the XDC Network)
XRC-20 token (layer 2 projects)
Native XDC coin as collateral example:
XRC-20 token as collateral example:
All ISO 20022 message types and variants are candidates for validation. SendMessageRequest includes an optional flag "validatePayload" for validation.
ISO 20022 payload is validated by checking:
Document
AppHdr (optional)
Both elements has to be a valid ISO 20022 namespace, e.g.
urn:iso:std:iso:20022:tech:xsd:pain.002.001.03
urn:iso:std:iso:20022:tech:xsd:head.001.001.02
urn:iso:std:iso:20022:tech:xsd:pacs.002.001.12
Supplementary data is not supported by the platform.
Field | Description |
---|
State | Description |
---|
The AppHdr element is an ISO 20022 message. Supported schemes:
Variable | Description |
---|
messageIds | List of proof's messages platform identifiers |
endToEndIds | List of proof's messages business identifiers |
status | Status of a proof in the platform (CREATED, SENT...) |
sender | Proof sender Party BIC |
recipient | Proof recipient Party BIC |
signature | Sender Party signature for a proof to send |
counterpartySignature | Recipient Party signature for a received proof |
channelHash | Hash of a proof's messages (hex format) |
netSettlementCollaterals | Sum of proof's messages collaterals |
NEW | Initial state of the message |
OUTBOX | Message is available to send to the counterparty |
SENT | Message has been sent to the counterparty |
RECEIVED | Message has been received by the counterparty |
ACKNOWLEDGED | Message has been checked and validated |
NOT_ACKNOWLEDGED | Message failed successful delivery |
${HEADER_TYPE} | head.001.001.01 and head.001.001.02 |
${SENDER_BIC} | Sending party's BIC |
${RECIPIENT_BIC} | Receiving party's BIC |
${BUSINESS_IDENTIFIER} | Identification |
${MESSAGE_TYPE} | pacs.009.001.10, pain.008.001.01, acmt.001.001.08, etc. |
${MESSAGE_DATE} | Date the message was created |
The message component of Impel's ISO 20022 API
The message component is the primary object to house the financial message's data and optional digital asset information used for collateral that is passed from one gateway node to another gateway node, essentially getting the ISO 20022 financial message from point a to point b.
Impel's ISO 20022 API gateway service's message envelope utilizes cryptography, ensuring the following:
High throughput
Instant delivery
Guaranteed delivery
Secured delivery
Impel ISO 20022 platform has a distributed architecture, meaning that each platform participant has to have its own gateway service (node) in a platform with dedicated identity provider (Keycloak).
New platform participant has to complete onboarding process:
Request for a dedicated node in a platform.
Generate API credentials (clientId/clientSecret).
Gateway service (node) exposes API which can be used to send messages and get information about them. It uses dedicated Identity Provider (Keycloak) to authenticate and authorize API requests. Gateway service requires JWT token on every requests, which can be obtained from Keycloak, from OpenID Connect token endpoint. In order to get JWT access token we need to first generate clientId/clientSecret.
With Initial Access Token we need to create Keycloak client by running below command:
Response example:
Extract client_id and client_secret fields. From now we can use these credentials to get OAuth2 JWT token from Identity Provider (Keycloak).
When you create a client through the Client Registration Service the response will include a registration access token. The registration access token (registration_access_token) provides access to retrieve the client configuration later, but also to update or delete the client. The registration access token is included with the request in the same way as a bearer token or initial access token. Registration access tokens are only valid once, when it’s used the response will include a new token.
Impel's sandbox environment to spin-up and test gateway nodes
Impel's ISO 20022 platform provides an experimental environment that can be used for demonstration and testing purposes, as well as to help understand how the platform works.
There are two different ways to interact with Impel's ISO 20022 API, allowing for exchanging of financial messages between clients and gateway services:
To secure whole process, we use feature. That means that platform participants will generate API client credentials.
When new dedicated Gateway service is setup in a network, an email will be sent with .
The Sandbox environment provides two default gateway services, a pretend and , allowing a user to exchange ISO 20022 messages between Gateway Clients.
Name | Description |
---|
Field | Description |
ID | Message identifier |
endToEndId | Message business identifier (extracted from ISO 20022 Business Application Header) |
Status | Status of message (CREATED, SENT. etc.) |
Direction | Message direction (INBOX, OUTBOX) |
Sender | Message sender Party BIC (extracted from ISO 20022 Business Application Header) |
Recipient | Message recipient Party BIC (extracted from ISO 20022 Business Application Header) |
Signature | Sender Party signature for a message to send (base64 format) |
counterpartySignature | Recipient Party signature for a received message (base64 format) |
messageHash | Hash of a message (base64 format) |
previousMessageHash | Hash of a previous message in a chain (base64 format) |
Collateral | Information about message collateral |
Type | Type of collateral, e.g NATIVE (XDC) or ERC20 |
Amount | Collateral amount |
exchangePrice | Price of a collateral amount |
exchangeCurrency | Currency of a collateral amount price |
tokenSymbol | XRC-20 token symbol (e.g. US+) |
Bank A Keycloak |
Bank B Keycloak |
Bank A API |
Bank A API Swagger |
Bank B API |
Bank B API Swagger |
client_id: gateway-api client_secret: UZbFa0uCD5NfaT9q
client_id: gateway-api client_secret: NiWaHZf8UmNYswWd
Authentication: OAuth2
Authentication: OAuth2
Step-by-step guide to use Terminal for Impel's ISO 20022 API
This documentation walks through exchanging an ISO 20022 financial message on Impel's platform using curl commands to call its REST API. This is the same walk through as described in Postman article, but using terminal.
The Impel ISO 20022 Gateway Service endpoints are secured, so in order to call them we have to get an authentication token from the Keycloak service.
We then save the value of the access_token field from the received response, which we will use in further requests as the ${BANK_A_AUTH_TOKEN} variable.
We will then save the value of the access_token field from the received response, which we will use it in further requests as the ${BANK_A_AUTH_TOKEN} variable.
The Authentication token is only valid for 5 minutes. After that time a new token has to be requested, otherwise endpoints will throw an "unauthorized" exception with HTTP status code 401.
Once we have a valid authentication token, we can exchange a Client Message with our counterparty using the Impel ISO 20022 platform. In the example below, we will use the ISO 20022 pacs.009.001.10 message type.
The pacs.009.001.10 message has to be wrapped in a Client Message.
Save the value of the messageId field in the received response, we will use it later in further requests as ${MESAGE_ID} variable.
Sent Client Message will be processed by the platform and new Gateway Message will be created with messageId as identifier. It can take a couple of seconds to create it.
Once the Gateway Message is added in a platform we can get it back from a platform.
The Gateway Message model is fully described here.
If the fullySigned flag is true, we can check if the same Gateway Message exists on Party B side.
Gateway Message on both sides should be the same, the only differences are related to message creation which is a normal behavior.
Once a Gateway Message is processed by the system and acknowledged by the counterparty, the Proof is then created (though it can take a moment to be created). We can wait few minutes after Gateway Message creation or try to get events using get events endpoint and search for events related to proof creation.
If the fullySigned flag is true, we can check if the proof exists and it is the same on Party B side.
Proof on both sides should be the same, the only differences are related to Proof creation and status update which is a normal behaviour.
Every state change in the Impel ISO 20022 platform is stored as an event, e.g. Gateway Message created, Gateway Message sent, Gateway Message received and many more. All events can be retrieved using the endpoint below:
The returned EventDto model is just a wrapper for a proper event triggered in Impel ISO 20022 node. In order to get a real event we have to deserialize the content of the data field. The data field stores events as a sequence of bytes, which is a JSON string of serialized events. The type of an event is given in a type property. Using the type and event schema from API definition we can deserialize the content of an event to proper data model. A full list of events types and their data schema is available in Events Article.
Step-by-step guide to use Postman for Impel's ISO 20022 API
Impel's ISO 20022 platform provides a public Postman workspace, which allows users to call API endpoints in an easy and convenient way.
In this article we will walk through exchanging ISO 20022 message on Impel ISO 20022 platform using Postman.
The provided Postman collection has defined a script which will authenticate all requests, which means that there is no need to supply an access token.
Postman Public Workspace has to be forked in order to send requests. To do that we have to fork a collection and environments to our private workspace.
First we have to select Impel ISO 20022 collection (1) and then click on a Fork button (2).
Next we have to set a name of the new fork (1), select a Workspace, e.g. "My Workspace" which is a default one for every user (2) and click on Fork button (3).
When collection is forked next step is to fork environments. In order to do that we have to select Environments from left menu (1), next click on the more options on the right side of environment name (2) and select Create a Fork (3). We have to create a fork for both environments. On "Create a Fork" form we have to set a name and a workspace, the same as when we fork collection.
Once everything is done we can go to the workspace in which we created forks.
The Postman Workspace has two available Gateway Services named, respectively, Party A and Party B. Each Gateway Service is a separate node in Impel's ISO 20022 platform.
First we need to select a Gateway Service, e.g. Party A (1).
Then choose Collections (2) from left menu and select Send message endpoint (3).
There are couple of examples for this endpoint, we will try with ISO 20022 message pain.002.001.03 (1).
We first have to copy the Body of the example and paste it in an endpoint request body (2). In the Body tab, we have to select the raw option (3) and then change its type to JSON (4). After that we can paste the example body into a request body window (5). Once that is done, we can click the Send button (6). In the response from the Gateway service we receive and messageId which is Impel ISO 20022 platform's identifier, which is set as global variable (gatewayMessageId) so later we can use GET endpoints without copying Gateway Message identifier - it will be set automatically.
Sent Client Message request will be processed asynchronously by the platform and new Gateway Messages will be assigned Id as an identifier N.B. this can take a few seconds to create
Once Gateway Message is added in Impel ISO 20022 platform we can invoke "Get message" (1), with messageId (2) from the previous response. In order to do that we have to click the Send (3) button. A response will appear in the response window (4) with a body that is the same as the original Client Message.
Gateway Message can be fetched using the "Get message" endpoint (1). Once selected, we can click Send button (2) and check the response (3).
If the fullySigned flag is true (1) then we know that message was already signed by Party B and we can verify that. In order to do that we just have to change environment to Party B (2) and click the Send button (3), and then in a response window (4) we should see the same data as on Party A side.
Gateway Messages on both sides should be the same, the only differences are related to Gateway Message creation which is normal behavior.
Once a Gateway Message is processed by the system and acknowledged by a counterparty, a Proof is created (it can take a few seconds to be created). We can wait few minutes after Gateway Message creation or try to get events using get events endpoint and search for an event related to the proof creation.
To get a proof we have to change the Gateway Service back to Party A (1). Then we have to choose "Get message proof" (2) and click the Send button (3). After that we will see a response with Proof data (4).
If the fullySigned flag is true (1), then we know that proof was already signed by Party B and we can verify this by changing the Gateway Service to Party B (2) and clicking the Send button (3). In the response window (4) we should see the same data as on Party A side.
Proof on both sides should be the same, the only differences are related to Proof creation and status update which is a normal behavior.
Every state change in Impel ISO 20022 platform is stored as an event, e.g. Gateway Message created, Gateway Message sent, Gateway Message received and many more.
Events can be fetched using endpoint "Get events" (1), setting the correct endDateTime request param (2), clicking the Send button (3) and waiting for a response (4).
The returned EventDto structure is a wrapper for a proper event triggered in the Impel ISO 20022 Gateway service. In order to get a real event, we have to deserialize the content of the data field. The data field stores an event as a series of bytes, and is a JSON string of serialized events. The type of event is given in the type field. Using the type and event schema from the API definition, we can deserialize the content of an event to a proper data model. A full list of events types and their data schema is available in Events article.
A video walkthrough demonstration of Impel's R3 Corda | XDC Network Bridge
Impel's R3 Corda | XDC Network Bridge
Blockchain protocols and other related distributed ledger technology platforms tend to be silos to themselves, unless a software bridge is created to connect the two platforms, so digital assets can be moved back and forth allowing for interoperability.
R3 exists to help organizations shape the future of regulated markets by leading the future of digital finance by powering multi-party solutions that deliver digital trust and unlock greater potential for regulated businesses everywhere.
Impel's R3 Corda bridge connects to the Cordite CorDapp on the Corda platform.
Cordite provides decentralised economic and governance services including:
Decentralised stores and transfers of value allowing new financial instruments to be created inside the existing regulatory framework. eg. tokens, crypto-coins, digital cash, virtual currency, distributed fees, micro-billing
Decentralised forms of governance allowing new digital autonomous organisations to be created using existing legal entities eg. digital mutual societies or digital joint stock companies
Decentralised consensus in order to remove the need for a central operator, owner or authority. Allowing Cordite to be more resilient, cheaper, agile and private than incumbent market infrastructure
Cordite is open source, regulatory friendly, enterprise ready and finance grade.
Impel’s R3 Corda bridge provides not only interoperability, but a settlement vehicle for making payments on contracts and settling debt obligations. Rather than using traditional banking systems that take much longer to process payments, entities can settle in seconds using digital assets via Impel's bridge to Corda's CorDapps (Corda Distributed Applications).
With this unique bridging technology, data can be recorded privately on the Corda platform, while limited data sets are transferred to the public XDC Network's blockchain DLT, thereby mitigating institutional risk, and turning Corda into a hybrid network. By extension, this shared ledger will connect the XDC coin and XRC-20 tokens (Layer 2 projects) with every other Corda CorDapp on their private network platform.
To access Impel's R3 Corda | XDC Network Bridge click .
To access Impel's R3 Corda | XDC Network Bridge click .
101 Blockchains does a deepdive into blockchain bridges with there article titled "".
The XDC Network is an enterprise-grade, EVM-compatible Layer 1 network equipped with interoperable smart contracts. A highly optimized, bespoke fork of Ethereum, the XDC Network reaches consensus through a delegated proof-of-stake (XDPoS) mechanism, which allows for two-second transaction time, near zero gas fees, and over 2,000 transactions per second (TPS). Secure, scalable, and highly efficient, the XDC Network powers a wide range of novel blockchain use cases. Learn more at
Impel's CEO and Founder wrote a deepdive article called , a quite helpful and informative write-up that paints the big picture of the network and its ecosystem.
The R3 team first developed - a purpose-built, private DLT platform that is not only sustainable by design, but has facilitated hundreds of networks across financial services. Building on Corda’s success, we then launched , a confidential computing platform for secure, multi-party data sharing that works with or without Corda.
is a scalable, permissioned peer-to-peer (P2P) distributed ledger technology (DLT) platform that enables the building of applications that foster and deliver digital trust between parties in regulated markets.
is an open source project creating open source DeFi features for Corda. Cordite continues to make leading-edge features available to the Corda community.
Cordite is built on , a finance grade distributed ledger technology, meeting the highest standards of the banking industry, yet it is applicable to any commercial scenario. The outcome of over two years of intense research and development by over 80 of the world’s largest financial institutions.
The bridge allows digital assets "cryptocurrency" such as a stablecoin like or other digital assets like XDC, the native coin to the XDC Network to move from the XDC Network's public blockchain to R3's private DLT platform.
To access Impel's R3 Corda | XDC Network Bridge click .
Step-by-step guide on how to use Impel's R3 Corda | XDC Network Bridge
Impel's bridge allows digital assets "cryptocurrency" such as XDC, the native coin on the XDC Network, or XRC-20 tokens, which are Layer 2 projects built upon the XDC Networks blockchain, such as Fluent Finance's US+ stablecoin to be moved from the public XDC Network's blockchain to R3 Corda's private DLT platform, specifically to CorDapps like Codite or others.
Digital assets moving from the XDC Network need to be located in a digital asset wallet, such as the XDCPay wallet, which is a browser extension plugin.
First, confirm that the XDCPay wallet has been installed on the device you want to use to process the transactions.
Learn more about the XDCPay wallet here.
Download the XDCPay wallet here.
(Step #1) Access the R3 Corda | XDC Network Bridge by clicking here.
(Step #2) Be sure that XDCPay wallet has been installed and logged into an XDCPay account (Image 1).
(Step #3) Ensure that the XDCPay wallet is connected to "XDC Mainnet" (Image 2).
(Step #4) Select which XDCPay wallet account to send/receive digital assets from. Note: Example in Image 2 shows "Account 3" as the selected "active" account that is associated to the proper XDC Network wallet address (i.e. xdc53e3...cb3e shown below in Image 2).
Note: Currently only authorized "whitelisted" wallet address are eligible to connect to Impel's R3 Corda bridge. For access, contact Impel's team to request access here.
After you choose the settings for XDCPay, click the CONNECT WALLET button (Image 1).
(Step #5) Access the Send tab by clicking on "Send", allowing for digital assets to be sent to a Corda CorDapp. (Image 3)
Enter the required information into the following text fields:
Digital Asset - Select the desired asset (currently, supports XDC coin)
Amount of Digital Asset - Amount of digital asset to be sent to a CorDapp
Destination CorDapp - Destination to where the digital asset is going to on the Corda platform
Destination Address - The specific CorDapp's account address. Example: Cordite account address (e.q account-1@OU=xinfin, O=xinfin, L=London, C=GB)
Reason for Transfer (optional) - Transaction details for clarity
(Step #6) Once all data has been entered correctly, the Send button is activated. Once clicked, a successful transaction confirmation message will appear, else a notification of failure will be displayed.
(Step #7) View transaction history for both sent and received digital assets, access the Transactions tab (Image 4).
There are two types of transactions, the first transaction type has an arrow-up icon and is called a teleport transaction and the second that has an arrow-down is called a settlement transaction.
Teleport transaction - Transactions moving digitalassets from an XDC wallet address to an R3 Corda CorDapp account.
Settlement transaction - Transactions moving digital assets from an R3 Corda CorDapp account to a wallet address on the XDC Network's public blockchain.
(Step #8) Click on each transaction to view its specific details. To view the blockchain transaction details on an XDC Network Block Explorer, click the "View on Blockscan" link towards the bottom . (Image 5).
(Step #9) Receive digital assets from an R3 Corda CorDapp and send them to an XDC Network wallet address (Image 6).
Digital Asset - Select the desired asset (currently, supports XDC coin)
Amount of Digital Asset - Amount of digital asset to be sent to a CorDapp
CordaApp URL - CorDapp node HTTP URL address
Username - CorDapp node credential
Password - CorDapp node credential
Origin CorDapp - The CorDApp where the asset will be requested from
Origin Address - The CorDapp's address. In this case, the Cordite CorDapp's account address (e.q account-1@OU=xinfin, O=xinfin, L=London, C=GB)
Reason for Transfer (optional) - Transaction details for clarity
(Step #10) Once all data has been entered correctly, the Send button is activated. Once clicked, a successful transaction confirmation message will appear, else a notification of failure will be displayed.
(Step #11) Refer back to (Step #7) to view transaction history and transaction details.
Impel's R3 Corda | XDC Network Bridge Architected Design
Impel's bridge platform's architectural style is classified as a Service Oriented Architecture (SOA), to which there are two main services; a user interface service and a bridge service.
A strong advantage of having decoupled application components allows for readiness to easily connect with each new component or with other types of network systems.
Using The Twelve-Factor App principles make Impel's bridge scalable, robust, clean, and easy to incorporate additions.
The main components of the architecture (Image 1) are denoted with digits from 1 to 6 and each one is explained as follows;
The architecture has four core components:
Other bridge actions;
Both the UI and Bridge service uses a Layered Pattern that helps to organize project files and folders, simplifies the entire project structure. This pattern works real well with Angular 9 concepts like service and components to which Impel's bridge uses.
Most importantly, the Adapter pattern is the chosen methodology design used, assisting the bridge service, and allows to scale the system vertically. Depending on the teleport event or if the payload includes digital assets, the appropriate adapter class is chosen to complete a successful transaction.
Other design patterns used by Impel's bridge for both UI and Bridge services include:
Impel's ISO 20022 API uses a Layer 2 security solution
Layer 2 is a collective term for solutions designed to help scale your application by handling transactions off the Ethereum Mainnet (Layer 1) while taking advantage of the robust decentralized security model of Mainnet.
Layer 2 solutions are built on top of a Layer 1 blockchain DLT protocol (like the XDC Network) to utilize security on a private layer to protect the data from being made public on the public decentralized blockchain. It also lowers transaction costs by combining multiple off-chain transactions into a single message, and also increases transaction speed with the use of data rollups.
Increased transactions per second greatly improve user experience, and reduce network congestion on Mainnet Ethereum
Transactions are rolled up into a single transaction to Mainnet Ethereum, reducing gas fees for users and making Ethereum more inclusive and accessible for people everywhere
Any updates to scalability should not be at the expense of decentralization or security – layer 2 builds on top of Ethereum
There are application specific layer 2 networks that bring their own set of efficiencies when working with assets at scale
Impel's API utilizes a tremendous strategy for sending ISO 20022 financial messages over the XDC Network through an API that permits advanced security and complex data handling. Furthermore, Impel's Layer 2 functionality allows financial messages to be sent without interruption or exposure to a third party.
Our ISO 20022 API's Layer 2 solution is a better fit for meeting the needs of financial institutions using our financial messaging platform, as we have a modified version of the state channels Layer 2 scaling pattern, allowing for a smarter, more secure solution.
Components | Description |
---|---|
Core Components | Description |
---|---|
Action | Description |
---|---|
An application programming interface is a way for two or more computer programs to communicate with each other. It is a type of software interface, offering a service to other pieces of software. A document or standard that describes how to build or use such a connection or interface is called an API specification. (as per )
The following API endpoints are located at this URL:
Ethereum's describes Layer 2 as follows:
Ethereum lists the benefits:
(1) Blockchain
Is the core technology where all types of XDC Network transactions are stored.
(2) Smart contract
Bridge pieces of code stored in the blockchain that helps the system to interact and manipulate data in the blockchain.
(3) UI service
A Angular 9 frontend application created for user interaction with the system functionalities.
(4) Bridge service
NodeJS backend application containing the business logic functionalities of the system.
(5) Cordite bridge node
Cordite application node instance where bridge account is stored.
(6) Cordite node
Simple Cordite node where other accounts can be stored.
(U)ser
The human user interface interactions
(S)end
Send flow system actions
(R)eceive
Receive flow system actions
(T)ransactions
Transactions query system actions
U1. User interaction
The user can send or receive XDC asset value to or from Corda accounts and further this will trigger system actions like S1 or R1.
S1. Trigger send
Calls a smart contract method to send XDC tokens further to Corda account.
S2. Process teleports
Bridge service reads contract events and sends asset value teleports that will be processed further to be sent to the Corda network.
S3. Issue assets
Get teleports from the S2 action move this to Corda bridge account and further to the account used by the user using Corda API.
R1. Trigger settle
Calls REST API from the bridge account that initiates a settlement process, data that is passed to the API contains also the user and password credentials in order to connect to the Cordite account.
R2. Settle
Bridge service calls the Cordite API where it gets the XDC asset value and sends this to an XDC account.
T1. Query transactions
In order for the UI service to display transactions in real-time the system queries the blockchain for the last transactions that are not stored in the cache and displays this to the User Interface transactions component screen.
Message id
Created
Ok
Ok
OK
The bank identification code (i.e. SWIFT/BIC)
Ok
Unique identifier for this party
Name of party
Swift BIC for this party
URL for this party's gateway
Base64 encoded certificate
Addresses for this party
XinFin address
The RSQL filter to apply as search criteria
The zero-indexed page number, optional
The page size, optional with default being 10
Ok
A filter to get events from given date
A filter to get events to given date
The zero-indexed page number
The page size
Ok
The RSQL filter to apply as search criteria
The zero-indexed page number, optional
The page size, optional with default being 10
Ok
Unique identifier for this party
Name of party
Swift BIC for this party
URL for this party's gateway
Base64 encoded certificate
Addresses for this party
XinFin address
Send message request
Message end to end id
Sender BIC
Recipient BIC
Message payload type
Message payload
Collateral
Collateral type, e.g. native XDC or ERC20 token
Collateral amount
Collateral exchange price
Collateral exchange currency
ERC20 token symbol, required when type is equal to ERC20
Flag which enables payload validation
Accepted
Message id
Message id
Ok
Proof status
Proof status change date time
Proof channel hash as hex
Sender BIC
Recipient BIC
Net settlement collaterals
Collateral type, e.g. native XDC or ERC20 token
Collateral net settlement amount
ERC20 token symbol
Flag which tells if all parties signed a proof
Initiator signature
Counterparty signature
Proof's messages identifiers
Proof's messages identifiers
Proof's messages end to end identifiers
Proof's messages end to end identifiers
Proof creation date time
Proof update date time
Message id
Flag if payload should be returned in a response
Ok
Message id
Message end to end id
Sender BIC
Recipient BIC
Message payload type
Message payload - returned only if requested
Collateral
Collateral type, e.g. native XDC or ERC20 token
Collateral amount
Collateral exchange price
Collateral exchange currency
ERC20 token symbol, required when type is equal to ERC20
Message status
Message direction (INBOX|OUTBOX) which tells if message was sent or received
Message hash
Previous message hash
Flag which tells if all parties signed a message
Initiator signature
Counterparty signature
Proof
Proof status
Proof status change date time
Proof channel hash as hex
Sender BIC
Recipient BIC
Net settlement collaterals
Collateral type, e.g. native XDC or ERC20 token
Collateral net settlement amount
ERC20 token symbol
Flag which tells if all parties signed a proof
Initiator signature
Counterparty signature
Proof's messages identifiers
Proof's messages identifiers
Proof's messages end to end identifiers
Proof's messages end to end identifiers
Proof creation date time
Proof update date time
Message creation date time
Message update date time
The RSQL filter to apply as search criteria
The zero-indexed page number, optional
The page size, optional with default being 10
The field to use for sorting
The sort direction, either ASC or DESC
Ok
Message id
Message end to end id
Sender BIC
Recipient BIC
Message payload type
Message payload - returned only if requested
Collateral
Collateral type, e.g. native XDC or ERC20 token
Collateral amount
Collateral exchange price
Collateral exchange currency
ERC20 token symbol, required when type is equal to ERC20
Message status
Message direction (INBOX|OUTBOX) which tells if message was sent or received
Message hash
Previous message hash
Flag which tells if all parties signed a message
Initiator signature
Counterparty signature
Proof
Proof status
Proof status change date time
Proof channel hash as hex
Sender BIC
Recipient BIC
Net settlement collaterals
Collateral type, e.g. native XDC or ERC20 token
Collateral net settlement amount
ERC20 token symbol
Flag which tells if all parties signed a proof
Initiator signature
Counterparty signature
Proof's messages identifiers
Proof's messages identifiers
Proof's messages end to end identifiers
Proof's messages end to end identifiers
Proof creation date time
Proof update date time
Message creation date time
Message update date time