It’s no secret that bitcoin miner fees have gotten more expensive, and that on days with large blockchain backlogs of unconfirmed transactions. Ways to insta-confirm DEx trades may be possible, but meanwhile, let’s look at different trading strategies using the DEx. Below fees are based on low mempool-size conditions, they may drop by half

1. Whale Profit Tails – Someone who is investing in size in Omni Layer assets may have positions large enough that getting in and out is a tricky, and potentially very expensive proposition. Staggering orders over a range of prices can be a great way for a long-term inverstor or intermediate-term trade to optimize the average price received when exiting a position. A good way to figure what price increment to use between orders, would be to pick a range, say 110% higher to 130% higher, and lay 5-20 orders across even intervals in that range. One way to figure amounts is to consider equal dollar value proceeds at each increment, putting the largest amount of units up front to be bought first, reducing risk, while preserving total profit by selling slightly less at each higher price increment. Because there are no fees on the DEx for placing limit orders, this is the lowest-cost way to scale in and out of large positions. Use lower fees expecting confirmation in days or more, to spread more orders or save more on execution cost.

   Cost: 0.0001 BTC for 5 to 20 trades, ranging from 0.0005 BTC to 0.002 BTC

2. Market Maker Spreads – Look up an outside market with a centralized exchange, keep some trading capital on the open blockchain for DEx trades, and deposit some on a centralized exchange. Calculate prices where you could detect a  matching MetaDex trade, and then immediately take liquidity off of the orderbook on the centralized exchange. When prices move, cancel the trades and place new ones at newly calculated prices. When a match comes in, trade on the centralized exchange at the market. Having calculated match prices with a margin of profit after fees and slippage, earn a steady trading profit.

Cost: 0.0003 BTC x 2 + 0.0005 for the cancel, per cycle, 40 times a day,  use 0.5% or better profit-margin, needs a $5000 value position to trade at least twice a day in order to break even on miner fees. A saturated DEx would involve a number of such traders utilizing fee analysis and high-fee cancels, and matches hitting every block, with profit margins tightening to .1%.

3. Combination Spreads – Professional investors making markets across multiple exchanges and carrying inventory  can combine strategy 1 with strategy 2 to achieve the goal of price-range distribution/accumulation of large, illiquid positions in some assets, and save money for strategy 2, in that many potential matches could occur with cheaply placed orders that were transmitted many blocks earlier. Also, funds that work with 50-100k or more on such a strategy would accumulate a 30-day average volume on centralized exchanges that could entitle them to lower maker fees on that side of the books, enabling them to provide tighter spreads, making the 4th strategy more accessible to everyone.

    4. Liquidity Taking Arbitrage – As markets get deeper, there will be opportunities to buy potentially large blocks of an asset while simultaneously trading it off at better prices on a centralized exchange. These orders will likely become competitive, in that within the same block confirmation time, multiple traders will try and match the order. Increasing miner fees to 0.0007 or as much as 0.0012 makes sense here, once fees are active a 0.05% taker’s fee will also be deducted from the proceeds of the trade. Maybe the objective is to hold the resulting asset, taking advantage of a favorable price, or maybe one is aiming for accumulation by selling it on one market and buying it back more cheaply on another.

Cost: 0.0007 BTC + 0.05% of the trade proceeds

5. Triangular Arbitrage  – Because the DEx permits total free in what pairs trade against, creating exponential possibilities as the number of asset grows, one can combine strategy 2 with strategy 4 by looking at triangular arbitrage opportunities. If I can take liquidity to buy MAID with OMNI, then sell MAID for USDT, and end up with more USDT than I would have selling OMNI, then it’s a reasonable move to take liquidity on both markets. A trading system based on this could provide limit orders to hedge on centralized exchanges when they are matched, or take the opposite approach, scanning the blockchain for order chains that would enable a profit after 0.05% is deducted twice, and after 0.0014 BTC is paid in miner fees for fast confirmations. Therefore, the total triangular arbitrage value should be at least a 0.2% on a (based on current BTC prices) $1700 valued order, or larger amounts for arbitrages worth between 0.1% and 0.2%.

Cost: 0.1% + 0.0014 BTC

These 5 strategies cover the elemental basics of decentralized exchange trading, but if you have any other ideas, please share in the comments.

 

 

 

 

 

 

 

 

The recommended way to do a managed smart property issuance is through a multisignature address. Also, long-term storage of assets held on an institutional level, and institutional operations such as payroll management, may also benefit from using multisignature addresses. Most importantly, exchanges integrating the Omni Layer protocol can manage risk with one central multisignature address, or preferably, a series of rolled multisignature addresses.

The protocol does not currently support sending to multiple addresses in a single transaction, this is a feature we’d like to develop. Creating transactions that fulfill customer withdrawals as secondary outputs is not yet possible, so a combination strategy of hot wallets and multisignature repository wallets is recommended for doing a large number of send transactions, for now. For example, an exchange could keep 10% of the assets in a hot wallet that the server controls for fast withdrawals and then re-fill it on a daily basis.

It’s also possible to create applications that make the below illustrated process much easier, and even facilitate exciting uses like market places for real goods, with paid arbitrators available to settle disputes with a 3rd key.

First, one must safely generate and store private keys and their corresponding public keys. The best way to do this is install Linux on a formatted USB, drop a download of Omnicore on the same USB, wipe a hard drive, and boot from the USB. Load up Omnicore (or Bitcoin Core, for this purpose, it’s the same) and go to Help -> Debug -> Console. Then type:

getnewaddress

Copy the address and paste it in front of the following command:

validateaddress <address>

