Rate3 Technical Architecture Part 1: Using Stellar to power transactions

Davis Gay
Official Rate3
Published in
15 min readMay 8, 2018
An overview of our Technical Structure

We will be publishing a series of articles explaining our technical architecture, our rationale and technical roadmap:

Part 1: Why we chose Stellar to power transactions

Part 2 : How Ethereum is used for credit scoring (coming soon!)

Part 3: A Detailed Technical Roadmap and Implementation Plan (coming soon!)

Rate3 will be an end-to-end global payment network for all players in the e-commerce space (consumers, retailers, distributors, manufacturers, etc) to send and receive cross-border e-commerce payments easily. The payment networks that we know today is far from ideal. Cross-border payment frictions arise from the presence of various intermediaries, causing:

  • Expenses, delay and friction
  • For instance: Swift takes up to 3 days/$40. Likewise goes for SEPA in europe and ACH in US.

Given the above issues, three major issues arise in the global e-commerce space today:

  1. Cross-border payments
  2. Lack of reliable trustworthiness assessment
  3. Ineffective incentive system for all participants
Rate3’s Mission: Payments should be as easy as the Internet.

The Rate3 Mission

We believe that payment can be easy and it should be — see why we started Rate3 Network. Rate3 is established for three key reasons:

  • Create a simpler infrastructure for establishing trust and incentives in e-commerce relationships
  • Facilitate fast transfer of funds between the merchant and the consumer, for both cross-borders and domestic online purchases
  • Establish a reliable and accessible credit scoring system for traditional lenders and capital providers

To achieve these objectives, any payment infrastructure powering Rate3 has to have the following properties:

  • Store, prove possession, transmit value.
  • Fast and scalable
  • Decentralised
  • Interoperable
  • Fungible
  • Easy to exchange
  • Easy to adopt
  • Secure

Fast and scalable

To facilitate real-time purchases and accessible credit, there should be payment confirmation in matters of seconds. Other than speed, the payment infrastructure needs to support current and future growth of global transactions volume. This also means that the transactions fee should be very low in order for payments on Rate3 network to have zero transaction fees.

Decentralised

The peers in the payment infrastructure need to be able to run independently of each other. If Visa servers fail, the Visa card network will cease to function and we will not be able to use pay online with our Visa card. Similarly if a single bank network fails, no one will be able to touch the money in the bank. To achieve a truly open and highly available payment service, we will need a decentralised payment network.

Interoperable

Transactions should be interoperable like how the Internet made emails interoperable. Send messages to anyone and you do not think about it. Pay anyone and anywhere at ease.

Fungible

Money in the payment network should also be mutually interchangeable. For example, one kilogram of pure gold is equivalent to any other kilogram of pure gold. The value of 10 RTE from any Rate3 participant should be recognised as 10 RTE.

Easy to exchange

Unless the world operates on a single currency, there will be a need to exchange between currencies in global payments. Payments received need to be in correct currency for further use for other payments inside or outside of Rate3. Ease of exchange contributes to ease of global payments.

Easy to adopt

Low barriers to entry allows more entities to create transactions and generate economic activity. As simple as passing money hand-to-hand, yet this is done through a global infrastructure.

Secure

An ideal payment infrastructure should have strong security to protect assets transacted in via the infrastructure. For Rate3 to be widely adopted, it has to be trusted. The payment infrastructure of Rate3 has to be robust and data should be immutability, if not resistant to unintended changes.

Enter Stellar: an Open Protocol for Payments

Stellar is an open protocol to achieve the following:

  • Store, prove possession, transmit value.
  • Digitally represent existing currencies and assets
  • make payments interoperable across institutions and currencies
  • Create a scalable payment system

Stellar is a open distributed ledger comprising different servers running the Stellar Core software. Like a traditional ledger, the Stellar ledger records a list of all the balances and transactions belonging to every single account on the network. Stellar Core maintains a local copy of the network ledger and communicates with other instances of Stellar Core on the network to stay in sync. Any one can run a Stellar Core server. Changes to the ledger will be broadcasted to all servers.

Rate3 tokens (RTE) will be used as a medium of exchange for cross-border settlements, store-of-value for rewards and incentive programs organised any network participant and facilitate credit scoring in the network.

This article explains further on how the Rate3 network utilise the features of Stellar to implement these use cases:

Fast and scalable

The median transaction confirmation time is 3 to 5 seconds with a rough 3,000 transactions per second. This is possible via Stellar’s unique consensus mechanism —the Stellar Consensus Protocol which relies on message passing.

Decentralised

The Stellar network does not depend on any single entity. The idea is to have as many independent servers participate in the Stellar network as possible, so that the network will still run successfully even if some servers fail. Any entity can run a Stellar server.

