ContractPedia: An Encyclopedia of 40 Smart Contract Platforms

A Complete List of all Smart Contract supportive Platforms

The blockchain is changing the world as we know it today.

It solves one of the greatest problems know to the mankind: it removes the need of trust. The way blockchain solves it by creating an unalterable trail of anything that needs trust to operate.

But there is lot of power within this technology.

The power to extend the above property to create rules that need to be followed as written, where every action leads to some reaction. In other words, smart contracts.

Today we are going to list 40(and growing) platforms/projects that support/develop smart contracts. If you find anything missing or wrong here then shoot that in the comments. Also, the article will be updated regularly as I study more about these platforms and projects.

, , , Polkadot

Polkadot Reddit | Polkadot GitHub | Pokadot Telegram

33. Radix

Smart Contract Language: JavaScript/TypeScript

Status: Not Live

Explanation: Scrypto is a state machine which provides security and functional abstraction to virtual-machines that live on top of it. This enables any VM to interface (providing it can) and execute any script in any language.

The planned JavaScript module will simply be a VM that interacts with the Scrypto state machine.

Learning Resources: Radix developer Intro, Radix DLT

Radix Reddit | Radix Github | Radix Telegram

34. Exonum

Smart Contract Language: Rust. Java bindings TBD

Status: Live

Explanation: Services allow specifying the business logic for Exonum applications. They are the main extension points of the framework, which play the same role as smart contracts in some other blockchains.

Exonum Service Architecture

Developing Exonum services is similar to service development in Web or in enterprise platforms; they have the same principal components.


A service has a set of endpoints (realized as REST APIs) using which the service can communicate with the outside world. The Exonum framework acts as middleware, dispatching requests among services and abstracting the intricacies of data (de)serialization, access control, and other typical middleware tasks away from service developers.

There are 3 types of service endpoints:

  • Transactions correspond to PUT or POST requests in REST
  • Read requests correspond to GET requests in REST
  • Private APIs represent administrative and maintenance endpoints, generally not accessible to the outside world.

The key points differentiating Exonum smart contracts from other models used in blockchains are as follows:

  • Restricted environment. Exonum executes only predefined request types, not allowing to execute untrusted code received from a client. This results in a more controlled environment, and makes it easier to argue about smart contract safety
  • No isolation. Request processing is performed in the same execution context as the core of the system. This is beneficial for performance, although has certain security risks
  • Local state. Exonum services may define a local state, which is specific to the node on which the service is running. The local state can be used to manage secret information (e.g., private keys). The local state may be managed by private service endpoints. By utilizing the local state, services can be more proactive than their counterparts in other blockchains. For example, the anchoring service uses the local state to fully automate anchoring transaction signing
  • Split transaction processing. Transaction verification is a separate step of transaction processing. It is performed immediately after receiving the transaction, before applying the transaction to the blockchain state. Verification may include authentication checks (for example, verifying the transaction signature), as well as other structural checks over the transaction contents. At the same time, transaction verification has no access to the current blockchain state

Learning Resources: Exonum Docs, The Bitfury Group

Exonum GitHub | Exonum Reddit | Exonum Telegram

35. Universa

Smart Contract Language: Javascript

Status: Live

Explanation: To understand how Universa’s smart contracts work, we have to break the whole picture into smaller parts.


Each participant in the Universa is represented by the notion of the party. The party could be completely anonymous or physically identified. There are several ways of identifying a party In the root contract the party could be identified by:

  • By the public key, mentioned in the contract body (for example, as the issuer or owner).
  • By the anonymous public key Id which allows identifying the party’s public key without disclosing until to the first usage (for example to make anonymous purchases).

The party could add any other details of itself (name, nick, social security or passport number, whatever) in the contract record.

Inside the contract


  • Definition. Immutable part that can’t be changed in revisions. Contains issuer, issuing timestamp, permissions (some permissions could be also moved to the state), and any data the creator want to be immutable.
  • State. The mutable section which could be changed in revisions. Contains revision number, creator and timestamp, reference to the origin and previous revision, changeable roles and (rarely) permissions and any mutable client data.
  • Attachments. Any file, mentioned by mean of the signed reference in the definition or state.

Universa network knows only definition and state, the rest is never sent to the network. It is important part as attachments may and often contain a sensitive and private information. While this information is well protected by mean of signed references in the contract state and definition, it is even better protected by not being transferred to the Universa network.

So, the full contract is only exchanged between parties involved, where any appropriate transport could be used (email, messengers, clouds, USB flash, whatever). The immutability of the attachments is guaranteed by the signed references in the contract, which are in turn signed by the parties and approved by the network.

So, the chain of trust is:

  1. Universa network approves the revision of the contract, provide the registration time and the immutability of the state and the definition.
  2. Parties that have signed the revision approve (by signing it) that the state and definition are correct, and that they possess all mentioned attachments and agree with them, whatever they are.
  3. Signed references in the state and definition guarantees immutability of the corresponding attachments located somewhere in the client storage.


The smart contract could not be smart enough without it. Universa smart contracts allow Javascript to be included as an attachments. The script can implement actions to be performed by clients, generate new contracts, and process events in a completely automated way. The 3rd generation of the Universa client will be able to run as even as an autonomous web service or web application and, in the GUI client, work as a simple GUI application to perform workflow automation together with user interface. Our target is to allow smart contracts to be full-sized application, with all benefits of Universa platform and services incorporated.

