owned this note
owned this note
Published
Linked with GitHub
# Navigators Season 2: Growth Grants Proposal Template
# **Title:** ZK Proof Engine for Tokenization (ZK–PRET)- RWA Supply Chain Finance
This MINA Navigators Proposal is to build on top of the win at ZK Montreal in Aug 2024. ( Open for further branding discussions with MINA experts)
# ZK-PRET(SCF Reimagined)
# **Project Background**
**ZK Proof Engine for Tokenization (ZK – PRET) - The platform ZKPRET is a provable business process composition engine for real-world asset tokenization. SCF-RWA-Reimagined is a reference implementation of ZK-PRET for supply chain finance, including international trade finance and insurance.ZK PRET is a business infrastructure layer that produces layers of proof composition to reduce the validation risk for financiers for supply chain finance. The fundamentals of supply chain financing involve financing invoices and receivables, primarily the Bill of Lading and other instruments underlying the SCF tokenization.** These are typically closed, centralized systems, which are highly in-efficient, and DLT tech opens up this area. The platform reference implementation addresses MSMEs' lack of financial access, lack of privacy-protection methods for business-sensitive data, lack of appropriate counter-party decision aggregation in traditional systems, and very rudimentary current blockchain efforts. This is an area where Western banks, other institutions, and increasingly Institutional Defi want to participate in meeting global demand, particularly from the developing economies. Still, it is heavily under-penetrated due to a lack of transparency. Blockchain adoption has been limited because of rudimentary capabilities, and the capabilities of the ZK PRET platform are a key enabler for RWA / Institutional Defi, which is starting to emerge in late 2023 and early 2024. Going into 2025 and 2026, this area is expected to grow highly.
# **PROPOSAL: SHORT SUMMARY**
Tokenization efforts are poised to grow exponentially following regulatory moves globally. Today, most L1 and L2 systems lack deep information integrity optimized for privacy-preserving off-chain enterprises and small-business tooling needed for on-chain tokenization for scalability-sensitive counter-party interactions. This proposal is built on deep technical and domain expertise in standards-based proofs for practical Tokenization/Institutional Defi.
The proposal solution builds on the work from the **Proposer’s ZK Montreal 01 Labs Hackathon win on ZK proofs for Supply Chain Finance tokenization, and the Proposer’s tokenization data integrity win from XDC an EVM chain, adding Privacy and tokenization scalability capabilities with MINA**
**Why ZK? Why MINA?**
The most significant barrier to blockchain adoption has been hesitancy to put business information on the blockchain. Based on about 7 years of experience working with blockchain applications in real enterprise usecases, significant concerns have been observed from many stakeholders including the legal office, the operations and technology. Two major issues have been business privacy, and the scalability of off-chain information counterparties actually need. ZK-PRET builds on 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
**ZK-Proof Engine for Tokenization (ZK PRET) is a set of key business-infrastructure toolsets that support tokenization.
ZK-PRET RWA SCF is an assembly of them for a critical, high-impact area in supply chain finance.**
ZK PRET consists of 4 sets of tokenization capabilities to define minimally needed, business-sensitive, privacy-protected, and scalability-aware tokenization.
**ZK PRET DEEP COMPOSITION ENGINE** – For deep capture of identity, compliance, alignment to standards schema, and inter-object integrity.
**ZK PRET DOMAIN ORACLE REGISTRY** – Advances the concept of registries for discoverability and will host a reference schema (for supply chain finance).
**ZK PRET BUSINESS PROCESS PROVER** – Proving actual off-chain business processes conform to the expected steps to represent RWA on-chain.
**ZK PRET RISK MODEL PROVER**—This represents what the counterparties need for risk management for next-gen Fintech / Defi / 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.
Technically, the following key aspects of MINA /01 JS 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](https://uncitral.un.org/en/working_groups) 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 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](https://en.wikipedia.org/wiki/Algorithmic_Contract_Types_Unified_Standards) for Principal At Maturity, Annuity, FOREX) etc, for Market, Credit and Operational risks.
These capabilities are built and planned,
* Leveraging earlier MINA projects like ZK-RegEx
* To complement other emerging projects like Aligned Layer, ZKON, Reclaim
* To extend the concepts of collaborative ZK and position MINA as a Proof hub for tokenization for multiple chains, including EVM chains
* To draw more developers and more importantly, easy-to-use tooling to plug into small businesses that fall in the individual/proprietorship businesses that are the driving force in major economies in the MINA ecosystem ( Please refer to our research and profiles in the detailed section).
These capabilities 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, as this area is poised to grow exponentially( Please refer to details in the research below).
**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 people day-to-day, what Supply chain Finance brings.** This is estimated to be 2-3 Trillion in demand in just the international trade, and up to 16 T including all domestic working capital efficiencies, as Tokenization becomes the defacto going forward.
**Profiles:**
The proposer **[SATHYA KRISHNASAMY](https://hackmd.io/@mujLtcP5RdumclDmbyg4gA/SJCvpx_C0#Team)**, advisor **Dr Badri Gopalakrishnan**, and the full team details are available in the detailed section below.
**References:**
Gar- O1 Labs, Mahmoud -01 Labs
Navigators Contacts: Aytunc – O1 Labs, Atakan – 01 Labs.
Further details including the team details and Profiles are available in the detailed proposal below. Excited to advance tokenization with MINA.
# PROPOSAL OVERVIEW: DETAILED
**Problem Statement:**
Centralized solutions have not been able to reach a global scale into developing economies. These systems are fragmented with excessive delays and a high degree of inefficiencies. Beyond the technical aspects of provenance, audibility, and non-reputability needed for validations, Blockchain opens a new era of financial access networks, particularly for developing economies in all topologies, private, public, and hybrid.
# Supply-Chain-Finance-Scope
**Supply Chain Finance Scope**
So, What is the problem in Finance, and particularly in Supply Chain Finance?
The lack of wider financial access for borrowers, particularly in developing economies, is well documented. Even, traditional finance wants to get into this area earlier. Still, both the origination and the fulfillment have been in narrow quarters marred by a lack of access infrastructure, closely held exclusive networks, predominantly local. With the first wave of blockchains, the connectivity is improving, with a lot of promise, but there is a lot more ground to cover. Defi sounded good, but most credit in Defi has been overcollateralized lending, based on on-chain native crypto assets and only seemed to have helped native traders. origination and fulfillment.
**The predominant issue has been validation risk for financiers.** Even the DLT-based systems attempted so far, do NOT go beyond a simple hash of a current process documents, which only marginally improves the situation, and does NOT include the deep data integrity of the underlying systems of proofs. For the borrowers, the issue is that they are having to do excessive documentation and information for documentation and the timelines. Even with excessive due diligence efforts, because of the lack of transparency, decisions are made on partial understanding. Specifically, there are no capabilities to model dynamic possibilities arising out of DLT/AI-based transformation of the supply chain finance process, as these can shrink the cycle time for efficiencies that allow for many dynamic ways of negotiating and re-negotiating payment terms in the delivery-versus-promise cycle. Institutional Defi / and RWA, and tokenization in general, have spurred interest with increasing regulatory movements and awareness of real-world blockchain use cases possible with the underlying technology.
# Solution:
**The proposal solution builds on the work from the Proposer’s ZK Montreal Hackathon win** on ZK proofs for Supply Chain Finance tokenization, and the **Proposer’s tokenization data integrity win from XDC an EVM chain**. The solution extends addressing the privacy and scalability aspects of the needed tokenization integrity for Real world Assets in Supply Chain Finance using a combination of effective off-chain and on-chain design with MINA blockchain.
The MINA navigators proposal is to build the following components of the ZK-PRET Engine for Supply Chain Finance Tokenization
**ZK PRET DEEP COMPOSITION ENGINE FOR SUPPLY CHAIN FINANCE
ZK PRET DOMAIN ORACLE REGISTRY
ZK PRET BUSINESS PROCESS PROVER
ZK PRET RISK MODEL PROVER**
**ZK PRET DEEP COMPOSITION ENGINE FOR SUPPLY CHAIN FINANCE** produces proofs for
a) layered identity (including local jurisdictional identity, domain-specific identity, and emerging global legal entity standards like GLEIF )
Is the candidate borrower a registered entity? in the local jurisdiction?
Is the candidate borrower a global legal entity?
b) verification of the key title document information based on the Model law for electronic transmission of records (MLETR) specifications. Key instruments like the Bill of Lading, and other collateral documents like the consumer invoice, and other substantiative documents for the jurisdictions involved are critical for real world tokenization in the supply chain finance space. Verifications are needed not just for integrity of the source identification, or just wallet KYCs, but in supply chain finance in goes deep, and also includes
Is the instrument / document truly complying to the standards schema ? like ( digital container shipping association schema for bill of lading )?
counter-party sensitive data integrity – (for example, Purchase Order to Consumer Invoice)
Is the Bill of Lading in sync with the customer invoice? and is the customer invoice in sync with the PO in a privacy – protected proof.
c) layered compliance,
Are the borrowers and the associated entities compliant with export-import agencies.
Configurations for sanctions can be checked as well.
d) operational excellence indicators, including history
e) financial health proofs about the cash/asset balances and other financial metrics
f) proofs of association (being part of a deep supply chain network)
the financiers are inclined to support a supplier that participates in the global supply chain of well-known brands for running efficient supply chains
**ZK PRET DOMAIN STANDARDS ORACLE REGISTRY**
This component is a registry of standardized digital negotiable instruments based on evolving regulations in the supply chain finance RWA tokenization space.
The primary’s business relationships have been with many industry standards groups, which are emerging the standards. The primary has working relationships with these industry standard groups in multiple jurisdictions. Since the start of the shaping of this proposal, initial conversations have happened with most of them, and they are showing interest, to onboard those APIs to ChainAim’s ZK PRET. These include APIs for standards and data providers in digital trade instruments, algorithmic contract types, risk model APIs from ACTUS unified standards for finance, and access paths to corporate registration, legal entity identifiers. Initially we will be working in jurisdictions with known APIs, and emerging standards for income tax, and GST.
This registry provides validation of the data and the models from the source, which ZK-PRET in turn attests and further composes aggregated proofs on them to meet the demands of the verifiers.
We expect this to extend into other sources based on some of the MINA ecosystem partners, and other external partners, which we will cover in the ecosystems section (also having discussions with the MINA team on some of the ecosystem details).
**ZK PRET BUSINESS PROCESS PROVER**
As the standards-based trade instruments are provided, these tokenization workflows need the deep content analysis based on global schema compliance, and attestations on top of them for the execution completeness and the order sequence based on the process definition (including branches and parallelism) for start to end state of the process.
Per the industry practices, and for financier risk management, the specific templates for types of engagement and payments are modelled, for “negotiable”, non-negotiable types of interactions and any delivery-versus payments contract / guarantees.
For a given template, the expected flow is matched against the execution trace – the “witness” trace. The solution uses a standard for modeling these templates and mapping them to convert them into circuits and state-transition checks for producing proofs of execution of expected business processes.
**ZK PRET RISK MODEL PROVER**
This module asserts and produces proofs based on the standards evolving in the space of next generation standards management that central banks are starting to use to model financial data and flows, based on credit risk, behavioral risk and market risk.
ChainAim has strategic relationships with many of the work groups and will produce the configurable service layer implementation serving as an oracle, based on these underlying evolving standards.The proofs of the simulated cash flows will be modeled against desired risk tolerance.
These proofs address the critical Trade finance flows for Bill of Lading acceptance, which is a guarantee under English law (which is the global trade law ), for the tokenization of the instruments and the value transfer.
The same concepts equally apply to other kinds of insurance for business process flows, in insurance including primacy (primary / secondary ) evaluations and agreements at the business levels, for primary/secondary.
**The Schematic:**
![Slide3](https://hackmd.io/_uploads/rJbwNfu0A.jpg)
![Slide6](https://hackmd.io/_uploads/ByJuEz_AA.jpg)
The proposal draws from extensive experience of the principal and the advisor in emerging technologies (DLT , distributed AI , and hyper productive collaborations, and consultative engagements with many standards organizations, working groups, and working relationships with many international organizations and the developments working with many governmental entities. Please refer more about the profiles in the Team section in the additional information.
# IMPACT
**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 people day-to-day, which is precisely the opportunity that Supply Chain Finance (RWA-SCF) brings. Supply chain finance is the lifeblood of working capital for SMEs and MSMEs in most economies.** In the MSME sector, financial access is still under-penetrated in all areas. For example, in India, a huge number of people are on the thin borderline of GST payments based on their revenues and are classified as proprietary business owners.
**Just how important are MSMEs (Micro Small and Medium Enterprises)?**
In the International trade area alone, this is a 2-3 trillion financing deficit, and in general supply chain finance, it is estimated at 16 T.
MSMEs are important globally (Davies, Narayanan and Balasubramanian 2021):
– Over 95% of all companies are UK & US are MSMEs.
– 90% of all businesses globally are MSMEs, they employ over 50% of all workers.
– 88% of EU companies exporting to USA are MSMEs.
– They are even more important in developing countries like India, particularly in the context of exports/imports (Chakravarthy, Bharathi, Khire, and Narayanan, 2023): 30% of GDP (40% of emerging economies income globally).
– Roughly the total addressable market is about 16 trillion USD – that’s the income generated by SMEs globally!
Please refer to the About ChainAim section for more details about the publications. (in attachments ) .
In general tokenization efforts, are expected to increase after the electronic Bill of Lading related laws (Sep 2023 ), MicA ( 2024 ), and anticipated regulatory movement in 2025 in the USA. In all this, the English law leads the way with respect to the trade finance digitization, which works alongside MLETR, and other regulations in different parts of the world.
**Audience**
This is a multi-sided network platform that includes MSMEs (Both Buyers and Sellers ) and financiers, and many other web 2 platforms, brick-and-mortar factoring companies, which need an on-ramp into web3 tokenization. This is where the scale comes in, as this includes single-owner proprietary companies, and their accountants who are motivated to get their GSTN credits on time, for both domestic and international operations.
ChainAim is already in talks with SMEs / MSMEs looking for better options than their current options which even in developed countries take significant amount of time, and cuts in to 20-40 % on rotational velocity, and in developing economies, we have seen rates as high as 60 percent for even a 2 week advance of working capital. This tokenization services platform will also serve many tokenization projects. We have had initial conversations with tokenization efforts like Bulla Network who have validated the need for such integrity services. Over time, the regulatory bodies could participate in the network.
---
# ARCHITECTURE & DESIGN
**Architecture:**
![Slide7](https://hackmd.io/_uploads/B1AmBzOAC.jpg)
The ZKPRET architecture is fundamentally a plug and play architecture for a balance of off-chain and on-chain topologies leveraging the capabilities from MINA blockchain. MSMEs' business sensitives need privacy-protected solutions, and Zero-Knowledge proofs allow for wider adoption by MSMEs to confidently share minimally required information on the blockchain with a wide variety of financiers The architecture is set up modularly to build deep composed layers of aggregation of enterprise data as Proofs closing the wide gap between Web 2.0 and Web 3.0 layers for counter-party trust mediation.
Why ZK ? Why MINA ?
MINA is one of the protocols that was conducive for the needs based on the typescript architecture, for producing web-based intuitive Zero Knowledge Proofs as these use-cases are B2B2C, as they interface with many different sources and variety of data on both enterprise and consumer side. Also there is a need for systems to have low barrier to entry in terms of being able to get some of these inclusive financing in to web3 systems, as most of these users are Small Businesses and individual proprieters and they need to protect their business sensititivites as well.
As indicated in schematic, our solution is designed as a collection of pluggable components that we expect will help us participate in and work with the overall MINA and emerging blockchain ecosystems.
**Unique Aspects of the Solution:**
The tokenization space is still evolving, and the institutional interest is starting, but there are no detailed solutions. The few that have surfaced are very trivial and shallow that simply hashes the documents on which a token is likely associated (or) a simple band-aid on existing inefficient processes.However, in reality, the trade finance area needs a detailed integrity analysis. Also, the structures needed for effective tokenization and institutional defi need a range of capabilities between the Web 2.0 and Web 3.0 layers. These need to aggregate and disaggregate information in a privacy-centric way in a B2B2C environment that assembles the needed information for the needs of the financiers in the institutional defi space.
ChainAim has been working with multiple industry standards groups to identify and formulate the standards in this area including Trade Finance distribution initiative (TFDi), Algorithmic standards for systemic risk modeling (ACTUS), Global Trade Analysis Protocol ( GTAP ) and many others including operational supply chain. Also, we have been in talks through our strategy consulting advisory Infisum Modeling, to many governmental agencies, ministries and trade organizations and EXIM banks in many jurisdictions. We are also following the regulations very closely and mapping them meticulously for the details that are needed for high fidelity.
Please refer to the deck, and the details in the Annexure on the Principals, and their publications on topics of payment integrity, emerging technologies, and strategy consulting.
We are uniquely positioned to bring in the technical and the domain expertise needed to build a ZK Co-processer / Attestor for this tokenization. Though the reference implementation is targeted towards the supply chain finance, as we expect that to be in first waves of payment innovation, the architecture is designed to be super flexible for other types of enterprise data integrity for domains including payments, and delivery-versus-payments in many domains, but not at a superficial level, but truly answering the questions of actionable, provable privacy protected enterprise integrity at the right level of aggregation for multi-party computing.
Another important distinction is the concept and the multiple levels of proofs we have built during and since ZK-Montreal in Aug 2024, to show these concepts in multiple-levels of aggregation. This we believe strongly paves way for producing minimal data availability proofs for the maximum level of utility from an overall consumption and scalability point of view.
---
# Ecosystem:
First, we expect some components of our solution to be fully open-sourced. We expect some aspects of generic identity, compliance, and data integrity proofs to be fully open-sourced. At this point we expect that some service components will be in the areas of generic and basic standards of financial instruments (DSCA) and contract types for risk analysis like Principal At Maturity, FOREX, Loans etc.
We expect some domain-specific services to be initially run as a service and, with sophistication, open up for development sandboxes but a paid model for production services.
We have examined the ecosystem MINA protocol has developed, working, and continuously intend to use, and work closely with the following.
**1. MINA Protocol:** Firstly, we intend to give a good view of layered composition that is needed for deep composition flows for real-world tokenization to
further advance MINA protocol for the off-chain / on-chain design constructs and give an indication of depth and layers that would be needed and practical ways to achieve them by adequately combining and balancing on-chain / off-chain designs and further developing the core protocol capabilities.
**2. Aligned Layer:** As our designs evolve and capabilities are built, we expect the proofs in MINA to be available to multi-EVM chains. We are developing our understanding of the MINA-aligned layer integration, and we think we would be able to build a capability for minimal data availability but sufficient sample sizes and the right type of data availability for the intended tokenization requirement utility while achieving modularity and scalability amidst the current landscape, constraints, and capacity roadmaps.
**3. ZK ON:** We have read through some of the ongoing work from ZK ON, and we intend to be an important player in this space as a predominant Attestor and Aggregator for the collaborative ZK. Our architecture is set up with pluggable Composition—Recursion modularity and Proof DA that can work with other Proof Providers and other Proof Consumers.
ChainAim is also familiar with Threshold cryptography, along with some work we did for encrypted data on off-chain / next-gen wallet designs for privacy-protected data and threshold-based security for reassembly sharding. With a deeper understanding of the MINA foundation and ecosystem, we intend and expect to add capabilities and participation.
**4. Reclaim:** We could possibly look into Reclaim protocol for the UI layer for the user interactions for Web content related flows, as needed, as a provider and an overall demand generator for the MINA protocol.
**5. ZK RegEx:** We expect to reuse some libraries developed in earlier efforts from the MINA protocol, like ZK-RegEx, and enhance them where needed.
**6. ZK OK:** We would like to get support for our marketing activities from the ecosystem ZK OK
From our efforts, we will be more than happy to extend the leverage we have with ChainAim’s partnerships to contribute to the overall ecosystem with MINA including systemic risk modeling frameworks that central banks are starting to use (ACTUS), and other standards advancing tokenization in supply chain, payment integrity and insurance verticals( TFDi, DCSA, ITFA-DNI etc. )
QUESTIONS: We would like to work closely with MINA foundation to understand ZKAPP off-chain roadmap and MINA to other blockchain implementations (particularly EVM based).
---
# **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 PRET DEEP COMPOSITION ENGINE**
The ZK PRET composition Engine produces different categories of proofs for business processes. The reference implementation for RWA Supply Chain Finance includes Identity, Compliance, Instrument Integrity for the 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 for composing lower-level proofs that are based on data assimilated from different sources that the financiers need, that the engine sources work with minimally needed information, and produce the ZK proofs. For the entity the Proof Tree is constructed leveraging off-chain storage and the desired aggregation of proofs are submitted on-chain to MINA protocol, and other tokenization definitions that require the 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.
‘
**ZK PRET Deep Composition Engine: Proof Tree**
![Picture1-ProofTree](https://hackmd.io/_uploads/HkYquzdCA.png)
This type of composition is used for entity identities and compliance, and other potential structural elements.
The following design diagram shows an example that was built during the ZK Montreal Hackathon., which has been continuously expanded for more layers of compliance.
![Picture2-ComplianceRecursion](https://hackmd.io/_uploads/HJ_nuGORA.png)
**ZK Deep Composition Engine: ZK PRET Data Integrity Prover**
This capability proves the reliability of not just the content hash but the deep understanding of the contents themselves of the instruments behind the tokenization. In supply chain finance, the predominant Digital Instrument that is behind the title transfer and the settlement is typically the Invoice and the Bill of Lading (shown in brown color below), and could include trade instruments. The true efficiencies of DLT and AI transformation can be achieved by fulfilling the key decisioning requirements which are minimally needed, not much and not less. Hence this module has capabilities to define the global standards schemas behind these documents, for example DCSA for the key title document, Bill of Lading, and PEPPOL standards for e-invoicing, and other evolving standards for risk management, and trade finance initiation and distribution. The protocol schema definition, proof of alignment to schema, and identification of minimal data needed based on these global standards. The diagrams below highlight these tokenization critical instruments, defines the thresholds for proof, that takes in to account the alignment to the schema, the availably of critical data in the document, and identifying and disseminating the minimal required information and their metadata, that includes source validity, alignment to schema, and critical referential integrity between these structures.
**Why is this so critical?**
The absence of this rigor simply erodes confidence in the tokens that represent these real-world enterprise data structures, which in the Web3 economy is a B2B2C flow, where the data owners are MSMEs. We have heard the need and noticed the void, and that led to the simpler implementation in the XDC EVM Chain. However, for full fledged high scale implementation the implementation needs a privacy protected and closer to Web2 connectivity, and hence these designs model them as MINA protocol typescript 01.js data structures for ZK proof generations and verifications.
![Picture3-SCFInstruments](https://hackmd.io/_uploads/rygktGu00.png)
![Picture4-SCFTokenizationInstrtumentIntegrity](https://hackmd.io/_uploads/rytJtzuRC.png)
**ZK PRET DOMAIN STANDARDS ORACLE REGISTRY:**
The standards needed for the deep composition and the source of instruments needs for the deeper referential integrity for tokenization reliability are defined in the ZK PRET Domain Registry. This registry will initially focus on the standards and sources needed for supply chain finance based on what is evolving in specific jurisdictions and the sources of information, including jurisdictions like India, Saudi Arabia, UK, Japan and the US. The ZK application will be configurable for jurisdictional compliance, by corridors. The corridors in immediate consideration is India-Saudi, India- UK, and India-Japan, followed by India-US and other combinations.
The standards include the any core standards for SCF including the digital container shipping association(DCSA), the e-invoicing standard( PEPPOL), Global Trade Analysis Protocol GTAP, ITFA digital negotiable instruments initiative, TFDi Trade Finance Distribution Initiative, ACTUS – standard framework for finance contract types.
The identity layers include personal and business identity primitives, registration proofs (ministry of corporate affairs-India (MCA), Director general of foreign trade-India(DGFT), Export Development Authority-India), Global Legal Entity Identifier Foundation ( GLEIF). The compliance layers include MCA, DGFT, LEI India, GLEIF, KYCAML registries, Sanctions Registries. GSTN Setu sandbox for GSTN and Income Tax data. This registry will expand into other jurisdictions, and we also expect this area to extend and collaborate with other global initiatives with different governments and identity solutions evolving, that we expect to leverage, contribute towards a wider registry ecosystem with MINA blockchain and overall blockchain ecosystem partners. We expect the registry to grow in India, Saudi, US, UK and Japan jurisdictions.
We are starting the registry with the above-mentioned end points. We also expect some of the proprietary relationships that ChainAim has cultivated to on-board more participants along with their signature details for the source validation. We expect to also grow this with other MINA and other blockchain ecosystem partners. This is not intended to be a complete registry but a definition registry that refers to this work and other work in the ecosystem that can be brought in through the ecosystem.
**ZK PRET DOMAIN BUSINESS PROCESS PROVER:**
The following is a standards Modeling standards notation for a sample business process expected is shown in the BPMN 2.0 Modelling language in Figure below. This module will have an UI component that hosts templated such files for specified business processes the financiers, and other tokenization products would need to have proved. These templates can be fine-tuned and approved states are saved in the standards XML or JSON files. This engine understands the expected paths including all parallel flows, fork 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.
![Picture5-BPMN-SCF-Model](https://hackmd.io/_uploads/HyhZYz_CC.jpg)
Expected sequence of process: a(cb|bc)d(ef|f)g extracted from the BPMN model.
The actual execution trace is deducted from the instruments complying to the standards and uploaded or fed from the sources in the registry. The expected is compared against the trace witness executions which can be private input, and the ZK Proofs are generated based on specific states being available or not available, and the timeseries proofs check compliance to the state transitions. This component is so critical because it helps to make sure anything the financiers need to be checked for the integrity of the process before the tokenization can be checked and gives a live monitor for any deviations much before the current status quo, with fragmented systems with no traceability. We intend to further advance other projects in the MINA ecosystem like o1.js , and ZKON for the steps and the compositions involved. We expect this to further enhance the concepts of Collaborative ZK that we see emerge in the MINA ecosystem. Please note that the basic instruments can be in any off-chain source or potentially another blockchain, but the proof systems can be generated and hosted in a succinct and privacy protected manner, including sampling models for data availability in MINA protocol, and through aligned layer in the Ethereum Ecosystem.
## Example-Business-Process-Prover
**Example for Business Process Prover : SCF process**
The following are an illustration of some samples of the accepted and rejected scenarios for the proof generation.
Legend
a = Purchase Order b = Booking c = Invoice d = Shipping Instruction e = Other Instruments F = Bill of Lading G = Received
![image](https://hackmd.io/_uploads/Bkb_4F34Je.png)
Expected path: a(cb|bc)d(ef|f)g
![Picture7-businessprocess-trace-1](https://hackmd.io/_uploads/HJ2sKz_0R.png)
Trace accepted scenario: abcdefg (accepted)
![Picture7-businessprocess-trace-2](https://hackmd.io/_uploads/HJJLYfu00.png)
Trace rejected scenario : abfcdg (rejected)
![image](https://hackmd.io/_uploads/SyaM7wnNyx.png)
The sample shown will be expanded to different segments of the process, and composed in to and full end2end process, We expect to handle a set of templates for different processes in the securitization frameworks as they develop for the underlying assets, and the tokenization process based on whether they are security or commodity / utility tokens, and the proof of the business processes behind the tokenization.
**ZK PRET RISK MODEL PROVER:**
The increasing complexity of financial markets and the growing need for risk management have necessitated the development of robust financial risk models. Also, slowly the Tradfi and defi systems are starting to show some signs of blending, and Institutional Defi is emerging as a concept With the advent of tokenization, there is increasing realization that are wide gaps between the Web 3 and Web 2 current day systems.
The ZK PRET Risk Model Prover provides capabilities to fill these gaps by running risk validation services for financiers for both TradFi, a frameworks that promote 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, and provide proofs for financiers that the base scenario, and the risk events scenario. In the basic implementation, we expect to cover 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.
The Key components include
**Contract Types:**
Defines various financial instruments, such as loans, fixed or floating rate notes. forex, etc with specific attributes and behaviors.
**State Variables:**
Captures essential characteristics of contracts, including loan amount, payment schedules, interest rates, and maturity dates, reference rate, and reset frequencies.
**Events:**
Represents occurrences that affect the contract, such as payment events or defaults.
The ZKPRET Risk Model Prover stores templated risk models, and can respond to financier risk models, and produce proofs for risk metrics validation and potential compliance proofs, without revealing granular characteristics or individual borrower data.
![Picture9-RiskModelProver-1](https://hackmd.io/_uploads/Hkyu5zOCC.jpg)
## Example-Risk-Model-Prover
In a typical supply chain financing arrangement, a supplier (Importer in Trade Finance) provides goods to a buyer (Exporter in Trade Finance) on credit. The buyer, in turn, obtains financing from a financial institution to pay the supplier. ZKPRET Risk Model Prover, models a receivable financing contract modeled using frameworks like ACTUS, detailing payment schedules, interest rates, and terms of repayment. The market risk evaluations include US treasury rates changes, and FOREX changes.
The platform can generate, validate, and attest ZKPs for the financial institution to prove the validity of its credit risk models, demonstrating that the expected default rate of suppliers is within acceptable limits without revealing extraneous supplier details. We are engaged in research of dynamic models these tokenization models produce like dynamic discounting, for working capital optimization for each of the entities. The dynamic discounting agreements will be analyzed to produce ZKPs that confirm the accuracy of expected cash flows from the receivables without disclosing the identities or amounts of the invoices involved.
The following example shows a scenario where cash inflows and outflows are modeled, and an incoming finance request is evaluated and arithmetic circuits are formed to check for liquidity ratio checks as a metric, and to produce proofs for a financier to prove if their threshold metrics are met or not.
![Picture11-RiskModel](https://hackmd.io/_uploads/B1JwZq91ye.png)
This is vast area for tokenization, depending on the underlying structure that is tokenized (securities and commodities), and we expect to design this in a much more extensible manner, but the first basic implementation will be in sync with the other aspects of the engine, to make it a compelling suite of capabilities that can be extended as a service.
As explained earlier, the reason we are focused on supply chain finance is that we expect this area to be the next after cash and treasury bills in the line of tokenization that is practical in the tokenization spectrum based on the regulatory and legal movements we have been following and gaining a deep understanding of since 2023, and the regulations we expect to fall in place in the next 18 months. Given this is a very bread-and-butter for B2B2C flow, for advancing credit and needs risk analysis for simple things like cash advances and working capital credit analysis, we see the relevance for the gaps to be filled for tokenization in this area, and we think the off-chain and on-chain composition mechanisms with MINA/o1.js, and working with the ecosystem and the data availability for succinct proofs in a minimal data availability layer with substations that can be further directed will be a significant demand generator.
---
# VISION
The futuristic vision for ChainAim’s ZKPRET (Proof Engine for Tokenization ) is to be a key Tokenization enabler in multiple financial markets at the business source of truth layer, and be a connectivity hub between Web2 and Web 3 systems onboarding B2B2C users and enabling Institutional Defi, by running key components of a modular decentralized architecture. Most systems today are able to verify that the transactions were signed by a private key, but the content of those systems are not relatable to the notion of truth. As we move in to tokenization, and as the technical architecture layer emerges with ZKTLS, ZK Provers, Decentralized verifiers etc like Aligned Layer, we expect to play a role in the ecosystem, by being a multi-party attestation service, that can translate the tokenization demand side needs , by evaluating the standards driving tokenization and develop a layer of Business application level infrastructure leveraging MINA protocols off-chain / on-chain proving systems to store class of proofs and their applicability in the tokenization context, by making it available in a data availability and attestation layer from ChainAim’s ZK PRET libraries.
![Slide5](https://hackmd.io/_uploads/rybOlPhEyg.jpg)
The execution environment of such an ecosystem can leverage effective representation off-chain data, processes, in a privacy-protected and a scalable way for instituional defi / RWA projects in MINA, but also can serve as the proof layer for institutional defi/RWA projects spanning in multiple heterogeneous systems.
The borrower flow is numbered and indicated in blue, where the minimal data that the borrower or consumer wants to expose is turned in standards-based zks proof in MINA blockchain.
The lender and the regulator flow is indicated in green, where the lenders / lending protocols can prove compliance requirements ( mostly along basel 3), without exposing the sensitive portfolio, and validated by the ACTUS financial standard.
The flows in biege show the interaction where MINA could be the hub for effective off-chain proofs irrespective of which blockchain, the borrowers and lenders are participating in instituitional defi / RWA.
The following sequence diagram also shows a futuristic situation where the effective off-chain representation on chain can be used as a proof-hub for multi-chain institional defi and RWA.
![vis-seq-multi-chain-png](https://hackmd.io/_uploads/S13UIPnVyx.png)
We inspire to be a business source of truth layer for business standards, and alignment to standards service as a decentralized service leveraging re-staking and crypto economic security layers such as Eigen Layer that helps accelerate the business layer components. Our Vision is to be the business source-of-truth and integrity layer. We are working on a provisional patent as well. This integrity layer can work with the ecosystem that builds on Proofs generated by us and other systems at the class of context-aware proofs for specific tokenization areas. Our Key focus is to put out source-of-truth attestations, minimal data definitions for the ecosystem based on schema and alignment to schema analysis ( these become extremely important in the context of regulatory mechanisms like HIPAA, BSA etc ), facilitating minimal data transfer between the ecosystem players including ChainAim, which can be re-attested for minimal data, and Zero Knowledge proofs for the decisioning context, and machine learning classification contexts for tokenization.
We are set up to use the MINA platform as proof for the underlying instruments as well as tokening them on MINA and other platforms as the institutional interest is growing in real-world asset tokenization in the EVM chains, leveraging technologies bridging MINA to multi-chains.
The following is an early-stage conceptualization schematic and we intend to review and enhance it working with the MINA team, and the ecosystem partners, as these newer concepts get flushed out, and the scalability parameters are tested out.
![Picture10-VISION](https://hackmd.io/_uploads/Skz55GOAC.png)
We expect to start with deterministic simulations for Proof of Risk Validation, with simple contract types, but extend them to comprehensive contract types, and advanced ZKML models, and provide tiering of digital instruments for the client validation needs. As the tokenization aspects are proceeding in multiple blockchains in all combinations of Private / Public and hybrid (Subnets), we intend to build an extensible system that can use a ZK Proof system that payment entities / risk-bearing entities (financiers/insurers) can bring their configurations to standards-based risk validations.
We are already in conversations with early-stage alternatives for traditional factoring and even large tradfi banks who want to explore Institutional Defi, who have indicated the need for this deep validation for this critical supply chain finance tokenization in the RWA space.
---
# Existing Work:
There is no existing project.
**Work In Progress on the new project:**
Since the hackathon the following activities have been continued.
The Deep Composition Engine that was developed during the Aug 2024 hackathon, is now continuously getting extended for recursive identity and compliance circuits successfully.
Building on top of it, based on the O1.js tech stack, the wishlist we had during the hackathon to check for critical data content in a document, has been tested out. This gives us the ability to do Intra Instrument Integrity as well.
The design for the deep composition using composition, recursion and off-chain structures have advanced.
The sources of data have been identified for jurisdictional and global identity and compliance for supply chain finance.
The Business Prover module has been charted out, including test proofs for expected and actuals using BPMN standards.
Many standards have been already analyzed as part of detailed design including MLETR (Model Law for Transmission of Electronic Records), DCSA for Bill of Lading, ITFA – DNI, Business Process Modeling Notation (BPMN V2.0)
Initial Conversations have happened leveraging ChainAim’s strategic positioning ACTUS framework for with Unified Financial Contract Risk Modelling, which we have received positive feedback. These concepts have been validated in many forums and with emerging networks such as Bulla Network who have started financing in the Ethereum Ecosystem,and had validated the need for such validation services as well, and have expresses initial interest in working with ChainAims ZK PRET Engine.
**Key File structures for the Design**
ProofOfCompanyRegistration.ts
ProofOfInternationalTradeCompliance.ts
ProofOfGlobalLegalEntityIdentifier.ts
bpmnBusinessProcessProver.ts
businessProcessViewer.ts
bpmnCircuit.ts
DomainRegistry.ts
InstrumentIntegrity.ts
InterInstrumentIntegrity.ts
SCFStandards.ts
BillOfLading.ts
PurchaseOrder.ts
Booking.ts
ShippingInstruction.ts
CustomerInvoice.ts
ComposedRecurrsiveSCF.ts
ComposedRecursiveSCF3LevelProofs.ts
ComposedRecurrsiveSCFAdvanced.ts
RiskAnalysisProof.ts
ACTUSData.ts
ACTUSEpochs.ts
MarketRisk.ts
CreditRisk.ts
OperationalRisk.ts
RiskMetrics.ts
CashFlowBase.ts
CashFlowProjectedSeries.ts
parse_bpmn.py
circuit.bpmn
RiskSimulation.ts
RiskTolerance.ts
RiskScenario.ts
bpmnCircuit.xml
RiskClassification.ts
LiquidityCheckCircuit.ts
LiquidityRiskProver.ts
---
**Production Timeline:**
Roughly 3 months for these components to be in production.
---
**Budget and Milestones:**
Though many components need to be developed, the design has progressed far, and we will be able to start development by October 1, or the first week of October.
Milestones: Deliverables can be planned in 4-week intervals.
**Milestone 1: End of Week 4** – Iteration 1 Complete. 25000 MINA
ZK Deep Composition Engine - Implementation of Identity, Compliance Proof trees, SCF Standards Schema Artifacts and Compliance to Schema. Finish complete specs on Inter Instrument Integrity.
ZK Business Process Prover - Complete for Common templates in Supply Chain Finance / Trade Finance. UI Designs complete.
ZK Domain Oracle Registry - Design complete and connectivity with the different sources identified. Inter Ecosystem analysis complete.
ZK Risk Model Prover - Connectivity to the risk analysis standards engine sandbox.
**Milestone 2: End of Week 8** – Iteration 2 Complete 25000 MINA
ZK Deep Composition Engine – Complete Inter Instrument Integrity.
ZK Business Process Prover - Complete, including UI integration
ZK Domain Oracle Registry - Operational for identified data sources. Inter Ecosystem dependencies complete.
ZK Risk Model Prover - Connectivity to the sandbox complete, and basic contract types tested out( PAM and ANN contract types for SCF Invoicing)
**Milestone 3: End of Week 12** – Iteration 3 Complete 25000 MINA
ZK Deep Composition Engine – Completed Already.
ZK Business Process Prover - Complete for Common templates in Supply Chain Finance / Trade Finance. UI Designs complete.
ZK Domain Oracle Registry - Implementation Complete and inter- ecosystem extensions planned for future.
ZK Risk Model Prover - Risk Models for SCF Done. Extension roadmap charted out for comprehensive tokenization of financial markets in priority order.
Documentation Complete.
We expect to make available the modules indicated as stand-alone components, which we envision can be further re-used and adapted for other business processes. Thus, we expect these to also have a utility function to further other ecosystem projects in MINA. For the tokenization proof service, all these components are needed, as they are needed for the needed RWA integrity.
**Break up of the Budget:**
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 first level optimizations, the break up is as follows:
ZK Deep Composition Engine: 15000 MINA
ZK Business Process Prover: 15000 MINA
ZK Domain Oracle Registry: 15000 MINA
ZK Risk Model Prover: 20000 MINA
End2End App: 10000 MINA
Our focus is on the technical stack implementation, while we in parallel will 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 75000 MINA.
Any additional details we are ready to discuss with the MINA experts.
Documents and Artifacts:
GitHub from the ZK Hack, Montreal:
https://github.com/chainaimlabs/ZK-SCF-RWA
The updated GitHub is available at:
https://github.com/chainaimlabs/ZK-PET-RWA-SCF
Please note that the github struture is yet to be updated to the updated name ZK-PRET-RWA-SCF.
We are abstracting this into a re-usable component architecture around the ZK-RWA-Engine for SupplyChainFinance, Insurance, Payment Integrity, and DvP flows.
---
# Team:
**Proposer:**
**The Proposer is Sathya Krishnasamy.**
**Proposer Githubs:**
https://github.com/chainaimlabs/
https://github.com/chainaim3003
**Proposer Experience:**
This proposal leverages his extensive experience in high scale software systems in supply chain, international trade and payment integrity and innovation., over 25 years. He led the Emerging Technologies Practice (DLT, AI, and Quantum) at a major insurance company and also led the formation of a consortium of payors, banks, and providers. He has conceptualized, architected, and trademarked payment innovation and integrity solutions for the insurance sector in enterprise blockchain technologies, and has been in the blockchain development space 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. His research work for blockchain adoption has been published, and he has delivered many keynotes on Web3 adoption and the Discovery framework to identify and build the business architecture components bridging Web2 and Web3. He is currently the Principal and President of ChainAim Technologies and works on Distributed Ledgers, Computational Economics, Distributed AI, and hyper-productive multi-party collaborations. He consults with governments and many international organizations on emerging tech in supply chain, finance, and payments verticals. LinkedIn: https://www.linkedin.com/in/sathya-krishnasamy-3b369a20/.
**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.
**Team Members and Accolades:**
**Sathya Krishnasamy: Principal, Architect, Product, Lead Developer. Full time. Detailed Profiles Added.**
https://www.chainaim.com/ - 2020-Present. Full time since Feb 2024.
https://www.linkedin.com/in/sathya-krishnasamy-3b369a20/ - Until Feb 2024. Six plus years in Blockchain Development and Executive Experience. Now full time Founder, and Principal, ChainAim
Graduate : Advanced Ethereum, ZK , ZK, and Scaling, Move - From Encode Reference: Laurence Kirk
**Accolades:**
**ZK Hack , Winner, 01 labs , MiNA , August 2024.** – Tokenization Proofs Business Infrastructure for Reimagining Supply Chain Finance
**Winner ETHBoston 2024**– SocialSecureShare – DataShare via Threshold cryptography and NFT access controls.
**OnXDC 2023, Winner.** – A re=composable tokenization engine. https://x.com/onXDCNetwork/status/1722734452353204672. 1st
Place: Trade Sync - An enterprise solution for trade finance using DLT, AI, Hyper-Productive flows with deep provenance and composable tokenization to keep the integrity at each layer while transferring the ownership.
Emerging Tech in Supply Chain Visionary – Internet 2.0 International Conference
**ETHGlobal 2020 , Winner** - TrafiGuard, on-chain. https://ethglobal.com/showcase/trafiguard-96ge8. On Chain Oracles.
**Amplify 2023** at Elevance, for the Blockchain /Ai implementation.
**Keynotes:**
Keynote, Sep 2024, - https://conv2xsymposium.com/ Boston, 2034: DLT, AI and ZK –Together – Breakng Barriers ?
Keynote March 2024, - Internet 2.0 Conference: Web 3.0 – Bridging Web 2.0 to Web 3.0.
Keynote, Sep 2023, - https://conv2xsymposium.com/: Moving Beyond Pilots and POCs: Lessons for Mainstream Blockchain Adoption – A payor payment integrity reference implementation.
# Publications
**Blockchain Adoption for Real world usecases**
https://www.researchgate.net/publication/376968064_Moving_Beyond_POCs_and_Pilots_to_Mainstream_Discovery_and_Lessons_from_Blockchain_in_Healthcare
https://blockchainhealthcaretoday.com/index.php/journal/article/view/340
**Model Complexity Reduction for ZKML - Regulated Healthcare applications**
Privacy protection and inference optimization for ZKML applications: A reference implementation with synthetic ICHOM dataset
**Vision 2047 India: Compendium Article on Blockchain Regulation**
**My Holistic Data Share: A WEB3 Data Share Application:**
https://blockchainhealthcaretoday.com/index.php/journal/article/view/341
**E-Commerce in International Ocean Shipping, 1st Annual Conference, International Journal of Logistics and Supply Chain Management**, Aug 2007.
**Logistics E-Commerce in global ocean shipping supply chain, Information Systems,10th Annual Conference, International Journal of Industrial Engineering,** Clearwater FL, Dec 2005.
**Dr Badri Gopalakrishnan:** Strategy, Relationships. Part-time. Detailed profiles and Github added.
https://www.linkedin.com/in/badrinarayanang/
**Sharien SK, Developer Part-time** – Blockchain Engineer( Experience in Enterprise Blockchains Ethereum, Hyperledger, Ernst & Young )
https://www.linkedin.com/in/shareinsk/
**TBD (Pankhuri Gupta / Chidambaram Ganesan )** – Full time – Blockchain / Full stack Developers. (Typescript/ Node /IPFS/ Ethereum).
https://github.com/pankhuri0209
Winner ETHBoston 2024 – SocialSecureShare – DataShare via Threshold cryptography and NFT access controls.
Winner WebNova 2024 – Computer Vision ML models to minimize container congestion in ports based on satellite information from Web3 WebNova project.
**Abhirup Guha** – Anayst, Supply Chain / Trade Finance – Part Time(Data Science, APIs, Python, ML ) - Part Time
https://www.linkedin.com/in/abhirup-guhathakurta/
We also expect to train 1 or 2 interns interested in the ZK and MINA, who are Web 2 developers and AI grads.
---
# Marketing Efforts:
Following is the list of the [consultative reach](https://docs.google.com/document/d/1u1dUncDKhbcszu6JALUNoZAQAr1qzxvA/edit?usp=drive_link&ouid=102300027745565646885&rtpof=true&sd=true)
We intend to drive the adoption of privacy-protected, data integral DLT tech for various real world usecases, starting with the global advisory capacity to many ministries of global governments as they are showing focus to understand DLT and the Defi elements as they shape up their regulatory frameworks.
We are also working on actively integrating ACTUS based risk framework in to our existing capabilities in Global Trade Analysis, and new capabilities we are building for privacy-protected data integrity and risk analysis, for RWA tokenization and opening up newer mechnanisms to extend beyond
crypto-only par or par-plus collaterals, which is an interesting area for many tokenization projects in the emerging Institutional Defi area.
# Risks-and-Mitigations
DLT in general, and Tokenization is still an emerging area, where the regulatory aspects are still emerging, which presents macro, geo-political, and timeline risks.
That said, We have been following the legislative developments accross the globe ( UK electronic bill of lading, MLETR, Mica) since Fall 2023. We expect the trend to continue and accelerate in to 2025 and 2026, where some of the laws we expect to drive operational systems.
So, we have taken a pragmatic approach to build the business infrastructure components that could be stood up with less dependencies. Those could also be combined in to meaningul tokenization usecases at different levels, as explained in the plug-and-play architecture.
We expect to make available the modules indicated as stand-alone components, which we envision can be further re-used and adapted for other business processes. Thus, we expect these to also have a utility function to further other ecosystem projects in MINA.
For the end2end implementation of the SCF, the project risks include the timeliness of the source API availability from the data sources for the intrinsic components, the draft of the standards documents, and the evolving regulatory artifacts. For the extrinsic components, there is a dependency on the overall MINA ecosystem, like Aligned Layer and ZKON.
Overall, we expect the risk for this proposal to be low, as these are pretty modular and self-contained capabilities, and the deep domain expertise we have in these areas.
**Mitigations:**
For the intrinsic components,
We have been following the regulatory aspects, and the regulations like eBl, Model Law for Transmission of Electronic Records, transferDocumentRecord from Digital Container Shipping Association,ITFA DNI,TFDi, ACTUS and working with these standards organizations closely. We have a very influential role in these standards organizations and have already spent 3-4 weeks since the ZK Hack, Montreal hackathon in further validating some of the standards requirements, and proof of concepts based on them.
For the extrinsic components,
We intend to work closely with MINA as we progress through our implementation. We have so far engaged with many members of MINA and have had introductory conversations with other ecosystem members as well. We are confident in putting out the roadmap for any integration or usage in the context of the evolving ecosystem capabilities.