Community Effort to Launch ERC20 MAID

Check Harmony(one)

Wrapped hasn’t been as forthcoming as I’d like. I’m hoping that energy once the testnet is released (plus the increased volume from P2PB2B) will give them confidence to move forward more quickly.


Been experimenting with creating multisig addresses/script for omni and also found that future token will most likely be a ERC777 (backward compatible with ERC20) or ERC1155 which have a lot of great features over ERC20.


Like ERC20, ERC777 is a standard for fungible tokens, and is focused around allowing more complex interactions when trading tokens. More generally, it brings tokens and Ether closer together by providing the equivalent of a msg.value field, but for tokens.

The standard also brings multiple quality-of-life improvements, such as getting rid of the confusion around decimals , minting and burning with proper events, among others, but its killer feature is receive hooks . A hook is simply a function in a contract that is called when tokens are sent to it, meaning accounts and contracts can react to receiving tokens .

This enables a lot of interesting use cases, including atomic purchases using tokens (no need to do approve and transferFrom in two separate transactions), rejecting reception of tokens (by reverting on the hook call), redirecting the received tokens to other addresses (similarly to how PaymentSplitter does it), among many others.

Furthermore, since contracts are required to implement these hooks in order to receive tokens, no tokens can get stuck in a contract that is unaware of the ERC777 protocol , as has happened countless times when using ERC20s.


ERC1155 is a novel token standard that aims to take the best from previous standards to create a fungibility-agnostic and gas-efficient token contract.

Batch Operations

Because all state is held in a single contract, it is possible to operate over multiple tokens in a single transaction very efficiently. The standard provides two functions, balanceOfBatch and safeBatchTransferFrom , that make querying multiple balances and transferring multiple tokens simpler and less gas-intensive.

In the spirit of the standard, we’ve also included batch operations in the non-standard functions, such as _mintBatch .


This sounds very promising!
I envision a new poll coming up, and a never-ending disussion after that :smile:

Jokes aside, this is worth digging into. I will do my duty and read up on this, so I can make an educated choice when the poll is launched.


I managed to create a multisig address using 5 local private keys and it requires at least 3 to sign the raw_transaction that is created, then when it collected enough unique signatures it will be a valid transaction to be broadcasted and settled on the network.

Now I need to see how one can create a raw omniasset transaction so you can move omnilayer tokens instead of just bitcoin.


Take a look at my two posts here:


To use this wallet you need have access to the OMNI node. After new wallet initalisation electrum node access credentials should be added to wallet settings (Preferences->OMNI->Daemon Url). Example: http://username:password@IP:port/. This is a pure python application.

I believe you need access to the full node RPC to utilize this then?

1 Like

Great news, I finally managed to create a raw transaction and was able to do a Omni SimpleSend from the multi-signature address earlier! The multi-signature address was created with 5 unique private keys and requires at least 3 to create a complete transaction that can be broadcasted.

My idea is to have independent full nodes with omnicore (although signing does not require a full node!) and these nodes validate all the incoming and outgoing transactions. Only if majority of the nodes is in consensus then the funds are able to move. This removes a great deal of risk as the attack vector surfaces is spread and no single node can move any funds!

With more testing I believe we could see the first swap coming into shape, now that the omni-part is done I will move to the ethereum multi-signature contract which will work in a similar way with unique/independent validators who will sign transaction before anything can happen.

Transaction ID: eac903478641c604e16fb7f4cf4491fb2e78b25cd0f32640822b4a20acd6b6c2


Great work. I’m wondering about the robustness of a three of five concensus. Would control (I’m thinking of hacking) of the nodes give full control of all MAID?

With the difficulty maintaining a omni node to be available 24/7 with no down time is 3 of 5 going to be reliable enough. I estimate that without some (very) good equipment/internet connections that at least one of the 5 at any one time will be down with a decent chance of 2 down often enough.

This means that probability says sometimes there will be 3 down at once for some period greater than 1 second.

Added to that if the node does not come back up within a short time frame then it will have significant resync time adding to its down time as a full node. The follow on effect is increasing the chance of 2 or more nodes down at the same time.