The pubkey will be displayed, write it down, it’s in Hex (base 16) so your hand might get a cramp. Pasting it into an email and having a copy in the cloud is acceptable since pubkeys are not a security vulnerability, and are actually meant to be shared. The other board members or team members, or your accountant, or your spouse, or whomever is going to follow these steps on their own to generate their own private key, will have to share their pubkeys with you in order to generate the multisig address.

Now the very important part:

dumpprivkey <address>

Like it says on the tin, this will dump the private key for that address (though it only works if you’ve generated the address locally and it’s saved in that local client).

It’s very important that the privkey is written down on paper, make sure your hand-writing isn’t too bad, that characters that might be confused for another are marked.

Now it’s time to generate the multisignature address, let’s say you want to create a 2-of-3 address, you’ll do this by specifying the number of signatures needed (2) and listing an array of pubkeys:

 omnicore-cli createmultisigaddress 2 '["0232b7c756b51c8ad37fa63929d119b118af54598c8a0f1ab8f1966704e4cbff96",
"02343986778e78ff014076967c5f49923e3304c43c79e58e82f4119df19833ba8e",
"027aa3757d4a869a8e886a4562322a251fe8a7b1c710a8a33f7aad980c9e6e9a3b"]'

The createmultisigaddress call will return the new address and the redeem script, which like the pubkey, is very long, annoying to physically write down, and not a security risk to share, but necessary to complete transactions. It can be copied to a digital back-up and shared in emails.

It’s essential that you fund the new address you just created with some bitcoin, it can be a very small amount, but no less than .005 is recommended. Check your transaction hash when you send, you’ll need it later.

Now the most technically complex part: preparing a transaction to be signed. There are a series of RPC calls that begin with “omni_createpayload_”and then are followed by the name of an existing transaction, for example “omni_createpayload_simplesend”, “omni_createpayload_trade”, and “omni_createpayload_issuancemanaged” – the full list can be found here.

Issuance of a managed smart property is one of the more parameter-intensive transaction types, here is a list:

Arguments:

Name	Type	Presence	Description
ecosystem	number	required	the ecosystem to create the tokens in (1 for main ecosystem, 2 for test ecosystem)
type	number	required	the type of the tokens to create: (1 for indivisible tokens, 2 for divisible tokens)
previousid	number	required	an identifier of a predecessor token (use 0 for new tokens)
category	string	required	a category for the new tokens (can be “”)
subcategory	string	required	a subcategory for the new tokens (can be “”)
name	string	required	the name of the new tokens to create
url	string	required	an URL for further information about the new tokens (can be “”)
data	string	required	a description for the new tokens (can be “”)

omnicore-cli omni_createpayload_issuancemanaged 1 2 0 “” “” “myTokens” “www.myblockchainasset.com” “Experimental multisig tokens.”

Very important note, OP_Return only allows 80 bytes of data, 4 of which are consumed by the omni market, so your hex payload must be less than 152 characters long (76 bytes), the categories parameters are not worth the text, just name your asset, include the URL and come up with a very succinct 3-5 word description. Longer strings will fail to modify the transaction.

The resulting hex is what would go into the OP_Return of a Bitcoin protocol transaction that would effectively make it an Omni Layer transaction.

We must also create the components of a bitcoin transaction as if we weren’t creating an Omni transaction, with an added bonus of inserting the payload you just create as an OP_Return, and after that we’ll have a proper transaction hex to sign.

The steps:

omni_createrawtx_input, then add the payload via
omni_createrawtx_opreturn, then add the reference  address via
omni_createrawtx_reference, and finally add the change address with
omni_createrawtx_change.

Now step by step with parameters:

omnicore-cli “omni_createrawtx_input” “<raw tx hex to modify, we’re creating a new one, but it’s necessary to put in the quotes and leave it blank>” “<the transaction id of the bitcoin you sent to fund the address earlier>” <the vout position of the output that this input transaction is providing to fund mining fees – an integer, usually 0 or 1, you can tell what integer by looking at the transaction on blockchain.info, the 0 position output is listed fist, then the 1 output, then the 2 output and so on>

Now copy the hex that was just emitted, as well as the Omni Layer transaction payload you created two steps ago, as parameters for the next step:

omnicore-cli “omni_createrawtx_opreturn” “<modified transaction you just got from the createrawtx_input>” “<hash that is the payload of the Omni transaction you want to put into the OP_return>”

You’ll get another modified hex representing the new data, now copy that and your multisig address as parameters:

omnicore-cli “omni_createrawtx_reference” “<the most recent transaction hex you want to build-up>” “<address to send to>”

Note that your reference address is only the address you’re sending from if you’re doing an issuance, usually this is the address you want to send tokens to. If you’re doing a grant or issuance, this step can be omitted.

Now finally, we’ll take the resulting transaction hex and add a change address (change as in “spare some change?” not as in “we want change”), which will also be the address you’re transacting from, so any bitcoin not used in the fee will end up on the same address.

