Pairwyse DSL Protocol - Whitepaper - V08.pdf

Confidential – for emailed recipients only, please do not distribute. Clinaro Ltd. Version 0.8
Domain Specific Language (DSL) for Building and Managing
Smart Contract Applications On-chain
Dr. Avtar Sehra Dr. Ashwin Tumne Akiva Dubrofsky
Abstract
Building smart contract applications requires off-chain development, testing and compilation, after which the application can be
deployed live on-chain. In this scenario even if the system of contracts is designed to be upgradable, any future update requires
inevitable off-chain development, compiling and testing, before the upgrade contracts can be deployed. In non-upgradeable
systems, any future updates require replacing and deprecating the old smart contract infrastructure. In doing so, you need to
transfer assets from the old to the new smart contract infrastructure. Such off-chain upgrade/update processes come with
significant risk and cost. This introduces significant challenges when you are structuring and executing complex financial
instrument agreements, where many different scenarios need to be catered for, but taking all these into account on day one
means you would incur significant financial cost and complexity risk.
The approach described in this paper enables instrument structures to be agreed with multiple parties in a decentralised
manner on-chain, through a Domain Specific Language (DSL), and the resulting instrument applications composed using
atomic building completely on-chain without the need of any off-chain development and compilation i.e. we transition to an
off-chain compilation to on-chain composition. This drives greater cost reduction in development bespoke and secure smart
contract applications, and with the ability to be upgraded. In addition, any future updates can also be made at a future date
without compiling any new off-chain smart contracts, and also without deprecating the older versions and migrating any locked
assets.
We then outline the first implementation of this DSL protocol, which enables custom capital structures to be formed on any DeFi
liquidity pool e.g lending and staking. In this case multiple decentralised parties can coordinate and structure a tranching
infrastructure on a lending pool, so if there are underlying losses, due to defaults (or slashing in case of staking), the financial
impacts to the liquidity providers can be staggered based on the tranche they locked their LP token in. At a future date if the
tranche structure needs to be modified, this can be done by the LP token holders who have locked their funds in this tranche
infrastructure i.e. these users can propose and agree updates to modify changes such as adding a new tranche, with different
terms such as a higher attachment point.
The vision, as explained at the end of this paper, is to provision this technology through a public protocol as the world’s first Low
Code / No Code Web3 protocol for launching on-chain instruments and their lifecycle management infrastructure. Users will be
able to interact with the protocol through normal transactions, coordinate terms with each other and structure new DSL
generated smart contract instruments that can be composable with other protocols, and contain complex operational
processes. Then any flow of funds through such DSL generated smart contracts can incur a transaction fee that will be passed
as a protocol fee.
Outline
1. Introduction to Smart Contract Development Risks
2. On-chain Composition with a DSL
3. Example of Securitisation with and without DSLs
4. DSL Product Overview
5. Example of Capital Structures Composed on DeFi
6. DSL Protocol Vision
1. Introduction to Smart Contract Development Risks
The biggest problem with smart contract-based financial applications on the blockchain is the lack of
ability to fix errors and or upgrade functionality once they are deployed.

