Part of the work product is all the research hours to understand the ISO-20022 problem set - opportunity gap. I focused on this for some time. Can build an “OpenZepplin” like product, but need to buy all the ISO definitions from the International Standardizations Organization.
I’ve outlined how this tool can be built, and provided some logic for it. I would alter this logic slightly but for the most part it’s the process and method I would go through to build the contract for ALL smart contracting languages. I’ve only shared an ethereum example here, but this process would be used of all languages for this tool. There is nuacnces in which definitions should be used for different transactions. For example - a swap from a stable coin to a L1 coin is a different ISO definition than a swap from a L1 coin to a L1 coin.
In any case it would be required to buy the definitions 1st.
import * as fs from 'fs';
function generateSolidityContract(definition: string): void {
// Define the Solidity contract content
const contractContent = `
pragma solidity ^0.8.0;
contract ISOEventContract${capitalizeFirstLetter(definition)} {
event ISOStandardEvent(uint256 isoStandardId, string description);
function emitISOEvent() external {
emit ISOStandardEvent(${definition}, "${definition}");
}
}
`;
// Write the content to a Solidity contract file
const filename = `ISOEventContract_${definition}.sol`;
fs.writeFileSync(filename, contractContent);
console.log(`Solidity contract '${filename}' generated successfully.`);
}
function capitalizeFirstLetter(str: string): string {
return str.charAt(0).toUpperCase() + str.slice(1);
}
// Read ISO standardization definitions from the 'definitions' file
const definitions = fs.readFileSync('definitions.txt', 'utf-8').split('\n');
// Generate Solidity contracts for each definition
definitions.forEach((definition) => {
generateSolidityContract(definition. Trim());
});
Alternative to an ISO “contract generation tool” such as this, I’ve suggested that in the code review process, that code reviews could get some ISO certification stating that the authors of the software implemented the correct ISO definition for the code. This is a fundamental question to the entire crypto community as to the level of professionalism we operate at. A work item I wouldn’t mind working on more, but that requires coordination with other L1 protocols, getting the ISO organization enguaged and derterming how to get code reviewers a certification to ISO certify the logic.
Both are likely viable initiatives.
Outside of those efforts - there is the end-to-end KYC/AML digitalID system solution. I haven’t finished and/or tested the logic for a smart contract that would receive a ZKP attestation from the KYC/AML operator, and the sake of brevity, I just linked to that conversation. Can mock a server to test this. It would require funding to continue work.
Rust
use cosmwasm_std::{
entry_point, to_binary, Binary, Deps, DepsMut, Env, MessageInfo, Response, StdResult,
};
use schemars::JsonSchema;
use serde::{Deserialize, Serialize};
use winterfell::{Proof, VerifierError};
use winterfell::crypto::hashers::{Blake3_256, Hasher};
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum ExecuteMsg {
VerifyProof(VerifyProofMsg),
}
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct VerifyProofMsg {
pub proof: StarkProof,
pub public_inputs: Vec<u8>,
pub vk: Vec<u8>, // Verification key submitted with proof
}
#[entry_point]
pub fn instantiate(
deps: DepsMut,
_env: Env,
_info: MessageInfo,
_msg: Empty, // No instantiation message needed in this example
) -> Result<Response, ContractError> {
// Initialize the verification key hash (if using hash commitment)
// ...
Ok(Response::default())
}
#[entry_point]
pub fn execute(
deps: DepsMut,
env: Env,
info: MessageInfo,
msg: ExecuteMsg,
) -> Result<Response, ContractError> {
match msg {
ExecuteMsg::VerifyProof(proof_msg) => verify_proof(deps, env, info, proof_msg),
}
}
#[entry_point]
pub fn verify_proof(
deps: DepsMut,
env: Env,
info: MessageInfo,
msg: VerifyProofMsg,
) -> Result<Response, ContractError> {
// 1. Load Verification Key (Stored in contract storage)
let vk = load_verification_key(deps.storage)?;
// 2. Verify Proof
match winterfell::verify::<Blake3_256>(&vk, &msg.proof, &msg.public_inputs) {
Ok(()) => Ok(Response::new().add_attribute("action", "proof_verified")),
Err(VerifierError::VerificationFailed) => Err(ContractError::InvalidProof),
Err(err) => Err(ContractError::VerificationError(err)), // Handle other errors
}
}
With a digitalID I see how a NFT fits into this narrative. I could see how a NFT minted with every transaction that includes the ISO definition for that transaction could be viable. I actually broached the subject of making the patent ownable by the hub - or a DAO aligned with the hub. I’m actually not opposed to the hub or org going in that direction.
What is critical here is not storing any personal information in a public database.
SUMMARY:
The bulk of the retroactive funding is for countless hours working solo on this problem set and solution(s), and/or logic provided so far. More work requires funding. There’s several moving pieces to the overall effort…none of which is required to use the information provided independently.
For Clarity Sake - and you can “see” what I’m talking about.
The 3rd party associated with Cheq’d is FinClusive…this is their api for:
Add a new entity client for compliance review.
APIs: Details - Microsoft Azure API Management - Developer Portal
To include a crypto wallet validation, assosiated with their process KYC/AML validation…this is the api surface that would have to be extended in a production scenario.
Their API needs to be extended to include a One to Many assosiation for blockchain addresses assosiated with the Clinet KYC/AML product. On chain addresses are still pseudo anonymous.
// 1. Define the DTO for a SINGLE blockchain
class BlockchainDTO {
blockchain: string; // A single blockchain identifier (name, symbol, etc.)
addresses: string[] = []; // Addresses for THIS blockchain ONLY
constructor(blockchain: string, addresses: string[] = []) {
this.blockchain = blockchain;
this.addresses = addresses;
}
}
// 2. Define the type for tracking MULTIPLE blockchains using an array of the single DTO
export type MultiBlockchainTrackingDTO = BlockchainDTO[];
// 3. Example Usage
const multiChainData: MultiBlockchainTrackingDTO = [
new BlockchainDTO("Ethereum", ["0x123...", "0xaaa..."]),
new BlockchainDTO("Bitcoin", ["bc1q...", "3J98..."]),
new BlockchainDTO("Solana", ["So11..."]),
];