omnicore-cli “omni_createrawtx_change” “<latest version of the hex for this transaction you’re building>” “[{\’txid\’: \'<id of input transaction that funded the address>\’,\’vout\’:<0 if the input you’re spending is first among inputs, 1 if second, ect. – an integer>,\’scriptPubKey\’:\'<3039a5ee506a381271c1a8974eda16457838f249 – should look like this, click the “Scripts and Coinbase” link under “Inputs and Output”in the tx view of blockchain.info and scroll down to the hex ouput corresponding to the output you’ve chosen to spend>\’,\’value\’:<BTC spent in output, an 8 decimal place floating point number, must equal the whole output chosen by vout from the input tx>\’},<other JSON objects representing other input transactions used, where applicable>]” “<your address to receive the change, same as in the previous action>” 0.00035

The last parameter is an integer for the miner fee paid.

One tricky thing about this step the JSON has to have “\” in front of every ” or ‘ used in the JSON part, but other JSON sections in, for example, the signrawtransaction call, don’t require this. Just a quirk of the design of the RPCs. If you don’t use the \’s you’ll get an “Error parsing JSON:” response.

Here’s a really clear example:

 ./omnicore-cli omni_createrawtx_change “0100000001cde12afc42d31cf0dc70ffdda31f11d470d45407790fc487e478223a249228fa0000000000ffffffff031ef579120000000017a314a6eb127dfb988196197f8e2aa1353974b66a2s648700000000000000001b6a14ef7d6e69000000000000007600000006c7c12e10aa0a0000000000001976a0b3e8cab9b8383e121f2dbf77be8fc79″[{\”txid\”: \”b13e92243a22783485c407780724d170d313cfa3ddff70dcf01cd342fc2ae1c\”,\”vout\”:0,\”scriptPubKey\”: \”b264a9ed243dfb686126127e8d1cb1356281d26a278487\”,\”value \”:0.749}]” “3QSYoxGXw5sfHLzMMSsDUgdW45G2W7M8sM2” 0.00025

There are extra spaces separating : and \ so the blog doesn’t show a emoticon, remove those in practice.

And now we have a valid transaction to broadcast. Share the hex with your co-signers. They can copy it in along with their private keys using this command:

$ omnicore-cli signrawtransaction "0100000001e006a9...f16c9f4af17f8700000000" 
'[{"txid":"41a76b319ba24cd32fecd85fe234e32aa58c6151d964ca5968b8b41415a906e0",
"vout":0,
"scriptPubKey":"a9148baa686154e24014b546f3cb5223f16c9f4af17f87",
"redeemScript":"52210232b7c756b51c8a...980c9e6e9a3b53ae"}]' 
'["cQoN38zUcZV9egX8XbMv5B2CPzaAg4ccdVPGxdwbpdy3TPt85eS8"]'

These parameters are: the transaction hex, a JSON including similar information as the change address call above, but including the redeem script shown when you generated the multisig (which can be saved digitally, as its compromise can’t really be used to compromise the address, but which is necessary to sign transactions on a multisig address). And finally, the private key. Note that the \’ required above is not required for the JSON here, just one of those things. Finally, use the pubkey prefixed with OP_HASH160 bytes and suffixed with OP_EQUAL byte.  This is the script to redeem that output and is what you use in the transaction. You can get it by decoding the transaction:

 ./omnicore-cli decoderawtransaction "0100000001cde12afc42d31cf0dc70ffdda31f11d470d45407790fc487e478223a249228fa0000000000ffffffff031ef558160000000017a914a9eb247dfb988196197f8e2aa1353974b66a2784870000000000000000166a146f6d6e69000000000000007600000006c7c12e10aa0a0000000000001976a914e8fab7b8383e121f2dbf77be8fc79effec252e7688ac00000000"
{
 "txid" : "5bef1c94f072317bc14201273eaf1f17a60ca4c97d5586b35333dc7b327b05c6",
 "version" : 1,
 "locktime" : 0,
 "vin" : [
 {
 "txid" : "b13e92243a22783485c407780724d170d313cfa3ddff70dcf01cd342fc2ae1cd",
 "vout" : 0,
 "scriptSig" : {
 "asm" : "",
 "hex" : ""
 },
 "sequence" : 4294967295
 }
 ],
 "vout" : [
 {
 "value" : 0.749,
 "n" : 0,
 "scriptPubKey" : {
 "asm" : "OP_HASH160 a9eb247dfb988196197f8e2aa1353974b66a2784 OP_EQUAL",
---> "hex" : "b264a9ed243dfb686126127e8d1cb1356281d26a278487",
 "reqSigs" : 1,
 "type" : "scripthash",
 "addresses" : [
 "3QSYoxGXw5sfHLzMMSsDUgdW45G2W7M8sM2"
 ]
 }
 },
 {
 "value" : 0.00000000,
 "n" : 1,
 "scriptPubKey" : {
 "asm" : "OP_RETURN 6f6d6e69000000000000007600000006c7c12e10",
 "hex" : "6a146f6d6e69000000000000007600000006c7c12e10",
 "type" : "nulldata"
 }
 },
 {
 "value" : 0.00002730,
 "n" : 2,
 "scriptPubKey" : {
 "asm" : "OP_DUP OP_HASH160 e8fab7b8383e121f2dbf77be8fc79effec252e76 OP_EQUALVERIFY OP_CHECKSIG",
 "hex" : "62b63ee8fab7b8383e121f2dbf77be8fe19effec252e7688ac",
 "reqSigs" : 1,
 "type" : "pubkeyhash",
 "addresses" : [
 "1J2P7J6yAkPOpVsanJSHx4RrhZqd1fc8dn"
 ]
 }
 }
 ]
}

That arrow in the middle of the above block quote shows you where to find the hex you need to properly sign. The one at the bottom is what you’d need to use to sign a successor transaction that takes the output you’re about to produce as an input.

The result will be transaction you can copy and email to your other co-signers to continue signing. You’ll get a message suggesting an error and see “complete: false” but don’t let this fool, you, that means you did it right. Once the transaction has enough signatures, it will show an output where “complete:true”.

But before you sign that last transaction, make sure it’s something you’d want to sign with a special version of the decode call:

./omnicore-cli omni_decodetransaction “0100000001cde12afc42d31cf0dc70ffdda31f11d470d45407790fc487e478223a249228fa0000000000ffffffff031ef579120000000017a314a6eb127dfb988196197f8e2aa1353974b66a2s648700000000000000001b6a14ef7d6e69000000000000007600000006c7c12e10aa0a0000000000001976a0b3e8cab9b8383e121f2dbf77be8fc79effec252e7688ac00000000”

{
“txid” : “8cda8e91f973717b317426292d8c1637360c12c97d5586b35333dc7b327b05c6”,
“fee” : “0.00025000”,
“sendingaddress” : “3QSYoxGXw5sfHLzMMSsDUgdW45G2W7M8sM2”,
“referenceaddress” : “1J2P7J6yAkPOpVsanJSHx4RrhZqd1fc8dn”,
“ismine” : false,
“version” : 0,
“type_int” : 0,
“type” : “Simple Send”,
“propertyid” : 118,
“divisible” : true,
“amount” : “291.21130000”,
“confirmations” : 0
}

Once you’re sure you’re good on signing, follow the steps linked above and when complete:true is the result, you can take the resulting hex and do this:

omnicore-cli sendrawtransaction  “<completed, signed transaction hex>”

If you get an “insufficient priority” error, this is because your miner’s fee is not large enough.

Also note, the Bitcoin Core RPC “createrawtransaction” will make your fee the different between the input and the output, it doesn’t have all the steps involved here so by default just that call won’t include a change address, so if you try to send 1 bitcoin from an address containing 10, you’ll pay a miner’s fee of 9 BTC and have a bad time.

REPEAT: THIS CANNOT BE EMPHASIZED ENOUGH – ANY TRANSACTION WITHOUT A CHANGE ADDRESS WILL SPEND ALL THE BITCOIN NOT INCLUDED IN THE SEND AS FEES. ANY SEND OF OMNI TOKENS WITHOUT A REFERENCE ADDRESS WILL BURN THOSE TOKENS – BE CAREFUL AND DOUBLE CHECK BEFORE SENDING

The output from sending the raw transaction, assuming no errors occur due to lack of sufficient signatures or fee, will be a transaction id that you’re used to seeing, copy it into a omniexplorer.info and blockchain.info or blockr.io and you’ll see the transaction out in the wild, pending confirmation.

For periodic business operations, weekly or monthly, this is a somewhat tedious process, but once you get the hang of it and have the commands in your SSH history, it’ll be easy. Except, for security reasons you must scrub your bash history after using a private key in the signing transaction, more on that here. It’s considered good security practice to create a new multisignature address prior to using your private keys on the old one, and periodically port funds and control of a smart property to it, limiting the possibility of a compromise over time for a highly re-used set of private keys.

Just to spell it all out, here’s that transaction:

omni_sendchangeissuer

Change the issuer on record of the given tokens.

Arguments:

Name	Type	Presence	Description
fromaddress	string	required	the address associated with the tokens
toaddress	string	required	the address to transfer administrative control to
propertyid	number	required	the identifier of the tokens

Result:

"hash"  // (string) the hex-encoded transaction hash

Example:

$ omnicore-cli "omni_sendchangeissuer" \
    "1ARjWDkZ7kT9fwjPrjcQyvbXDkEySzKHwu" "3HTHRxu3aSDV4deakjC7VmsiUp7c6dfbvs" 3

It’s possible for co-signers to write down a private key (and it’s important that they do it well, without ambiguity of upper or lower case in their long-hand, maybe a typewriter would be useful) and rarely use it, and for the administrator to use those pubkeys over and over while generating a new key and address each operations cycle.

It’s worth it to take more time generating keys in an air-gap and signing transactions in the same environment, reduces the risk profile to a physical compromise only. Every layer involved is a potential attack vector, which is why the best way to sign a transaction is in an unsync’ed Omnicore QT instance (Help->Debug->Console) on a Linux device that is clean-booted from a recently formatted USB stick and never used to access the internet.

People talk about air-gaping like it’s hard, but the hardest part is simply allocating a device for it, which should be a trivial line item for a serious operation. Different organizations will find different balances of compromise. Probably the best trade-off would be having a script that takes one private key as a parameter, pasted in fresh before the script runs, to prepare and partially-sign the relevant transactions and output a JSON object listing them along with their decoded parameters, and have it auto-email the CFO or accountant, who then saves it to a .txt file, carries it to the air-gap device on a USB stick, and then copies the long transaction hexes in while signing them manually. Maybe manually decode them again before signing to check for possible man-in-the-middle attacks. Then take a .txt file of those signed transactions, or maybe a .json file, bring it over to the internet-connected computer on the USB stick, and either email it back or submit it to a server to run another script that tries a sendrawtransaction call for each transaction. Hacking your operation should be as challenging as the famous sequence in the first Mission:Impossible film.

No exchange that requires multiple manual signatures to move assets has yet been hacked.

If you’re new to server management, see this tutorial.

I’ve had to set up different versions of Omni Core on servers over the last year, here’s a short-cut reference for those trying to get started with algorithmic trading over the DEx, or trying to do managed smart properties and apps.

Open your bash shell and copy this into the command line:

wget -O omnicore-0.0.11.2-rel-linux64.tar.gz https://bintray.com/omni/OmniBinaries/download_file?file_path=omnicore-0.0.11.2-rel-linux64.tar.gz

Then unpack the tarball:

tar -zxvf omnicore-0.0.11.1-rel-linux64.tar.gz

Then go to the directory you just installed to:

cd omnicore-0.0.11.2-rel/bin