Today, if you need to write a blockchain application that manages complex business logic and digital
asset flows you are required to build the application by programming smart contract code with all the
relevant logic declared upfront. This is because blockchain immutability imposes strict limits on smart
contract adaptability when contracts are deployed on-chain. Due to this, the following risks and
challenges need to be considered when deploying smart contract based applications that will manage
large value of asset flows:
● How do you respond to unknown behaviours and risks in your smart contracts?
● How do you quickly fix a potential vulnerability once it is found on-chain?
● How do you upgrade contract functionality without introducing financial risk or fatal error?
For institutions, solutions to these problems are critical as there is no pause button on the blockchain.
Transactions only move forward and the bearer property of crypto-assets can mean permanent losses
if smart contracts are not constructed with the highest level of quality and the ability to manage issues
as they occur.
Therein lies the cost-scalability-risk tradeoff for any smart contract application. Any organisation using
smart contracts to build highly scalable financial instrument applications must ensure all requirements,
possible issues and likely new scenarios are completely understood, tested and implemented ahead
of time, as any future change or upgrade incur significant operational disruptions, change
management and risks. This upfront work means significant costs for technical development.
Furthermore, if upgradability (i.e. scalability) is needed, risks must be managed by ensuring all future
off-chain development undergoes the same level of stringent testing before deployment, adding to the
costs. Under these constraints, an institution is left with two possibilities:
1. Keep costs down and manage risks by building low complexity hardwired contracts that are
not scalable and or upgradable. Real world use-cases of this type are highly limited, but
use-case specific “micro applications” could be one likely adoption path.
2. Ensure you capture all complexity and use-cases upfront, and perform significant testing and
audits for all use cases to ensure risk can be managed. However, capturing all possible
scenarios upfront is not realistic, so chances are future changes will happen, in particular to
safeguard client assets held in smart contracts.
A third option C remains elusive, which is scaling smart contract applications easily, even after they
are deployed, and as needs arise, and doing so in a manner that does not introduce increased risk
and costs much less than writing a whole new smart contract application.
2. On-chain Compilation with a DSL
Currently, most (if not all) smart contract development is done in the standard way, where smart
contracts are constructed (mostly coded in Solidity), compiled and tested off-chain, and then after a
number of iterations they are deployed on-chain for interaction on a blockchain. In this model, if the
system of contracts is upgradable, any future update requires inevitable off-chain development,
compiling and testing, before the upgrade contracts can be deployed. In non-upgradeable systems,
any future updates would require replacing and deprecating the old smart contract infrastructure. In
doing so, you need to transfer assets from the old to the new smart contract infrastructure. Such
off-chain upgrade/update processes come with risk and cost.
An alternative to off-chain smart contract development is to enable smart contracts to be composed
on-chain using standardised building blocks so no off-chain development and compilation is required.
How, then, is it possible to compose smart-contracts on-chain without ever compiling anything
off-chain? What benefits would this add?

When smart contract code is compiled in the standard way, all lines of the code are broken down into
Operation Codes (OpCodes) so that the Ethereum Virtual Machine knows exactly what to do when
running the code. All On-chain compiled smart contract code consists of a stack of these OpCodes,
which are executed in sequence whenever a smart contract is triggered. Therefore, you could
formulate any smart contract application completely on-chain by composing a sequence of OpCodes
that represents a smart contract application OpCode stack that you require.
Composing smart contracts on-chain in this way opens up new modes of operation, such as
formulating new smart contract agreements in real-time without any off-chain interaction between the
contracting parties. For example, two independent parties could coordinate and agree to a set of
terms and conditions completely on-chain through standard human readable instructions, and then
these instructions can be formulated into a unique set of OpCodes representing a smart contract
version of the agreement between the parties.
This means smart contract applications can autonomously create a new application without any
off-chain development resources and without the need for pre-compiled templates. The key
advantage of this approach is that the on-chain composed applications are fully upgradable i.e. you
can add and remove sequences of OpCodes to incorporate new logic and data without ever writing
and compiling off-chain solidity code. Furthermore, the governance of application upgrading can also
be implemented as a fully on-chain process.
An overview of on-chain composition and off-chain compilation is provided in Figure 1. A detailed
view of efficiencies and benefits between the two approaches, particularly as it relates to contract
development and upgrade cycles. is provided in Figure 2.
Figure 1. Overview of Off-chain Compilation vs. On-chain Composition

