Omni in the Alps

Community Members,

I’m happy to report that I’m back from representing the Omni community at the Paris Bitcoin conference.

While over in Europe I hopped onto a train eastward and made my way to the land of Zug. For those unfamiliar Zug is a Canton and city in Switzerland just about 20 minutes south (by train) of Zurich the financial hub of the country.


My purpose there was to open a Omni Foundation office in Europe and also incorporate the new Omni Foundation entity in one of the world’s most crypto friendly places. In fact the Omni Foundation is using the same law firm and this is the same jurisdiction that Ethereum, Monetas, Hermes and many other blockchain related projects have chosen as their home.

By choosing the same location we gain a great deal of network effect benefits. Chief among these benefits is that these fellow projects have smoothed the way, by educating local counsel, local government, about the opportunities of the blockchain technology world. As a result the cost and time required to properly incorporate  and comply with local legal and regulatory hurtles is much reduced.

This is a big step in the “The Great Transition” I described in my previous post about moving from the old MSC Foundation to the new community / member driven Omni Foundation.

In the coming week you will notice more and more of the websites, social channels, Github repositories for the community switching over to the new Omni name and terminology. Omni Protocol, Omni Core, Omni Wallet, and Omni Foundation. In addition we will be opening the membership application to the Omni Foundation at the same time we launch the new website.

Thanks for being involved in this effort to extend the blockchain in a whole world of new ways.

Best Regards,

David A. Johnston

Omni Foundation

Omni in the Alps

The Great Transition


Many of you (including myself) during the crowdsale last August endowed the MSC Foundation with the support needed to build out the open source features of the MSC Protocol. We have come a long way since then, seeing token creation, distributed crowdsales, decentralized exchange and many amazing projects become reality on top of the protocol we envisioned together last year.

Today though, I’m here to tell you of a great transition that is coming.

Many in the community are asking: What will happen when the funds originally contributed to develop the MSC protocol are all spent? Its an important question and rather than leave people guessing, here I will outline the plan moving forward.

A Community Driven Model

The crowdsale was a great way to spark off development and get the original vision of the protocol implemented and operational. However, now that there are many projects operational on top of the protocol, it is that community which should be the one taking the lead.

The best way to accomplish this is through a model very similar to the Bitcoin Foundation, where support is gathered from those projects and community members using the protocol in their technology stacks. While this model is imperfect, it remains the best we have available for aligning the support of those using the protocol and those working to develop it.

Already some of the largest projects in our MSC eco-system have stepped up to say they want to sponsor the core developers in their work, by becoming members of a community driven Foundation.  These community sponsorships will make it possible for the core developers of Omni Wallet and the Omni Core implementations to continue and expand their work on these open source projects.

New Entity New Branding – From Master to Omni

In order to fully embrace this vision of a community driven model, there has been a planned election of new board members for the MSC Foundation. However, I believe that an even further step is required. An entirely new entity. One that reflects the international nature of many of the projects building on top of the protocol. Along with this new entity comes the opportunity to move beyond the initial branding of Mastercoin / Master Protocol to a new brand that reflects the broad and inclusive goals of the new community driven Foundation. I propose that this new Foundation adopt the Omni brand. A new Omni Foundation.

Already users are associating with the Omni Wallet as there primary interface to all of their digital tokens. Lets extend that to an Omni Core, Omni Protocol, so on and so forth. Of course the ownership of the tokens (previously called MSC) will remain the same, and the objective of building great open source software on top of the existing protocol will continue.

Its worth noting this transition will take time. The websites will be updated, the international entity has to be formed, the sponsorships and new community members formalized. My expectation is this transformation will take the rest of 2014.

My goal is to launch January 1st 2015 with a new entity and a clear path forward for the community. That way there is a smooth transition from the existing Foundation to the new Omni Foundation.

Next Steps

I’ll be making more posts in the near future about the sponsors of the new Omni Foundation, filling in details and answering community questions on a Reddit AMA.

However this direction should give the community, the confidence they need to know, there is long and sustainable road ahead for them to build amazing project on.