Almost there, before we fire up omnicored, it’s essential to create a configuration file for bitcoin at root/.bitcoin/bitcoin.conf and set the following parameters:

txindex=1
logtimestamps=1
server=1
rpcuser=bitcoinrpc
rpcpassword=pass
rpcallowip=<ip>
deamon=1

Note: if you don’t intuitively know your way around a server, try a program like BitVise to shell in, it comes with an FTP client that loads up after logging into the bash shell terminal, and makes navigation and manipulation of files as easy as doing so in your local operating system.

txindex is essential to running Omni Core at all, when you try this process using the QT downloadable client a restart with txindex=1 is prompted, here we are doing it ourselves.

logtimestamps gets the logfile that should be included in the same folder as bitcoin.conf to track all transactions, you can omit this if you prefer.

server = 1 means you can skip including the -server flag that runs omnicored to listen for remote-procedure calls.

rpcuser = <enter your on user name here>

rpcpass = <enter your own password here>

allowip = <enter the ip of the server you’ll be using to run remote procedure calls on this node>

allowip gives some security to your operation by limiting mis-use of your node and any privatekey saved in it to a breach of the server ip specified, be sure to use pubkey encryption on your server.

Note: if you are going to run your code that does RPCs with Omnicore on the same sever, you can enter 127.0.0.1 for localhost.

Now we can run omnicored, if we hadn’t added the config entries, we’d want to add the -daemon and -server tags so it runs in the background and listens for RPCs:

./omnicored -daemon -server

Now wait patiently for a few days while the client proceeds to sync the Bitcoin blockchain. On a virtual private server or cloud-based instance, the incoming connections should be open by default and thus, the process shouldn’t take more than 2-3 days. If things take too long check your omnicore.log file in the .bitcoin folder to see time-stamps on each block coming in and get an idea of the progress, and if it’s going more slowly than 1 recent block per 10-20 seconds, make sure your server ports are open for incoming traffic.

Once your node has caught up with the blockchain, you can start working it from the command line or using RPCs via software packages like OmniTrade.js

For those who are new to server-based scripts, Cloud 9 is a free development environment that runs from your browser.

Finally, hosting a blockchain node requires a huge data foot-print, and most VPS providers simply don’t design their packages around hard drive space. However there is one that allows you to rent a 160 GB VPS that can host the blockchain for at least the next year, for an annual payment of <72 EUR. Now you may be wondering, is it secure to have a lot of funds on addresses controlled by a private key generated and saved inside a server?

The answer is no. Which is why the next tutorial is on multi-signature address management.

 

 

The Blockstream announcement of a production sidechain devoted to inter-exchange clearing got us thinking about the deep questions of utility, financially speaking, that their sidechain or our Dex provides to the public. The Liquid chain they are proposing isn’t a competitor to the Omnilayer Dex per se, but it is a competitor to Tether which allows dollar movements between exchanges and for trade on the open market. A sidechain that has a well-made Dex is likely to emerge in the next quarter or two, probably the Ethereum Dex app will be out in a similar timeframe. It is going to be competitive, but to what end?

The elimination of counterparty risk.

From hence forth human civilization will be able to eliminate the dependency on social trust by making our businesses and economics an efficient procession of smart contracts.

The real competition is not between start-ups, it’s us collectively against the useful service of a Banco Estado, or Banco Central providing mobile money to all citizens, like Ecuador’s closed chain, or the competent apps released by publicly traded financial corporations with their own blockchain infrastructure. It’s early yet but the field is so small right now, some hundreds of millions, we haven’t even seen the second half of the first inning. Now is our time to make a splash and whatever land grabs we accomplish will be followed by a wave of incumbent entrenchments.

Modern financial trading sort of solved this problem by legally segregating the custodial and brokerage functions, but modern stock trading accounts are still trapped in a currency, in a banking system, in a tax code deal like IRAs, in regulatory limits. So looking at the tens of trillions in free invest-able capital floating through offshore bank accounts, the decentralized nature of Bitcoin-recorded assets lends a certain appeal which may well continue to find its self-fulfilling prophecy in higher prices for a while longer. The more efficient but still legally controlled adaptations of blockchain concepts by banks will be better to use but still captive in a strong legal sense.

Look for trends in volume that are up and to the right across the board.

There are a few components to the value that a good Dex provides:

1. Reduction of opportunity cost due to having capital freely convertible into any of a multitude of denominations. This varies based on one’s country of residence – low value for US persons but higher value for Argentines, Chinese, Venezolanos ect.
2. Liquidity produced by new market entrants with smaller capital that are able to trade due to SIM-chip compatibility. These are people who would never open a formal trading account with a Bitcoin exchange and have never had a bank account, but they have risk appetites just like you and me.
3. Reduction in the trading spread for assets relative to their best alternative on centralized exchanges. Could bring the cost of trading down .15% on average.
4. Reduction in fees to de minimus levels, .05% for liquidity takers, free for providers. Futures at .02% to open.
5. Operability with decentralized applications on a reliable basis. Big volume driver.
6. Arbitrage opportunities due to 10 minute lag – also effectively eliminates high-frequency trading.

So you add those things up and you tell me what the utility is. I’d say we’re talking about billions of dollars in savings for traders and applications. It’s a paced price-discovery mechanism with no counterparty risk and a total cost (fees+spread) of 8-15 basis points, at least half the cost of trading anywhere else.

Unfortunately for the VCs that have invested in start-ups at high valuations, the competitive basis comes down to two things: user acquisition rates and cost. We are competing on price gentlemen, and the leaner, more automated environments may well be able to set the price very low, lower than the proposed returns on your equity, maybe lower than the operating expenses of a company with a solid payroll.

