I am in despair. Surely you know that feeling when you want to help a friend starting out in some pursuit, but in helping it comes to pass that their earlier decisions were greatly compromised. They’ve fallen into dangerous commitments beyond their control. You know that to assist them further entangles you in their mistakes and unbounded future repercussions.

You reason with them, they understand. You explore their motivations, they acknowledge where they were wrong. At best it can be put down to inexperience, forgivable, but you must make a decision. Do you leave them to the harsh teachings of experience or do you try and help them out of their sticky web?

Today, it came down to, how sticky the web and how venomous the spider?

I write Ethereum Smart Contracts, which are little programs that construct and account values. With 3 years experience there, I am not without a reputation though don’t promote myself for fear of excessive demand. I don’t even have a business card.

The most notorious class of smart contracts are called ICO’s. They are now legion. Who knows who wrote them, who’s behind them or whether the money raised will be used for the published intent. I’ve written a few, audited a few, and even bought tokens in a very few. But, for most of the ones I’ve seen, they lack the very property for which blockchain itself was invented, trustlessness.

Is it too much to expect any better at this early state of the technology? For millennia trade agreements have been scratched out on some medium in the hope that some other arbitrary or outright physical force can be called upon if the agreement is not honoured. Our very economies are genetically disposed to such things.

Now we have a most profound opportunity for automated reckoning of any such agreements to provide outcomes in the mutual interest or a graceful departure if things don’t work out. No force is necessary, no excessive time is wasted and short of a lost opportunity no one is left worse off.

Yet it is painfully obvious that a great deal of education is going to be required before people realise how simple and elegant Trustlessness can be.

My friend was solicited to write an ICO. This was their first customer and so was keen to impress. I was asked if I could audit the contract. I assure you they aren’t the first to mistake ‘audit’ with ‘please help us rewrite our dreadfully broken ICO because they launch tomorrow!’

Everything about the ICO was red-flagging, the website, the whitepaper, the lack of published team members, the ‘We’re not asking you to audit the “business model” just the code’.

Lesson 1: The business model must be explicit in the smart contract

They were approached by an intermediary, some opaque and insistent middleman between my friend and the actual client. A man apparently of formidable credentials in the incumbent systems of enforcement leaving my friend fearful of failing to deliver or pull out. If you do not know who you are dealing with off chain, you cannot trust them off chain. Decline to deal with such people.

Lesson 2: Disintermediate the intermediaries

They presented me the contract with confident words to the effect of “We just added to the Open Zeppelin token,” as if that was all that was required to pass an audit. I personally find the OZ library, with all it’s extraneous imports and unnecessarily granular interfaces a nightmare to read and audit. I’ve seen numerous inexperienced Solidity developers try to use it without understanding its model or even the model they are trying to use it for.

Lesson 3: Simple works, simplistic doesn’t but complexity kills. Flat code is readable code. Use as few imports as possible.

I wonder how many ICO’s just shuffle through the money to some anonymous address. Most of the ones I’ve seen do, including my friend’s. If I am given one to audit, I fail it outright.

An ICO is a debt to the community. You either provide a product or provide a refund. An ICO must commit to a minimum viable funding or accept the failure of not being ready for market.

Lesson 4: Escrow is only a few lines of code away.

The incumbent system of economic propaganda has the world worshipping the USD, willfully or otherwise. Let me not comment on how much blood continues to be spilt around the globe for the continued enforcement of that status, but personally, I have great issues with it. It is the very problem of fiat and central banks which blockchain seeks to solve, lets not give them precedence in our own domain. Technically they are simply incompatible in a contract.

The moment an ICO attempts to value against an off chain currency, the nightmare of exchange rate failure begins. There are still no viable, reliable oracles for trustless update of exchange calculations.

Lesson 5: Denominate your Ethereum ICO only in Ether

The vast proportion of people in blockchain now are newbies and it’s going to be like that for a very long time to come. Yet they come in all their excitement and trepidation, scared of being ripped off and so paradoxically throwing all their money, what ever its form, at anyone or anything that might trigger their ‘trust’ neurons. That is dangerous so providing them an actual trustless contract saves a lot of pain.

Lesson 6: Teach your community to use Exchanges, Shapeshift and MyEtherWallet (at least)

In another ICO I wrote, the team adopted my trustless approach but were then hobbled by the regulator who prevented them from exchanging received fiat to ether for the purpose of buying tokens by proxy. This ridiculous situation meant they had to run a parallel fund raising using the old ‘trust’ paradigm along side their trustless ICO and then manually account for and transfer tokens accordingly when the ICO finalized. Among the many issues that could have arisen in this double blind model, was if the ICO failed to reach minimum cap or was other wise aborted (yes I have an ‘abort()’ function in my ICO’s). The team would then have to manually process and refund all the fiat investors.

Lesson 7: Let the code prove to the regulator that it is safer than the regulations

That’ll do for now. I know it’s not a particularly structured article and doesn’t even really get into the principles of trustless design, but this is one of those, getting it off my chest kind of moments. There’s obviously tonnes more lessons to learn in order to teach, but let Trustless Principles be the prerequisite.