[Poll]: full OMNI to ERC20 swap

Great finds Cryptoskeptic :+1:

"In summary, token swaps do not lead to a taxable event. However, keeping a good record of the basis of new coins is crucial in calculating capital gains/losses when you dispose of them in the future."

This applies to the USA. So that is a good reference already. I think that a token protocol swap without changing the name, nor the value of the token, can be considered even less of a taxation event.


On Accountability / transparency, some discussion for ideas around governance and perhaps a tentative roadmap to something basic may help as that is part of what governance processes solve for. Decisions made in backrooms navigating conflicting goals with all good intention but without the ability for stakeholder participation are usually viewed as illegitimate to any group who do not like the decision, no matter how minority their position. Minorities can be very vocal if they feel their interests are threatened and so appear to be a bigger group than they actually are. We have seen various forum polls here over the years and one faction claiming the majority vote has validated their position, while the (alleged) minority claiming it does not. Both make a valid point - a forum poll is not really fit for purpose.

One example of state of the art in decentralised governance with researchers behind it taking centuries of lessons into account is described here, recent video here. I think this is way out of scope and reach at least for the moment, but is a good example of the type of governance system required to bring accountability and transparency to decisions where significantly large stakeholder factions/groups and interests are in play.

On this ERC20 proposal I am actually not very passionate have mentioned a few times that I am not wedded to it at all. Solving the underlying problem is way more of interest to me: Ways to quickly provide decentralised two way bridges in and out of established worldwide economies/fiat, at launch. It would be a shame if the principle way in and out of the SN after launch continued to be through the security state linked exchange Bittrex as we have now. Privacy out the window right from the start. ERC20 is just very convenient possibly decentralised solution but may not be the best, would be good to see other competing proposals as well.

I was actually pleasantly surprised to learn from you Jim that all the talk of KYC etc was only related to ERC20 proposal and not wider Maid->SN token transition as I was understanding. That was not clear at all to to me before you clarified, thank you. If MaidSafe ran off and started working on ERC20 proposals but only ones that required KYC and not decentralised bridges that may greatly sway the vote against it and reduce its appeal to Maid holders who previously supported it wasting precious time and resources. How can we tell? A slightly more formal governance system though nothing as comprehensive like I linked to above would avoid these kinds of misunderstandings, help navigate the choices better than forum polls and mega threads can. Also there would be no need for anyone to beat anything in possibly misguided attempts to address underlying problems.


Maybe I’m arguing semantics, but the hard problem is not verification of signatures, but verifying in a decentralised and secure way how many MAID the corresponding addresses hold on the blockchain(s). Verifying the cryptographic validity of a signature is a matter of adding the right cryptographic library as a dependency and calling a few functions of that library. The problem here is about verifying state of the other blockchain(s). In Bitcoin terms, specifically the UTXO set.

There are four options in general I think, with only one being properly decentralised:

  1. A snapsnot of all MAID wallets is used when the network is bootstrapped. This is a centralised action, but only once (there may be legal/tax risks here, depending on jurisdiction). People who don’t own their private keys may be out of luck. The transition is forced.
  2. MaidSafe premines an equivalent amount of SN and serves as or appoints a custodian and exchanges MAID->SN for a (long) period of time. Centralised, introduces both security and legal/tax risks, depending on jurisdiction.
  3. Combine 1 and 2, by making a snapshot of transactions to a burn address rather than all MAID-holding addresses, and do a SN premine only for the MAID that were not burned. This way the custodial risk is only there for people dragging their feet.
  4. SAFE integrates support for a large part of the Bitcoin&Omni protocols, where a type of node in the network forms consensus on what is the legitimate blockchain (most accumulated proof-of-work) to issue SN to those who burn MAID. Blocks & utxo set may be stored on SAFE rather than the local disk. Decentralised, lowest legal/tax risks, some security risk, but likely lower than a central custodian. Lots of extra dev work I fear.

Option 4’s decentralisation would be great to have, but I’m not sure whether the extra complexity and inevitable delay is worth it. I doubt MaidSafe is keen to have the extra work. I also fear doing the same for Ethereum (without compromising on decentralisation and thus security) would be harder, since running an Ethereum node is much heavier.

Generally speaking, to have a decentralised transition from one decentralised network/blockchain to another, you need to have at least the target network/blockchain be able to verify the state of the source network/blockchain. This is different from an atomic swap between two individuals, which can be solved with rudimentary smart contract logic using timelocks.


Of course this will not happen:)

But I hope safenetwork will implement a decentralized plugin system, which will allow to do any blockchain related tasks (both read and write ) in realtime. Or more universaly, any possible computation and external data processing tasks. With universal consensus already implemented, such decentralized plugin system is super easy to implement. We just need to delegate X random plugin instances to do the paralel task, sign the result with network key and punish those who returned a result that is different than majority has returned. Such plugins can be run by elders/clients/vaults/anyone and results stored into network… Client software can then do with those blockchain data whatever it wants. There can be another plugin/computation layer that does network owned computation on such external data.


There is a fifth class of option which has been talked about a few times. So rather than the only decentralised choice being (4) “SAFE integrates”, we could add:

  1. Swaps performed through a decentralised intermediary. “Intermediary Integrates SAFE and Omni/MaidSafeCoin”.

Option (2) is at the other extreme: swaps performed through a centralised intermediary.

Possible options vary in their degree of decentralisation. Array of possible candidates: One of the many Elliptic Curve Digital Signature Algorithm (ECDSA) based interoperability projects like Keep or Fusion AnySwap.