Interoperable

The Stellar servers communicate and sync with each other to ensure that transactions are valid and get applied successfully to the global ledger.

Fungible

Let’s say Deutsche Bank had put €1 billion into colored coins on Bitcoin. Suddenly, after a fork (e.g. bitcoin vs. bitcoin cash), there would be €2 billion IOU’s in the wild. The people on each side of that fork would not roll over and die, and it’s not simple to say “Oh, whoever Deutsche picks wins.” Or even “Whoever has the strongest chain wins.” I have a hard time imagining a company would ever take that risk. I worry big companies would never dare to put anything real-world redeemable directly onto, say, Bitcoin or Ethereum, for this reason.

The Stellar federated consensus story has Deutsche Bank as an actual player on the network. If you want DB redemptions then you would include them in your trust lines / quorum slices, and if Stellar fell apart and became partitioned, you would stay on DB’s side. All said, it seems significantly faster and more stable for cryptocurrency-to-real-world mappings, both for the consumer and counterparty.

Easy to exchange

SDEX for currencies and even assets on the Stellar network

Easy to adopt

Open source and no setup fees.

Secure

Stellar uses industry-standard public-key cryptography tools and techniques, which means the code is well tested and well understood. All transactions on the network are public, which means the movement of funds can always be audited. Each transaction is signed by whomever sent it using the Ed25519 algorithm, which cryptographically proves that the sender was authorized to make the transaction.

Many other ways to secure payment infrastructure integration with Stellar https://www.stellar.org/developers/guides/security.html

In addition to the public ledger being tamper-proof, Stellar has additional security features:

On a macro network level, the nature of SCP (being a FBAS) is such that each Stellar network node can choose any number of nodes to validate their transactions. This set of trusted nodes form a quorum slice in the consensus protocol. (More accurately, you should only trust nodes that you think are not in collusion with your other trusted nodes).

Stellar also uses industry-standard public-key cryptography tools and techniques that are well tested and understood. Each transaction is signed by whomever sent it using the Ed25519 algorithm.

On a more micro level, Stellar accounts also have to explicitly trust an asset issuer before it can hold the asset. There is also support for multi-signature contracts which require more than one weighted signature to sign an operation for it to be valid, according to the operation/account threshold. Moreover, Stellar optionally allows issuers to reserve the ability to freeze tokens in the event there is misuse.

Stellar contracts are also less expressive than Ethereum. Stellar contracts are based on atomic multi-operation transactions. While it loses the full generality of Turing-complete smart contracts like Ethereum, it has fewer pitfalls and hence can improve the security of the system and lead to more auditable code. Many blockchain hacks were due to exploits in smart contract vulnerabilities which are hard to fix as it is published on the blockchain.

Open-Source

Stellar code is also open-source, which means it can be publicly viewed, audited and improved.

Powering Payments through Stellar

Asset Flow and Network Operations

Via Rate3 interface apps, network participants will be able to send and receive any supported assets (physical or digital) in additional to RTE in the network. RTE will be the means of exchange in Rate3 network.

First, we have to understand how assets are transferred in Stellar network.

Real world assets such as dollars, euros, bitcoin, stocks, gold, or even physical goods like bananas can be tokenised on the Stellar network. The Stellar distributed network can then be used to track, hold and transfer these Stellar asset tokens (henceforth referred as assets for brevity). All assets on the Stellar network has an asset type e.g. USD, BTC and issuer, the account that has created the asset.

Accounts are the central data structure in Stellar. Accounts are identified by a public key and saved in the ledger. Everything else in the ledger, such as offers or trustlines, are owned by a particular account. Accounts can be used for various special purposes aside from general wallet use such as issuing tokens (issuing account), distributing tokens (distribution account).

The tokenisation of real world assets are done by special entities in the Stellar network, known as anchors. Anchors can be run by anyone — individuals, small businesses, local communities, organisations, etc. Anchors are entities that people trust to hold their deposits and issue credits into the Stellar network for those deposit. They are a bridge between assets in the real world and the Stellar network. Paypal is an example of anchor outside of Stellar network. You will deposit money in Paypal from your bank account and you are issued Paypal credits into your Paypal account. You can then send the money credits around the Paypal network to anyone who trusts Paypal. The recipient can then then convert the Paypal credits to real money by withdrawing it to the bank.

Asset transactions on the Stellar network is a form of network operation. A Stellar network operation involves a negligible fee (discussed later). A group of network operations is called a transaction. Transactions to be submitted to the public ledger sent via an RESTful HTTP API server called Horizon which help applications to communicate with the Stellar network. Sending and receiving payments is one of the few smart contracts in Stellar Smart Contract (SSC). A SSC is expressed as compositions of transactions that are connected and executed using various constraints. Some constraints are multi-signature, trustlines, batching/atomicity, sequence and time bounds