Figure 2. Efficiencies and benefits of On-chain Composition over off-chain compilation.
3. Example of Securitisation with and without on-chain DSLs
Let’s say an entity wants to create an on-chain securitisation structure and enable execution with a
pool of investors. It’s key requirements are as follows:
1. Vehicle securitisation logic must be entirely on-chain with events handled autonomously by
smart contracts.
2. Investors will interact directly with the on-chain structure, invest money into and receive
tokens from a particular tranche, including voting rights on events impacting their tranche and
certain actions at the vehicle level.
3. The on-chain structure needs to be dynamic and flexible so new structural features can be
added at a later date, e.g. new tranches and/or redemption rules.
Enabling an on-chain structure will also require key legal documents, such as the shareholders
agreement, be encoded in smart contract form in a manner that places boundaries on new issuances.
For instance, the entity has a key clause in the shareholders agreement relating to tranches which
reads as follows:
“Arbitrary new tranches can be added to the vehicle assuming they meet certain
characteristics, and they can have redemption criteria. This flexibility is required to ensure the
GP can assess market conditions to see what ALM strategy suits them best over time.”
Let’s say, at a future date, the entity wants to add a new tranche that includes the following
characteristics:

1. A target ratio between yield and amount raised must be met, e.g. 2% for every 100MM.
2. Early redeemable option only if it is sufficiently senior e.g. attachment point of >20%.
3. The parties who sign off on tranche creation cannot have signed off on too many prior
transactions. This is to avoid concentration, so new signatories can be new investors.
4. Additional options on the units must be structurally sound. The entity can provide its
definitions as to what their boundary conditions are for a sound option.
This precise logic needs to be integrated into the existing on-chain securitisation structure without
abridging existing terms and conditions of the shareholder’s agreement. We can examine
implementation with and without on-chain DSLs.
(A) Off-chain compilation
When using off-chain smart contract compilation for deployment and validation, the new capital
requirement can only be achieved in one of two ways:
1. Attempt to Program all logic you need for the instrument now and in the future upfront at t=0.
a. You will need to codify and integrate the shareholder agreement in such a way it can
anticipate all possible structural requirements the vehicle may need in the future as
well as a means to dynamically invoke new tranches on-chain without violating
shareholder terms and conditions.
b. The entity’s requirement for structural flexibility will simply balloon the amount of
smart contract code required to address any future complexity it may encounter with
introduction of a new tranche. This is because the shareholder agreement will need
to spread its enforcement across a plurality of potential capital structures that may or
may not be evoked in its lifespan.
c. Beyond bloated costs, the entity will never be able to cover unknown risks and
behaviours upfront anytime a new capital structure is evoked. This can introduce
systemic liabilities for the entity due to blockchain immutability. Even low complexity
applications will be increasingly difficult to maintain both technically and competitively.
2. Instead of building a complicated monolithic instrument, the entity can attempt to start small
with simple logic at t=0 and incrementally expand the smart contract instrument over-time via
new deployments
a. While this may seem cost effective at first, each improvement cycle will be costlier
than the previous. This is because even small code changes will require thorough
reconciliation of existing rights against new ones being introduced. This will bring
rising validation costs which compound with each upgrade
b. As the entity adds increasing contractual complexity through future deployments,
codification complexity will rise exponentially as vehicle structures are added linearly.
c. The validation cycles become even more costly when consensus processes are
required, such as shareholder votes or external approvals. In addition to instrument
changes, the entity will need to implement fail-safe on-chain multisig voting to ensure
its governance requirement for new signatories is strictly enforced.
In either instance, the entity deploying such a smart contract structure would incur a lot of upfront cost
and risk to manage the complexity of capturing all required logic for real-world applications plus
upgradability. The entity can also incur serious liabilities if stringent controls are not implemented to
enforce the rights in the shareholder’s agreement against any future instrument changes.
Furthermore, the entity will find very limited upgradeability options that don’t involve additional rounds
of off-chain development, validation and deployment. This means the cost of each new upgrade will
be higher than previous upgrades, making it a compounding expense.