Ren project or the recent ThorChain/Shapeshift. Any others? The space is exploding it is hard to keep up.

The SN token half of the swap channel would still require pre-mining, but there would be no need to put time pressure on anyone to perform the swap. It also has other longer term benefits:

Option 5) a) Decentralised Intermediary Integrates SAFE and Omni/MaidSafeCoin and Maid-ERC20 (or similarly widely used standard with large existing on/off ramp fiat network).

Option 5 a) Has potential to solve another large problem after SN launch: How to move value into and out of the network in a decentralised way after launch? We can hope that a CEX or two willing to buck FATF rules and integrate the SN APIs for us (and I have the sneaky suspicion Bittrex will step up for all the wrong reasons), but then the decentralized SN will have all its economic friction points channeled through a fragile, insecure and centralised bottleneck or two.

A few possible avenues to explore towards option 5/5a. For example ThorChain maintains 100 rotating nodes with minimal governance system, leaning on those rotating nodes staking value in supported coins to secure it. If official Thorchain cannot support Omni because it fails at being “economically significant”, then one possibility would be a straight fork of Thorchain + add extra Omni/SN observer components based on their templates. The 100 rotating nodes are then run by anyone interested inside or out of the SN community, each staking three things to secure it: Maid, Native SN Tokens, and a third token Maid.erc20 or similar. This could exist for as long as two way bridges are needed to move value in and out of the SN and there are community members willing to run nodes in exchange for fees. The other advantage to this method is there are fewer centralised legal considerations as swaps are via a decentralised bridge.

1 Like

Some notes future reference…

Fusion’s Distributed Control Rights Management (DCRM) was built to address cross-chain interoperability through a decentralized custodian model. It uses the latest cryptography technologies in Threshold Signature Scheme (TSS) for Elliptic Curve Digital Signature Algorithm (ECDSA) to provide a distributed key generation and transaction signing algorithm. This technology was developed for over a year, with the feedback of 4 leading cryptographers such as Rosario Gennaro and Dr. Pascal Paillier.
Why do I care?
With a distributed key generation and signing algorithm, private keys are no longer a single point of failure . Access to wallets or any data that needs protection is now distributed among N number of parties or devices.

DCRM - Fusion.org
Home · fsn-dev/dcrm-sdk Wiki · GitHub

With DCRM, your Private Key is ‘sharded’, or split up with each piece being managed by a different node on the network. To make an exchange of value, a transaction must be signed by each of these nodes, but the important part is that the PRIVATE KEY IS NEVER ASSEMBLED and so the transaction cannot happen without all of these nodes colluding. This is the safest non-custodial way of sending assets.


1 Like

Pretty good high level overview from the hyper productive Andre Cronje:


1 Like

Somewhere above I’d suggested that some proof of ownership of public key would be the ability to sign as that public key - owning a private key to that.

Coupled with DBC now, I’d expect it could be possible to have the network hold DBC against known public keys with non zero balance at a snapshot and those available for owners to claim when they prefer - and ideally in part or whole of the balance as they prefer. That way deceased owners or those with 1 MAID who bother not to claim, would not bind Maidsafe or custodians into a proof of negatives.


Omni working on some good feature here:


We’ve had 490 comments on this thread. Are we any closer to action on this issue?

This has been discussed for years and still no action. Swissprivatebanker said he would help yet needed assurances from Maidsafe. How are so many projects able to accomplish this and ours is not?

1 Like

I suggest you read the thread, the answers to your questions are there so please don’t keep asking them.


I’ll silence myself. Maybe the conversation data and method of could be pinned to the top of the thread.

1 Like

Are you sure? The largest exchange in the world is magical and accessible to everyone in the crypto world except us …

Privacy. Security. Freedom

1 Like

sure - we know this .
But until the very real issues involved in ERC-20 MAID are resolved in a safe way for ALL then its not going to happen.
It is NOT risk-free.

Sorry - wish it was :slight_smile:

I do not agree. When they hacked KuCoin 1 year ago, Noia issued a new token and distributed it to all holders. There are countless examples in the crypto world for a smooth transition in any situation to a new token…

My point is that even if something goes wrong, you just drop a new token and hand it out. If it goes wrong again, you release a new token, etc. There are Ethereum sidechains where this can be done for ridiculously little money…

Privacy. Security. Freedom

1 Like

So you say - but you have still not convinced us all that there will be no adverse tax implications either for Maidsafe or for the holders.

the taxman will have his say and cut no matter how clever the team on the code review are or how fast they can act.

I don’t care if they charge you. I am interested in new people to enter the project, OMNI prevents this and my personal opinion is that it puts the future of the project in serious danger.

Privacy. Security. Freedom


I personally have no problem with a tax bill, simply because my hodlings are comparatively modest.
Others may have, especially if it impacts on Maidsafe itself.
Your enthusiasm for getting new people into the project risks the project itself.
calm down, slow down and help find an acceptable solution.
Telling us all “heres what you could have won” constantly just does not move us forward at all. Everyone is well aware of the advantages of an ERC20 token

Why do you think I’m not calm? I pointed out the mistake that we need a lot of money to be on the largest exchange in the world.

Apparently not everyone knows this when we are constantly talking about how we should rely on someone else for the exchanges and ask him to add us and that we should even give him money. :lol:

Privacy. Security. Freedom

1 Like

Because you have STILL not adequately addressed the tax problem. And unfortunately, I doubt you can ever. This is a major project with many long term investors, not some shitcoin plaything on the DEXs
Until you can assure us that the potential losses to the project do not exceed the costs of listing on the major exchanges then it is simply prudent to continue to explore both methods.