It may in the end be only 1 day a month or less but could be more.

Would 4 of 7 or 5 of nine be better?

Unfortunately I do not have any hard figures on how long a person with a regular desktop can keep their omni node fully synced up. How often do they have disruptions and need to resync? How long on average is it down and resync when recovering? I only hear that people have trouble syncing for the first time and then keeping it in sync.

Maybe if there could be a human to veto any transaction, the human(s) cannot release a transaction only veto. So then all transactions get a human eye on it. Considering the relatively small number of transactions ongoing (except at start perhaps) this might help, or not? Just trying to brain storm here

1 Like

I will make my python scripts for creating a full raw omni transaction and also for signing/broadcasting available on github.

As stated earlier the signing process does not require any full nodes, basically omnicore on a usb stick could even though as you don’t need to sync up.

There always needs to be at least 1 full node running that is able to create the transaction and forward it to the signers. Not sure if only full node can do ‘sendrawtransaction’, maybe even simple unsynced node can do that as well.

I just send another transaction out of the multisig fully automated. It is now able to forward the new raw_hex from each signer to the next one who has not participated yet until the transaction becomes complete and ready to broadcast.

Next challenge is how to select certain inputs if there are multiple when people deposit BTC into the multisig to withdraw and then selects those to then fund the miner fee.


Python code to simply create raw transaction with Omni SimpleSend payload and change address.

First create a multi-signature address using omnicore-cli, you can specify how many signatures you want and require (n-of-k), this script will use 3-of-5 for the example test in the signing part.

To create a multisig address you do the following using omnicore-cli or the console in omnicore-qt, or even use a bitcoincore client as this does not involve any omni actions/functions:

Do getnewaddress k times for the amount of multisig holders you want to create, in real-world situation individuals would all do this by themselves on a secure bootable USB that has omnicore on it and does not need any internet connection.

You will get 5 addresses, for example:

  1. 36uwmRmD9X2BH4Hi9ekv34k1Lp86QiYGw4
  2. 36RGKtGoUiZwLucvcdvSm5m2mzY1qa4aCa
  3. 39hTG37BgWjaRCRGhZSSNGkzK3ErLbS8VZ
  4. 33bm8hy2Uo4xEubhnbj2ds66VydCJS8djW
  5. 32nDKbaDCQ3tnW1wvWVyjwskL1kfXcvkbW

Each address represent a unique entity holding a share of the multisig address.
Now run getaddressinfo <address> for each address, you will get the pubkey - Hex (base 16), these are meant to be shared and don’t pose any security risks.

It will look like this for each address (showing 1 for sake of simplicity):
getaddressinfo 36uwmRmD9X2BH4Hi9ekv34k1Lp86QiYGw4

{ "address": "36uwmRmD9X2BH4Hi9ekv34k1Lp86QiYGw4", "scriptPubKey": "a914394a90f1c8f864edb80b186baf48a54ebc89ede187", "ismine": true, "solvable": true, "iswatchonly": false, "isscript": true, "iswitness": false, "script": "witness_v0_keyhash", "hex": "00146bf7aad62dce4a9c6545df5794ea1636c1b3f382", "pubkey": "02d6406f9dd17dedc83496101cb3b997acdce67fba4f671c4eb9398c19d505b8ad", "embedded": { "isscript": false, "iswitness": true, "witness_version": 0, "witness_program": "6bf7aad62dce4a9c6545df5794ea1636c1b3f382", "pubkey": "02d6406f9dd17dedc83496101cb3b997acdce67fba4f671c4eb9398c19d505b8ad", "address": "bc1qd0m6443dee9fce29matef6skxmqm8uuz660mck", "scriptPubKey": "00146bf7aad62dce4a9c6545df5794ea1636c1b3f382" }, "ischange": false, "timestamp": 1614668157, "labels": [ "" ] ... }

Finally, the important part that requires to be done securely, dumping the private key of the address.
The private key(s) will be able to sign raw transactions and when enough do so funds can be moved, keep them secure at all time!
dumpprivkey <address>

dumpprivkey 36uwmRmD9X2BH4Hi9ekv34k1Lp86QiYGw4
Output (this is not actual key but should look like this):