Finally, the entity will find smart contract version-to-version control and migration increasingly difficult
when cryptocurrencies, decentralised assets and security interests are locked in the instrument
system (e.g. as collateral). In addition to smart contract code development, the entity must also
programmatically engineer transaction sequences for fail-safe migration of assets and rights on-chain.
These rising risks and costs will quickly negate any benefits of the smart contract instrument over
legacy securitisation solutions.
(B) On-Chain DSL composition
Instead of compiling smart contract instruments off-chain, the entity can exploit a modular
domain-specific set of already deployed and validated smart contracts as instrument building blocks.
As the smaller smart contract-based components have undergone formal verification checks, this
enables incremental on-chain validation of composed instruments against previous validations. All
the entity must do is transmit a sequence of plain english instructions dictating how to compose the
smart contract instrument bottom-up from modular pre-validated on-chain OpCode components.
To create its required structure, the entity can transmit a sequence of DSL instructions on-chain to a
particular decentralised financial messaging smart contract protocol at t=0. This smart contract
protocol interprets each DSL instruction to compose the smart contract instrument as a purely
on-chain product. Using linear DSL instruction sequences, the entity can compose its securitisation
instrument to the appropriate level of complexity it needs initially for the market and evolve it over time
without migration risk.
At t=1, the entity can implement its shareholders agreement on-chain via DSL composition of a
second smart contract. In addition the entity can add whitelisting criteria at shareholder and
instrument levels dictating the types of investors eligible to hold specific instruments.
Subsequently, at t=2, the entity can make an on-chain DSL upgrade to its securitisation instrument
giving the on-chain DSL shareholder’s agreement an exclusive supervisory authority to set
boundaries for new capital structures issued by the securitisation instrument (regardless of who
proposes it).
With on-chain shareholder governance implemented over the instrument, any attempted DSL
upgrades to the instrument are now subject to validation of on-chain terms and conditions contained
in the entity’s DSL shareholder agreement. This reduces the risk of any new instrument features or
conditions violating the shareholders’ agreement. At the same time, it maximises the entity’s flexibility
to cost-effectively evolve its securitisation instrument and shareholders agreement as required.
This becomes critical at t=3, when the GP proposes adding the new tranche to the existing
instrument. To make its proposal, the GP simply transmits the set of DSL instructions specifying the
new structure to add to the existing DSL securitisation instrument. However, before upgrading, the
DSL shareholder agreement smart contract is automatically called by the DSL securitization smart
contract to validate the proposed changes on-chain.
If the new tranche satisfies the DSL criteria specified by the on-chain shareholder’s agreement, the
upgrade is allowed to proceed to settlement. If, instead, a violation of the shareholder agreement is
detected, the transaction fails and the securitisation instrument broadcasts an event (i.e. on-chain
notice) of a failed upgrade.
The key for the entity is that the shareholders agreement is able to enforce what can and cannot be
added to the securitisation vehicle structure. This increases investor confidence in the vehicle while
reducing overhead and time-to-market 10x over off-chain smart contract compilation.

4. DSL Product Overview
Instrument scalability requires a cost-effective smart contract solution that can manage risks arising
from contractual complexity, but without compromising instrument performance or adaptability.
The holy grail of blockchain applications is the ability to create (a) bespoke, (b) scalable and (c)
cost-effective instruments capable of handling today’s complex business logic, financial flows and risk
controls.
We can qualify this in more precise terms:
a. Bespoke means the ability to address any level of complexity required for an
instrument without eating margins, which is key to scaling revenue.
b. Scalability means an instrument can be reliably composed, customised, expanded,
upgraded and cloned without introducing new technical, financial or operational risks.
This is the key to growing volume and clientbase.
c. Cost-effective means reduced overhead, high reusability, maximising margins,
minimising risk, agile implementation, stronger adaptability and process automation.
This is key to gaining a competitive edge over competition.
The only way to achieve bespoke, scalable and cost-effective smart contract instruments is to
compose them on-chain from pre-deployed, pre-verified OpCode primitives using on-chain financial
message processing to compose smart contracts, rather than hard-coding, compiling and managing
them off-chain (Figure 3).
Figure 3. Click to see a video intro to the DSL smart contracting protocol (2 min)
This new paradigm effectively inverts the smart contract building model from top-down waterfall
construction (off-chain) to bottom-up agile composition (on-chain). Our patented on-chain DSL
contracting protocol immediately solves three problems plaguing off-chain compiled smart contracts:
1. Financial instruments defined in a financial language reduce time and effort 10-fold over
traditional software translation and development cycles.
2. Smart contracts composed bottom-up/on-chain instead of top-down/off-chain enables live
instrument development and upgrading without severing existing on-chain custody,
stakeholder rights or instrument guardrails.