Rate3 will have an issuer account that creates the RTE tokens on Stellar network and distribution accounts to distribute RTE to wallets generated from interface apps. Channel accounts will also be created to facilitate high-rate transactions from different processes in Rate3 network.

Channel accounts are simply another Stellar account that acts as the “source” account of transaction. Channel accounts help to ensure that transactions submitted are in correct order of their sequence numbers. Transactions in Stellar have a source account that can be different than the accounts being effected by the operations in the transaction. The source account of the transaction pays the fee and consumes a sequence number. The base account (to make the payment from) can be used to make the payment operation inside each transaction. The various channel accounts will consume their sequence numbers even though the funds are being sent from the base account.

Fast and Safe Transactions

Stellar is designed from scratch to be a global distributed payments system that supports large scale transactions.

Stellar network is faster and safer than most blockchains. This is made possible by narrowed scope of smart contracts (SSC) meant for financial transactions and Stellar Consensus Protocol (SCP). SCP provides a way to reach consensus without relying on a closed system to accurately record financial transactions. SCP is the first provably safe consensus mechanism (modified federated Byzantine agreement system, FBAS) that simultaneously enjoys four key properties: decentralised control, low latency, flexible trust, and asymptotic security.

Comparing consensus protocol for distributed networks. Source: Stellar

In FBAS, nodes use a federated voting technique to get to an agreement.

The federated voting technique leads an FBAS, or a bunch of people in a coworking space, to agreement. Source: Stellar

The overall process involves initial voting, acceptance, ratification and confirmation messages.

Initial voting is where individual nodes do a “soft” decision on the outcome but open to change based on majority of other nodes in a group (quorum slice). In the illustration above Vanessa votes to be open to accept pizza. She has never and will never vote for any option contradicting pizza.

Acceptance involves nodes in difference slices influencing the decision of another. Nodes in the same quorum slices with opposing votes (v-blocking set of nodes) block the action of an individual node. Assuming Vanessa votes for hamburger instead in her initial voting. Her friends who are in quorum slices with Vanessa can block her action and influence Vanessa to accept pizza instead. The conditions to make Vanessa accept what she did not vote are:

  1. Vanessa has never accepted a contradicting statement to pizza.
  2. Each member of v-blocking set claims to accept pizza

The next process will be ratification where every member of a quorum agrees on the same outcome.

After that, confirmation is the final step of voting and implies system-wide agreement. A system agrees on a statement if sufficient confirmation messages are delivered and processed. Subsequently every responsive and accurate node will accept the statement.

SCP takes on the challenge of distributed consensus where there is trade-off between arriving at consensus and risk of getting blocked and losing liveliness (split votes). Blocking statements are neutralised by a ballot-based approach where a referendum is held to commit or abort any options once nodes agree on an option or agree to discard an option.

On every SCP round, the network reaches consensus on which transaction set to apply to the last closed ledger; when the new set is applied, a new “last closed ledger” is defined.

Since consensus is reached via message passing, it is fast like the internet, as compared to proof-of-work (mining). For example, if you want to send $10 to someone on the network, a list of trusted servers will begin the process to agree on the validity of your $10 payment to the recipient. The majority of these servers will have to agree that you do in fact own $10 worth of credit on the network via the mechanism described above before they will mark the transaction as valid. The entire process of reaching a consensus on the Stellar network takes a median of 5 seconds to process on Stellar compared to approximately 15 minutes on Ethereum. This is faster than most global payment networks out there.

On normal hardware (basically a machine with a SSD drive only), Stellar could support up to 4000 transactions per second (t/s). This transaction speed can be increased with more nodes or better hardware. Barclays Africa’s chief executive for corporate and investment banking, Stephen van Coller said that they can do ~10,000 transactions in a test with Deloitte.

For comparison, Bitcoin does 3–7 transactions per second. Etherum does 15 transactions per second, Visa does average 1,736 transactions per second at current volumes and 24,000 transactions per second at actual capacity.

Zero Fees

Rate3’s mandate is that there will be zero network fees for all participants.

This is made more sustainable from the low cost associated with using Stellar. There is no start-up costs and integration fees to use Stellar as it is a decentralised and open-source protocol. The Stellar network is usable immediately via Stellar SDK. Even for more complex business systems integration (think financial institutions, payment gateways, etc) with Stellar network, anyone can host Stellar Core, Horizon, compliance, federation and bridge servers to handle communication between existing company systems and Stellar network. Hosting these servers does not require any crazy hardware either.