Last part is to create the multi-signature address, important is to keep track of the order how you put the public keys! Specify how many required signatures are necessary and then the array of public keys, the github example uses 3-of-5:
createmultisigaddress <#ofSignaturesNeeded> '["scriptPubKey1","scriptPubKey2","scriptPubKey3","scriptPubKey4","scriptPubKey5"]'

Example for 3-of-5:
createmultisig 3 '["02d6406f9dd17dedc83496101cb3b997acdce67fba4f671c4eb9398c19d505b8ad", "02ad49bc6f2932fd02ee17b0f1fdd27c9f0373722c7d14d7fdd0dd6fbdef4bbdae", "0381ae9203e049a978a7b4b067a9f77659c5949b464ed3b6d5f40e6da4c7865ab7", "0347c558956c5e3386277b36d703a03fc7d8e94335305e7681901a621a812b4752", "0273d26832feaec937db4d933c9710a7cf3545711cc32918e84d2665a4c54daf19" ]'

Output with the required redeemScript and your multisig address!:
{ "address": "3QhJ3qajPviUgr6krrDYXGrEd8vwVvmP9a", "redeemScript": "532102d6406f9dd17dedc83496101cb3b997acdce67fba4f671c4eb9398c19d505b8ad2102ad49bc6f2932fd02ee17b0f1fdd27c9f0373722c7d14d7fdd0dd6fbdef4bbdae210381ae9203e049a978a7b4b067a9f77659c5949b464ed3b6d5f40e6da4c7865ab7210347c558956c5e3386277b36d703a03fc7d8e94335305e7681901a621a812b4752210273d26832feaec937db4d933c9710a7cf3545711cc32918e84d2665a4c54daf1955ae", "descriptor": "sh(multi(3,02d6406f9dd17dedc83496101cb3b997acdce67fba4f671c4eb9398c19d505b8ad,02ad49bc6f2932fd02ee17b0f1fdd27c9f0373722c7d14d7fdd0dd6fbdef4bbdae,0381ae9203e049a978a7b4b067a9f77659c5949b464ed3b6d5f40e6da4c7865ab7,0347c558956c5e3386277b36d703a03fc7d8e94335305e7681901a621a812b4752,0273d26832feaec937db4d933c9710a7cf3545711cc32918e84d2665a4c54daf19))#3h5wqtqk" }

Note that different order of public keys will create a different address and redeemScript, if you maintain the order it will yield same results.

So from the outputs keep the address, pubkey, private keys of each address and save the multisig address & redeemScript somewhere.
The multisig address and redeemScript can be shared and don’t pose any security risk.

Next you can try to fund your newly created multisig address with a bitcoin transaction, this transaction will be used when you want to create a rawtransaction, it will use the transaction id and inputs to the multisig address for creating new outputs and paying for the miner fee!

I send both some BTC and MAID to my test address, write the transaction id down of the the BTC funding that you will use later in the script.

On my github you can download these simple python scripts, they will do all the copy and paste work for you and create the raw transaction. Still working on it, currently it will create a raw transaction and directly do a test signing until it is complete (meets required # of signatures) but will not broadcast it until you change ENABLE_BROADCAST to True.

Please read more about it on my github in


FYI: The project tau agoras ( used an exchange called WhiteBit to allow swap to Erc20 from omni


Any movement on this? Or is the idea dead?

Probably need this more than ever with the State of exchanges…


Agree. I wish we could use some of the Bamboo fund to get someone on this full time until it’s over the line, leaving the rest of the team alone (if possible). The investment may pay itself back 10 fold if we get good liquidity.


@Sotros25 and somebody else, @DeusNexus, maybe?, mentioned recently that progress is being made, but they cannot yet elaborate.

Edit: Found it:


In the announcement thread of the fund it states:

But I think it could be argued that paying someone with the neccesary expertise to work on the ERC conversion is not applicable to any of the above, it is crucial considering the state of omni and also meets the following requirements:


There is movement. I am cautiously optimistic that news will be publicly shareable soon.


I hope this news comes with a few major exchanges that would accept trading the converted tokens :stuck_out_tongue:.