Thanks for being part of this community, which at its heart is moving such important decentralized technology forward.

Best Regards,

David A. Johnston

Chairman of the MSC Foundation Board of Directors

The Great Transition

Conferences, Notes from the Road & Important Projects In The Works


Its been a whirl wind tour of the globe the last four weeks as I have had the honor of representing the MSC Foundation at Bitcoin conferences in:

Isle of Man: Speech on the Future of Bitcoin and Beyond (see slides here: )

davidjohnston Isle of man

Shanghai: Fellow Blockchain Nerds Getting Dumplings Downtown

Bitcoin Nerds in Shanghai

London: Right after presenting bitcoin as a way to marry the programmable web with programmable money.


Vegas: Right after presenting on the mining panel and discussing a future where protocols such as Master Protocol support the development of bitcoin ecosystem and provide other revenue sources for miners.


Having literally circled the earth twice in the last few weeks its nice to be home in Austin for a day or two.

Next Stop Israel, Drop Me A Line:

My next stop is Tel Aviv this Sunday and Monday (October 19th and 20th) if you are involved in the MSC community in Israel and want to connect while I’m in Israel just email me:

MSC funders, not to worry I’m as frugal as they come and with a combination of conferences paying for my flights when I’m speaking (which is every conference I attend) and accommodations at AirBnB ($35 per night in Vegas) its been minimal cost to the Foundation to be represented at these Bitcoin events, where the community all rallies together.

I believe all this travel has benefited the Foundation as it presented opportunities to meet in person with the projects building on top of the MSC Protocol, spread the word about the platform’s new capabilities, and recruit more developers and sponsors for the Foundation and its work going forward.

Notes from the Road + Important Projects Emerging:

Its encouraging to meet in person the founders behind all the amazing projects that are being built in the MSC community, allow me to take a moment to highlight a few of the most important projects coming out in the near future:

The project (formally Real Coin) to convert fiat USD into digital tokens (Tether) on top of the blockchain, exchangeable for BTC or any other digital token. When this launches, it will open up a broad new channel for users to easily convert their money from the legacy financial system into the new digital blockchain based economy.

The Merchant Coin project will equip bitcoin advocates with the tools to sign up merchants to accept bitcoins at their business and they will be issuing their tokens on top of the MSC protocol. The goal here being to super charge the number of merchants accepting bitcoins by rewarding advocates directly for their work to sign up merchants.

The Factom project is growing quickly and I certainly want the MSC community to be at the heart of their mission to extend the scalability of blockchains, by solving the bloat issue, allow for instant confirmations, and reduce transaction costs. All of which benefits Omni Wallet and all the other projects integrating with MasterCore and the capabilities of the MSC protocol. Factom will be issuing its tokens on top of the MSC protocol and the MSC core developers are examining ways to leverage the Factom project to improve the speed and performance of MSC transactions.

Thanks to the MasterCore and Omni Wallet teams for pushing out all the new features that are making these projects possible.

I look forward to seeing many of you in person at the next conference.

Best Regards,

David A. Johnston

Chairman of the MSC Foundation Board of Directors

Conferences, Notes from the Road & Important Projects In The Works

Utility is the Mother of Liquidity

Good Afternoon Masterminds,

Recently a member of the MSC Reddit community (yandi23) asked me to address this question: “When can you make a post on the liquidity of Mastercoin?”

Thanks for the question yandi23. I’ve been working up plans on how the community can build up the liquidity of MSC and so your question is well timed and I work to address it in detail below in this post.

Utility is what gives a token organic demand, which in turn drives increased value and liquidity in a market. The first feature creating direct utility for the MSC token is the Meta Decentralized Exchange (Meta DEx). As more tokens are listed on the Master Protocol and MSC is required for the common trading pair on the Meta DEx, organic demand for MSC will build and the market cap and liquidity will be a reflection of the level of this organic demand. Here is the link to the OmniWallet feedback Google Doc if you want to add your suggestions or report bugs to enhance the utility of the DEx and soon the Meta DEx.

Happy testing : )

