Monax’s new social contracting platform: knocking a ‘blockchain’ software product out of the park

So the startup I co-founded and former employer, Monax, released its new product today.  My good friend and spiritual advisor Tim Swanson (@ofnumbers) asked me to write a review of the product to explain it to him exactly fifty-three minutes ago.

This is that explanation.

Social lawyering

Monax has always been early. As a consequence, the company used to struggle getting people to understand what the hell we were talking about. Casey (one of my co-founders) and I had a lot of fights about how to express these ideas in their early phases. First, it was permissioned chains; we were, to my knowledge, the first permissioned blockchain startup. Not among the first, not first in England, but the first, period. That took awhile (two years) for people to wrap their heads around. At the same time, we were among the first people to try to tell people what a “smart contract” was and how these critters could actually run a business process. That was hard for people to understand too (three years).

Monax no longer has this problem.

Monax has built a web application that allows lawyers to build agreements, manage their lifecycle and execution, and assemble complex packages of agreements together in complex workflows – i.e., all of transactional lawyering – in a fast and straightforward fashion that takes a lot of the headache out of managing contracts and keeping track of where they are.

Monax in one line

Automatic, social lawyering or “social contracting,” with apologies to Rousseau.

Monax in three bullet points

There are three things you can (currently) do with Monax:

  • manage the lifecycle of a templated agreement and associated contractual process;
  • build agreements that have a workflow process associated with them which the Monax platform can then carry out; and
  • share your work, and see the work others have shared.

Put these together and you have the future of law practice.

Monax in a few paragraphs for non-lawyers

From the perspective of the non-lawyer that means it fulfills several functions. The most basic function Monax performs is roughly an equivalent to docusign. But executing an agreement is but one part of the lifecycle of an agreement, so to say it’s a “slicker docusign” wouldn’t be quite correct. Monax also mixes in some CRM, workflow modelling, and even a social component where you can network with other users and share templates with a wider community of people. 

If you’re drowning in contracts, this will probably help you manage them.

Monax is less “Docusign with a social network” and more “LinkedIn where people actually get shit done.” Or, really, “What would happen if StackOverflow, Practical Law Connect, LinkedIn and DocuSign had a grand-child who decided to get a J.D.”

I should preface the rest of this post by freely admitting that I’m an idiot with a computer. If someone held a gun to my head and ordered me to code “Hello, World!” in Python I would be out of luck. I once had my GitHub privileges revoked at Monax because I inadvertently deleted our website. If I can do this, anyone can.

So let’s explore what you can actually do with this thing.

1) Executing an agreement

Docusign but better.

The process of getting an agreement from template to signed agreement is a little funky. Monax makes you first assemble a “package” of documents from a library of templates. Then once you “activate” the package, i.e. say that the docs are good to go, Monax prompts you to make a “collection” of documents which then draws from the “package” the contracts that are relevant for what you’re trying to do.

So e.g. you could have a “corporate” package with a narrower set of “fund incorporation” documents you draw from it, or really whatever combination you think is appropriate. You just click on “templates” from your home page, click “add to package,” and once added to a “package,” you can then drop the agreement into a “collection.”

The naming conventions are a little funky, but once you go through it once it makes sense. I’m advised the company is working on this bit of the process to make it clearer.


Once you’re done with that, hey presto, you have an agreement. And you can proceed to go and get it executed and agreed.

Note, the social component of this means you get your own, unique, public user handle. You don’t just log in with an email.


This agreement template which another user uploaded into the system has some fields. I populate the fields.


When I’m done drafting the agreement, I decide to clog up my old business partner’s inbox and I send him the agreement for execution. He did not prompt me to do this and this was not planned. I just did it for the lulz.

Note, one of the fields is the end date of the confidentiality period – so I can keep track, in my home screen, of how long the NDA I’m proposing to enter into will remain in force. Merging calendaring and document execution is an absolutely inspired move, since a lot of companies don’t keep track of this data point. Monax bakes it in to the agreement in machine-readable form and the platform handles the rest.


