Smart Contracts… or Dumb Software

The role of smart contracts in blockchain technology is creating an emerging area of jurisprudence which largely overlaps with computer programming. However, one of the first comments I heard about smart contracts when I started working in the blockchain and crypto industry was that they are “neither smart, nor legal”. What does this paradox mean in practice?

First, smart contracts are not “smart”, because they still largely rely on human coders. While self-replicating and self-executing software programs exist, a smart contact contains human-defined parameters or conditions that will trigger the performance of the contract terms once those conditions have been met. The simplest example might be coded as a type of  “if this, then that” function. For example, I could create a smart contract so that every time the temperature drops below 15 degrees, the heating comes on in my house, provided that there is sufficient credit in the digital wallet connected to my utilities billing account.

Second, smart contracts are not “legal”, unless they comprise the necessary elements that form a legally binding agreement: intent, offer, acceptance, consideration, capacity, certainty and legality. They must be capable of being enforceable in the event that one party defaults, but they must not be contrary to public policy, and parties must not have been placed under any form of duress to enter into a contract. Furthermore, there must be an agreed governing law, especially if the parties are in different jurisdictions, and the parties must agree to be subject to a legal venue capable of enforcing or adjudicating the contract in the event of a breach or dispute.

Some legal contacts still need to be in a prescribed form, or in hard copy with a wet signature. A few may need to be under seal or attract stamp duty. Most consumer contracts (and many commercial contracts) are governed by rules relating to unfair contract terms and unconscionable conduct. But assuming a smart contract is capable of being created, notarised and executed entirely on the blockchain, what other legal principles may need to be considered when it comes to capacity and enforcement?

We are all familiar with the process of clicking “Agree” buttons every time we sign up for a social media account, download software or subscribe to digital content. Let’s assume that even with a “free” social media account, there is consideration (i.e., there’s something in it for the consumer in return for providing some personal details), and both parties have the capacity (e.g., they are old enough) and the intent to enter into a contract, the agreement is usually no more than a non-transferable and non-exclusive license granted to the consumer. The license may be revoked at any time, and may even attract penalties in the event of a breach by the end user. There is rarely a transfer of title or ownership to the consumer (if anything, social media platforms effectively acquire the rights to the users’ content), and there is nothing to say that the license will continue into perpetuity. But think how many of these on-line agreements we enter into each day, every time we log into a service or run a piece of software. Soon, those “Agree” buttons could represent individual smart contracts.

When we interact with on-line content, we are generally dealing with a recognised brand or service provider, which represents a known legal entity (a company or corporation). In turn, that entity is capable of entering into a contract, and is also capable of suing/being sued. Legal entities still need to be directed by natural persons (humans) in the form of owners, directors, officers, employees, authorised agents and appointed representatives, who act and perform tasks on behalf of the entity. Where a service provider comprises a highly centralised entity, identifying the responsible party is relatively easy, even if it may require a detailed company search in the case of complex ownership structures and subsidiaries. So what would be the outcome if you entered into a contract with what you thought was an actual person or real company, but it turned out to be an autonmous bot or an instance of disembodied AI – who or what is the counter-party to be held liable in the event something goes awry?

Until DAOs (Decentralised Autonomous Organisations) are given formal legal recognition (including the ability to be sued), it is a grey area as to who may or may not be responsible for the actions of a DAO-based project, and which may be the counter-party to a smart contract. More importantly, who will be responsible for the consequences of the DAO’s actions, once the project is in the community and functioning according to its decentralised rules of self-governance? Some jurisdictions are already drafting laws that will recognise certain DAOs as formal legal entities, which could take the form of a limited liability partnership model or perhaps a particular type of special purpose vehicle. Establishing authority, responsibility and liability will focus on the DAO governance structure: who controls the consensus mechanism, and how do they exercise that control? Is voting to amend the DAO constitution based on proof of stake?