Context and History:
Lets start by examining the past. In the beginning, at the founding of the Bitcoin network, the bitcoin tokens had virtually no utility and thus no demand for the use of its token and as it logically follows, no liquidity in the market.

As more users acquired bitcoins and began trading them among themselves, eventually offering to purchase goods and services with their bitcoins, the utility of the bitcoin token began to materialize as a payment network. It took several years before the utility of bitcoin grew enough for a meaningful market price for the tokens to emerge and even then the small market cap and liquidity of the Bitcoin network really limited the use of the bitcoin token to fairly small purchases of real world or digital goods.

As user growth continued an organic process of building the market cap and liquidity of bitcoin emerged and resulted in many exchanges actively listing it for trade, many professional traders coming into the market, a large ecosystem of merchants accepting it, and users holding bitcoin over the long term as a store of value.

The Path for MSC:
In many ways the Master Protocol has been on a similar journey the past year. Since the crowdsale last August the MSC community has been working to build the reference client (MasterCore) and users have begun issuing tokens on the platform as of April 22nd 2014 (MaidSafe, API Network, soon Merchant Coin, Real Coin and many others).

Since the launch of the Decentralized Exchange (DEx) feature, users have been able to trade MSC and BTC with zero third party exchange risk and extremely low fees based on bitcoin dust level transactions.

The next step is to extend the Meta DEx feature to support all user issued tokens on the MSC protocol to trade against MSC as a common trading pair. Finally the world will be free of any future “Gox” type event because this feature will permanently remove third parties from the trading equation and bring a full P2P architecture into reality.

The launch of the Meta Dex is the first time that anyone has an organic reason to purchase MSC (to use as the common trading pair) and thus the first direct utility the token has provided in the system. Before that time users held MSC because they believed that the MSC system would develop utility as some point in the future.

It was expected at first that every feature of the protocol (for example the creation of tokens) would require some amount of MSC, however it was decided in May 2014 that in order to avoid creating unneeded friction in the system, only those features requiring MSC for solid technical reasons would require their use. The Meta DEx is the first of the features that meets this standard.

The Math About The Importance of Liquidity:
So the reason that liquidity is key for the Meta DEx is that while the fees are limited to the dust level transactions required to run the system, if the “spread” between buys and sells are greater on the Meta DEx than a centralized exchange, then that adds a cost to the user of the Meta DEx. As liquidity increases the “spread” becomes more narrow and it becomes more efficient for the user. In our case the key to liquidity is the depth of offers on the order book.

Lets use some math to give an example. User Bob wants to purchase 1 BTC worth of XAP on the Meta DEx. First he has to grab some MSC on the DEx to buy the XAP with (since MSC is the common trading pair). If there are 10 BTC worth of MSC on the order book and the sell offers are evenly spread up the price curve, then by purchasing 1 BTC worth of MSC, Bob will have moved the price of MSC by 10%. This is a substantial move and has in essence cost Bob an extra 10% on the price of his trade.

If the order book has 100 BTC worth of MSC sell offers, then Bob’s purchase would only move the market price 1%.
If the order book has 1,000 BTC worth of MSC sell offers, then Bob’s purchase would only move the market price 0.1%

So with an order book 1,000 BTC deep, a user can easily make trades in the 1 to 10 BTC range and move the market less than 1%. Thus at this order book depth the Meta DEx becomes competitive with a centralized exchange on direct and indirect costs of conducting a trade.

At the time of writing (2014/09/11) the depth of the BTC / MSC order book on the DEx is 163 BTC between the 200 to 46 mBTC price ranges. This is an important number to watch and will need to increase toward the 1,000 BTC range for traders doing exchanges larger than 1 BTC to be attracted to using the DEx and Meta DEx.

Action Items To Improve Liquidity / Order Book Depth: 
1. Educate traders and market makers on how to use the Omni Wallet Decentralized Exchange.

2. Build the API and RPC calls for MasterCore / OmniWallet according to the best practices of established exchanges for pro users to access.

3. Make the Omni Wallet API pull-able for third parties, such as to list all volume and price on the decentralized exchange.