And boom, we’re done. I send Casey the agreement and he executes it.

2.jpegNot only that, as this is a social platform, Casey’s in the system already so I can track my contract state with him. If we did a lot of deals together, such as might be the case if we were banks (spoiler: we’re not) or massive companies like Deloitte, this would be a great way to track and visualize SOWs, side letters and the like and get a heads-up view as to what needs to happen when. It will be particularly good at getting people who aren’t neck-deep in the business quickly up to speed and to run analytics (as all of the contract data is exportable into CSV files).


Signing is easy and we both do it from our Monax social accounts.


And when we’re done, we’ve got a contract that either of us can inspect at any time, which has been cryptographically proven in a blockchain, rather than e.g. DocuSign which can be signed as long as you have a link from an e-mail. At least here we know that some login credentials were presented, and have both server logs and the chain itself to refer back to in the event of a dispute.

Both our meatspace signatures are considerably uglier than these

These aren’t classical signature blocks, either. This part of a schedule appended to the end of the agreement. Why, when digitally signing, do we need to scribble on a particular line, when the document itself, a blockchain address and a hash provides better evidence than wet ink ever could?

The signing function on its own is basically a slicker DocuSign with slightly better verification properties. Where it differs from DocuSign is (a) in how Monax adds workflows into the mix and (b) how it allows people to share those workflows and the associated contracts publicly.

Screen Shot 2019-10-02 at 1.05.22 AM
What kind of jerk picks “marmot” as his legal hacking handle?

This crowdsourced automation of legal process knowledge has the potential to (a) eliminate most of the process-based aspects of transactional work, (b) allow people to easily share process knowledge on how to perform particular transactions in particular jurisdictions, and (c) as a result, allow smaller teams of lawyers to perform more complex work that hitherto only larger firms with specialized process-based lawyers could perform.

2) Building a contract

I’m going to build a really basic contract: a retainer letter.

Retainer letters are super simple. They require two signatures, lawyer and client, and have a limited number of parameters. In my experience those negotiable parameters (or defined terms) are

  • Parties and their contact information
  • Date
  • Scope
  • Fees
  • Retainer
  • Personal note at the end.

Monax lets me upload a document and set the negotiable parameters. This requires a little more work up front, as it makes more sense to make the document standard form and then have a schedule attached with the defined terms (it is possible with Monax to generate a bespoke agreement where you edit in the document but not in the schedule, but as I’ve only played with it for a few hours I haven’t figured out how to do that just yet).

So below we can see a letter (excuse the drafting) and, on the right, basic information about it together with the parameters I will later set.


And here’s where you can set the (two) parameters I’ve decided to make for this agreement (I’m just testing the software out, so cut me some slack that I haven’t done this more fully). In this case I’m adding signatories to the document.

“Name” should really be “Defined Term” given the Master/Schedule format that the system seems to prefer for standard forms, but whatever, the system has been working for six hours. Who am I to complain.


The software also anticipates standard boilerplate. Going forward I can foresee that they will likely build out a list of drop-down options covering every possible permutation of governing law & jurisdiction, forum selection, notice, etc.

Screen Shot 2019-10-01 at 8.02.16 PM.png
For choice of law

There’s also a “governance” function, which I would actually call a “workflow” function.

Screen Shot 2019-10-01 at 8.02.24 PM.png

In every transaction there is an order to the way things must be done. The process of carrying out the transaction and mastery of each step is a huge part of every attorney’s training, and explains a lot of the specialization we currently see in BigLaw, for example. Human beings are only so capable; when deals are extremely complicated, and the margin for error is small, we entrust complicated transactions to people who have done them before, not merely because they know what the issues are, but also because they’re not going to fuck up the deal by missing some essential step.

But we could entrust the process-driven aspects of these transactions to a machine.

This “governance” tab is a much bigger deal than it looks. It tells the user that before proceeding with an agreement, it may be that there’s another step they need to perform first. For example, you don’t sign a statement of work before you execute a master services agreement, and you don’t execute a bank loan before you’ve executed your security documents. Doing things in the wrong order can have catastrophic consequences for your client.

