Diversification of DAO Treasury through Real-World Assets (RWAs) and Real-World Projects (RWPs)
Rationale: The current DAO treasury is primarily concentrated in digital assets, exposing it to volatility and potential underperformance. Diversifying into RWAs and RWPs presents an opportunity to mitigate risk, generate sustainable yield, and foster the growth of emerging businesses and DAO communities. Key Benefits of RWA/RWP Investment: • Risk Mitigation: Diversification across a wider range of asset classes reduces exposure to the volatility of any single asset or sector. • Yield Generation: RWAs, such as real estate, startups, or infrastructure projects, can generate recurring revenue streams through rent, sales, dividends, or royalties creating a more robust and sustainable treasury. • Community Building: Investing in real-world projects can foster the development of engaged DAO communities centered around shared interests and goals. • Impact Investment: Strategic investments in RWPs can have a positive impact on real-world issues, aligning with the DAO’s values and mission. Proposed Projects: • ISO Standardization for Blockchain: • Develop an ISO-20022 compliant solution for blockchain transactions. • File a patent for this method and process,…
Excerpt (1193 of 6252 characters). Read the whole post on the forum ↗
Hi @jasonsprouse, please send us a message at [email protected]. We have pending ideas with potential overlap; it could be beneficial to confront ideas and collaborate on this endeavor.
Best,
Govmos
Sounded like you were primarily interested in the ISO piece…so, This is how to listen for events on Ethereum blockchain - this is with a ZKP. There is a contract that is launched that has the corresponding verification for the ZKP circuit in this instance. ``` const NFT_CONTRACT_ADDRESS = "0x8F283a6a1F14cf03bCE439c88c7e2b3863D7DB6A"; const OWNER_ADDRESS = "" const NFT_CONTRACT_ABI = require("../eth-contracts/build/contracts/SolnSquareVerifier.json"); const { proof, inputs } = require("../zokrates/code/square/proof.json"); const NUM_HOUSES = 5; async function main() { const provider = new HDWalletProvider(mnemonic, INFURA_URL); const web3Instance = new web3(provider); const contract = new web3Instance.eth.Contract( NFT_CONTRACT_ABI.abi, NFT_CONTRACT_ADDRESS, { gasLimit: "1000000" } ); // Houses issued directly to the owner. for (var i = 0; i < NUM_HOUSES; i++) { const result = await contract.methods .mintNFT( OWNER_ADDRESS, i, proof.a, proof.b, proof.c, inputs ).send({from: OWNER_ADDRESS}) console.log("Minted house. Transaction: " + result.transactionHash); } } main(); ```…
Excerpt (1194 of 3473 characters). Read the whole post on the forum ↗
The swim line you provide seems like a good streamline of event to process according to standards. If KYC verified we wrap it all together with the transaction data formated the right way and send it over for ISO compliance, then post a verification proof back on the smart contract for storage.
This particular approach obviously associated the wallet address with the KYC - so that would be the gatekeeping function of interacting with the contract. Not a bad solution.
Another potential solution that recently caught my attention using Lit - which I really like. This sequence diagram borrowed from Infinex Proposals. As discussed this also introduces quantum hardening properties. Could do something similar with Cosmos to capture user data for ISO transactions.
Here’s all the ISO definitions - I just downloaded an ISO book - they said over 800 definitions. That’s one of the reasons I only started the skeleton. It would take some time to research each definition, write smart contracts for all smart contracting platforms and build something like an OpenZeppelin for ISO standardizations. The other side of it is the listeners for every platform like Ethereum and Cosmsos.js solution above. It would be a very professional tool.
jasonsprouse:File a patent for this method and process, potentially creating a new revenue stream for the DAO.
With the patent, I would describe the process the code above achieves. The Cosmos.js code would have other conditionals that could be included, but essentially that’s how that data is collected and sent to the regulatory body. That patent IP being owned by a DAO and the DAO participants agreeing on any fee structure would be the most reasonable way to structure this emerging opportunity.
Does everyone agree that is the most logical way to progress?
Building the ISO tool would take some time doing it in a high quality professional manner - I would consider the CosmosSDK documentaiton high quality and professional for comparison.
I think we’ve got our KYC piece in the Cosmos community in a decentralized way with cheqd - @ankurb. This would be all the pieces to move this ISO implementation forward.
Some collaboration to demo the solution would be helpful.
Cheq’d discord:
Discord - Group Chat That’s All Fun & Games
Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.
I really love this use case and how you’re thinking about it. We don’t have an endpoint that you could call out-of-the-box to do a KYC, as most of the developers building so far use a blend of on-chain Decentralized Identifiers and off-chain digital credentials when working with cheqd network. Having said that, the kind of flow where you need just a yes/no on a different chain / smart contract is something we’ve heard a lot of demand for, and so one of the community pool funded projects we’ve been working on aims to enable exactly this, as a method that can be called over IBC to fetch a KYC proof from cheqd without necessarily writing too much sensitive/personally-identifiable information.
I need to check in with Nymlab on where they are, as I believe it was around June-ish that we were expecting some early code deliverables. So we might indeed have something available for this soon.
This would be relatively easy even with a Zero Knowledge Proof, but that could be optional. With or without a ZKP - it would have to be implemented on the KYC verifier side. The whole idea with the contract storage I have on that swim lane is have something to call 1st before sending an address to be verified, but what if a client abandons that address? What use then would that be in storage?
A diagram. ZK-Stark.drawio 1399×1078 124 KB Some code. ``` 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> {…
Excerpt (1192 of 2410 characters). Read the whole post on the forum ↗
Does any of this require KYC/AML procedures? Are there legal risks? How will privacy be preserved?
Sounds like web3 has sooo many sectors to diversify against, whats the point in going for one of the most complex ones?
There is other similar projects: 15 real estate crypto projects to check out in 2024 It would be REITish (Real Estate Investment Trusts), but I have a project that could also be akin to a digital REIT. It would be a blend of real and digital world assets and experiences. DREIT. However, some of the other solutions I’m proposing here do fall in the realm of a REIT. As an investor, we purchase shares of a REIT, and in return, we receive dividends from rental income and property sales, ect… The professionals working for the REIT handle property management and transactions on our behalf. Now, regarding the Know Your Customer (KYC) process, it depends on the type of REIT: • Public REITs : These REITs register with the Securities and Exchange Commission (SEC) but do not trade on stock exchanges. • Private REITs (Non-Traded REITs) : These do not have to register with the SEC, and their stocks do not trade on exchanges What is proposed above with the ISO solution allows people to KYC in a simple way, KYC is for money laundering and the such. Here’s a web3 example of money laundering, a wallet address is known to have received funds from a wallet drainer. Do you want to allow…
Excerpt (1198 of 3831 characters). Read the whole post on the forum ↗