4. Community testing of the OmniWallet interface and reporting suggestions to the OmniWallet team to improve the trading experience is key. Here is the link to the Google Doc for feedback:

I believe we can address these fundamental drivers of order book depth and liquidity in the coming weeks and months. This is a major priority for me as the Chairman of the Foundation and generally for the DEx and Meta DEx features of the OmniWallet and MasterCore to be successful in the market.

I’ve been spending a lot of hours testing the OmniWallet and DEx features the past few weeks.

I hope you will join me in this testing and most importantly report your feedback to the devs via the Google Doc.

Best Regards,

David A. Johnston
Chairman of the Board MSC Foundation

David (at)

Utility is the Mother of Liquidity

Reforms to the MSC Foundation Bounty System + Lessons Learned


The past year we have learned a lot of lessons on how to develop a decentralized protocol, how to engage core developers and how to offer bounties to encourage development of an open source project. Below I’ve outlined those lessons so that the whole decentralized community can benefit from them and that the MSC community specifically knows the direction the Foundation is headed with its bounty system.

TL;DR Lessons:

1. Empower the developers most heavily involved in the development of the platform.

2. Sponsor developers most involved, to be able to work full time on the clients.

3. Organize developers into teams with daily standup meetings, so that they are in constant communication.

4. Designate a single reference implementation for each use case (eg. designating “MasterCore” as the downloadable client and “OmniWallet” as the web wallet) and focus a single team dedicated to each implementation.

5. Set up specific bounties, narrowly defined, and with short timelines of two weeks or less.

6. Have those most involved in development define the specific bounties and judge their value.

MSC History:
At first, the Foundation started with a very loose approach of offering very generalized bounties for what ever developers came up with when it came to creating wallets, clients and building features listed in the protocol.

Over time it became clear that those contributing the most useful code were those focusing their time and efforts on the MSC platform and fully aware of the context and progress of development. The Foundation began sponsoring full time developers as part of its “Role Based Bounty” program. This program expanded over time from a few developers to its current size of 12 full time developers being sponsored.

At the same time generalized bounties continued to allow independent developers to contribute code and be rewarded at the end of each month, based on rankings from the other developers.

However this process has become tougher over time as the teams grew and developers had less visibility into projects outside of their team and even less insight into independent efforts. Also, without clearly defined bounties, the independent efforts of developers were uncoordinated, fragmented and difficult to integrate into the features of the clients.

Bounties Moving Forward:

1. The Foundation will no longer be engaging developers on a part time basis. Engaging team members full time has proven to be much more effective, as this enabled team members to be fully in sync, and drive the pace of feature development forward.

2. Starting September 1st, the Foundation will be phasing out generalized bounties and instead only listing specified, narrowly defined, and short term bounties, which will be judged by the developers most involved in that area of development. These bounties will be posted and shared with the community and serve as the open door, for new developers to prove their skills and the community to provide input on the direction of the MSC platform.

I’m confident in our team and I believe these reforms to the MSC Foundation’s bounty system, will empower their development efforts going forward.

Best Regards,

David A. Johnston

Chairman of the Board of the MSC Foundation

David (at)


Reforms to the MSC Foundation Bounty System + Lessons Learned

Progress Update: Road Map, Communications, and Partners


In my first post on the 5th of August when I took over the role of Chairman, I set out three immediate priorities for the MSC Foundation.

1. Establish a Clear Road Map:

2. Open Communications:

3. Streamlining of spending and partnerships.

On each of these topics I’d like to offer a quick update and invite the community to continue actively engaging as they have done so the last few weeks on how to improve the MSC Protocol, the Foundation, our community, and the open source software.

Road Map:

Firstly on the Road Map, I want to thank everyone for the helpful comments and input on the direction of the Foundation and its priorities. You can find the most updated version of the Foundation’s Road Map at:

As for the milestones for the August and September period I’m happy to report the team has completed 10 out of the 17 items on the list and the others are in progress. Completed items include; partnering with industry expert on best practices for order book of decentralized exchange, engaging our best developers and increasing the bandwidth of the MasterCore team with more testers, announcing points of contact for MasterCore, OmniWallet, and so forth.