I woudn’t want to bake my bread with fee revenue, I want to bake my bread with making those small spreads millions and then billions of times. Servers are cheap employees, hence the savings are passed on to the end-user.

It’s almost like trading algos are mining economic value through the processing order data and logics, worming through a search space of liquidity to discover price, yet price always seems to slip away. Trades stamping on the blockchain, block after block, locking in some profits and losses each turn.

A global commons of free trade: financial, commercial and social.

It’s gotta be simple to plug into… we’ve got that, technically speaking. We need a simple killer app for saving, but it’s easy to plug in Omnicore to build such an app.

It’s gotta be open to everyone… check.

It’s should be extremely low cost to use (optional)… a distributed protocol can afford to go lower, so check.

Here’s a crazy idea, what if a foundation formed to support crypto-finance projects managed to function on a cashflow-positive basis?

Here’s a crazy idea for the exchange business – what if exchanges made money on volume in liquid markets?

The top centralized exchanges will find themselves the dueling-pits for robots trying to carve out a nickle and the inter-exchange arbitrage will manifest on those minute timeframes but clear a settlement on-blockchain. Thus capital cycles a bit more slowly; though well-capitalized systems can optimize that.

Price discovery on-blockchains is going to be a really big thing. Imagine Gold: uncensored, and restricted currencies now more liquid than ever thanks to the advance of modern computer science.

Helping people worldwide to enjoy full use of their money.

I like doing non-profit stuff. Not because I don’t like profit, it’s a mathematical function of net-positive expectancy on human (or algo) activity, and I would starve without it. But “non-profit” really just means, no net-profit squeezed out on an indefinite basis to a few winners, you can still be non-profit if you do things that return a gross profit, which is summarily eaten in expenses.

You can also reinvest in expanding something as the top financial priority. The closest we see to that in for-profit corporations is Amazon, and it’s working for them. Why not for the crypto-finance revolution?

A decentralized autonomous organization (DAO) that is all about impact maximization… that could be interesting right? It’s like the prototype for the race of benevolent robots we’ve always wanted.

The Omni Foundation is legally a non-profit, and not a DAO, but we have pre-defined charter going back to the original crowdsale 2 years ago, and it mandates that the distribution of wealth be determined through voting eventually.

We are managing the liquidity operations of the Foundation’s assets, which as of now is predominantly OMNI, with the goal of reinvesting all capital traded into the ecosystem. This means bids for OMNI in various currencies. This means promotional expenses. This means helping start very human organizations in places where this technology is needed most, parking capital in decentralized banking, producing a monthly income, creating some jobs that seek out customers, and growing that capital as it is traded with that population for remittances, noding SMS transactions, merchant payment processing, building networks of cash-out agents, importing BitSims so feature phone owners can get hardware-level security, and finally organizing with farmers to underwrite securities backed by land and then with general small businesses to float secured and unsecured notes.

Finally when you’ve got a merchant class plugged into global investments, hedging markets and trade channels (“channels” meaning they can cold-email int. importers) fed by a base of farmers who are able to optimize their land’s productivity, luxuries like paying fees for electricity and mesh-net wi-fi is a broad business, which can be then capitalized by securities offerings for solar panel networks and mesh networks, $300 a node here, $700 a house there, communities participate in owning their infrastructure, foreign investors see a yield from the electronically paid fees… we’re talking about developed economies at this point. Everyone will be able to get a degree from the Kahn Academy for the cost of their time.

I believe in this so much I gave up lucrative opportunities to do arbitrage on a for-profit basis, to fuel the liquidity in the Dex and the eventual mission of the Foundation. It’s a way to grow capital with a 2% annual tax on investment income, and since my goals with capital predominantly involve doing things over having things, it seemed like the best way forward.

On a decentralized exchange of freely-issued smart properties, you can litter your list of markets with any random coin someone wants to put out. We might as well crowd our bazaar with the undocumented value of the global south, because that’s where the economic growth is going to come from in this world, and those people being able to get liquidity is the key to accelerating that process.

In the 2020s, more money creation will come from mutual credit networks than bank lending. Bernard Leiter and Stephen Belgin are big fans of mutual credit, read their book! They were involved in making the Euro but have repented. The intermediate term goal is to have enough success in capitalizing the base (both in terms of Dex volumes/issuances and cash flow break-even or better organizations we have endowed) that it makes sense to bring those guys in more actively and start coordinating with better-capitalized Charitable Trusts/Impact Funds.

We are beginning a step towards this goal of having bajillions of securities, notes, mutual credits and commodity currencies on the decentralized exchange, by working with the Sierra Leone Liberty Group. I’ve been coaching Mustapha Cole on lean start-up, they went out and surveyed import/export business people in Freetown, we’re using the data and a video to raise them $10k. A chunk of that we can endow OMNI for, credited at the average dollar value of the preceeding month. I am partnering with Dr. Charles Evans of the Conscious Entrepreneurship Foundation (501c) so that the Impact Bond offering is tax deductible for Corporations or Schedule C filers.

That money will be dBanked in a simple way (i.e. not as a dApp, they will have BTC inventory, a hedge position that is algo-managed, some of it in deposits on a verified Bitfinex account, multisig and human trustees will be involved) and chunks of the principal will only be released when there is a counterparty to trade BTC or Tether with. The OMNI position we endow will become activated as yielding, decentralized USD tokens at whatever dollar price it’s worth after we roll that capability out.

