This topic is to discuss the proposal submitted by @sathyachainaim
Please see below for the details of the proposal and discussion.
TBD
Current status: Under Consideration.
Opened for community discussion on : TBD.
ZK Proof Engine for Tokenization (ZK–PRET)- RWA Supply Chain Finance
Project Background
ZK PRET provides business infrastructure capabilities to real-world tokenization ZK business applications addressing privacy concerns; the biggest blocker for blockchain adoption for institutions. ZK PRET produces proofs for business processes and risk models for customers based on standards like Business Process Modeling Notation (2.0) and ACTUS financial risk modeling standard, with the basic business and risk factors fed from standards-based RWA information and produces the deep composition proofs, that addresses the next challenge of compactly delivering verifiable privacy-protected business sensitive content, powered by MINA blockchain.
Most first-generation tokenization protocols just do a hash of the off-chain information/documents, which limits real-world use cases; they do not address full-scale adoption concerns- privacy, business sensitivity, compactness, and aggregated and iterative negotiations needed for regulated real-world use cases. ZK PRET uniquely enables deep integrity based on standards that produce clean data for risk models, adding to the basic content verification. The capabilities can be used to power a variety of tokenization use cases, including tokenization for mortgages, supply chain finance, trade analytics, stablecoin business processes etc.
ZK PRET will have the component capabilities implemented generically for many tokenization use cases, and the reference implementation will be for supply chain finance. The analogy will be EigenLayer, a generic protocol, with EigenDA being a reference implementation, a specific case of that generic protocol.
SCF-RWA-Reimagined is a reference implementation of ZK-PRET for supply chain finance, including international trade finance and insurance. This business infrastructure produces layers of proof composition to reduce the validation risk for financiers in supply chain finance.
Tokenization efforts are poised to grow exponentially, BUT if we must bring the next one billion people into Web 3, the use cases that are going to be helpful are the ones that are inter-twined with the lives of most small business owners day-to-day who power most economies, which is what Supply chain Finance brings. for real-world use beyond speculation. This is expected to be 2-3 trillion in demand in international trade and up to 16 T, including all domestic working capital efficiencies, as Tokenization becomes the defacto going forward.
This proposal is built on the win at ZK Hack-o1Labs at ZK Montreal, and other EVM chain-based hackathons in EVM chain (XDC) for complimenting functionality, and deep technical and domain expertise in standards-based proofs for practical Tokenization/Institutional Defi.
For more details on our research on Supply Chain Finance Scope, and Impact to visit the sections in the detailed proposal.
Why ZK? Why MINA?
The most significant barrier to blockchain adoption has been the hesitancy to put sensitive business information on the blockchain. Our extensive enterprise blockchain experience notes significant legal, operations, and technology concerns. The major issues have been business privacy and the scalability of off-chain information that counterparties need. Please refer to our publications, research, and industry experiences in a detailed proposal for our research work on blockchain adoption for real-world use cases and the success factors for mainstream adoption.
ZK-PRET builds MINA capabilities to support the needs of these B2B and B2B2C capabilities, like
-
off-chain recursive proofs-to-be-proven on-chain
-
optimization of rich off-chain data for scalability needs in blockchains
-
producing high-level and high-value proofs in data availability layers for modular blockchain stacks
-
built on a tech stack with Typescript to draw more developers
Architecture & Design
ZK PRET consists of 4 sets of tokenization capabilities to define minimally needed, business-sensitive, privacy-protected, and scalability-aware tokenization.
-
Deep Composition Engine – Identity, compliance, schema standards, and inter-object integrity proofs.
-
Business Process Prover – Proving actual off-chain business processes conform to the expected steps to represent RWA on-chain.
-
Risk Model Prover — Represents what the counterparties need for risk management for next-gen Fintech / Institutional Defi. It is based on emerging standards and vast research in traditional finance, systemic defi risks, and next-generation data/contract standards for RWA tokenization and institutional defi models.
-
Domain Oracle Registry—RWAs with different business domains require different checks. This registry is the store for the standards and processes by domain.
These modules are designed:
-
To be used as a stand-alone component in any tokenization projects for specific capabilities by any development teams.
-
To be assembled for end-to-end tokenization and reference implementation for supply chain finance.
Here are some case examples of how the stakeholders will use the services.
-
On the demand generation side, **the borrowers will prove their genuineness/creditworthiness to have wider access to finance without exposing all their data, choosing to select financiers **, and eventually to be set up for even fractional financing.
-
Traditional finance companies increasingly seek aggregator services like ZK-PRET to streamline their operations. Their need is on portfolio-level decision-making, requiring high-fidelity invoice bundles and vetted standards-based risk assessments (e.g., ACTUS framework ). These companies benefit from ZK proofs demonstrating compliance with risk thresholds while maintaining confidentiality around internal loan/finance decision-making processes.
-
The defi protocols, entering into newer collateralization systems beyond over-collateralized crypto-based lending, need ZK-PRET services to prove to regulators that they comply with the capital ratios( active US regulation discussions for US and global institutional defi along the lines of Basel 3 extension), based on their transactions and off-chain data, without exposing deep transaction details. We expect this requirement in the next 6 months.
-
Also, we do see the merge of RWA and institutional defi, which needs precise risk modeling for newer stable, higher yet realistic and sustainable yields. These systems need business-sensitive data that will have to marry on-chain and off-chain data to adhere to compliance ratios and depositor returns. This needs private and public data combinations to be put together as proof for various situations and stakeholders.
Architecture
ChainAim ZK PRET focuses on elevating technical infrastructure into a business-oriented layer tailored for privacy-protected enterprise data sharing. This involves aligning business data standards for tokenization use cases and serving as a “master attestor” for key standards, such as DSCA for bill of lading ( supply chain finance ), PEPPOL for invoices, ACTUS for risk compliance, and LEI, for global legal entity identification.
-
Deep Composition Engine: Provides attested identity (of participants) , along with compliance, collateralized title information. In the SCF reference implementation includes the following standards :
-
DCSA ( for Bill of Lading )
-
PEPPOL ( e-invoice) standards.
-
ACTUS for risk compliance in institutional DeFi.
-
Identity Standards (LEI), and local jurisdictional standards.
-
Business Model Prover: Uses the BPMN2.0 standards to define expected, actual business flows and proofs to indicate accuracy.
-
Risk Model Prover: This tool uses the ACTUS unified standard of Finance to produce proofs based on standardized contract types ( for example, Principal At Maturity, Annuity, Forex, etc ) for risk thresholds set by financiers for Value At Risk, Liquidity Ratios etc. This capability is generated based on the attestation from an ACTUS implementor( ChainAim’s ZKPRET). Over time, this will be decentralized, and we will be looking to onboard other validators for this service.
-
Domain Registry: The registry defines the metadata to host the standards and the source providing the standardized information in different jurisdictions.
The registry is expected to put out a proposed structure and will host:
a. Define generic metadata for a variety of use cases to identify the standards and the schemas for transactional integrity.
b. Mock APIs and Mock responses for all standards APIs for the reference implementation
c. Sandbox access to APIs in some jurisdictions over time.
d. Production APIs for an ACTUS implementation from a live implementor.
e. Attestor implementor details.
Please note that no standard has been widely adopted for business discovery services for DLT use cases. ChainAim will continue working with many standards organizations, regulators, and universities to promote this concept. As things evolve, this is an opportunity for MINA research to get involved in such initiatives. Please refer to the detailed proposal. Please note that the Registry will evolve, and what we are putting out is first cut from a supply chain finance perspective and, hence, will be scoped minimally.
UX/UI
The UI/UX screens are available in figma for
the four stand-alone capabilities
the end-2-end supply chain implementation
These will evolve as we move through the project.
Data Flow
User journey of a MSME (MINAL Exports), as they go through working capital finance.
The components are implemented flexibly as ZKPrograms, Oracles, which can be instantiated as smart contracts on-chain for the reference implementation as well.
The sequence diagrams for the components and the Supply Chain Finance reference are given below.
The deliverables will include
- ZK app instance reference examples as smart contracts for individual proofs ( Like global Legal Entity Identifier for identification, business process checker for bpmn 2.0 adherence and expected versus actuals evaluation, ACTUS implementor for Risk threshold etc ).
Though this would be useful, given the nature of the complex orchestration of RWA steps, we are focused on deep composition as described below
- ZK programs as building blocks to compose recursive off-chain proofs to aggregate and optimize the on-chain state management. The ZK programs can be verified in smart contracts for proof of correct assertions effecting, optimized use of on-chain states.
The components of ChainAim ZK PRET’s predominant focus are to build a standards-based business infrastructure layer for finance flows, with a reference implementation for a supply chain finance for real-world financing use cases at the intersection of institutional defi and RWA.
The sequence diagram for an example SCF reference implementation use case is as follows:
Step 1: The Lender connects to the registry to find the SCF standards schemas. Lenders can modify any minimally needed data specifications.
Step 2: The Borrower connects to the registry to find the SCF standards schemas and decide the information they might want to share.
Step 3: The Borrower interacts with the ZK-PRET deep composition component to submit the transactions for identity and compliance and the instruments submitted for supply chain finance.
Step 4: The deep composition engine produces ZK proofs matching the minimally needed financier information to the Borrower’s privacy choice and submits the ZK proofs to the MINA blockchain to effect state changes based on the proof assertions.
Step 5: The borrower adds information on specific business process proof needs (bill of lading creation process in relation to other SCF documents like purchase order, booking, shipping instructions, etc), with their attestations and any relay attestations to the Business Process Prover.
Step 6: The Business Process Prover produces ZK proofs along with its attestation for the expected to actual results to MINA blockchain to effect state changes based on the proof assertions.
Step 7: The Lender provides privacy-protected(aggregated) information, including identity and business processes needed for institutional financial compliance, with lender attestation.
Step 8: The ZK Risk Model Prover runs the ACTUS protocol with the information provided for the risk factors(the availability or lack thereof id, compliance, business process proofs, risk thresholds), provides ZK proofs for the compliant risk assessment thresholds( modeled after Basel 3 but set up extensible) to the MINA blockchain, to affect any state changes.
Step 9: Based on the proofs/evaluation and the state changes, the Inst Defi/RWA protocol decides on the loan (approve/reject). This could be highly extensible regarding how projects would want to deal with liquidity, etc. The key for this project is to be able to prove the key financial ratios ( ValueAtRisk, Liquidity Ratio) to governance and regulators
Step 10: The Borrower accepts/rejects the finance terms.
Further tracking of continuous payment flows is currently out of scope
Please see the FAQ for more details on each pillar. Also, Please refer to the detailed proposal detailed proposal
Design
The ZK PRET Tokenization Proof Engine provides the Proofs needed for the tokenization process for data and process integrity. These programs are primarily designed as ZK Programs that can be composed and recursive, from self and different sources.
ZK-Programs versus On-chain
The components are implemented flexibly as ZKPrograms and Oracles, which can be instantiated as smart contracts on-chain. These components are extensible and adaptable. As the off-chain and on-chain options evolve in the MINA ecosystem, this design gives many options for gradually decentralizing these components and flexibly assembling standards-based off-chain information, counter-party sensitive data, off-chain storage, and on-chain state management.
The predominant focus of the components of ChainAim ZK PRET is to build a standards-based business infrastructure layer for finance flows, with a reference implementation for a supply chain finance for real-world financing use cases. It is designed to be adaptable to all deployment options. It is very complementary to projects in the MINA ecosystem around off-chain storage, programmable objects, collaborative oracles, and MINA to other protocol bridges, and data availability.
Please refer to the Vision and the Ecosystem sections in the detailed proposal. for more details.
1. Deep Composition Engine
The composition engine produces different categories of proofs for business processes. These could involve identity, compliance, and data integrity processes for any schemas that a business transaction has to be validated against and referential integrity between business transactions.
Please refer to section 3 of the UI/UX artifacts for Deep Composition Engine in Figma
The reference implementation for RWA Supply Chain Finance includes Identity, Compliance, data Integrity of the SCF data instruments that are the underlying data sources for tokenization, Business Process Correctness, and Risk Alignment proofs based on standards evolving in trade finance instruments and finance, and other custom proofs.
Each classification of proofs uses composition and recursion to compose lower-level proofs based on data from various sources for minimally needed information and produce higher level ZK proofs. The proofs are aggregated and submitted on-chain to MINA, and tokenization protocols in other chains as proofs in a data availability layer. The following figure shows the summary structure of the ZKPRET Proof Tree as a MINA o1.js Typescript composition/recursion implementation. The details of every kind of poof needed for the tokenization will be explained in the later section with a detailed view.
For the SCF reference implementation, the IDs of the Borrowers are modeled, and their compliance is modeled in a recursive structure, as a 3-level structure. Following is an example of the Indian Jurisdiction
Identity Compliance (SCF)
Most blockchain projects use KYC, which is often minimal, predominantly for retail around user-updated passport or state ID details. However, we need additional identity and compliance data for institutional use cases like lending, etc.
For example, in supply chain or trade finance, the exporters and importers can be big corporations or Micro, Small, and Medium Enterprises (MSME)( majority of the world’s economy) - mostly single-owner proprietorship businesses. Please refer to our publications in the detailed proposal.
There is a need for enhanced identity and compliance proofs from the lender and borrower sides, particularly on the borrower side. These include,
-
Local Jurisdictional Registration:{{sandbox_host}}/mca/company/master-data/search
-
Import-Export Identifier:/dgft/v3/iec/{iec}
-
Global Legal Entity Identifier: GLEIF API - LEI Data – GLEIF
Some lenders might need just LEI verification, and some might need the LEI verification plus proof for an import/export license and also might want to know if that legal entity has complied with local corporate governance.
This is important for the lenders in predicting future complications and defaults.
In ZK PRET, the lenders can configure what they want. ZKPRET, using MINA, will produce these recursive compact proofs, relaying the user and source attestations. They will also form inputs to the risk modeler in the ACTUS financial framework.
Validating these IDs complements other KYC/ AML processes, as these checks are needed to reduce the financiers’ validity risk.
We will use the standards for SCF reference implementation, information integrity in business processes, inter-instrument integrity, etc.
- Bill of lading: DCSA - Driving digitalisation in container shipping
In this example, specific JSON contents of the instrument (in this case, the bill of lading invoice) from the source, which is also the title document, are attested by the buyer or the seller who produces the invoice and validated against the schema so that there are no discrepancies or default risk later.
For instance, the schema of one such instrument is defined in the bill of lading schema. The document will be validated for all the minimally required fields defined by the financier in its full integrity.
One example of such a critical field is
Name Description
transportDocumentReference *
string
(path)
The transportDocumentReference of the Transport Document
HHL71800000
pattern: ^\S+(\s+\S+)*$
maxLength: 20
The integrity of such needed fields and their format references are deep checked to align with the schema from the standards.
2. Domain Registry
This registry will initially focus on supply chain finance standards evolving in specific jurisdictions and information sources like India, Saudi Arabia, the UK, Japan, and the US. The ZK application will be configurable for jurisdictional compliance by corridors.
Please refer to section 4 of the UI/UX artifacts for Domain Registry in Figma
3. Business Process Prover
The following is a Standards Modeling notation for a sample business process expected, shown in the BPMN 2.0 Modelling language in Figure below. This module will have a UI component that hosts templated files for specified business processes, financiers, and tokenization protocols in multiple chains need. These templates can be fine-tuned. This engine understands the expected paths, including all parallel flows, forks, and joins. The implementation of the BPMN circuit in o1.js for this sample is included in our GitHub, and additional material for the model.
Business Process Prover: Example Click here
The business process prover can be used to prove a wide variety of business processes.
Examples include:
-
Mortgage Application Review process and Internal Audits
-
Liquidity Check protocols for Internal and External Financier Audits
-
Proof of Reserves for Stablecoins
Please refer to section 1 of the UI/UX artifacts for Business Process Prover in Figma
These proofs of business processes also feed in to the risk factor definitions to be analyzed by the ACTUS financial contract evaluations.
For more detailed explanation view FAQ page
4. Risk Model Prover
The Risk Model Prover provides capabilities to fill Validation gaps by running risk validation services for financiers for both TradFi and Defi.
Financial markets’ increasing complexity requires robust financial risk models. Also, slowly, the Tradfi and defi systems are starting to blend into Institutional Defi. There are wide gaps between the Web 3 and Web 2 current-day systems.
ACTUS financial framework promotes unified standards and financial contract types that can be common between transactional and analytical needs to simulate cash flows on time epochs for contract types. ZKPRET uses ACTUS to provide proofs for financiers on base and risk scenarios dynamically for events @ scale, including interest rate changes, forex changes, pre-payments, delayed payments, delinquency predictions, etc. Some central banks have started to explore ACTUS for the national level financial portfolio management for banking regulations and emerging technologies risk evaluations, including defi scenarios.
The Proofs generated or lack thereof from the ZK PRET deep composition engine and the business process prover set up the risk factors for the ZK Risk Model prover.
Risk Model Prover: Example Click here
We will be producing proofs for scenario analysis based on the ACTUS financial framework for a variety of financial contract types Principal At Maturity, FOREX etc. Details about ACTUS financial framework methodology can be found here. These financial contracts will be evaluated for the risk factors fed from the deep composition and business process prover inputs. They define the risk factors such as Market risk ( Increasing Interest rates, Tariffs), Credit Risk ( Financial health of borrowers Example - Business Loans), and Counterparty risk ( Financial Health of the counterparty Example. Derivative Contracts(Swap).
Please refer to section 2 of the UI/UX artifacts for Risk Model Prover in Figma
For the SCF reference implementation, We will implement basic scenarios related to supply chain finance, leveraging ChainAim’s strategic working relationship with ACTUS framework simulations and other risk datasets for supply chain finance. We plan to implement some SCF discounting scenarios as part of the SCF working capital management solution.
Technically, the following key aspects of MINA /O1js are used and proved in the MVP as described in the detailed sections.
-
Recursion and Composition for Proofs mapped to specific next-generation standards for finance tokenization (Identity and Compliance oracles, and standards referred in the Model Law for transmission of electronic records and UNCITRAL working groups like DCSA for bill of lading, PEPPOL Invoices – which are the title document for tokenization)
-
A layered proof hierarchy where a certain level of Proof embodies proofs in layers below, to be proved for a class of proofs, and/or membership ( in supply chain)
-
Leveraging and extending business process model standards ( BPMN 2.0) and ZK-RegEx for RWA process proofs
-
Proof of deterministic risk models, including epoch-based liquidity checks for emerging financial contract types ( universal financial contract standards for Principal At Maturity, Annuity, FOREX) etc, for Market, Credit and Operational risks.
Please see the FAQ for more details one each of the pillars. Also Please refer to the detailed proposal detailed proposal
Budget & milestones
The budget has been scoped to 60000 MINA to include
-
4 standalone modules that can power multiple tokenization use cases.
-
Reference implementation for end2end supply chain finance
Milestones are planned in 4-week Intervals.
The detailed deliverables for each milestone and checklist towards them are indicated in the following link
We expect to deliver the Business Process Prover for basic templates and ZK composition engine for templated SCF flows for open dev for other MINA ecosystem projects to use in test environments. Some parts of it could be open-sourced.
Roughly, between the modular components, after a few rounds of re-scoping optimizations documented in the deliverables sheet, the breakup is as follows:
-
ZK Deep Composition Engine: 15000 MINA
-
ZK Business Process Prover: 10000 MINA
-
ZK Domain Oracle Registry: 10000 MINA
-
ZK Risk Model Prover: 15000 MINA
-
End2End App: 10000 MINA
Our focus is on the technical stack implementation, while we will simultaneously work on the tokenomics aspects for further extensions as the regulations mature.
Given this is a full-fledged capabilities for the platform, we expect the timeline to be roughly 3 months, and the budget at 60000 MINA.
Team Info
The Executive Team Profiles are indicated below
For detailed information on the team, accolades, publications etc. Click here
The Proposer is Sathya Krishnasamy.
Proposer Githubs:
Proposer Experience:
The proposer leverages over 25 years of technical experience and led Emerging Technologies (DLT/AI/Quantum) at a major payor insurance company.
LinkedIn: https://www.linkedin.com/in/sathya-krishnasamy-3b369a20/.
He has conceptualized, architected, and trademarked payment innovation and integrity solutions for the insurance sector in enterprise blockchain technologies. He has been in blockchain development since 2018 and has experience in Hyperledger, Ethereum, Baseline Protocol, and other L1 and L2 technologies. He has won many accolades, including ETHGlobal 2020, ETHBoston 2024, once 2023, and ZK Montreal 2024. He consults with governments and many international organizations on emerging tech in the supply chain, finance, and payments verticals.
Sathya Krishnasamy served as Advisor for the Center for Advancing Research in Financial Technology (CRAFT), an industry-academic collaboration, where he prioritized research agenda involving DLT, AI, and Quantum.
He is also an advisor in the ACTUS Financial Working Group Committee.
ZK Encode Graduate
Please refer to the details in the Profiles of the docs in the GitHub.
Advisor:
Dr Badri Gopalakrishnan is an Advisor at ChainAim Technologies. He is a renowned economist and works with many governments and ministries globally across jurisdictions, setting up policies, technology regulations, and analysis for global trade. He is a Consultant to many entities, including WTO, World Bank, IMF, Governments (ASIA Pacific, UK), and corporates and NGOs worldwide, including McKinsey. He is also involved heavily in the Vision 2047 projects of the Government of India. LinkedIn. https://www.linkedin.com/in/badrinarayanang/. Please refer to the details in the Profiles of the docs in GitHub.
Marketing
Following is the list of the consultative reach
We intend to drive adoption for various real-world use cases, from the global advisory capacity to many global government ministries as they shape their regulatory frameworks.
We are also working on actively integrating an ACTUS-based risk framework into our existing Global Trade Analysis capabilities and new RWA tokenization capabilities.
Through our strategic relationships, we also expect to play an onboarding role for other ACTUS implementors involved in various aspects of risk management.
Risks & Mitigations
Regulatory aspects are still emerging, presenting macro, geo-political, regulatory, and timeline risks across jurisdictions in tokenization efforts. To mitigate risks, we have been following regulations closely and working with many standards groups to identify the rapidly advancing landscape and adapt.
Overall, we expect the risk for this proposal to be low, as these are modular and self-contained capabilities.
For further details, please refer to the short version of the proposal in hackmd.
References
For a more detailed proposal please follow the following link. Detailed Proposal Click here.