Some Biatec CLAMM LP pools will be deployed with required verification level 2, which means that anyone’s account who will want to execute trades there must be linked to verified profile.
This will make the algorand DeFi trading secure because people does not have to be afraid that they will receive stolen algos or they fund the terrorists.
Some pools will have verification level 4 required so that only regulated institutions will be trading between each other.
Anyone can use this info in their smart contracts if they want to be on the safe side with the MiCA regulation or other regulations.
I did run the regulated commodity exchange for more then 10 years and have enough experience in collecting and processing the users kyc data and communicating with government. I was also one of the developers of the portu.cz product where the biggest investment bank in czech republic (Wood&Co) decided to do retail product and we developed the KYC verification processes.
In the proposal is clearly stated that the personal data will be stored in the secure offchain decentralized storage, so that if someone hacks one specific server he will not have access to the data. The solution will be open source, and everybody can audit the secure storage process which will be in place.
Can i please kindly ask you to refrain from humiliating Biatec group team or products please?
You already have an open clAMM proposal that needs its first milestone completed. Based on this comment from @Adri, it would seem that the xGov rules do not permit this proposal at this time. xGov 202: Pact Stableswap Retroactive Grant - #14 by Adri
Any future dApp that will want to deal with AML check can use this service, and thus more apps will be usable to users of the Biatec identity then others. At the moment biatec CLAMM smart contracts is integrated to this solution as 1) the AML check can prevent blocked users interacting with the AMM, 2) the engagement levels directly influence the trading fees. Without the frontend and management of this identity contract all fees are little higher, which benefits the liquidity providers. Users of the identity service will have lower trading fees and ecosystem will be more clean of gray economy.
Even though CLAMM is connected to this project, the identity service is self governed project which is not dependant on CLAMM. More dApps can use the service.
Also the milestone 2 of the ClAMM has been reached and smart contract has been delivered. Within this delivery also the identity smart contract (which was not originally planned) has been delivered, and this grant request proposal is basicall the frontend management and offchain secure data storage solution for this identity smart contract.
The proposed accepted milestones in xgov80 : 1 and 2) has been delivered. The third milestone was not approved in the last voting session, and i cannot propose more than 2 proposals in this voting session.
The identity service is basically not related to xgov80, only that the clamm uses identity service such as anybody else on the blockchain can use it.
My understanding is that the third milestone funding was rejected because the prior milestones hadn’t been delivered yet. I wish you would have resubmitted milestone 3 rather than proposing a new project. But it is what it is.
While I recognize that there will be a need for KYC verifiers under MiCA, I’m concerned you are biting off more than you can chew. Are there not other, larger entities tackling this issue in an industry wide way?
It seems like to run a competent KYC verifier one would need to do this at scale. For instance, one of the data points you have listed is in person verification of Govt ID. That’s only possible if you are operating with physical offices in many jurisdictions. That requires a lot of capital up front, and is certainly not something that could be supported by the needs of just Algorand users.
We already have dApps on Algorand that integrate KYC procedures utilizing existing providers. For instance, AlgoMint previously required KYC, and Stasis has KYC to get EURS. Why is that not sufficient?
Yes, even with asa.gold we have option to register your personal data, mainly so that person can request the delivery of physical gold coin to his address.
None of the services you mentioned provide KYC services to third party, so technically we cannot use it. And it is not just about collecting the KYC data, the main thing is pairing the unique person id with the algorand address onchain, so that everybody can see that the algorand address is legit.
I would love to use this type of service if it existed.
What do you mean? Are you saying that there are currently no methods for Stasis to operate in a MiCA compliant way? If you aren’t, then what need is this addressing that is not currently met?
I’m struggling to see what this proposal adds compared to existing providers or how this would scale without significant capital contributions and a crypto-wide focus rather than just Algo.
No, what i meant to say is that stasis is providing KYC service for their own project only. The same as AlgoMint. They do not provide identity services to third party.
Biatec identity is solution where third party can use the service to ensure MiCA & AML requirements. And btw its going to be open source, so other projects can use it for themselves if they want to.
This assumes that the corresponding enterprises (i.e. Stasis) will accept verification from what you are proposing. Why would they?
Yes, they can. But again why would they? Why would they adopt your code to set up an international KYC mechanism? If some other project is going to embark on this, why wouldn’t they just build that code themselves and do it from a chain agnostic way rather than looking at your Algo specific repo?
When you start a business you do the check what needs to be coded and what needs to be adopted or somehow modified. I am not saying that everybody is going to use our service, but we give businesses the choice.
And they should consider it because it can cut them either the dev costs or operation costs.
Why does pera uses third party service to do identity check when you verify the asset? Because pera does not want to deal with identites, securing them and managing the GDPR and stuff like this… If this service would exist before perhaps they would choose it.