Despite these emerging uncertainties, and the limitations inherent in smart contracts, it’s clear that these programs, where code is increasingly the law, will govern more and more areas of our lives. I see huge potential for smart contracts to be deployed in long-dated agreements such as life insurance policies, home mortgages, pension plans, trusts, wills and estates. These types of legal documents should be capable of evolving dynamically (and programmatically) as our personal circumstances, financial needs and living arrangements also change over time. Hopefully, these smart contracts will also bring greater certainty, clarity and efficiency in the drafting, performance, execution and modification of their terms and conditions.

Next week: Free speech up for sale

 

No-code product development

Anyone familiar with product development should recognise the image below. It’s a schematic for a start-up idea I was working on several years ago – for an employee engagement, reward and recognition app. It was the result of a number of workshops with a digital agency covering problem statements, user scenarios, workflow solutions, personas, UX/UI design and back-end architecture frameworks.

At the time, the cost quoted to build the MVP was easily 5-6 figures – and even to get to that point still required a load of work on story boards, wire frames and clickable prototypes….

Now, I would expect the developers to use something like a combination of open-source and low-cost software applications to manage the middle-ware functions, dial-up a basic cloud server to host the database and connect to external APIs, and commission a web designer to build a dedicated front-end. (I’m not a developer, programmer or coder, so apologies for any glaring errors in my assumptions…)

The growth in self-serve SaaS platforms, public APIs and low-cost hosting solutions (plus the plethora of design marketplaces) should mean that a developer can build an MVP for a tenth of the cost we were quoted.

Hence the interest in “low-code/no-code” product development, and the use of modular components or stack to build a range of repetitive, automated and small scale applications. (For a dev’s perspective check out Martin Slaney’s article, and for a list of useful resources see Ellen Merryweather’s post from earlier this year.)

There are obvious limitations to this approach: anything too complex, too custom, or which needs to scale quickly may break the model. Equally, stringing together a set of black boxes/off-the-shelf solutions might not work, if there are unforeseen incompatibilities or programming conflicts – especially if one component is upgraded, and there are unknown inter-dependencies that impact the other links in the chain. Which means the product development process will need to ensure a layer of code audits and test environments before deploying into production.

I was reflecting on the benefits and challenges of hermetically sealed operating systems and software programs over the weekend. In trying to downgrade my operating system (so that I could run some legacy third-party applications that no longer work thanks to some recent systems and software “upgrades”), I encountered various challenges, and it took several attempts and a couple of workarounds. The biggest problem was the lack of anything to guide me in advance – that by making certain changes to the system settings, or configuring the software a certain way, either this app or that function wouldn’t work. Also, because each component (the operating system, the software program and the third party applications) wants to defend its own turf within my device, they don’t always play nicely together in a way that the end user wants to deploy them in a single environment.

App interoperability is something that continues to frustrate when it comes to so-called systems or software upgrades. It feels like there needs to be a specialist area of product development that can better identify, mitigate and resolve potential tech debt, as well as navigate the product development maintenance schedule in anticipation of future upgrades and their likely impact, or understand the opportunities for retrofitting and keeping legacy apps current. I see too many app developers abandoning their projects because it’s just too hard to reconfigure for the latest system changes.

Next week: Telstar!

 

 

 

Startup Victoria – Best of the Startup State Pitch Night

In support of Victoria’s reputation as “Australia’s Startup State”, last week’s Startup Victoria pitch night was designed to showcase four of the best local startups. Hosted by Stone & Chalk, the judges were drawn from Mentorloop, Brosa, Giant Leap Fund, Rampersand and Vinomofo.

The pitches in order of presentation were (website links embedded in the titles):

Code Like A Girl

Founded four years ago, Code Like A Girl’s stated mission is to bring greater gender diversity to the ICT sector (information and communications technology), within both the industry and education spheres. To do this, the founders say we need more female coders, which they plan to achieve via coding camps, internships, and community events. Positioning itself as a social impact enterprise, the business is active in four States, and 75% of interns are placed into full time roles.

To support the ongoing development of its “role ready” value chain and to prepare for possible overseas expansion, Code Like A Girl is seeking $1.5m in seed funding. Currently piloting the training model via education providers (RTOs, boot camps, universities, online code schools), the business takes a 10% commission on courses sold (held twice a year), plus it charges placement fees of $2k per person.