Stellar does not require any “gas” to execute programs and only requires a negligible transaction fee. There are two kind of fees associated with using Stellar. Base fee for transactions and base reserve for minimum account balances.

The base fee at time of writing is 100 stroops which is 0.00001 XLM (USD 0.000002190 at USD$0.218957/XLM). XLM is the code for lumens, the Stellar network native asset.

Transaction fee = # of operations × base fee

A transaction that allows trust on account’s trustline and sends a payment to that account will have a fee of 2 × base fee = 200 stroops. Stellar deducts the fees from the transaction’s source account, regardless of which accounts are involved in each operation. As aforementioned, source accounts allow Rate3 to fund the XLM required for network transactions, which are negligible anyway.

Lowest exchange rate

A unique feature of Stellar is that it has a native decentralised distributed exchange within the network. Any Stellar accounts can access this exchange as part of a network operation and any asset issued on the Stellar network can be exchanged.

The Stellar ledger stores both balances held by accounts and offers that accounts make to buy or sell assets. Offers in Stellar behaves like limit orders in traditional markets. The account must hold the asset it wants to sell and similarly, the account must trust the issuer of the asset it’s trying to buy. When a offer crosses an existing offer, it tis filled at the price of the existing offer. For example if an offer to buy 10 XLM for 2 BTC is made and there is the existing offer to sell 10 XLM for 2 BTC, your offer will take that offer and the assets are exchanged.

If the offer does not cross an existing offer, the offer is saved in the orderbook. An orderbook is a record of outstanding order on the Stellar network. Some asset pair might have nonexistent of thin orderbook. To mitigate the impact of thin orderbook on liquidity in the Stellar network, there is another feature called cross-asset payments. Cross-asset payments supports sending from a source asset (code and issuer) to any other destination asset. It makes use of the orderbook to look up the lowest offers available to help convert the assets via up to 6 chained offers. Cross-asset payment is an atomic operation. It will either succeed or fail. Payment send will not be left with unwanted asset when the cross-asset payment fails.

Rate3 will make use of the exchange at two fronts. During the early implementation phase where Stellar liquidity is not high enough for instant cross-asset payments, we can do bulk asset conversions to other currencies or assets on Stellar network and withdrawing them to real-world to send to network participants when needed. As Stellar network grows and more anchors support different kinds of fiat currency tokens, it will be more efficient to use on-demand asset conversions using cross-asset payments.

Powering Rewards through Stellar

Reward programs such as cash back or loyalty points are common in the e-commerce space. Issuing of rewards points, cash back or gift cards can be done easily via Rate3 and interface apps. Rewards can be in the form of RTE tokens and be converted to fiat or other assets, depending on the reward recipient. Rewards can even be new Stellar asset issued by us e.g RTEACME to be used only at ACME merchant.

Cash back usually takes up to 2 to 30 days to be credited. This is due to accounting delays and slow movement of payments. In Rate3, transactions are recorded on the public ledger and the once the ledger is closed through

Stellar network is immutable and fast. The entire process takes about 3–5 seconds. This means cash back and rewards can be issued quickly since payments moves within the network and is confirmed in near instant.

Querying Transaction Data through Stellar

Transaction history and details in Rate3 network can be obtained by querying the Stellar ledger. We can differentiate payments to Rate3 network participants as compared to Rate3 address when participants’ account address is registered with our federation server on the Stellar network.

The Stellar federation protocol maps Stellar addresses to more information about a given user. It’s a way for Stellar client software to resolve email-like addresses such as name*yourdomain.cominto account IDs like:GCCVPYFOHY7ZB7557JKENAX62LUAPLMGIWNZJAFV2MITK6T32V37KEJU. Stellar addresses provide an easy way for users to share payment details by using a syntax that interoperates across different domains and providers.

Other services who wishes to use the credit score from Rate3 can do so by querying our compliance server. This server supports Stellar compliance protocol for external services in Stellar network and will also support RESTful API endpoints for non-Stellar services.

We have come to the end of Rate3 Technical Architecture Part 1: Using Stellar to power transactions! Stay tuned for Part 2, where we will elaborate on Ethereum for credit scoring.

About Rate3

Rate3 is a decentralised dual protocol for cross-border payment and credit scoring. Rate3’s Cross-Border Payment Protocol and Credit Scoring Protocol aim to empower a world of payment without borders. Rate3 Network’s first chrome dApp is live on Rate3 testnet and you can try it out here: https://www.rate3.network/testnet. Likewise, their Pre-Sale has started and you can participate here: https//kyc.rate3.network.

Website: https://rate3.network

Blog: https://medium.com/official-rate3

Twitter: https://twitter.com/officialrate3

--

--