Web3 protocol
Last updated
Last updated
Fundamentally, Sumara’s smart contract protocol requires five services to create the smart contracts for each transaction:
KYC & AML
Payments
On-chain Document Management
Credit
Sumara smart contracts
Each of these is run as a microservice.
KYC, KYB & AML are crucial processes for bringing real-world companies into on-chain DeFi products.
Sumara’s approach is inspired by that used by Goldfinch. KYC, KYB and AML processes are conducted by off-chain third parties. Personally identifiable information remains stored off-chain, with a Unique Identity (UID) created as a non-transferrable NFT on-chain representation. The UID follows ERC-1155 standards.
KYC, KYB and AML will be required for all participants in a trade facilitated by Sumara, and consequently a UID will be created for exporters, suppliers and lenders (lenders UID will be via Goldfinch if used in v1).
Note that in smart contract transactions, customers will be referenced with their UIDs so there is one global identifier for each entity. This is important for when Sumara’s protocol is an open platform in later phases.
Payments microservice will be split into:
Traditional- which will support off-chain payments and record relevant parts on-chain
On-chain, which will support crypto native payments (eg. USDT).
These parts may interact where a transaction has the payin using crypto, and the payout using fiat (or vice versa).
To ensure transparency and immutability, for payments that occur partially or entirely off-chain, Sumara records these transactions as events in smart contracts as event logs. Sumara creates a specific smart contract designed to log off-chain transactions and interact with other relevant smart contracts for verification and storage.
It does this using the following process:
Responsible for logging off-chain transactions
Stores transaction details such as the sender, receiver, amount, transaction type, and a unique transaction ID.
Also has functions for recording, updating, and verifying transactions
Handles the verification of transactions logged by the OffChainTransactionLogger
Integrate with external services to verify that the off-chain transaction has occurred
Handles the storage and verification of trade documents using IPFS and Ethereum smart contracts.
Sumara will generate transaction documents, which are stored using IPFS with smart contracts managing document metadata. It will record as part of a transaction relevant off-chain data, and create immutable records that can be trusted and relied on by parties in the transaction.
Sumara requires access to credit to finance international transactions (where applicable).
The Sumara credit microservice facilitates access to credit and collateral management using DeFi protocols.
Credit will be sourced from third party on-chain deFi protocols Goldfinch or Huma Finance in v1. Sumara may raise credit on our own platform in subsequent phases, depending on suitability and economics of third party DeFi protocols available.
Sumara uses an automated risk underwriting model. Until at least v2, this will be augmented by human decision making. Human decision making will be used until data suggests that Sumara is able to support fully automated risk underwriting.
In v1 Sumara’s risk underwriting model uses the following logic, inspired by the model created by Huma Finance:
Sumara will gather on-chain and off-chain information, and supply to an on-chain Decentralised Signal Portfolio service
Sumara will develop and run an on-chain Evaluation Agent service
Where the Evaluation Agent approves finance, funds will be drawn from the lending pool and released to the Sumara transaction smart contracts
Repayments will be released back into the lending pool at the conclusion of a transaction by the Sumara smart contracts.
This approach gives Sumara control over all parts of the automated risk underwriting model, allowing learnings to be made to refine this model. Sumara is assessing the use of Huma and Goldfinch as DeFi lending supplier in v1.
In the event of a transaction, these microservices interact as follows:
KYC and KYB of clients
Minting of UIDs for verified entities
Credit Request and Approval
Loan requested in the credit microservice (if applicable)
Loan is approved, and funds are made available
Document Upload
Trade documents uploaded to IPFS
Document hashes are stored in on-chain document management microservice
Payment
Payment transacted through on-chain payments microservice, referencing the document hashes (note- may be value transfer for on-chain payments, or records for off-chain payments)
Verification and Finalization
On-chain payments microservice verifies the set of transaction documents through the on-chain document management microservice. On successful verification, payment released
Transaction is completed, updating the status in on-chain document management microservice.
This workflow applies to each of the following transaction types, with certain variances:
International payment
International payment using virtual accounts (with & without use of credit line)
Letters of Credit
Proof of funds / payment guarantee
