Katal: A standard framework for finance
KKatal
A standard framework for finance
Bruno Franc¸a, Sophie Radermacher and Reto Trinkler
Trinkler Software [email protected]
Version 3 – July 3, 2019
Abstract —Katal is a new blockchain that provides a standardway to build and deploy decentralized finance applications.It brings together all the components necessary for the backendof a financial application, namely: a high-performance consensus,an authenticated data feed system, a standard for financialcontracts and connectivity to the rest of the blockchain ecosystem.Katal enables and simplifies the creation of financial servicesthat are non-custodial, trustless, fast, convenient and interoper-able.
I. I
NTRODUCTION
Katal aims to create a standard framework for the next stageof decentralized finance. In order to do this, it combines a high-performance blockchain, built using an innovative consensusalgorithm and virtual machine, with a runtime that allows easycreation of assets, a standard for the creation of algorithmicfinancial contracts, and connectivity to the outside world andother blockchains.Katal appeals to both developers and users: • For developers, Katal is a low-latency and high-throughput decentralized platform with native access tooracles, stable assets, connectivity to other blockchainsand algorithmic contract templates that can be combinedto create any type of financial contract. This allowsdevelopers to easily create decentralized financial serviceson top of Katal since custodianship, settlement and datafeeds can be completely delegated to it. • For users, Katal makes finance easy, using unprecedentedspeed, security, and risk management. Funds alwaysremain under the user’s control, empowering them to trulybe their own banks. Settlement and data feeds are openand decentralized eliminating the need to trust exchanges.And, through a single Katal account, it is possible tointeract seamlessly with all the financial services built ontop of Katal (like futures and options exchanges, tokenexchanges, margin trading, short selling, collateralizedloans, etc) and also with all the blockchains that connectto it.In this paper we will introduce and describe every compo-nent of Katal and how they interact between themselves. Therest of the paper is divided as follows:
This work is licensed under the Creative Commons Attribution-ShareAlike4.0 International License. • In section II we will discuss the main building blocks ofKatal. • In section III we will give an overview of the runtimeand operation of Katal. • In section IV we will delve into the runtime and describeit in detail. • In section V we will explore several examples of appli-cations that can be built on top of Katal.II. B
UILDING BLOCKS
Katal is built on top of an infrastructure that is composedof six pieces: • A blockchain development framework called Substrate, • A consensus algorithm called Albatross, • A virtual machine called Enso, • A standard for the algorithmic description of financialcontracts called ACTUS, • An authenticated data feed system called Town Crier, • And a heterogeneous multi-chain ecosystem called Polka-dot.We will now briefly explain each one of these components.
A. SubstrateSubstrate is a software framework for blockchains createdby Parity Technologies. It packs a series of tools, written inRust, that enables developers to easily create a blockchain.For developers who prefer simplicity over freedom, it ispossible to generate a new blockchain with just a simpleconfiguration file. While developers that prefer freedom cancreate their own consensus algorithms and runtimes fromscratch.Substrate is a combination of mostly two technologies,WebAssembly and Libp2p. The built-in WebAssembly in-terpreter enables developers to write their own ready-to-usemodules in any language they wish, as long as it compilesdown to WebAssembly, and Libp2p constitutes the bulk ofthe networking functionality.For Katal we will use the most bare-bones version of Sub-strate, called Substrate Core, that provides only the network-ing, the WebAssembly interpreter and some other auxiliarytools and we will provide the consensus and runtime modules.1 a r X i v : . [ c s . CR ] J u l . AlbatrossAlbatross [1] is a novel consensus algorithm, developed byTrinkler Software and Nimiq, that is inspired by speculativeBFT consensus algorithms.Speculative BFT is a class of classical consensus algorithmsthat have very high performance when compared to olderalgorithms like PBFT [2]. Speculative BFT consensuses havetwo modes of operation: an optimistic mode where nodesare assumed to be well-behaved thus resulting in greaterperformance, and the pessimistic mode where it is assumedthat some nodes are malicious and the only goal is to makeprogress.Albatross takes a ’trust but verify’ attitude to block pro-duction. Nodes are allowed to make updates to the state bythemselves but other nodes can revert the update if it is notvalid.In Albatross there is a validator list that is selected atrandom from the set of all nodes that stake tokens. Thevalidator list is changed every epoch, where an epoch iscomposed of T micro blocks and one macro block.Validators take turns producing micro blocks, which aretransaction-containing blocks that are signed by a single val-idator. Macro blocks do not contain any transactions , beinginstead used to change the validator set, and are produced withPBFT.If all validators follow the protocol correctly, Albatross willproduce blocks as fast as the network allows. Since macroblocks don’t contain any transactions, there will be a smallpause at the end of every epoch, but that downtime constitutesonly a small percentage of the total time. So, in the optimisticcase, Albatross will come close to the theoretical limit for asingle-chain consensus algorithm.However, if there are malicious validators they may misbe-have. There are three ways in which they can do that: • Invalid blocks:
Validators may produce invalid blocks,in this case the other validators will simply ignore thoseblocks. • Forking:
Creating or continuing a fork will result in thestakes of the misbehaving validators being confiscated. • Delays:
If a validator, in his turn, does not produce avalid block after a predetermined amount of time, the We use same definition for transaction as the one taken by Parity. Thereare extrinsics, which are any input to the state transition function, andboth transactions and inherents are mutually exclusive types of extrinsics.Transactions are extrinsics that are propagated through the network and signed.Inherents are neither propagated nor signed. An example of an inherent is atimestamp. other nodes will begin a view change protocol that willallow another validator to produce a block.Albatross has some desirable features besides its low latencyand high throughput. It allows nodes to bootstrap quickly byonly requiring them to download all of the macro blocks andthe most recent micro blocks. It offers strong probabilisticfinality, with a certainty of 99.9% being reached in only6 blocks. And honest clients can get instant confirmationthat their transaction will be accepted by directly asking forreceipts from the validators.
C. EnsoEnso [3] is a general-purpose virtual machine forblockchains developed by Trinkler Software.Blockchains can be seen as distributed virtual machines,since they are designed to run a given application on a networkof heterogeneous, and possibly malicious, nodes. We canrepresent a blockchain as a stack:App data ≡ StateApp logic ≡ STFConsensusNetworkingWhere
STF is the state transition function. Note that theapplication logic, also called the runtime , is embedded intothe state transition function, while the application data isembedded in the state. For example, in the case of Bitcointhe application logic is that of a ledger and the applicationdata is the set of all unspent transactions. This model workswell for most cases but it is cumbersome to program and failswhen it is necessary to update the application logic.We take a different approach and have the state transitionfunction be a general-purpose virtual machine. Then, theapplication logic and data can reside in the blockchain state:App logic & data ≡ StateVirtual machine ≡ STFConsensusNetworkingEnso is this virtual machine. Having a general-purposevirtual machine speeds up development, since only the stateneeds to be programmed, and allows for simpler and morefine-grained updates, because the state can be changed withsimple extrinsics instead of forks.Enso itself is a relatively simple virtual machine, inside of iteverything is either an object or an event . Objects are entitiescomposed of: • ID:
An unique identifier of the object. It can be any string. • Code:
A block of code containing functions that can becalled by other objects. • Storage:
A data structure containing arbitrary informa-tion and that can be read and modified by the code.While events are asynchronous function calls from oneobject to another and always have the following information: • priority: The priority of the event, used for the eventqueue.2
ID_to:
The ID of the object that will receive the event. • function_call: The name of the function that willbe called. • parameters: A list of parameters that will be passedto the function.The state of the blockchain is the set of all objects, and itis these objects that will contain all the application logic anddata.
Everything is an object .The virtual machine itself is composed of just two compo-nents: the event queue and the super object .The event queue is, as the name indicates, a queue forevents. It is an ordinary priority queue and, when any event iscreated, it is added to this queue. Events with a higher prioritygo to the top of queue, while events with a lower priority goto the bottom.The super object is a special object that is unique and cannot be deleted or changed in any way. It is similar to the superuser in Linux systems, in that it has complete control over thestate. In fact, it is the only object that can change the ID,code and storage of other objects. The super object has thefollowing interface: • Create(ID, code, storage):
Creates a new ob-ject with the given ID, code and storage. • Delete(ID):
Deletes object with the given ID. • Check(ID):
Checks if any object exists with the givenID and returns the answer. • Request_object(ID):
Returns the code and storageof the object with the given ID. • Change_ID(ID, new_ID):
Changes the ID of theobject with the given ID to new_ID . • Change_code(ID, new_code):
Changes the codeof the object with the given ID to new code. • Change_storage(ID, new_storage):
Changesthe storage of the object with the given ID tonew storage. • Set_input(ID):
Sets the input object to the objectwith given ID.The input object is the object that is designated to receiveextrinsics. An extrinsic in Enso is just a event like any other,but with the caveat that it must be sent to the input object.Any object can be the input object, the only requirement isthat it designated as such by the super object.A state transition in Enso looks like this:1) Receive an ordered list of extrinsics.2) Add the first extrinsic to the event queue.3) The resulting event will be sent to the input object. Theinput object then may create more events, that in turnwill also be processed and create more events, and soforth, until no more events are created.4) Add the next extrinsic to the event queue and keeprepeating steps 3 and 4 until there are no more extrinsics.
D. ACTUS
The
Algorithmic Contract Types Unified Standards [4], or
ACTUS , is a standard developed by the ACTUS Financial Research Foundation. It seeks to describe all possible financialcontracts as algorithmic patterns of cash flows between twoparties.In ACTUS, any financial contract can be replicated as acombination of simpler contracts, called contract types . Thesecontract types include basic financial contracts, like annuitiesand futures, and more exotic ones, like perpetual bonds andcredit default swaps. In total there are 32 contract types, andtogether they form a taxonomy of financial contracts.The contract types themselves are defined in algorithmicform. In other words, for each contract type there is aset of rules that, given some input parameters and externaldata, determine unambiguously the cash flows between thetwo parties to the contract. This allows them to be easilyimplemented in smart contracts. And, by combining differentcontract types, we can create any imaginable financial contractin algorithmic form.There are five types of parameters that define a contracttype: attributes, variables, contract events, payoff function andstate transition function: • Attributes are parameters that are static. They are definedwhen the contract is created and then they never change. • Variables, as the name indicates, are parameters thatare dynamic. At the time of the contract creation theyare initialized to a given value, but they may changeafterwards. • Contract events are actions that cause a cash flow and/ora change in the variables. They may be scheduled, forexample at the beginning of every month, or initiated byan external object, for example by one of the parties. • The payoff function takes the attributes, the currentvariables and an event as inputs, and outputs a cash flowobligation from one party to another. The state transitionfunction takes exactly the same inputs, but it outputs newvalues for the variables. Together, these two functionsconstitute the logic of the contract.Contracts have two interfaces that enable it to interact withother objects: the risk factor observer and the child contractobserver.The risk factor observer allows the contract to request datafrom an oracle object, such data can be, for example, priceinformation or interest rates.The child contract observer allows one contract to observethe attributes, variables or events of another contract. Thisfunctionality is what makes it possible for several contracttypes to be joined together into more complex financialcontracts.Another useful characteristic of ACTUS contracts is thatthe cash flows between both parties of a contract, called the creator and the counterparty , can be tokenized . By this wemean that it is possible for users to have fractional ownershipof a contract, thus it is perfectly possible to have the creator’sor counterparty’s cash flows (both positive and negative) bedivided among several different users.Tokenization also creates a simple way of transferringownership of a contract. This feature is optional for any3 ig. 1. The ACTUS taxonomy of financial contracts. contract, since in some cases it may be undesirable, but whenactivated, it makes it possible for contracts to be sold insecondary markets.
E. Town CrierTown Crier [5], developed by the Initiative for cryptocur-rency and Contract (IC3), is an authenticated data feed systemfor smart contracts, also known as an oracle . It acts as a bridgebetween HTTPS-enabled websites and blockchains, and doesso by taking advantage of a trusted execution environment ,specifically the
Intel SGX .A trusted execution environment can be thought of as aspace inside the CPU that allows programs that run insideit to be protected from other programs, the operating systemand even from some types of hardware attacks. This spaceis called an enclave , and it is basically a black box insidewhich programs are certain to be executed correctly and withconfidentiality.An enclave can only use the CPU and the RAM by itselfand needs to rely on the operating system for file and networkaccess. However, by using public key cryptography, it canestablish secure connections over the internet. Another useful feature of enclaves is that they can providea publicly verifiable proof that a given program was executedcorrectly and produced a given output. Such a proof is calledan attestation .In order to serve source-authenticated data to smart con-tracts, the Town Crier system only needs a specific smartcontract, called the oracle , and a relaying server, called the
TC server .The oracle contract acts as the front-end for the blockchain,creating requests for data, verifying attestations from enclavesand distributing rewards to servers that provide data.The TC server has two components: the relay and theenclave. The relay handles all the network traffic to andfrom the enclave, since the enclave itself has no networkingcapabilities. The enclave establishes HTTPS connections towebsites and produces attestations.The process works as follows:1) The oracle contract produces a request for data. It doesthis by updating its state and signaling that it is readyto receive data from a TC server.2) The relay, who periodically watches the blockchain, seesthe data request and relays it to the enclave.4 ig. 2. The Town Crier system.
3) The enclave processes the request and initiates a HTTPSconnection to the requested website.4) The relay handles the traffic between the enclave andthe website during the HTTPS session.5) The enclave scrapes the website for the requested dataand produces an attestation that the scraping was donecorrectly. Then, it sends the data and the attestation tothe oracle.6) The relay forwards the data and attestation to the oracle.7) The oracle, after verifying that the attestation is correct,updates its state with the new data. Then, if appropriate,it distributes a reward to the TC server.8) At any point, other contracts can fetch data from theoracle by requesting its more recent state.Town Crier was recently acquired by Chainlink [6], a projectthat provides decentralized oracles for a variety of blockchains.Oracle contracts in Katal are updated by Chainlink nodes usingthe Town Crier protocol.
F. PolkadotPolkadot [7] is a heterogeneous multichain framework in-troduced by Gavin Wood in 2016. It is a protocol that allowsblockchains to exchange information, but unlike internet mes-saging protocols like TCP/IP, Polkadot also enforces the orderand the validity of the messages between the blockchains.Polkadot is composed of a central blockchain, called the relaychain , and a number of peripheral blockchains, called parachains , that connect to it. Parachains may outsource theirconsensus to the relaychain or have their own consensus al-gorithm and validators. The relaychain, as the name indicates,acts as a relay for messages between different parachains.Connecting to Polkadot enables Katal to not only exchangeinformation with other parachains but also for other parachainsto transfer tokens to the Katal blockchain and vice-versa.III. O
VERVIEW
The Katal technology stack is illustrated in Figure 4.Analyzing it we see that Substrate Core is at the bottomand is used for networking, module swaps and other auxiliary
Fig. 3. Polkadot: relaychain and parachainsFig. 4. Katal technology stack services. Albatross and Enso are, respectively, the consensusalgorithm and the virtual machine, and they will be imple-mented as modules in Substrate. Lastly, there is the Katalruntime on top.It is the runtime that enables Katal capabilities and so,for the rest of this paper, we will focus mostly on it. BothAlbatross and Enso are explained in detail in two other papers[1] [3].The Katal runtime is composed of a set of objects and theinteractions among them. Broadly speaking, the objects canbe divided in two categories: • Kernel objects:
All the objects that are created at thegenesis block and during updates to the blockchain. Theseare the objects that define the rules for how the runtimeworks and are unique objects, meaning that there is onlyone instance of each object type. An example of a kernelobject is the governance object , which handles updatesto the blockchain. • User objects:
All the objects that are created by the users.Any user can create user objects from a predeterminedlist of object templates. For example, there is an accounttemplate and each instance of that template, created bythe users, is an account object .For a full description of the Katal runtime it is enoughto outline all the kernel objects plus all the different object5emplates. Let us begin with the kernel objects: • Dock object:
It serves as the point of entry for extrinsicsand is always the first object to be called, in other wordsit is the input object . It parses each extrinsic, verifiestheir signatures and then creates the events to the desiredobjects. • Authentication object:
It maintains a list of the IDs ofall user objects and their corresponding authenticationmethods. The dock object calls this object to verify thesignatures on transactions. Other objects may also call itwhen they need authentication services. • Schedule object:
It enables periodic, or scheduled, callsto other objects. Every block it receives from the dockobject the current time and block number and thenproceeds by calling any objects that are scheduled to becalled at that particular time. • Instantiation object:
It creates all user objects. Users cancall it to create a new user object from a list of objecttemplates. It maintains the list of object templates anddefines which parameters are allowed for the instantiationof those templates. • Native issuance object:
It is a special instance of themore general issuance template . It manages the nativetoken (
XTL ) by maintaining a list of all object IDs andtheir corresponding balance. It also deals with transfer-ring, minting and burning
XTL tokens. • Governance object:
It implements whichever gover-nance method is chosen to update the blockchain. No-tably, it is the only object that possesses unrestrictedaccess to the super object , thus allowing it to modifyany part of the Katal runtime. • Consensus object:
It manages certain tasks related tothe consensus algorithm. Namely, it maintains a listof validators and their staking deposits, applies slashinherents, distributes block rewards, etc.Besides these seven kernel objects, the Katal runtime is alsocomposed of the following four user object templates: • Account object:
It is the most basic object in theruntime, being basically just an ID. Whenever an ac-count is created, a corresponding entry is created in theauthentication object with the authentication method andparameters chosen by the user. • Issuance object:
It creates and manages its own tokens.It can be user-controlled or automated, is capable ofmanaging several different token types and supports bothfungible and non-fungible tokens. • Oracle object:
It maintains an external data feed byserving as the interface for Town Crier servers. It createsrequests for data, validates the data authenticity anddistributes rewards to servers. • Contract object:
There are actually 32 different con-tract templates, one for each ACTUS contract type. Allcontract objects are capable of interacting with issuanceobjects, to create cash flows, and with oracle objects, tofetch data. It also maintains a list of all its owners, both creators and counterparties, for tokenization purposes.The above list gives a rough description of all the objectsbut it does not shed much light on how they interact together.Even though it is not possible to detail all possible interactionsin this paper, we will now discuss some of the most commonones.
A. Transaction docking
All transactions pass first through the dock object. Anytransaction is just a ‘bundle’ of function calls to other objects,and the dock object must first verify the validity of thetransaction before creating the corresponding events for thosefunction calls.When the dock object receives a transaction it will firstcheck that it is well-formed. Then it will call the authenticationobject to verify the signatures contained in the transaction. If,and only if, all signatures are valid then the dock object willcreate the requested events. Each of these events will include,as part of their parameters, the IDs of everyone that signedthe transaction.
B. Token transfers
Like ERC-20 tokens in Ethereum [8], tokens in Katal aremanaged by a single object. In other words, instead of everyaccount storing the balance of every token that it owns, foreach token there is a single object that stores the ID andbalance of every account that owns those tokens. These objectswe call issuance objects .When an account wants to transfer some tokens to anotheraccount, it just sends a request to the issuance object of thattoken. The issuance object will then update its internal ledgerto reflect this change.6 . Schedule functions
It is useful to have functions that are started at predefinedtimes. For example, we may want an oracle that is updatedevery minute. In order for this to happen, some object needsto call the oracle object every minute, so that it can acceptupdates to its state. That object is the schedule object.Every block the dock object sends the current block numberand time to the schedule object. The schedule object has a listof functions, IDs and conditions. Upon receiving the blocknumber and time, it goes through this list and, if any of theconditions is satisfied, it triggers the corresponding functionat the corresponding ID.
D. Oracles and data feeds
Each oracle contract only maintains one specific data feed.When they request an update, a Town Crier server can senda transaction containing the update and potentially receive areward. Other objects can send a function call requesting datafrom the oracle and it will respond back with the most recentdata in its state.
E. Template instantiation
Users can create new objects using the instantiation object.Through the dock object, a user can request the instantiationobject to create a new object from a list of templates. Theinstantiation object then sends the necessary events to thesuper object and also, in some cases, to the authenticationand schedule objects.
F. Governance
The main purpose of the governance object is to controlwho can have unrestricted access to the state, and especiallyto the super object. It will receive calls from the dock objectand, given its internal logic, it will decide if the calls are tobe forwarded or not.IV. S
PECIFICATION
In this section we will detail the runtime of Katal, beginningby giving some general remarks and then by describing thekernel and user objects. Our focus will be on the objectsinterface and function.
A. General1) Reserved namespace:
There is a reserved namespace forthe kernel objects. The namespace consists of all the IDs thatbegin with ’XTL’ . For example, the dock object will have thename ’XTL Dock’ .User objects are not allowed to have an ID that begins with ’XTL’ . This is enforced by the instantiation object, who willnot accept any requests to create an user object with an ID inthat namespace.
2) Transactions:
A transaction is a bundle of function callsto objects. Users can join several different function calls intothe same transaction and sign them. The function calls are onlyforwarded by the dock object if all the signatures are valid. Atransaction has the following format: • [ID]: A list of the IDs that are authorizing this transac-tion. • [Function calls]: A list of the desired function calls. • Window:
Determines the time window in which thistransaction is valid. For example, if the window is [2000 , then the transaction will only be acceptedbetween the block number 2000 and the block number2050. • Nonce:
A long integer chosen by the users. Together withthe validity it prevents replay attacks . • [Signature]: A list of the signatures for this transaction,one for each ID.Where [.] represents a list. A transaction can also be thoughtof as a wrapper to a series of function calls. These functioncalls have the following format: • ID_to:
The ID of the destination object.7 call_function:
The function to be called at thedestination object. • [user_parameters]: A list of user-provided param-eters to be passed to the function.
3) Origin ID:
All function calls, except the extrinsics fedinto the dock object, will include in their parameters the field
ID_from which is the ID of the object that originated thefunction call.Adding this information to every function call allows objectsto have functions that can only be called by certain objects.For example: • Internal functions that can only be called by other func-tions in the same object, • Kernel functions that can only be called by kernel objects, • User-forbidden functions which are functions that do notaccept calls from the dock object, thus they cannot becalled by users, • User-only functions which are functions that are meant tobe called by users and as a result only accept calls fromthe dock object.
4) Extrinsics order:
A block is composed of several extrin-sics, either transactions or inherents, and they are fed into thedock object into a specific order: • Timestamp:= { time, block number } : An inher-ent that contains timing information. It is forwarded tothe schedule object. • Slash:= { ID } : An inherent that is used to slash thestake of a misbehaving validator. It is forwarded to theconsensus object. • Seed:= { seed } : An inherent that contains a randomseed used to select a new validator set. It is forwarded tothe consensus object only in macro blocks, otherwise itis ignored. • Transactions:= { [transactions] } : The list oftransactions. They are only sent in micro blocks. • Reward:= { ID } : An inherent containing the ID towhich the block reward is paid to. It is forwarded to theconsensus object.
B. Kernel objects1) Dock:
The dock object acts as the point of entry forextrinsics and its interface only has one function: • input(extrinsic): Parses the extrinsic and veri-fies its validity. If it is a transaction then it calls theauthorization object to verify the signatures and, if theall signatures are valid, then forwards the function callsto the correct objects.For each function call in the extrinsic a new event iscreated by the dock object with the format e(priority,ID_to, call_function, ID_from, [auth_ID],[user_parameters]) , where [auth_ID] is the list ofevery ID that signed the transaction.
2) Authentication:
The authentication object verifies au-thentication proofs provided by the users. To do so it maintains the following internal key-value store, called the authentica-tion registry : Key ValueID (Method, [Parameters])Where method is any authentication method supported bythe authentication object. It can be a signature scheme likeECDSA, Schnorr or BLS, or a multisignature scheme, or ahash-lock, or even a zero-knowledge proof system. The pa-rameters are any information necessary to authenticate proofs.For example, in the case of ECDSA the parameters would bethe public key.The next functions form the interface of the authenticationobject: • verify([message, ID, proof]): Goes throughthe list verifying that each proof is a valid authenticationof the message by the corresponding ID. Accepts callsfrom any object. • method(message, proof, parameters): General function type for authentication. There is oneinstance for each different authentication method. It isan internal function, and as such it accepts only callsfrom the authentication object. • add_key(ID, method, parameters): Adds theID with given method and parameters to the authentica-tion registry. Does not accept calls from the dock object. • change_key([auth_ID], ID, method,parameters): Changes the authentication method ofthe object with given ID. Accepts calls from any object,but if the call originates from the dock object, it willonly be accepted if ID ∈ [auth_ID] . • delete_key([auth_ID], ID): Deletes the entryin the authentication registry with given ID. Accepts callsfrom any object, but if the call originates from the dockobject, it will only be accepted if ID ∈ [auth_ID] .
3) Schedule:
The schedule object serves to make functioncalls to other objects at regular intervals. To achieve this,it maintains an internal key-value store called the scheduleregistry : Key Value(ID, Function) ConditionThe key identifies which function needs to be called atwhich object, and the value states under which conditions thefunction call will be triggered.Its interface is composed of the following functions: • init(block_number, timestamp): The mainfunction of the schedule object, it is called once everymicro block by an inherent. It goes through the entireschedule registry and checks if block number and times-tamp satisfies any of the conditions. If it does, it triggersthe corresponding function call. • add_key(ID, function, condition): Addsthe given ID, function and condition to the scheduleregistry. Does not accept calls from the dock object.8 delete_key(ID, function):
Deletes the entry inthe schedule registry with given ID and function. Doesnot accept calls from the dock object.
4) Instantiation:
The instantiation object creates new userobjects from a set of object templates. Its interface consists ofonly two functions: • create([template_ID, parameters]): Foreach item in the list it checks if the requested ID isavailable and, if they are all available, then instantiatesthe requested objects from template_ID with thegiven parameters. Accepts calls from any object. • template_ID(parameters): General functiontype, one exists for each object template. It instantiatesa new object with the given parameters. It is an internalfunction.
5) Governance:
The specific implementation of the gover-nance object will depend on the governance method used. So,it is not possible for us to give a description of the object thatwill be valid in every case.However, we will exemplify the simplest case, which iswhen one single ID has full control over the governance.This hypothetical dictatorship object would have the followinginterface: • transmit([auth_ID], ID_call,function_call, parameters): If dictator_ID ∈ [auth_ID] , it forwards therequested function call. Where dictator_ID is hardcoded into the function. This function basically gives dictator_ID full access to the entire state.
6) Native issuance:
The interface for the native issuanceobject is exactly the same as any other issuance object (seeIV-C2), since it is just an instance of the issuance template.However, we can be more specific regarding its specifica-tion: • There is only one asset_ID , which is the native token
XTL . • The mint and burn functions only accept calls fromthe consensus object.
7) Consensus:
The consensus object deals with all thetasks related to the validators, specifically managing stakedeposits, collecting fees and distributing block rewards. To doso, the consensus object has a key-value store of all potentialvalidators, called the validator registry :Key ValueID (deposit, validating key, status)The key is just the ID of the account that deposited thestake. The value contains the amount deposited (in
XTL ), thepublic key used to validate blocks and the status. The statusjust indicates if the validator is currently active or not. • stake([auth_ID], ID, amount,validating_key): Transfers the given amountof
XTL to the consensus object. If successful, it addsID, validating key and amount to the validator registry. It accepts calls from any object, but only if ID ∈ [auth_ID] . • restake(ID, new_validating_key,signature): Calls the authentication object tocheck if signature is valid. If it is, it replaces thevalidating key of ID. • unstake([auth_ID], ID): Returns deposit backto ID and removes the corresponding key from validatorregistry. It accepts calls from any object, but only if ID ∈ [auth_ID] . • fee([auth_ID], ID, amount): Transfers agiven amount of
XTL to the consensus object. Ifsuccessful, updates block reward value. It accepts callsfrom any object, but only if ID ∈ [auth_ID] . • slash(ID): Divides the deposit amount of the givenID between all other active validators and deletes thecorresponding key from the validator registry. Can onlybe called with an inherent. • reward(ID): Transfers the block reward to the givenID. Can only be called with an inherent. • change_validators(seed): Produces a new listof active validators from the seed and updates the registryaccordingly. Can only be called with an inherent.
C. User objects1) Account:
Accounts are the object most utilized byusers and also the simplest. They are basically just an ID.All the functionality normally associated with accounts, liketransferring tokens and entering into contracts, is provided byother objects.The interface of an account has a single function: • self_destruct(): Deletes this object and all dataassociated with it.
2) Issuance:
Issuance objects create and destroy tokens,and maintain a list of everyone who owns tokens. Eachissuance object can have several different token types, eachidentified with asset_ID . Because of this property, issuanceobjects can support both fungible and non-fungible tokens.Its interface is composed of the following functions: • mint(owner_ID, asset_ID, amount): Createsa given amount of tokens of type asset_ID and de-posits them in owner_ID . Depending on the optionchosen, it can be called by no one, by a predeterminedset of IDs or it can be scheduled. • burn(owner_ID, asset_ID, amount): Destroys some amount of tokens of type asset_ID in owner_ID . Depending on the option chosen, it can becalled by no one, by a predetermined set of IDs or itcan be scheduled. • transfer(owner_ID, destination_ID,asset_ID, amount): Sends a given amountof tokens of type asset_ID from owner_ID to destination_ID . Accepts calls from any object, butif the call originates from the dock object, it will onlybe accepted if owner_ID ∈ [auth_ID] .9 check(owner_ID, asset_ID): Returns the bal-ance in asset_ID tokens of owner_ID . Does notaccept calls from the dock object. • self_destruct(): Deletes this object and all dataassociated with it. Depending on the option chosen, itcan be called by no one, by a predetermined set of IDsor it can be scheduled.
3) Oracle:
Oracle objects are the front-end to the TownCrier system. Their main purpose is to maintain a data feed.Such a data feed can be any tuple, as long as it includes atimestamp:
Data:= { a, b, ... , timestamp } Oracle objects have the following interface: • request(): Turns on a flag stating that it will allowupdates to the data feed. • update(value, timestamp, proof,receiving_ID): Updates the oracle data feedwith the given value and timestamp, after verifyingthe accompanying proof. It can provide a reward to receiving_ID . It accepts calls from any object, butit may be permissioned. • fetch(): Returns the latest value and timestamp. • set_reward(issuance_ID, asset_ID,amount): Sets the reward per update to amountof asset_ID at the object issuance ID. Dependingon the option chosen, it can be called by no one, by apredetermined set of IDs or it can be scheduled. • self_destruct(): Deletes this object and all dataassociated with it. Depending on the option chosen, itcan be called by no one, by a predetermined set of IDsor it can be scheduled.
4) Contract:
Contracts are any financial contracts that are apart of the ACTUS standard. There are 32 different contracts,so it is not possible for us to give a detailed descriptionof every single one. However, the interfaces of all contractsfollow the same pattern.The interface of a contract has two main functions: 1)processing events and 2) managing ownership of the contract.This results in the following general interface: • event(parameters): General function type, it isany event of the associated ACTUS contract type. Itcan be triggered by a user or by the schedule object.When triggered, the contract will update its internal state,fetch data from an oracle, observe another contract and/orcreate a cash flow. • transfer(owner_ID, destination_ID,position, amount): Transfers fractionalownership of the contract, corresponding to eitherthe creator or counterparty position. Accepts calls fromany object, but if the call originates from the dockobject, it requires authorization of both owner_ID and destination_ID . Depending on the contractparameters, ownership transfer may not be allowed forthe creator, the counterparty or both. • check(owner_ID, position): Returns the own-ership amount of a given position by owner_ID . Doesnot accept calls from the dock object. • self_destruct(): Deletes this object and all dataassociated with it. It can be scheduled or triggered by acontract event.Some explanation is needed about the ownership mecha-nism. In order to support tokenization contracts have some ofthe functionality of a issuance object. Specifically, all contractshave exactly two different asset IDs, one for the creatorposition and another for the counterparty position. Also, eachof these asset IDs has exactly one token unit. So, if someoneholds 0.2 counterparty tokens, that means that he owns 20%of the counterparty position.Contrary to the tokens of issuance objects, which are justsymbolic representations of external assets, contract tokenshave a more active role inside Katal. Contract tokens givewhoever holds them a share in the future cash flows (positiveor negative) generated by the contract.A cash flow is executed by a contract by directly callingan issuance object or another contract object. For example,imagine that Alice has 0.2 creator tokens, Bob has 0.8 creatortokens and Charlie has 1 counterparty token. If a contractgenerates a cash flow of 100
XTL from the creator to thecounterparty, it will call the
XTL issuance object to transfer20
XTL from Alice to Charlie and 80
XTL from Bob to Charlie.V. F
UNCTIONALITY
Developers can build an endless variety of financial servicesin Katal by combining different ACTUS contracts. In this sec-tion we will give a few examples of the financial applicationsthat can be created.
A. Asset-backed tokens
Issuance objects can be used to create tokens that representany asset, all that is needed is a trusted entity to hold custodyof the underlying assets and to allow the exchange betweenthe token and the asset. This is one of the methods used tocreate stablecoins.Any asset can be used to create asset-backed tokens, forexample: • Fiat currencies like US Dollar, Euro, Swiss Francs, etc, • Stocks of exchange-traded companies, • Commodities like gold, silver or oil, • Land, houses and other real estate.By far, the most useful asset-backed tokens are the onesbacked with fiat, since they can be used as a settlementcurrency for financial contracts. But other assets also openinteresting possibilities, like using stock-backed tokens to10reate a Katal stock exchange, or using real-estate-backedtokens to create a land registry.Some critics point out that asset-backed tokens are central-ized, but the matter of fact is that there is no better option.For tangible assets, like commodities and real estate, noblockchain can hold custody of them, so a central entity isrequired.
Physical assets can not be stored in a blockchain.
For intangible assets, like stocks and currency, it is tech-nically possible to store them in a blockchain. However, bydefinition, these are centralized assets. A central bank controlsthe currency that it issues, and a company controls its ownstock.
B. Transfers
Transfers are the simplest financial service and also one ofthe most basic functions for any blockchain. The convenienceand usability of transfers in Katal matches, or even exceeds,that of banks, online payments systems and other cryptocur-rencies: • Variety of currencies: Katal supports transfers of both fiatcurrencies, through asset-backed tokens, and cryptocur-rencies, through Polkadot connectivity. • Human-memorable addresses: Accounts in Katal canhave any unique string as their address, thus being moreuser friendly than other blockchains and banks. • Variety of authentication: Katal supports a variety ofauthentication methods and lets its users pick the methodthat they prefer for their own account. • Speed: Katal’ consensus algorithm, Albatross, can final-ize transactions in just a few seconds.
C. Token exchange
Many blockchain projects revolve around doing exchangesbetween different tokens. In Katal, a token exchange can beexecuted with a single contract, called a foreign exchangecontract .If Alice and Bob want to exchange two types of tokens, theyonly need to create the contract. Afterwards, it will transferthe respective tokens out of Alice’s and Bob’s accounts andtransfer them to their new owner.The foreign exchange contract is atomic , meaning that iteither completes successfully or it does not happen at all.There is no risk for any of the parties involved. Given that Katal supports both asset-backed tokens andcryptocurrency tokens (of any blockchain that connects toPolkadot), in addition to its native token
XTL , the tokenexchange contract can be used in a variety of interestingsituations: • Fiat-XTL: Buying XTL inside Katal using a fiat-backedtoken. • Fiat-Stock: Buying and selling stocks using a fiat-backedtoken, akin to a stock exchange. • Fiat-Crypto: Buying and selling cryptocurrencies withfiat. • Crypto-Crypto: Exchanging different cryptocurrencies.
D. Collateralized loans
More complex services can be constructed, for examplecollateralized loans. Imagine Alice has a house, which isrepresented in Katal by an asset-backed token, and she wishesto ask Bob for a loan while giving her house as collateral. Todo this, Alice and Bob first create two contracts, an annuitycontract and a collateral contract, that will codify the terms ofthe loan.After creating the contracts, the following series of cashflows will happen:1) The loan amount from Bob’s account and the collateralfrom Alice’s account are transferred into the correspond-ing contracts.2) The loan amount is transferred to Alice’s account.3) Periodically, payments are transferred from Alice’s ac-count to Bob’s account.4) If at any time, Alice does not have enough money in heraccount for the loan payment, the collateral is transferredto Bob.5) If every loan payment is made, at the end of the loancontract the collateral is returned to Alice’s account.Note that Alice and Bob do not need to interact with theblockchain after the contracts are created. All the cash flowsare initiated and managed automatically by the contracts.
E. Margin trading
Margin trading is the act of borrowing money to buy assetsand is widely used in all areas of finance.In margin trading borrowers are required to maintain thenet value of their position, meaning the difference between11he value of the assets and the value of the loan, at a constantvalue. This value is called the margin .This financial service can also be done in Katal, and is infact similar to collateralized loans. Imagine Alice wants to buy
XTL on margin and to do so she will borrow money, in theform of
XTL tokens, from Bob. Alice will maintain her marginusing fiat-backed tokens. They will create two contracts: acollateral contract and a margin contract.An oracle for the price of
XTL is also necessary for adjustingthe margin amount. With the contracts created, the followingcash flows will take place:1) The borrowed
XTL is transferred from Bob’s accountinto the collateral contract, and the margin amount istransferred from Alice’s account into the marginingcontract.2) Periodically, the margining contract will query the oraclefor the
XTL price and adjust the amount of marginaccordingly, transferring cash in and out of Alice’saccount to maintain the necessary margin.3) When Alice decides to terminate her position, or whenshe is no longer able to maintain the margin, the collat-eral and the margin are transferred into Bob’s account.4) If, when her position is terminated, Alice has made aprofit then part of the collateral will be transferred intoher account.In this case we exemplified margin buying, but a similarscheme can be used for margin selling, also known as short-selling.
F. Futures
Futures are one of the most versatile financial contracts,allowing anyone to speculate not just on assets, but onpractically anything, for example commodities, stocks, bonds,cryptocurrencies, fiat currencies, indexes, interest rates, energy,weather, etc. As long as there is some publicly availablenumerical value, a futures contract can be created for it.Imagine Alice and Bob want to speculate on the price of oil.First, they need to see if an oracle for the price of oil exists inKatal, this is necessary for the contract. Then, Alice and Bobcreate three contracts: a futures contracts and two marginingcontracts, one for each of them. After the margin amount gets transferred into the margincontracts, the rest of the exchange proceeds as follows:1) At regular intervals, the futures contract fetches thecurrent price of oil from the oracle and updates its stateto reflect the profit and loss of each of the parties. Themargining contracts also observe the futures contract andadjust the amount of margin required.2) The margining contracts transfer cash in and out ofAlice’s and Bob’s account to maintain the necessaryamount of margin.3) When the futures contract ends, it will settle by makinga transfer from one margining contract to the other.4) Then the margin contracts will terminate and return theirdeposits to Alice’s and Bob’s accounts.
G. Options
An option is a contract that gives one party the option tobuy or sell a given asset at a predetermined price. One partywill pay a fee upfront in order to have that option, while theother party will receive that fee. So, the party that buys theoption only has upside and the party that sells the option onlyhas downside.Like futures, options can also be used to speculate on almostany asset. The scheme for options in Katal is also very similarto the futures scheme.Imagine Alice wants to buy an option on the price of goldfrom Bob. Alice will pay Bob for the option and, at the same12ime, an options contract and a margin contract will be created.The next cash flows will then happen:1) Periodically, the options contract requests the currentprice of gold from the oracle and updates its state toreflect the profit and loss of each of the parties. Themargining contract observes the options contract andadjusts the amount of margin required.2) The margining contract transfers cash in and out ofBob’s account to maintain the necessary amount ofmargin.3) When Alice exercises the option, or when it expires, itsettles by transferring the necessary amount from themargining contract to Alice’s account. The rest of thedeposit is returned to Bob’s account.VI. C
ONCLUSION
In this paper we introduced Katal, a new blockchain de-signed purposely for the creation of decentralized financialservices and applications. All the different components ofKatal allow it to offer a better experience for both users anddevelopers than the one that would be possible using currentgeneral-purpose blockchains.We feel confident that Katal will help revitalize the currentdecentralized finance industry by making it simpler thanever to create non-custodial trustless interoperable financialcontracts. VII. A
CKNOWLEDGMENTS
We would like to acknowledge all other members of theTrinkler Software team, without whom Katal would not bepossible. In alphabetical order: Addison Huegel, Arie Levy-Cohen, Herv´e Fulchiron, Mark Greenslade, Nils Bundi andSeraya Takahashi. R
EFERENCES[1] B. Franc¸a, M. Wissfeld, P. Berrang, P. von Styp-Rekowsky, andR. Trinkler, “Albatross: An optimistic consensus algorithm,”
White Paper ,2019. [Online]. Available: https://katallassos.com/papers/Albatross.pdf[2] M. Castro, B. Liskov et al. , “Practical byzantine fault tolerance,”in
OSDI , vol. 99, 1999, pp. 173–186. [Online]. Available: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.127.6130[3] B. Franc¸a, “Enso: A general-purpose virtual machine,”
White Paper ,2019. [Online]. Available: https://katallassos.com/papers/Enso.pdf[4] N. Bundi, “Actus: The algorithmic representation of financial contracts,”
White Paper , 2018. [Online]. Available: https://docs.wixstatic.com/ugd/3df5e2 eceb16e5f7f14d11903a6412aebb9e4a.pdf[5] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier:An authenticated data feed for smart contracts,” in
Proceedings ofthe 2016 ACM SIGSAC Conference on Computer and CommunicationsSecurity . ACM, 2016, pp. 270–282. [Online]. Available: https://eprint.iacr.org/2016/168.pdf[6] S. Ellis, A. Juels, and S. Nazarov, “Chainlink: A decentralizedoracle network,”
White Paper , 2017. [Online]. Available: https://link.smartcontract.com/whitepaper[7] G. Wood, “Polkadot: Vision for a heterogeneous multi-chain framework,”
White Paper , 2016. [Online]. Available: https://polkadot.network/PolkaDotPaper.pdf[8] V. Buterin et al. , “A next-generation smart contract and decentralizedapplication platform,” white paper , 2014. [Online]. Available: https://cryptorating.eu/whitepapers/Ethereum/Ethereum white paper.pdf, 2014. [Online]. Available: https://cryptorating.eu/whitepapers/Ethereum/Ethereum white paper.pdf