Enter the Monax workflow modeller:

Screen Shot 2019-10-02 at 12.21.23 AM.png

Monax gives us a machine-readable workflow modeller which can be paired up with machine readable Monax contract or series of contracts. The “governance” box, far from being just a thing you tick off to make sure you can sign a contract, is in fact an event controller which can be linked up to a contractual workflow which can be as complicated as Monax’s workflow engine allows.

This is what really differentiates Monax from everything else out there.

DocuSign is principally a platform for closing simple agreements like NDAs. It’s for guys who work in sales.

Monax is a platform for lawyers, by lawyers, which will connect lawyers and clients, and the lawyers representing commercial counterparties. And lawyers and anyone else who uses the platform. A lawyer could build the lifecycle of virtually any transaction, from a simple sale of goods to a 40-year securitization, on this platform, share it widely (what better content marketing is there? It’s why I have a blog), and allow, after getting appropriate waivers, other users of the Monax network to then carry out the transaction themselves, with all of the document management and process management being performed automatically in the background while the lawyers focus on negotiating the high level issues. A few added features and you could even use Monax to negotiate the docs. Smaller, nimbler firms mean lower overheads, which means lower fees, which might also mean fewer hours at the office and more time with your kids.

Simply brilliant. I didn’t get it when I first looked at this a few months back but I sure as hell get it now.

Back to the contract, though. So we have a contract, an engagement letter, which has a simple, one-stop workflow: sign it. So it’s time to populate the fields, put the agreement into agreed form and sign it.

First, populate the fields (just a test, so there aren’t many of them and they’re not too complicated)

Screen Shot 2019-10-01 at 8.13.06 PM.png

Then, create the agreement…

Screen Shot 2019-10-01 at 8.16.16 PM.png

Now, the agreement is generated (with my standard terms blacked out, because that feels a little personal)…

Screen Shot 2019-10-01 at 8.17.04 PM.png

…and then automated notifications go out to the parties instructing them to proceed with the next steps of the transaction, whatever those might be.

Screen Shot 2019-10-01 at 8.19.53 PM.png

In this case, my process was a simple one: sign the agreement and it becomes enforceable. But, as I alluded to above, what Monax has built can conceivably scale to any level of arbitrary procedural complexity. There’s simply no limit on how many contracts you can put together and cross reference in a machine-readable workflow.

I’ve worked on deals with thirty transaction documents and over six hundred conditions precedent docs. Legal workflow automation with no limits can gobble up processes like that.

3) Conclusions

This infinite extensibility, combined with the inherently social nature of the tool and the fact that anyone, anywhere can use the platform to collaborate and review other people’s workflows and agreements, tells me that this platform distinguishes itself from all the boring legal tech we encounter on a daily basis. The incentives are right. The efficiencies are right. Once you grok that document parameterization happens in a schedule and that there are no signature blocks, the interface is pretty intuitive and will undoubtedly become more so. The price is a little steep, but then I’m a little cheap, and for a few more features it’ll probably be right as well.

Monax lets non-programmer lawyers do machine readable stuff. If Monax isn’t “it” in terms of ushering in the digitization of law, something very much like Monax is exactly what “it” is going to look like.

Oh, and I almost forgot: there’s a blockchain in here. But it is barely visible. Monax built an absolutely killer application and buried the blockchain deep in the guts of the thing, where it hums along, barely visible, until it is needed to prove that everything happened in a particular way, at a particular time, in a particular order. Which, as a lawyer, I can attest is extremely important.

That ultimate kernel of verifiability permeates the application totally unnoticed. But that’s what makes it good enough to make it worth a law firm’s time to make the jump to new tech – the fact that we have a means of making legally relevant communications and everything is proven in a friendly UI as you go along will obviate the need for original signatures, transaction bibles, and potentially even e-mail (what I called “document tennis” in my “open document monkey” proposal in 2014) in transactional law. The lawyers can do the thinking while Monax handles the process.

This experience earned Monax one happy paid subscriber today.

(My username is “marmot,” by the way.)