Rubber Meet Road Part 2 of 3: Kommerce’s approach to Multi-Stage Financing
In our previous post, we talked about some of the pain points discovered during our first trade, one of which is that the financing stages change between trades, which directly affects smart contract architecture.
Warning: This is a semi-technical piece that covers possible approaches to solve a business case problem and is useful for enterprise architects working in blockchain or looking at blockchain for existing business cases. It is also useful to people on the business side of crypto companies, to understand architecture and how you communicate workflows in business use cases. Crypto geeks, carry on.
The “Many Workflows” Problem
The following payment configurations represent the variety of deals offered in the market. They represent the different pricing and deposit structures available, each expressing different dimensions of risk sharing, cash flow and pricing.
Configuration 1: The Importer can pay a 50% deposit when they order the goods, 0% at the port of departure, then 40% when the goods reach the port of arrival, and the final 10% when the goods exchange hands. We shall refer to this as 50:0:40:10.
Deals of this nature (50% deposit) tend to net a lower price, as compensation for the higher level of deposit and risk sharing. It also impacts cash flow of the Importer significantly, as 50% of the value of the shipment is tied up during the sea voyage, which can be between 22–30 days.
Configuration 2: Rather than 50:0:40:10, the Importer can pay 20% deposit, 30% when the goods reach the port of arrival, and the remaining 50% when the goods exchange hands. We refer to this as 20:0:30:50. In this case, the variable is the amount paid at each stage of the trade.
Configuration 3: the Importer will pay 50:40:0:10, but they make the 50% deposit when they order the goods, 40% when the goods reach the port of departure and the final 10% when the goods exchange hands. Therefore, the stages where they make each of these payments will differ based on the location of goods.
In these examples, we see how 2 variables, stages of deposit and location of cargo, can affect how an Importer can pay their deposit, subsequent milestone payment, and final settlement payment in reality. How do we map out the almost-infinite possibilities of financing into a single smart contract?
In this article, we will cover 3 of the possible solutions to multi-stage financing.
Solution A: Implement all options in a single Smart Contract
Imagine knowing all the possible financing options available for any one trader in all our target markets. The simplest brute force approach then will be to hard-code all these options into the smart contract. In this way, just 1 single smart contract will suffice, as every financing option will be available there. However, there are a few flaws to such a simple model.
First and foremost, this model rests on the assumption that we know all the possible financing options available, not just for now, but also in the future. This is especially important, as any new additions or amendments to the smart contract will require it to be re-deployed, which is not an endeavour for the faint-hearted.
Furthermore, all the credit history stored in the previous smart contract will then be lost in the new smart contract implementation. Can we, or anyone else, say with reasonable confidence that we will know all these current and future financing options, in every single market that we will enter? We don’t think so.
Next, even if this was possible, by lumping every single option available into one single smart contract, it will result in a more complex smart contract.
This makes it difficult for a comprehensive security audit to take place.
Therefore, the risk of
- unknown trade terms and;
- a security loophole in such a smart contract configuration;
renders this solution to be too inflexible for us as we scale up and enter other markets.
Solution B: Using a domain-specific language (DSL) for trade
Solution B has greater optionality: on the language front (being amenable to compilation to natural as well as programming languages); and in terms of compatibility with existing, parallel, and/or future enforcement structures.
With a domain-specific language (DSL) for law, one can express trade finance (whether the contractual arrangements, rules & regulations, or business process logic) in the same common-denominator programming language — one that is specifically designed to capture the semantics, deontics, and pragmatics of the domain. This in turn gives us existing frameworks from each of those fields to utilise (like the Deontic Octodecagon pictured below), thus allowing one to go from pseudocode (natural languages) to real code. Your contracts and documents are no longer just dead hairballs; they are programs.
This means that you can get from syntax (i.e. what does it say) to semantics (i.e. what does it mean) to pragmatics (i.e. what does it mean for me). With the DSL as the foundational infrastructure, one can further apply the batteries of tools that computer scientists have at their disposal to the process and documentation (both legal and quasi-legal) involved in trade finance: dependency management, static analysis, unit testing, fuzzing, formal methods, just to name a few.
However, there are some drawbacks of this approach:
A DSL for law takes many years to design and build, and an additional period of on-boarding time is expected for the implementation for and on a particular use case; time and resource expenditure for the creation and encoding of all relevant rules and law libraries specific to the jurisdiction and legal sub-domain of choice.
Secondly, since a DSL for law will be a high-level language that has to get compiled into a lower-level bytecode, it would be a better fit for standardised bytecodes such as E-WASM in Ethereum 2.0, where there is a developed compiler framework. This would depend on the development and availability of E-WASM or other similar bytecode frameworks to become available.
Therefore, the time it takes to design a tested and usable DSL specific to trade finance, and dependency on future technology suggests that solution is more forward-looking, but not implementable in the near future.
Disclosure: We work with Alexis Chun of Legalese.com who is actively researching computational law to create a DSL that works with smart contracts.
Solution C: Using smart contract as lego bricks
The final solution and Kommerce approach is to use a few basic smart contracts to assemble the different forms of financing options as demanded by the trade. If you have the right bricks, you can make many shapes!
Imagine this: parties agree to a trade where 50% of deposit is paid upon trade confirmation, 40% is paid once the goods reach the port, and the final 10% is paid once the goods exchange hands. Using our solution, this financing will be formed and aggregated by 3 different components, instead of 1 universal smart contract as mentioned in Solution 1.
The process of using basic smart contracts as building blocks gives Kommerce flexibility for many financing configurations. The majority of these seemingly complex financing configurations can be logically assembled with granular and simple smart contracts.
This makes the financing solution and workflow easy to implement and reduces the security audit costs by reducing complexity and attack surface.
One trade off is that our approach may not comprehensively cover all trade possibilities, with edge cases for extremely complex financing options outside our lego bricks solution. We have made a considered judgement call that complex financing options are relatively unlikely in Emerging Markets trade finance.
Further, traders that utilise such complex financing options are not our target customers, SME merchants.
Therefore, this solution is optimal for Kommerce’s needs as it provides:
- sufficient flexibility for the foreseeable future
- ease of implementation
- feasibility of a comprehensive security audit
The small probability of this solution not being able to meet certain financing options is a small trade off for all the benefits this solution can provide.
Now that we have a clear solution for our problem of multi-stage financing, it begs the question, how can we implement this solution in practice?
Technical Details of our Solution
Every trade smart contract serves as a building block in this approach, each identified with a unique trade-id. Since smart contracts can iteratively chain from one trade-id to another, this allows for an unlimited number of financing stages to be built from this basic building blocks, and theoretically, seemingly endless possibilities of trade financing combinations.
As mentioned earlier, this minimises implementation complexity, and the security audit has to be conducted on only the basic units of trade smart contract to verify that every stage of trade financing can be fulfilled properly.
In the final article of this three part series, we will talk about a new requirement that emerged from the first trade, the need to capture more information about downstream traders in order to improve credit scoring for Importers on the Kommerce platform.