3. Instrument balance sheet, terms and conditions can be constructed to any level of granularity
and complexity required for validation, deployment and activation. These serve as the
constant source of truth for the vehicle, embedded in but isolated from the smart contract
instrument container itself.
Figure 4. The DSL protocol on-chain architecture for smart contract composition (left)
composing transactional terms and conditions for an existing agreement smart contract
(right).
The DSL platform vision is of a decentralised P2P smart contract protocol enabling composition of
complex on-chain financial instruments via purely on-chain financial messaging-based composition
(Figure 4). Three key properties underscore the platform’s utility in financial smart contract
instrumentation:
● On-chain amendability enables continuous instrument adaptation.
● On-chain composition and validation ensures instrument security.
● On-chain messaging enforces coordination and validation, thus reducing overhead.
The protocol receives instructional DSL messages from authorised participants to be able to agree
and create new smart contract logic. It also receives DSL instruction sets representing additions,
amendments or deprecations of smart contract terms and conditions. The on-chain protocol creates a
two layer smart contract vehicle that effectively isolates the balance sheet of the vehicle from its smart
contract container at its fixed blockchain address. This means no migration of existing assets and
rights are required after instrument upgrades.
Through on-chain instrument composition, a vehicle’s chart of accounts can be explicitly defined along
with the conditional rights and obligations of each participant at an individual or group level. The
on-chain compilation of contract definitions, terms, conditions and authorised signatories places
operational limits on the scope of transactions that can be made against a vehicle's balance sheet
(Figure 5).

Figure 5. Example of how a traditional paper contract can be tokenized on-chain
term-by-term and condition-by-condition in a manner that enforces on-chain the
DSL-specified rights and obligations. In this instance, a simple GP/LP crypto-asset
vehicle.
The DSL protocol can be used to compose both simple and complex financial instruments in a
reusable manner such that the simpler smaller instruments can serve as building blocks for larger
ones. For instance, an entity can compose or access small customised instrument primitives such as
escrow, warrant, option or insurance smart contracts (Figure 6).
Figure 6. The composition of on-chain primitive instruments as modular building blocks for
application in larger more complex on-chain instruments.
The DSL protocol can also be used to build decentralised trading applications for digital assets.
Starting with simple P2P asset exchange apps (Figure 7), more complex trading facilities with order
book, market-making and clearinghouse functions can be iteratively composed from modular
independent components.

Figure 7. A very simple illustrative demo showcasing how easy it is to implement a trade
application between two parties. Such simple apps can be expanded incrementally to
provide decentralised exchanges with clearing and settlement functions fit-for-purpose.
5. Example of Capital Structures Composed on DeFi
One of the initial commercial focus points is to leverage the DSL protocol to create new variants of
existing on-chain instruments without having to reimplement previous business logic or controls. This
reduces development and validation costs considerably. For example, a DSL-composed vehicle can
have interactions with other vehicles/protocols, such as a master agreement over sub agreements. In
this manner, more complex financial instruments can be composed, including on-chain instruments
interfacing with existing decentralised finance (DeFi) protocols (Figure 8).
Figure 8. Our first marketplace product, the Universal Capital Stack, can serve as a
standalone decentralised instrument to launch customised capital structures around a
portfolio of DeFi investments.
Expanding DSL applications from investment to securitisation instruments is a matter of repurposing
previously composed instrument primitives and customising to bring both issuer and investors under a
single capital contract. For instance, our first public product, the Universal Capital Stack (UCS), can
be modularly expanded into an on-chain instrument capable of handling real-world requirements for
bond issuance on-chain (Figure 9).
This USC enables a compliant and institutional grade layer to be easily composed on top of existing
DeFi protocols. In this way you can enable issuers to be whitelisted, and they can then tap into public
DeFi liquidity pools to raise capital. Also the issuer can also establish a capital structure to provide

