Skip to content

Payment Layer Design and Architecture

This is an issue to design NuNet Payment Layer architecture for the implementation on tops of contracts package emphasising good design but also speed and simplicity of implementation.

Summary

  • Payment providers are entities in the nunet network, which have the capability to relay claims to settle transactions between other entities (DMSs) in the network via a third party payment layer. Payment providers implement interface between NuNet (concretely, DMS) these payment layers:
    • In case of blockchains (Ethereum, Cardano, or potentially others), payment providers layer includes only a regular DMS (which would have a build-in capability to interface between dms contracts and blockchain RPCs); the only difference may be that they would need to keep secret API keys for that;
    • In case of Fiat payments, the architecture may be more complex, as interface to fiat payment layer is more complex than web3 infrastructure;
  • Nunet Appliance is the current (and evolving) UI for accessing DMS installation and machine; It already has a web management interface, served from a machine with a dms installed into it. This web interface will be used for integrating a chosen crypto wallet so that users can sign transactions issued by the contract host; In principle it could be any wallet that has a browser extension; The first candidate is ASI-Wallet, developed within ASI ecosystem (https://github.com/fetchai/asi-alliance-wallet?tab=readme-ov-file, which is a fork of Kepl https://www.keplr.app/);

Connections

  • Green connections represent calls of DMSs (representing compute providers, service providers or other entities in the network that need to transact value);
  • Blue connections represent internal interface within payment provider's entity between dms and other components; As per current estimation, these will not be needed for blockchain powered transactions, since payment provider 's DMSs will directly interact with blockcahin RPCs;
  • Red connections represent communications between NuNet network and external RPCs / Payment APIS and defined by the implementation of these external components;
  • All communication (arrows) within nunet network will be secured via nuActor system (so green and blue);

Use-case / behavior

A contract is signed between two entities represented by DMS#1 (service provider) and DMS#3 (compute provider) and indicating Payment provider #1 (who is possibly, but not necessarily, is also a contract host, indicated in the contract). When parties settle their transactions according to the contract, a contract host issues transactions for parties to sign;

Relevant / historic conversations:

Edited by kabir