Open Communication:

Secondly, on “Open Communications” in addition to making regular posts on the blog, being available on Reddit, and the forums, Shannon Code is working to weave together all the different channels of the MSC community so that users can see updates on progress, developer discussion, and so forth easily without having to log into a proprietary program such as Skype and find a invite based chat room.

Shannon will be posting soon about his efforts on this front to open up all of the communications.

Streamlining Spending and Partnering:

Thirdly, on Spending I’ve been reaching out to the community to get input on how to improve the Role Based Bounty and general bounty system that has been in place since the beginning of the Foundation’s work. One point of consensus is to move from a generalized bounty system which is currently paid on a monthly basis, to that of a deliverable based bounty system, where the milestones are clearly defined, prioritized, and set at the beginning of each month and paid out at the end of each month. This way the priorities of the community for the development of the MSC open source software clients will come first in focusing contributing developers time and energy.

As for “Partnering”, serious new projects with the potential of engaging new demographics and users have announced they will be developing on top of the MSC platform including the recent post about the Merchant Coin project.


All in all, I believe we have the right team members working with the Foundation to encourage the development of the MSC protocol and make its open source clients the standard for reliability for major projects who have large user bases and will transact significant value on top of the protocol. I’ll continue doing everything in my power to encourage the continued development of an engaged and authentic community of users and developers extending the capabilities of the bitcoin blockchain to include smart property, decentralized exchange and much more.


David A. Johnston

Chairman of the MSC Board

David (at)

Progress Update: Road Map, Communications, and Partners

MSC Open Communications Update – Next Steps

Thanks to everyone who participated in kicking off our open communications for the MSC Foundation with your blog posts, AMAs, questions and comments the last week.
The energy level in the community has visibly increased with a 132 comments on 9 posts that were made to One of the first outcomes has been new developers coming in to help with OmniWallet, who saw the AMA’s and want to get involved in the project.
Going forward the plan is to keep up this weekly posting of blogs and Reddit threads, which Shannon Code will cross post to all of the other MSC channels (Twitter, Facebook, IRC, Skype Chat, MSC and BTC forums, etc)
To keep things on a consistent and daily basis, 7 of us from the MSC Foundation will have 1 day each week we will posting to the blog and Reddit thread that day on different topics. Including new projects launching on the Master Protocol, updates on MasterCore and Omni Wallet, bounties available for the community, guest posts by technical thought leaders in the crypto ecosystem, and a lot more.
Communicating openly with the community about our progress, challenges, ideas, and so forth is the primary way for the MSC community to grow and empower everyone to add their value to this great endeavor to extend blockchain technology and decentralize the corrupt financial institutions of our day.

I’m excited about where we are headed. Lets pull together as a community and make it happen.

As my old friend Christopher Orem used to say, Go Team!

Best Regards,

David A. Johnston

Chairman of the MSC Foundation Board
David (at)
MSC Open Communications Update – Next Steps

Notary Chains and Scaling MSC Transactions

Guest Post by Paul Snow Lead Developer and Founder |


NotaryChains is a deceptively simple yet critical technology for leveraging the power of the Bitcoin block chain.  The goal of the project is to build a protocol stack, beginning with a proof of existence layer, and ending with a layer providing proof of process.  All of which is secured with the Bitcoin block chain, without adding a significant number of transactions to the Bitcoin block chain, nor requiring any changes to the Bitcoin protocol.

Proof of Existence

The lowest layer in the NotaryChains protocol stack implements Proof of Existence.  This is done by collecting the unique fingerprints (hashes) of digital artifacts (financial transactions, documents, pictures, media files, etc.) into what we refer to as a notary block.  The unique fingerprint (hash) of the notary block is then placed into the Bitcoin block chain.  In this way, an unlimited number of digital artifacts can be secured by a single entry in the Bitcoin block chain.

Each entry submitted by a user to the Proof of Existence layer is time stamped, and added in order of receipt to the current notary block.  An intermediate hash can be provided to the user at submission as proof of its position in the current notary block.  Periodically the notary block is completed, and sealed by adding its hash to the Bitcoin block chain.  