Other languages which compile to pure javascript, like Coffeescript, could also be used and even incorporated in the contract as another attachments, but at the execution time only the signed set of compiled javascript will be used.

The scripts are executed by the client software and in the client’s environment. The Universa network does not ever see the script, but it always check the result to conform with the contract definition and state. It means, that even if a script will perform some forbidden operation, the network will not accept the result. Generally, it is always simpler to specify few permissions and conditions limiting the allowed operations than trying to check the script source for hidden vulnerabilities. The permissions DSL is clean and straightforward, comparing to the script, and permission check performed remotely by the Universa can not be bypassed by the script, which works locally and is never even transferred to the Universa nodes.

The usual script execution cycle is: scripts is being activated by the user or, in the server environment, some event, like incoming contract or payment notification from our Bitcoin integration service. The script then execute, modify its state (each script have some local storage to work with and can access its contract chain), create and approve with Universa new revisions and derived contracts, and, if need, send it over the network using any connected communication tools. Actually the script could be allowed to connect to any network service using HTTPS API.


Smart contract is a tree (structure or hash) of objects and could be stored in any modern format, such as JSON, YAML, XML, BOSS, whatever else that can hold arrays, structures, strings and numbers. YAML-based DSL representation is often used as new contract templates, inside the network contracts are always serialized with BOSS, as it is the best to keep binary data that are widely used in Universa (keys, signatures and binary IDs).


Each smart contract is packed to the heavily protected signed container — the capsule. The capsule consist of the body and set of extended signatures. The body includes a packed binary contract itself and set of extended signatures. Each extended signature signs the body and the own type, fingerprint and timestamp, so many types of electronic signatures could be used at once. The corresponding public keys (or it’s anonymous IDs) are normally mentioned in the contract body so the system can check whether the mentioned key was used to sign the contract.

The contract’s capsule contains no encrypted data, as the part of the contract known to the Universa network should not include any sensitive private data. Instead, such a data must be attached to the contract as signed references (to external files, for example) and will never be transferred to the Universa network, both reducing the unnecessary traffic and protecting private information.

Learning Resources: Universa Docs, Universa

Universa Reddit | Universa GitHub | Universa Telegram

36. Urbit

Smart Contract Language: Hoon

Status: Live

Explanation: Urbit is a secure peer-to-peer network of personal servers, built on a clean-slate system software stack. It uses Ethereum for its functioning.

One simple way to think about Urbit is as a “personal blockchain.” Like a blockchain, Urbit is a deterministic virtual computer. Its semantics are defined by a frozen lifecycle function, which maps its event history to its current state. But, unlike a blockchain, an Urbit instance is a private computer for one user, not a public record for everyone.

Urbit’s lifecycle function is a nano-interpreter called Nock. A typed functional language, Hoon, compiles itself to Nock. An event-driven OS, Arvo, is written in Hoon. Everything above Nock can upgrade itself over Urbit’s own overlay packet network, Ames. Ames is live and stable with test keys.

Our Urbit interpreter runs on any Unix machine. The Urbit server is a single-level store — both database and application engine. Every Urbit event is a transaction. Urbit is semantically frozen and cannot call out to Unix.

Your Urbit instance is your personal server. Your urbit should eventually contain and manage your whole digital life. You may compute at home or in the cloud, based on your security/privacy tradeoff, but Urbit’s formal semantics makes ships trivial to migrate. You’ll never be locked in to one computing provider.

Learning Resources: Urbit Docs, Urbit Data

Urbit GitHub | Urbit Reddit | Urbit Telegram

37. Soil


  • Same as of Ethereum


  • Same as of Ethereum

Smart Contract Language: Solidity

Status: Live

Explanation: SOILcoin is an Ethereum-parallel cryptocurrency, using smart contracts and distributed applications (dApps) run over a “global computer network” secured by blockchain technology utilizing the Dagger algorithm. This “Ethereum Virtual Machine” (EVM) is fueled by the digital currency called SOIL, which acts as the gas that runs the computational processes on the SOILcoin network, and is minted through Proof of Work mining.

Learning Resources: Soil Docs

38. Expanse


  • Same as of Ethereum


  • Same as of Ethereum

Smart Contract Language: Solidity

Status: Live

Explanation: It is regarded as first stable fork of Ethereum and its smart contract implementation is same as of Ethereum.

Learning Resources: CryptoZombies, Solidity Docs, OpenZeppelin

39. Ubiq


  • Same as of Ethereum


  • Same as of Ethereum

Smart Contract Language: Solidity

Status: Live

Explanation: Ubiq is a fork of Ethereum with some improvements, but those alterations don’t effect much on it’s smart contract implementation.

Learning Resources: CryptoZombies, Solidity Docs, OpenZeppelin, Alex Sterk

40. Ethereum Classic


  • Same as of Ethereum


  • Same as of Ethereum

Smart Contract Language: Solidity

Status: Live

Explanation: It is a fork of Ethereum and its smart contract implementation is same as of Ethereum.

Learning Resources: CryptoZombies, Solidity Docs, OpenZeppelin

read original article here