Adam Levine called me out for mentioning this direction and my oh-so-pure intentions, because (paraphrasing him) everyone in this business talks about doing something Africa and its broadly disingenuous. I agree, it’s like a prayer bead for the NPR crowd, costs nothing to say “Africa” but it takes a few hours time to study all 54 countries on the continent, how many people who name-drop a continent know all its constituents? I’m glad he mentioned that, because it gave me a chance to mention how International Development has failed and we’re students here, trying to take it up a notch, with automated accounting, verifiable business models, and from that, the notion of Impact Dollars yielded from Impact Bonds, which measure economic activity made possible by the capital.

Now, it’s ludicrous to imagine that a bunch of geeks can fly in, pass out crates full of iPads and solve economic, cultural, medical ect. problems that people face which prevents them from reaching the comfortable, coffee and cookies coding mentality we enjoy in the West. Neither am I blind to the numerous lessons from both failures in international development that have wasted money on underused tech or distorted local economies, and failures in quantitative finance which created extreme volatility at least once a decade for the last 40 years. Knowing what I don’t know also makes me aware that I am not the smartest person I know, and attempting these ambitious tasks may yield failure just due to me not being smart enough. But there’s one thing I know for sure:

Quantifying transaction data from System D is going to be insanely useful.

We’re talking about the majority of the world’s economic growth for the next 10 years coming from people who will be, for the first time, doing business more efficiently than on a 100% cash basis.

That’s why will be publishing bounties to develop a “kit” for social entrepreneurs to get all the finance rowed out and make admin and growth management easy. Before those bounties can even be defined, we need to stumble with Mustapha a bit. We need to see how it’s different in Botswana, or in the Villas of Buenos Aires. We need the early data to make a guess as to how to frame the data of the next 5 years. Baby steps.

The ultimate goal of the Omni Foundation is to have a giant cloud of money whizzing through the decentralized exchange over Bitcoin, made up of futures bets, spot trades for different securites and app coins, and dBanking yield payments/hedge-rolls. That will make OMNI worth a lot of money as the fee recipient and as a collateral base. We’re looking at growing our supply of OMNI in trading so as we go up orders of magnitude in capitalization, we can begin to yield a larger budget from hedging with futures premium but without ever liquidating. The more budget we get from the system, the more we top-up our endowed organizations to help them scale, endow more organizations, and if we get really high priced we’ll start basic income projects.

OMNI holders will, at some yet-defined point, begin being able to participate in referendums about how we spend the budget.

Let’s say after the annualized yield from the assets exceeds $100,000 USD a year.

All of the Impact Dollars the Foundation gets from its Impact Bonds can be distributed to OMNI holders as well, the record of success is still in the chain, and since they have no monetary value you all may as well get the benefit of the collectible value and the sentimental value.

Then we can do sub-referendums on how much money approved projects should get where Impact Dollar holders get weighted input. This gives Impact Dollars some financial value, actually, as it allows “activists” to buy influence, perhaps in the Carl Icahn sense rather than the Occupy Wall St. sense. Hey it could be very problematic, it will be fascinating to find out.

Eventually combining these mechanisms with an automated Trust address (not like “trust us” but like a Charitable Trust), ideally one built in to Omnicore’s DB logics at a low level so we can know it’s safe, we can have the capital managed by trading algorithms running as a service on a decentralized architecture, have some human input in feeding referendums to the Trust and the voting. Maybe referendums need approval before becoming votable, decided by the board members? Maybe we all get keys and need unanimous consensus before it goes out to vote? Maybe the Trust has well-defined criteria about what is a viable use of funds encoded at the smart contract level and referendums must fit them to pass even with unanimous board votes.

At that point we would be 90% DAO, an almost unrecognizable cyborg compared to the all-too-human organization we were in youth. We see the Foundation reaching this vista over the next 3 years if we are successful in these adolescent steps, making the second 5 years of its life a well-optimized mission of capitalizing as many people as possible.  

You run an open-source project without payroll for 8 months, you end up with a team full of people who prefer value to money. JR donated over half of his OMNI position to the dev team’s option pool, for example, that’s ethical design. We (as natural persons) have a profit motive but the Foundation (a legal person) is framed so that there’s also a non-profit motive in the driver’s seat.

Why do smart contract developers try to convince oligarchs to adopt our tools without appropriating it into a cherry-picked monstrosity? Bad outcomes await for such expectations. I’d rather go make clients of people with $500 net-worth mostly in goods and some physical cash. They will go have excited conversations with their familiars about how they’re making more money, and it catches fire. 
If you think about it deeply, this attitude of service is really the best way to maximize value for crypto-finance technology. In order to receive, we must first give.

One of the benefits of being the oldest “Bitcoin 2.0” project is that we get to use our foundation of highly secure atomic transactions to then place some of the amazing work in smart contracts and distributed IT on that foundation. Eris Industries recently released their ErisDB and I really like it. It plugs into Tendermint’s blockchain consensus protocol to roll an insta-chain based on what could be described as proof-of-stake taken to logical maturity with a bonding requirement for transaction noding, what I call proof-of-bond. Tendermint allows any amount of chains with a minimum of 4 bonded verification parties to achieve Byzantine Fault Tolerance. ErisDB utilizes Docker to distribute application-logic code that is able to define the permissions of writing to your Tendermint blockchain du jour. Then it allows you to plug in a smart contract based in Solidity (Ethereum’s baby, since adopted by Counterparty, and then Eris, and now us). So now you can hardcode these logics based on blockchain events to give permissions to write to your Tendermint blockchain. 