The hash in the Bitcoin block chain provides a rough time stamp of the entire notary block, and the time stamps internal to the notary block provide a finer time stamp of each entry.  All the notary blocks are shared to all interested parties using one or more platforms for sharing data.  Initially we will share them over BitTorrent, but in the future we may share over the SAFE network, Storej, or other technologies.

Proof of Existence only requires the document, the appropriate notary block, and the Bitcoin block chain to prove a document’s existence at a point in time.  Proof of Existence does not require the continued running of NotaryChains, nor can anyone alter the notary blocks after the fact to remove or modify an entry without breaking the hashes stored in the Bitcoin block chain.

Entries and Meta Data

The next layer in the NotaryChains protocol is to add information about documents, and perhaps link documents with other documents within an entry.  An entry is a structured data representation (such as XML or JSON).  Such a structure can include a document’s URL, its hash, perhaps a database key, or any other information useful for tracking with the document.  It can even include multiple document hashes and information, tying documents together.  Notary chains hashes the entry, and records the hash in the current notary block (picking up a time stamp and type).

Again, all that is required for proof of an entry will be the documents referenced, the entry, the notary block, and the Bitcoin block chain.  

Notary Chains: Chains of Entries

Finally, entries can be managed in chains.  Each chain gets its own type, and the first entry represents the genesis entry for the chain.  The first entry defines the rules by which the chain is audited.  Any attempt to add an entry that does not conform to the rules of the chain is disregarded.  The first entry will generally provide an link to the documentation for the rules for the notary chain.  This should include a text description as well as a reference application that performs an audit of the chain.  Constructed in this way, any entry must past the audit in order to be a valid entry in the chain.

NotaryChains will provide support for some basic types.  These types will likely include:

  • Logs — periodic logging of data streams, such as security cameras, building access, computer access, etc.  
  • Accounts — documents the use of a resource.  Can allow for limited access (like limited numbers of views of a movie, limited visits to a gym, etc.).  Allows for a business to sell so many units to a user, and allows a user to document their use of those units via signed access.
  • Coins — Provides for the trading of tokens.  Configuration choices will include specifying conditions for the generation of coins, arbitrary creation of coins, authority to reverse transactions or not, and other coin features. 
  • Versions — Allows the updating of software versions.  Binary and Source can signed and the signatures placed in a notary chain.  updates can be validated by signatures and by being part of a version chain.  Particularly useful to manage generic notary chain types, so that bugs and security issues can be addressed in a way that can be validated against the appropriate notary chain.

Federated Servers

NotaryChains will use a set of independently managed and controlled federated servers.  Each of these servers will be responsible for performing real time audits of the other servers.  If a server fails a dead man switch test, another server of the federated set will pick up responsibility for processing submissions to that server.  

This architecture allows for much more rapid clearing of submissions.  Furthermore, the centralized processing of transactions insures no double spends are possible, as the server handling the transaction is responsible for managing race conditions on a first come first serve basis.  Other features of the protocol (not discussed here) insure proper ordering of submissions even if they do not arrive at the server in order. Notary Chains also allows the audit particular notary chains with partial information (not all notary blocks, not all entries are required for a cryptographically secure audit).

The MSC Protocol and NotaryChains

NotaryChains is using the MSC Platform to issue the digital token associated with the NotaryChains protocol.  Upon completing all the layers, NotaryChain tokens will be converted to native coins running on NotaryChains.  In fact, we may even be able to help improve the speed and reduce the cost of MSC transaction by running synced MasterCore nodes on the NotaryChains platform.