But the model is difficult to scale, especially as Code Like A Girl does not own or create the actual training content – it is acting as a sales channel for third party courseware, and providing platform for advocacy, engagement and influence. Its key metrics are based on things like social impact scores – such as 30% of kids return to boot camps. The panel felt that the community platform is a huge cost centre, and it might be preferable to try a TedX model, where Code Like A Girl provides branding and foundational support to build more of a network effect – but without its own curriculum, the business will still struggle to scale.

Seer Medical

The business claims to make epilepsy diagnosis easier, and is currently raising $14m for European expansion (UK & Germany). To improve current diagnosis, the model needs to capture time series data to distinguish epilepsy from other conditions, but do so faster, cheaper and more efficiently than current processes. Founded in 2017, Seer has already serviced more than 1500 patients via 200 clinicians.

Using the Seer Cloud infrastructure,  it can achieve diagnostic outcomes 10x faster than traditional methods, and the platform is using machine learning to train its algorithms. The service is subject to Medicare reimbursement, which has no doubt assisted adoption.

Asked by the judges if the platform could be used to diagnose other conditions, the founders mentioned cardio, sleep and other health domains. As for competition, this comes mainly from the status quo – i.e., hospital based services. With advocacy from neurologists, giving them access to customers, the founders have a strong track record in the research field, which helps to open doors with clinicians. Along with research partnerships, plus the public health cost reimbursement, data is the fuel of the business –  Seer even have access to some third party data on which to train their diagnostic.

Liven

A dining rewards app, Liven is also bringing a behavioral gamification layer to a real world use case. Currently, there is a poor linkage between loyalty programmes and gamification. So, Liven has launched a universal reward token (the LVN token) for use in a digital/real world context.  The details were scant, and the status of the LVN token sale is unclear, but it seems users can earn LVN tokens from completing certain “missions”. The token (using a standard ERC 20 token format on the Ethereum blockchain), is designed to be interoperable and fungible (but Liven does not yet appear to use blockchain in its end user app or merchant point of sale solution).

The said merchants pay a 10-25% commission on app-based sales, of which upto 40% is paid back to the end user in the form of LVN tokens – if I got the maths right, Liven itself is securing $15 profit on every $100 of sales. Currently only available in Melbourne and Sydney, the judges wanted to know what the appeal is to merchants. According to the founders, users typically spend more in an average transaction when they use the app. It also seems that the app only works in brick and mortar restaurants, cafes and bars. The path to scaling will be via channel partners such as PoS systems.

Although not yet deployed, in future, it was suggested that users will be able to pay in any crypto – which raises all sorts of questions about the tokenomics of the LVN token, and whether LVN will be subject to exchange rate volatility (and even token speculation) or act as a stable coin; if the latter, what will it be backed by or pegged to?

Phoria

Phoria is in the business of extended reality technology (XR). Started in 2014, Phoria was an entrant to the Melbourne Accelerator Programme (MAP), with the stated goal of moving VR into a mobile experience (“democratize VR”).  Having gained some clinical VR research experience, Phoria has since worked on commercial projects such as “Captured” (turning a 3D scan of a building or structure into a Digital Twin), “Rewild Our Planet” (a Singapore-based AR experience), and various art installations museum exhibits.

Phoria is commissioned by tech and media brands to create XR content. It has developed a SaaS model, whereby it can turn real space into virtual space (“virtualising internal space”).

The judges wondered where we are along the cycle of mass adoption vs peak hype. In response, the founders mentioned that the first wireless headsets are now available, although consumer-facing mixed reality hardware is still 3-5 years away. With a growing customer base in engineering and architecture applications, Phoria’s main focus is on spatial information.

After the votes were counted, the People’s choice was Seer Medical, who also won the overall prize.

Next week: 30 years in publishing

Gigster is coming to town….