Why am I shilling so hard for “competing” projects? Because this isn’t a Highschool Football team, this is technology, sometimes tech can be complementary. I have been looking at using Omnicore RPCs in conjunction with Node.js apps hosted on a VPS, not too complex. Problem is, that’s no dApp, that’s just an app, but now a bunch of projects are making it possible to easily do p2p blockchain-ified meta-web of things and glaiven.

No ETH or XCP required to execute computer programs in a decentralized way.

Consider the possibilities for combining ErisDB and Omnicore. You’ve got your Bitcoin blockchain with the Omnilayer Dex for monetary settlement and hedging. You’ve got your ErisDB writing to a Tendermint Chain as sort of the console-event-log of your dApp as a blockchain. Got that? Then the two chains can reference each other.

Tendermint requires some kind of bonded collateral as the basis for qualifying a node to stake changes. Therefore if you want your app to support multi-party transactions, there’s a couple ways to get that collateral on your local chain. The first way is to reference a balance on the Bitcoin blockchain, ideally that balance is locked by assurance contract in bitcoind, or as we have built, a move to “Reserve” status in Omnicore, a title reserved for balance used in limit orders, pending confirmation transactions, and futures contract margin. It should be possible for a Tendermint chain to write an issuance of $1000 for instance, by referencing an Omni balance that has 300 OMNI hedged at around $3.33 each. The ErisDB logic for writing Tendermint transactions can be tied to the known parameters of the lock used in Omnilayer. For the sake of fairness, you can do locks directly in bitcoind and MirrorX is working on that.

Now that you’ve got your bonding stake, you can participate in verifying the Tendermint transactions executed in accordance with the ErisDB logic to read/write, and smart contracts that codify such logic in a functionally guaranteed way. However, ideally logics should be factored out as much as possible to the overall flow model of your multi-blockchain application. Don’t worry that this seems complex, it’s just the plumbing that makes a trustless autonomous application possible to spawn and operate in perpetuity independent of its publisher.

Let’s consider how you could do the converse, have something written in the Tendermint chain parsed by an Omnicore node with the right script settings switched on, and then summarily have a pre-signed transaction template executed when the pre-defined conditions are heard from the Tendermint chain. The contents of the Tmint chain could also parameterize the contingent transaction signature. That transaction could:

– Issue something new with parameters.

– Issue more of something existent.

– Redeem something.

– Buy or sell something.

– Pay a dividend.

– Use a reserved balance that is thusly earmarked in an Omnicore transaction to make a payment to somewhere or a set of somewheres.

– To the extent that ErisDB is recording an ID registry with associated Bitcoin addresses, pay specific someones.

This would be all the smart contract layer Omnicore needs to do everything anyone else can do. But you’re doing it with Omnilayer, so it will be fast to plug-in for you and rock solid money movement for your users. Think of it like a wrapper framework.  

Now, I like to ask myself often, “how could this awesome thing I want to build but everyone better at software engineering than me is busy not building, be built by me?”   

Which brings me to the prototype of the decentralized banking system and futures contract that I am building for the Citi Mobile Challenge using these technologies.

I’ve got a busy month ahead as we launch the Omni Dex. Maybe I will not get to the futures contract and lean on OkCoin instead. Maybe I will not get to the more full decentralization of the app-layer logic and lean on simple Node.js running on my own server. Maybe the prototype has a private key dangerously rubber-stamping in the bowels of an Omnicore node running on such a server, lacking the implementation of the wrapper proposed above. We’ll see, but here’s how I’d build the world’s first production decentralized futures contract:

1. Create pairs of smart properties as flexible issue, one is the short-side counterpart to the other. So for example I do two tx 54s that give me long and short OMNI/BTC contracts.
2. I create two templates of an issuance and redemption transaction and set up the robo-signage in Omnicore.
3. I use either a Omnicore-outside-blockchain wrapper (scaleable solution) or just Node logic running my side to parse for a Tendermint blockchain of a given signature.
4. Fire up a Docker instance running ErisDB with a few smart contracts for writing what transactions to broadcast for Omnicore in the Tendermint whose defining handle I have passed to my node.
5. The smart contract logic has to do with writing into the Tendermint chain every time there is a transaction for one or both of the two “contract” smart property tokens representing long and short positions. This records an index of trades in quantity at price P, time T*, with the nature of the trade (Both contracts opened, long opened/short closed, short opened/long closed, both contracts closed).
6. The Omnicore uses the nature of the trade to write “grant” or “revoke” N contracts to the balances in question, based on a netting logic. The only thing that must be added to Omnicore then is, at a minimum, an integer parameter for a smart property that is 0 OMNI by default and asks how much OMNI does this smart property lock in Reserve balance per unit of the smart property. An optional parameter to specify another collateral type is viable, e.g. “USDT” for Tether-dollar collateralized contracts.
7. The confirmed changes in balance record another index entry on Tendermint chain indicating the trade was not spoofed.
8. Come a certain block height on the Bitcoin chain, a settlement algorithm works at the ErisDB logic level, parsing the Tendermint Index and triggering settlement events when it does. The ultimate settlement event goes through the chain, does the formula against the prices, nets everything, and posts the settlement roster on the Tmint chain.
9. Omnicore has a batch simple-send filled in per the parse of the other chain’s settlement block.

That wasn’t even 10 steps.

*(Tendermint goes down to very short timescales, so a contract with enough leverage for reserving Omnilayer balances can potentially be high-frequency traded, just not ultra because the Omni collateral needs some confirmations to settle. This is the role I originally envisioned for Factom.)  
I won’t bore you with enumerating the rest of the dbanking function built off of the futures contracts, but it seems likely to be workable in this architecture.