The advantages to running MasterCore on NotaryCains include:

  • The NotaryChains system of record secured by the Bitcoin block chain  Because the notary blocks are hashed into the Bitcoin block chain, they are just as secure as Bitcoin transactions themselves. 
  • Reduced load on the Bitcoin block chain  Unlimited MSC transactions can be performed on NotaryChains for each entry NotaryChains places in the block chain. 
  • Fast transaction processing  Centralized servers allow for millisecond processing of MSC transactions that currently take quite a long time on the Bitcoin block chain.  
  • Secure transactions  All transactions of MSC will require cryptographic signatures.  This means even if the centralized servers wanted to misdirect MSC transactions, they could not.  They will not have the private keys to do so.
  • Simplified protocols  The flexible entry format means that MSC transactions (as well as many other applications) can clearly add all the data and entries required to support the Master protocol.  NotaryChains allows the flexibility to construct transactions exactly as required by the application rather than force them into an awkward encoding scheme.

We are looking forward to working with MSC core developers and delivering the NotaryChain protocol to the Bitcoin ecosystem.

To find more information see our website, whitepaper, and GitHub at these links:

I look forward to community feedback on this topic.
Paul Snow
Lead Developer and Founder |
Notary Chains and Scaling MSC Transactions

Opening Up Communication and AMA’s Starting Today

Dear Masterminds,

As promised here are some additional details on the plan to Open up Communications in the MSC community.

Here is the contact info for all the points of contact on Omni Wallet, MasterCore, Bus Dev, and Developers. Core contributors to the code + Foundation points of contact will be holding regular AMA’s and posting to the community every week. The communications channels for MSC are going to be streamlined and cross posted.

Announcement of Point of Contacts:
Wondering who you should talk with about a issuing a digital token, or a new features of the Master Protocol?

Refer to this list for the best point of contact.

Point of contact for companies and organizations who want to issue a token (Judith Jakubovics) Judith (-at-) and on Skype: Judith.Jakubovics

Point of contact for developers who want to develop a project on top of the MSC Protocol (Shannon Code) Shannon (-at-) and on Skype: genecyber

Point of contact for developers that want to work with the Omni Wallet (Adam Chamely) Adam (-at-) and on Skype: shmali81

Point of contact for developers that want to integrate MasterCore (Faiz Khan) Faiz (-at-) and on Skype: xgrodx

Point of contact for founders working on decentralized applications that want input on their whitepapers (Sam Yilmaz): Sam (-at-) and on Skype: mrcemonatyilmaz
Each of the points of contact will be holding regular AMA’s with the community on topics they want to discuss. This will begin Thursday with Craig (2014/08/07), Friday with Shannon (2014/08/08), next Monday with Judith (2014/08/11), next Tuesday with Adam (2014/08/12), and next Wednesday with Sam (2014/08/13). Starting with me today (2014/08/06).

Streamlining Community Communication:
There is a substantial amount of chatting, discussing, debating and otherwise talking about Omni Wallet, MasterCore and the Protocol going on, however its spread over many different channels, here are a few ideas to bring together those different threads of discussion.

Removing the Trello board and instead posting all of the bounties and opportunities directly to the MSC Forums.

Cross post content from the MSC forums to the BTC forums, Twitter, Facebook, Skype, and IRC.

Post once each day on the MSC Sub Reddit from a different point person on the project on what’s going on:

Channels for following the Development Process and Contributing:
Dev (-at-) is an open thread for any development related chatter and it auto posts to the MSC forums developer thread.

There are three primary Skype groups where the devs tell to chat about MasterCore, OmniWallet, and General Discussion. Email Shannon (-at-) with your Skype ID for an invite.

Github is the center for comments, pull requests, and debate on the actual code see links below to get involved.


Omni Wallet:

Master Protocol Spec:


MSC Vennd:

Lastly for those that love IRC here are the channels for OmniWallet, MasterCore and the MSC Protocol.

General News Channels for MSC Development
There are a lot of places to keep track of MSC development. Pick your favorite and follow what the community is working on and developing.



Google +:



Going forward I expect the core contributors to the MSC code and Foundation to engage with the broader community on a regular weekly basis. I’ll be pushing to publish more and more raw debate, meeting notes, and developer resources directly to the community on all of our channels.

If you have more ideas to improve and open communications up, I want to hear them : ) so feel free to engage on these threads or contact me directly.

Best Regards,

David A. Johnston
Chairman of the Mastercoin Foundation
David (-at-)
Opening Up Communication and AMA’s Starting Today