Before we dive into the details of how we imagined, designed, and then developed a Proof of Concept on an InterPlanetary Payment System, let's talk about why we got inspired to do such.

Problems we're addressing

From the early 2000’s, payment gateways such as Visa and Mastercard have dominated cashless money transfers through their centralized monopolistic network - which in many ways have given them a price-setting capability. What if we had a system that provides a breakthrough in this market by leveraging blockchain network as ground truth and thus removing friction and intermediaries within the fiat money transfer systems? What about the jurisdictions or regions that don't allow or are still in the process of legalizing crypto?

To highlight three (3) core problems:

1. The high percentage of transaction fees, set by the Payment Gateways
2. The slow currency conversion rates, often delayed by KYC/AML checks
3. Lack of proof-of-reserve (and hence, inter-bank communications)

Hence, to seek the possibilities and address its technical feasibility, we started working on a Proof of Concept and called it IPPS (Inter Planetary Payment System). It's a blockchain-based payment gateway system to enable centralized banks or any financial institutions to participate in DeFi movement by tokenizing fiat assets.

Solution Overview

IPPS aims to leverage concepts of Proof of Reserve, Zero Knowledge Proof, and Mint-and-Burn techniques to implement a payment system in an ecosystem of Banks/Financial Institutes, Stakers, Users, and Merchants. It uses Chainlink Nodes, Exchange Price Feed, and Proof of Reserve oracles to achieve these. It also uses web3.storage, Polygon, and NFC (Near field communication) cards for the user-end payment application. Some other common tooling, such as Solidity & Typescript, OpenZeppelin libraries, Typechain, Hardhat, Mocha, and Chai.

System Components

1. Banks: Banks provide us with users; fiat balances in their respective accounts. These assets are then tokenized by minting XX tokens in a 1:1 ratio according to their fiat balance.
2. Stakers: Stakers stake in favor of these banks, validating and lowering risks for users in case banks opt out from providing fiat balance to our users against XX token. They are rewarded with a portion of transaction fees and governance tokens
3. Users: The users of our platform who can make payments, and transfer balances in XX tokens (representing their fiat balance) - Should we charge users/ banks for using our service?
4. Merchants: The business organizations registered within a bank - who pays (subscription fee/ percentage amount - per transaction?) a certain amount when receiving XX tokens from users as payments. (Should we/banks charge them cash-out fees when redeeming XX tokens to fiat?)

User Journey/Process Flows

Bank & User Onboarding

A bank requests to join X platform specifying a limit (which can’t be exceeded for this bank unless changed)

Stakers verify and stake in the stablecoins

Banks get limits for the amount which is staked for that particular bank

Banks provide us with user wallet addresses and initial fiat balance (amount which they internally decide to allow for each user - may vary from user to user based on their use or balance)

X mints XX tokens to user's wallet in a 1:1 ratio to its balance (provided by the bank).

Additionally, the wallets are whitelisted in the protocol so that the tokens are non-transferable to any other address

Merchant Onboarding

Merchant wallet addresses are provided by the banks

Whenever a token is transferred from other wallets (from users), a small fee is charged - which could be the main source of revenue for IPPS

Merchants can redeem these tokens from banks

Staker Onboarding

Stakers view limit requests by the banks in IPPS

Additional details of banks are uploaded in Filecoin

Stakers stake an amount in favor of the bank to provide them limit for that particular amount

Stakers receive transaction fee shares proportional to their staking amount (Whenever users make payments using XX tokens)

Additional Note on Staking

A bank can stake in favor of itself too - As onboarding stakers is not our goal. The goal is to minimize the risk for users in case the banks decline to provide fiats against XX tokens. In such circumstances the DAO can reimburse platform users with staked assets (most likely stablecoins).

What's Next?

We have quite a few things on our roadmap, including:

1. DAO Contract development and deployment: Stakers get privileges as DAO members with the governance token distributed respectively to their staking amount. They can perform certain actions, protocol management, etc. with these governance tokens, received along with transaction fee shares
2. Chainlink ZK Proof: Leveraging Chainlink ZK Proof for interbank comms, like age verification for user eligibility
3. Chainlink VRF: Implementing Chainlink VRF if we want to pick random stakers via reward/incentivizing programs
4. Chainlink Automation: Integrating Chainlink Automation to execute smart contracts via cron job in terms of periodic transactions

Technical Specifics

Technologies

Languages: Solidity, TypeScript

Libraries: OpenZeppelin, Typechain, Wagmi React Hooks

Frameworks/Development Environments: Hardhat, Mocha, Chai, NextJS

Oracle: Chainlink

Storage: Web3.Storage

Infra: Quicknode, Alchemy

Chain: Polygon Mumbai

Others: NFC Card

Technical Architecture

Note: This is an early version of the technical architecture draft we published publicly. The most recent architecture versions, Figma designs of Bank UI, Staker UI, and Mobile UI are in progress closed-source.

Demo

1. Video: https://youtu.be/WkEaQCn6oBI
2. Technical/DevPost Ideation: https://devpost.com/software/x-defi

End Note

As we continue to experiment with different proof of concepts with an aim to solve problems at Leveor, we would very much like to hear how our team can help you to solve yours! We're always one email away from you, live and listening on the other end of [email protected].