multiple tranches for investors depending on risk appetite, as well as other elements of optionality. In
addition the issuer can provide incentives for the underlying DeFi protocol LPs to lock their LP tokens
into the capital structure, and choose a tranche that fits their risk profile. The USC then enables the
returns coming from the DeFi protocol to be split across the tranches based on risks and volumes in
each tranche. Finally, a further compliance layer could also be inserted on the investor side, which
ensures locked liquidity providers would need to be whitelisted to interact with this infrastructure. To
drive usage of this top layer as opposed to the underlying layer the issuer can provide significant
advantages (interest incentives and fixed rates) to UCS locked LP token holders that far exceeds that
being offered to LPs solely in the underlying protocol.
Figure 9. Example of a Securitisation application that can be composed on the DSL to
interact safely with DeFi liquidity pools and credit facilities
6. DSL Protocol Vision
Beyond securitisation, the application domains for the DSL are as wide as the potential for the
blockchain itself (Figure 10). The DSL protocol simply helps entities build faster and more robustly in
a cost-effective and scalable manner. As such, we are exploring broad application of the DSL
protocol across capital markets asset classes and decentralised finance protocols e.g. for quickly
structuring multiple instrument types with relevant logic and compliance whitelists in a manner that
enables future upgrades to be securely implemented without complex and risky operations.

Figure 10. Breadth of application domains for the DSL protocol across transaction
verticals, public blockchains, decentralised marketplaces and industry domains.
In addition to enabling deployment of a decentralised P2P DSL protocol that enables the scalable
composition of smart contract applications, we are also working to build a DSL smart contract
marketplace for on-chain financial and economic DSL based instrument discovery (Figure 11). Under
this B2B model, instrument developers can publish their smart contract products for sale on a
decentralised app store. Business entities seeking on-chain instrumentation solutions can purchase
simple to complex smart contract products on the marketplace and customise them to their specific
needs. We envision this B2B model extending to on-chain money marketplaces to facilitate
transaction discovery, clearance and settlement between DSL instruments and participants in the
ecosystem.
Figure 11. We are building a network of DSL publishers powering marketplaces for
financial and economic instruments, transactions, clearing and staking.
As the DSL protocol matures, these marketplaces themselves can be composed using the DSL itself.
In the future, the core DSL protocol itself will be made upgradeable under protocol governance so that
a variety of DSL smart contracting functionalities can be deployed for applications across multiple
industry domains.
As part of this long term vision we are also planning on issuing a protocol governance token, that
would enable holders to stake these tokens on the protocol and take part in governance votes.
Furthermore, staked tokens would enable holders to partake in a pro-rata share of protocol fees that
are clipped from all transactions flowing through instruments composed and deployed via the DSL
protocol. The governance and staking structure that is being designed consists of a time-lock model,;

so holders will be incentivised to lock their tokens for longer periods to be eligible for a larger share of
fees compared to lower or no time-locked tokens.
The roadmap towards the above vision is broken down into the following early phases:
● Phase 1: Launch first version of the protocol to enable ecosystem participants to deploy
complex capital structure management instruments and enable ease of composability with
existing DeFi protocols (Ledning, Staking and AMMs), and add whitelist options for
compliance management and other operational automations.
● Phase 2: Launch a generalised protocol for participants to deploy complex instrument
structures with full upgradeability, and allow development and management of new custom
DeFi use cases i.e. this becomes a Low Code / No Code Web3 Protocol.
● Phase 3: Establish ecosystem governance structure using a DAO, and issue token to be able
to manage community voting and fee sharing between stakeholders. This will be the
sustainable business and operating model to drive the Low Code / No Code Web3 protocol.

Pairwyse DSL Protocol - Whitepaper - V08.pdf

Recommandé

Recommandé

Contenu connexe

Similaire à Pairwyse DSL Protocol - Whitepaper - V08.pdf

Similaire à Pairwyse DSL Protocol - Whitepaper - V08.pdf (20)

Dernier

Dernier (20)

Pairwyse DSL Protocol - Whitepaper - V08.pdf