If there was slippage/error in ETH20, then Omni holders should not be affected. I expect that would be accepted as fair and not contentious.
It perhaps is not about anyone guaranteeing coin count and more a matter that those adopting ETH20, adopt the risk.
The answer to any slippage in ETH20, would be relative to what occurred but if the third party (not Maidsafe) that is actioning that and is limiting the number of coins to what is converted 1:1 from Omni.MAID to ETH20.MAID, then should be simple in principal.
However, at conversion it becomes more complex
If snapshot at conversion:
I donāt know, if there is flexibility in the concept that at conversion all becomes again Omni.MAID for the simplicity of conversion but perhaps a third party can confirm the state of ETH20 blockchain at the same moment as Omni.MAID is snapshot.
But if we burn over time for conversion (and I noted above some reason for doing that):
There is a level of trust at burn over time, if ETH20 slips and is burnt, then those late to burn would have a problemā¦ unless the third party and ETH20 is able to evidence confidence that no issue has arisen.
Perhaps for burn, the only option is a conversion back to Omni.MAID, which third party would see as a diminishing availability of Omniā¦ again a problem for those late to convert backā¦ if thereās been a problem.
Itās Friday and one good IPA has the better of me; so, I canāt be sure if this complexity of two MAID flavours can be made simpleā¦ but I wonder that if there has been no problem with ETH20, then all options are possibleā¦ just doubles the work for conversion as previously notedā¦ if there has been a problem, then unclear we would know it.
Still what Keith @krnelson suggested above was very interesting and as motive, it goes beyond what went before; so, there is something worth considering still but itās not obvious yet.
It seems unlikely to me any 3rd party would do so, and make right their wrong unless they gained in the first place.
Id like to be wrong, but I dont see it.
If the decentralised contract code checks out is tested and audited to the best of ability, and the Ren project cross chain transaction or similar technology solution is two way so you can bridge back and forth between assets as often as you like, then is there any need for a guarantee? Those risking value in any kind of transaction on a decentralised platform already accept the standard disclaimer: Use at your own risk. This is all the guarantee we are going to get with Maid->SafeCoin conversion after a certain date anyway no matter how the conversion is performed, so none of any of this is risk free.
If conversion Maid->Safecoin is going to be a snapshot then all that is required is an ample āconvert back by this dateā warning. That would be way more than this community has received from various exchanges delisting Maid or going under over the years with Maid lost forever in the process.
So it seems that ERC20.MAID will be redeemable 1:1 for SAFE so long as the total number of MAID (OMNI + ERC20) remains 452,552,412 and thereās a streamlined process in place.
@SwissPrivateBanker, can you ensure that the process you would use keeps the total number of MAID at 452,552,412? Can you provide clarity on the process that would be implemented/ensure the process will be streamlined?
Or, are you now recommending renproject? If so, can you provide some insight into whether and how renproject could limit the total MAID supply to 452,552,412 and that the process would be streamlined?
First thing to get the ball truly rolling for ERCmaid is to have at least some semblence of an official push via a post by CEO (ideally? Or maybe others?) putting all the info out there, and āthis is what we are going/can do,ā and have a poll I guess?..asking if most agree with the plan laid out. Maybe revise if more agree with the revision. This takes manpower out of getting Fleming/whatever out; so Who Knows When is best to make such a post/poll, is the conundrum. Higher price isnāt guaranteed, though if it was that kind of could work in Fleming etc.'s favor.
A regulated entity like Altcoinomy cannot mint tokens out of thin air, without having a set of contractual documents signed with a party that is clearly identified as a client/issuer. It would be illegal in our jurisdiction.
During the TGE ( token generation event) Altcoinomy would ensure minting or redemption and be the go-to provider for crosschain interoperability.
It means that even though we are operating on behalf of the issuer, we have control of the money supply of the erc20 token and can ātheoreticallyā print more tokens than we should, if we were a malicious actor.
What guarentees that we are not abusing the system is the fact that the number of Omni-maids locked is the same as the number of Erc20 in circulation at all time, and this can be shown publicly on-chain at anytime. We are also bound to respect our contracts. In case of a breach, whether on AML or issuance, our auditors KPMG can report bad practices to VQF our supervisor who would escalate to the Finma our regulator. Such bad practices can land our directors (me included) in jail.
Thatās the regulated world:
KYC is mandatory and trust is ensured by supervision by regulatory bodies.
Yes we could ensure a burn/redemption mecanism is in place, but we need contracts and commitment from the issuer as we are playing the regulated game. Not pushing for it, just saying there is no way around it if we are involved.
Ren is a very different breed.
There could never be too many erc20 in circulation simply because they are only minted upon locking the original Omni. The minting is done in a trustless way by a smart contract automatically after a network of virtual machines have validated the lock of an Omni token by a user.
Onboarding process is well described here:
@dirvine, is there anything else you would need from SwissPrivateBanker (SPB) or would you prefer the renproject route?
I think one of the convenient things about SPBās offer in comparison to renproject is that working with him would lessen the work on the MaidSafe team (heās volunteered to have his team take care of the technical details). Going the renproject route would likely require MaidSafe to appoint a point person to more actively manage the process.
I had the opposite impression. With Ren anyone can make a PR to get Omni support added to RenVM. Since it is a bidirectional bridge only Omni MAID to SAFE conversion needs to be supported when the time comes, as was always the plan.
Maybe the Ren devs would be interested in adding Omni support (probably mostly because of Omni Tether, but MAID could piggy back on that)?
āopen a pull request for your asset/chain! The Ren team will help implement it, review it, and merge it. Once this has happened, it can be considered for support in RenVMā
Does Ren charge fees for this? Do they specifically state that they donāt require a project team contact? I could see them being willing to develop OMNI functionality if enough people requested it, but it seems a bit odd that theyād be willing to create ERC20.MAID specifically without MaidSafe involvement and for free. Maybe Iām missing something hereā¦
In addition, someone technical that the community and MaidSafe trusts still needs to be involved/kick things off (e.g. make the request, follow up on the request, track progress, etc.). Who would this person be?
Not as far as I can see, if everything is transparent to the community and we fix supply as @SwissPrivateBanker has said it would be then I donāt see any issue.
From Renās side of things, the more tokens and chains that they support the more volume will flow through their bridge network, which means more fees collected and more value accrued to the REN token. So thatās why I could imagine some motivation from their side to help out with Omni.
The main thing thatās not clear to me if this avenue was pursued is when it is time for Omni MAID to SAFE conversion, will it be by burn or by snapshot? If there is an ongoing burn process for the conversion Ren will be fine because people can go ERC20 to Omni MAID to SAFE. If there is a snapshot Iām not sure that would work with the decentralized custodian that is RenVM holding Omni MAIDs at the time of the snapshot. So perhaps a point in favor of a burn conversion process.
I think processing it with Ren project with a little help from @SwissPrivateBanker (not demanding full responsibility of him) seems like a better idea.
Good point - we do not know how to make a snapshot properly. Any idea?
In my visions SAFE Network will make most cryptos, including Bitcoin useless. Is there a risk that this could happen so quickly that MAID Omni token is not secure for a very long time after SAFE goes live? I mean BTC mining ending, hashpower decreasing, double-spending becoming easier, etc? Should this be a reason to have limited conversion time, or some other safety mechanism? Would some other token be safer? Or is this just me dreaming?
Even with zero hashpower, as long as a snapshot (which is the current chosen method I think anyway) of the blockchain is taken, we can sign a message with our private keys and so then proving that we own the coins.
A quick google search show you how to sign messages.
But I donāt think other cryptos will fall over night.
That is solved by the snapshot method because the record will be there becauce a copy of the blockchain can be made. As @Zoki said. I should have read his first
Ok, to summarise, from a team perspective, where we are at with this thus far.
In principle itād be great to allow MAID to exist and be traded in any form that suits those that wish to hold them, provided it can honour the commitment of there being a fixed supply of 452,552,412 MAID, and that these can be exchanged 1-for-1 to Safecoin when the network is launched. This doesāas you can see from all the threads within threads right hereāquickly lead to questions of the redemption process, and the network genesis itself.
So that is where we find ourselves at the moment, we are discussing internally the various approaches to this, the practicalities, the sequence of events, and how these could be made intro proof of concepts, either by us and/or the community, so we can make it all robust prior to launch.
I guess I just wanted to acknowledge the frustration for some to see us standing in front of what looks like an open goal; but to let you know we are grappling with it, but yet still keeping focus on the tasks for Fleming.
My frame of mind has been that a Fleming release would bring more interest to the Omni token and ERC20 wouldnāt really be needed.
Butā¦ a Fleming release coupled with an ERC20 token would be quite refreshing I think. It would demonstrate progress in the product, and some form of progress in trading.
As long as the ERC is transferable 1:1 back and forth from the Omni, then I donāt see why the Maidsafe team need to guarantee much more.
A third party guaranty of a 1:1 back and forth transfer between omni and ECR would be enough? Especially if they are a trusted community member.
Or we could wait and see how the market reacts to a Fleming release.
has the better of me; so, I canāt be sure if this complexity of two MAID flavours can be made simpleā¦ but I wonder that if there has been no problem with ETH20, then all options are possibleā¦ just doubles the work for conversion as previously notedā¦ if there has been a problem, then unclear we would know it.