Melbourne’s Work Club recently hosted Gigster Senior Project Engineer, Catherine Waggoner, in conversation with Venture-Store’s George Tomeski. Part of Startup Victoria‘s Fireside Chats, it likely herald’s Gigster opening an office in Melbourne, to service local clients and to tap into the local developer community.

gigsterFor the uninitiated, Gigster describes itself as the “world’s engineering firm”, that helps clients scope, design and build software, apps and digital products. Using an established product development methodology, and drawing on the resources of a 1,000 strong network of freelance designers, developers and product managers, Gigster is taking much of the pain out of the costing and requirements process for new projects, as well as building a growing client base of enterprise customers.

Not mincing her words, Ms Waggoner opened her remarks by commenting, “The software development industry model is f*#$ed”, because:

  • Requirements are poorly defined
  • Scoping is laborious
  • Development costs blow out, and
  • The whole process is not very transparent and not very accessible.

As a case in point, she mentioned the significant cost disparity between what some digital design agencies or app studios might quote for building an iOS product compared to what Gigster would estimate. By: breaking projects down into the distinct stages of scoping, design and pre- and post-MVP; only engaging the “best of the best talent”; using proprietary tools both to estimate fixed rate costs (rather than billable hours) and to define and source solutions; and re-using content from a library of “Community Software” resources, Gigster is able to deliver quality projects in shorter time, and on more modest budgets. For example, based on the large number of projects that they have fulfilled, their “Gigulator” estimating tool incorporates 5,000 possible features.

From an investor perspective, Mr Tomeski mentioned that the “VC inflexion point is getting much earlier” in tech startups. Meaning, with lower development costs (and potentially, reduced valuation multiples), investors are looking to get in sooner, with lower exposure, but still generate reasonable returns on exit, thanks to cheaper establishment costs.

Of course, Gigster sits at the heart of the gig economy, a huge issue when it comes to discussing the Future of Work. Interestingly, many of Gigster’s contractors are themselves startup founders, who freelance while building their own businesses. But such is the strength of the network, something like 35%40% of their contractors work full-time for Gigster – they like the flexibility combined with the continuity. Many of the contractors are referrals from existing team members, and a number of teams (known at Gigster as “houses” – presumably a frat thing?) have bonded to such an extent that they get allocated specific projects to work on together, even though they themselves may be working in different locations, based on previous projects.

Working for Gigster is probably a career choice for some contractors, because there is a variety of projects to work on, and the opportunity to be involved from start to finish. Which may be the opposite if working in a more corporate or enterprise environment, where work may be routine, repetitive and reasonably narrow in scope.

If Gigster does decide to set up shop in Melbourne (with encouragement from
InvestVictoria) they will be joining the likes of Slack, Stripe and Square, tempted by financial and other incentives. Such a move may challenge a number of local digital agencies, who will face even more competition for talent and customers.

According to Ms Waggoner, enterprise clients represent 40% of the business, and should comprise 60%-80% very soon. Not only that, but the average deal was initially $15k, now it’s more like $100k. However, enterprise clients have a much longer sales cycle. Plus, many innovation teams within enterprises are more like loosely formed groups of niche experts, so they need training on how to think like a startup. When you consider the greater dependency on legacy software by corporate clients (where it may make financial sense to retire some assets and build afresh, but the emotional disruption can be huge…), combined with the greater emphasis placed on after-sales service, Gigster has had to adapt its business model accordingly.

But Gigster must be doing something right. They’ve stopped outbound marketing and prospecting, relying on in-bound leads, repeat business and client referrals. There has been a shift from a sales focus to a customer focus, complete with a dedicated customer success team.

A number of audience questions related to getting VCs interested in your idea: What do they look for? How do they assess opportunities? How far should you go in building a product before you can attract funding? What’s the best way to validate an idea? etc. Much of this is about product/market fit, building the right team, getting customer traction, and executing on your strategy (aka Product Development 101.) As part of her closing comments, Ms Waggoner noted that unlike some of the high-profile VC funds (e.g, Y-Combinator, Techstars and 500 Startups) many VCs are becoming more sector specific, because they prefer to invest in what they know and understand.

Next week: Building a Global/Local Platform with Etsy