Security Token Offerings (STO) With KYC And What Komodo Is Doing - Issuing
- Storing
- Sending
- Trading
- KYC
Komodo ecosystem blockchain projects can already deploy Crypto Conditions (CC) for extending consensus and developing smart contracts. One smart contract is the Assets Crypto Condition and it can be used for issuing STOs. Mainnet community projects (TT#8) using Crypto Conditions are KMDICE, a mineable dice rolling game & Verus Coin a friendly Komodo fork who used CC to solve the Nothing@Stake problem with PoS chains. One of the upcoming reference contracts shipped with Komodo is an asset tokenization contract – token creation and on-chain DEX. These capabilities are available to all independent blockchain projects using Komodo technology. The dev team has been quietly working on a token storage wallet and here is an early screenshot of the cross platform working prototype.  What happens when you can issue tokens backed by assets and integrate another Crypto Condition into the workflow? If using the Gateway Crypto Condition, it will easily enable the tokenization of other Cryptocurrencies for trading. For every blockchain project. Integrated into your own blockchain. For trading and transactions. Know Your Customer – KYC? Komodo does not handle this process, but integration with many third party KYC providers is an ongoing marketing and business development process. Komodo is continually working on pathways to integrate KYC providers in different jurisdictions. Business developments in these areas will likely become available in the software by way of plugins/integration into KYC providers when the necessary requirements are specified. The KYC processes can then be made available to the entire ecosystem, streamlining project's go-to-market saving effort and resources. If your project requires KYC and you are already in discussions with a KYC provider, please reach out to the Komodo marketing team.
Non-Fungible Assets And Bundling Assets On Komodo
Non-fungible tokens are possible right now with the tokens contract (mentioned above). We just need to use 1 satoshi of KMD(or whatever base coin) to create the tokens. Then only one token with an id is created (so it has a unique token id). Whatever base coin? Yes, you don't need KMD to create a non-fungible token economy. Use your own coin from your assetchain project. If not a komodo ecosystem project, then use your preferred alt-coin. Using alt-coins for non-fungible tokens? Yes, theoretically by using the Gateway Crypto Condition, funds from another cryptocurrency can be tokenized and then this tokenized alt-coin can be used to fund a non-fungible token creation. One big disclaimer: Komodo has not finished creating this technology as there hasn't been the purpose to expedite it – crypto conditions opens the doorway to other cryptos to extend their functions whilst still maintaining their current exchange listings. What else can be done with a non-fungible token? Whoever has the token can add op-return data to it. GUI side can deal with the rules on how the OP-return data is interpreted. Dapp level protocols built on top of the blockchain. Creating bundles of assets can be done with another CC (crypto condition) that enforces such bundled restrictions. E.g. for use in tokenized assets (trading cards, game assets, STO TT#3), supply chain (TT#7), or zero transaction fee dapps (TT#9).
PoS Chain – First 100 Blocks, The Importance Of Distribution And Weakness Of PoS Chains
Last week in TT#9 we briefly covered what should be done within the first 100 blocks of a PoS chain. And this week we have a user in our discord asking: Can anyone explain in 100% POS why the staking stops if there is only one address that is staking? As we have experienced no block is created after around 4500 blocks. What is the logic behind this number of 4500 blocks? And the response was: It is more likely that you have less than 100 utxos. Since a utxo needs to be >100 blocks old, if you have less than 100 utxo, you will run out of eligible utxo and if the chain cant make more blocks, no existing utxo will become eligible. In 100% PoS you have to spend effort to create utxos and preferably distribute to 64+ addresses. There is a reason PoW is more reliable than PoS and the initial distribution problem with PoS is one of its weaknesses. With 100% PoS, the entire chain depends on the initial distribution, so you can't just put it all in one address and expect it to work, from a continue staking point but more specifically from a distribution point. 64 utxos is enough to begin with, just don't set -pubkey on staking node, and block rewards will stake. 64 UTXOs on a couple separate nodes without -pubkey not set is most reliable. The conclusion from a team member was, "…we need a better doc for it. I'll write up how I do it. There are plenty of ways to do it, but I've found what I do is reliable…" We are already working on the documentation and developer journeys.
Blockchain 2FA On Komodo – $25,000 KMD Bounty + F/T Job
There is one person already attempting this bounty at the moment – more details are in this bounty post in the Komodo forum. The following details are a simplification of what is involved. It is nearly this easy! Basically…
 and able to run with every block and programmable into a smart contract. If you understand what these are: - Hash functions (one-way)
- Blockhash (at height X)
- Block Reward transaction ID
You are 10% of the way to claiming the bounty. A quick but insecure example for this short article using the most recent block at time https://kmdexplorer.io/block/071273fd46d138590a0d505257a791f34816e4efd79cb5766371e140b6e639de of writing would be to use the broken MD5 hash function found on any linux or mac computer:
 This produces the resulting string 02e97cf….. Next block, new string – like any good 2FA solution. Now all that really is required for this insecure md5 example is integration with Crypto Conditions to extend the consensus of sending a transaction with blockchain2fa. This is only a high-level explanation of the problem to solve. Using safe one-way hashes instead of md5 an obvious necessity. One of my team members asked...
 My response still needs formulating because I'm not a real blockchain dev. Others in the team are interested in blockchain/p2p/decentralized solutions which I continue to learn from their vision. Maybe in the coming weeks there will be a follow up to this. My current thoughts (and only my thoughts, not the Komodo team) are that if your privkey is stolen, but the transaction requires blockchain2fa, there is only one device that can provide the 2fa and it's all derived from blockchain/p2p inputs. It's a decentralized solution to current 2fa. Further thinking required for all possible outcomes. For example, perhaps the 2FA "device" needs an MofN multi-sig to create a tx to instantiate the 2FA from trusted sources (like a notary or a lawyer/accountant etc.) and an MofN to unlock the blockchain2fa in case the device is lost, stolen or damaged. The point of blockchain2fa is that it will be available at some stage and the real world use cases will extend and extend at higher levels as people learn what can be done with it. Similar to when you buy your first tablet/iPad or Alexa speaking device integrated with AWS. These technologies get used more and possibilities expand.
Vanity Addresses – Get Them Whilst They're Hot
If you've already got komodo installed from source, all but one dependency remains for vanity address creation. sudo apt-get install libpcre3-dev git clone https://github.com/exploitagency/vanitygen-plus.git cd vanitygen-plus make ./vanitygen -o results.txt -i -k Rtechtue -C KMD $ cat results.txt KMD Pattern: Rtechtue KMD Address: RTEcHtueYhad8412YwsGnG97eMWxfgqKXk KMD Priv: xxxxxxxxxxxxxxxxxxxx So, now Tech Tuesdays have their own vanity address to use! Interested in GUI dApps development? Discord's #cc_gui channel will be where most of the work will take place in the coming weeks. Thank you, Komodo (& ecosystem) developers, what an exciting week!
| 
