Basics and main concepts

🇬🇧 / 🇷🇺

Smart contracts

A smart contract is the primary element, whose validity can be stored in the Universa distributed ledger. It is a structured document (and can be represented in XML/YAML/JSON forms):

  • with a very specific structure, but having sufficient flexibility to store various data of many kinds;
  • which contents can be restricted by various rules imposed by the original author of the contract (like, “only the current owner of the contract can transfer the ownership to somebody else”);
  • which is not stored by the Universa network itself (and it is often an end user duty to store it somehow);
  • … but if it valid, the Universa network can store the fact it is valid/approved by Universa, in a secure and non-falsifiable way;
  • which may be altered, and new revisions of which may be registered in the Universa (probably revoking the previous revision on which they are based);
  • any new revision of which may be registered only if the previous revision (on which it is based) is approved by Universa, and the new revision is derived from it using some legitimate operation (not contradicting the rules/permissions already defined in the contract).

Note: alternative smart contract platforms may use a different definition for a smart contract, like, “a smart contract is an distributed app which code is stored in the distributed ledger and is executed by every node”. Universa is not a “Dapp sandbox runtime mimicking as a smart contract platform”, Universa is a true smart contract platform where the smartness of the contracts doesn’t require you to code any apps.

If you want to learn the smart contract creation better, you can go to our Smart Contract Designer Central.


A popular case of smart contracts usage is creating the tokens or some other coins/cryptocurrencies (during various ICO/TGE events), and distributing them among the purchasers.

In Universa, the restrictions imposed by the contract authors can be ensured by contract permissions. One of the permissions is a “split-join” permission, meaning the following:

  • each contract in a smart contract family may have some “amount” field containing some number;
  • several multiple revisions can be legitimately derived (“split”) from any revision only if their total amount is the same as the amount of the base revision;
  • and several multiple revisions can be legitimately “joined” only if the result amount is the same as the sum of amounts in the base revisions.

Creating a contract and specifying such a permission properly, will make the contract revisions fungible and will basically create a token-style smart contract.

Universa tokens: UTN and UTNP

Besides being able to create any tokens with ease, some tokens are pre-created for you already, and may have some special meaning for Universa functionality.

The core Universa token is UTN. It is a pre-built token to be used in Universa network for paying its operational fees.

To assist with integrating the Universa with existing platforms (like, exchanges) and make it possible for you to purchase the tokens to pay for the network functioning, the counterpart UTNP token has been created as ERC20 token over the Ethereum network. Historically, it is the token that appeared earlier, as a placeholder token (hence UTNP). Both tokens are convertable to each other at 1:1 fixed rate (the network fees are still to be paid though); and you can use either of them to “feed” the network and pay the transaction costs.

graph TD subgraph Universa network utn(UTN token) end subgraph Ethereum network utnp(UTNP ERC20 token) end pay[... pay Universa network fees ...] utn-->pay utnp-->pay

The total supply of each of these tokens is 4 997 891 952 (which is the amount calculated after the token sale finish). Though for every amount of UTN token in circulation, the appropriate amount of UTNP tokens are locked by Universa, and vice versa. Hence 4 997 891 952 is also the total circulating supply of both UTN+UTNP; while the circulating supply of each of them can freely vary within this limit.

Attention: not every token listed as “UTN” in the Universa interface is a valid UTN token supported by Universa! Similarly, not every ERC20 token in Ethereum network listed as “UTNP” or “UTN-P”, is a valid UTNP-token supported by Universa. The title of the token is not the unique identifier. Please pay attention to what tokens you receive, to prevent being misguided.

You can find more details on these tokens (including how to purchase them and how to distinguish legitimate supported Universa tokens from any other ones), at Universa tokens: UTN/UTNP page.


Another kind of pre-created Universa tokens, are so-called Hypertokens, namely UltraBTC and UltraETH at the moment. They exist to provide a direct mapping of external currencies/assets into the Universa smart contracts; and, inside the Universa, they are 1:1 (consider network fees though) swappable with the resource they are based upon (UltraBTC is based on Bitcoin running on Bitcoin Core blockchain; UltraETH is based on Ether running on Ethereum blockchain).

Attention: not every token listed as “UltraBTC”/“uBTC” or “UltraETH”/“uETH” in the Universa interface are valid hypertokens supported by Universa! The title of the token is not the unique identifier. Please pay attention to what tokens you receive, to prevent being misguided.

Other hypertokens may be created in the future, to provide the Universa counterparts of the assets on other blockchains (including not just the native “coins/currencies” of the blockchains, but the tokens over those blockchains, like, hypertokens for Ethereum ERC20 tokens).

Private keys / public keys / key pairs

The core of Universa authentication and access control is the asymmetric cryptography (see  Wikipedia for details). This means that for Universa, every user must create their own key pair, containing of a private key and a public key (which are mathematically correlated), and use them to sign the operations.

The private key (as clear from the “private” word) is the most-secret part of your key pair. You should never, never give it out, or provide any access to it, to any third parties. If somebody gets your private key, they can perform any actions on your behalf. Storing your private key securely is your duty; all of the Universa functions assume that if some operation is signed by your private key, then it was you who performed it. Think of the private key as your unique personal stamp or signature that nobody besides you can use, and which allows you to sign any document for any other parties.

The public key is, well, public. It can and will be publicly available to various parties you communicate with. It may be stored in various places in the contract, for example, in the creator or owner fields. Think of the public key as the unique name by which you are known to everybody, and which anybody can use to refer to yourself.

How this can be used? Short example: a typical token-style smart contract has an owner field, which may contain your public key; this means, that only you, using the matching private key, can sign any operation to utilize the tokens stored in this smart contract.

When you create your private key/key pair in the web client on your computer (doing it on the mobile or tablet is possible though not recommended), you usually automatically download the file with .unikey extension. This is the binary key file you must store securely. You don’t need to “open” it locally on your computer (it is a binary file, and you see nothing useful or comprehensible even if you open it in some editor; and there is a risk of you occasionally altering it, breaking it forever), but you can use it in your web client, e.g. to sign it to Crypto Cloud, or just to upload it to your keys and then use it for signing the operations.


The address is a short alternative representation of your public key, convenient to be used when you need to enter it in some forms. For your convenience, you can alternatively use a short address (51 symbols long) or a long address (72 symbols long), both referring to the same public key, with the long address providing the ultimate level of security and the short address still sufficient for most usage scenarios.

The addresses are case sensitive and contain  Base58 set of symbols. For even more details, you can read the Key address article.


Multiple clients for Universa network are available.

Most users can start with the Web Client, which you can find at Visit the Web Client page for details.

Advanced users who need to integrate Universa with their system, can use the Uniclient CLI (command-line interface), available for download on your computer and running on Windows, macOS and any other platform supporting Oracle Java. See the Uniclient page to learn more.


Some people may ask if is there “a Universa wallet” or some other similar software/applications.

Please note that the Universa is not “a cryptocurrency” or “a coin” to have “a wallet application”. Instead, it is a platform for smart contracts; and many various tokens (or “coins”/“currencies”) can be easily created over it, but they are far from being the only possible applications of smart contracts.

The “wallet” in Universa is not like a separate “application”, it is just a feature already available in the Universa clients. E.g., if you have any token contracts, in the web client interface they automatically get collected into the Wallets.

If you get the UTN tokens in your web client, they will be shown in a separate wallet. If, during any other ICO/TGE executed over the Universa platform, you receive some other tokens, they will automatically be merged into an independent wallet, too, just using the existing client interface.

Fun Fact: do you know that the Universa Testnet has been launched on November 7th, 2017 (during the 2nd week of the ongoing Token Sale); and just on the next morning one of the community users announced the creation of TeddyBear user, who was giving out the fresh-issued (on Universa) HUG tokens for free? Isn’t that sweet? 💖💖💖


The primary network that stores the Universa distributed ledger is the Mainnet. It is a decentralized network running on top of multiple nodes, some of which are provided by the Universa Foundation and some are run by third parties (who take a share of all the fees for smart contract registrations in the network). (Mainnet has been launched on April 12, 2018. See the current status of the network if you are curious).

In other projects, there are often separate Mainnet and Testnet networks, with the Testnet being the network cheap to operate and ready for various development/experimental works, but sometimes being not fully compatible with the Mainnet, or being different in some settings.

In Universa, even the Mainnet costs are rather tiny (being around €0.01 for a basic smart contract registration).

But there is the Testnet in Universa as well. It is not a separate network, but it is a storage mode of the contract validity; registering the contract in the Testnet is way cheaper than in Mainnet, but it will be heavily time-limited; also, the Testnet-stored data may be occasionally wiped, while the Mainnet data is stored as long as it is needed. Testnet has been launched on November 7, 2017.

If you want to run your own node, visit the Node Owner Central for details.


If you want to utilize the Universa network, you need to have some UTN/UTNP tokens to pay for the network operations. Normally, all the read operations are free and all the “submit contract to Universa” operations are paid. The internal unit of Universa network, representing how much resources the Universa network should spend to deal with your operation, is called U.

So, to work with Universa, you often need to fill your U balance, like, “reserve more U” in the Web Client interface. You will do that by purchasing some “Universa pack”, normally reserves some amount of U (to pay for the Mainnet registrations), and a very generous amount of “test U” (to pay for the Testnet registrations). You can perform that using either UTN or UTNP tokens, depending on which ones you have already.

A basic transaction registration will deplete just 1 U; more complex combinations of contracts may deplete more Us from your balance.

(Internally, both “U” and “test U” just belong to some special Universa smart contracts).

graph TD subgraph Universa network utn(fa:fa-address-card-o UTN token) u(fa:fa-address-card-o Universa pack smart contract:
U balance top-up
test U balance top-up) end subgraph Ethereum network utnp(UTNP ERC20 token) end pay[Purchase a Universa pack] utn--pay-->pay utnp--pay-->pay pay--receive-->u

Crypto Cloud

Crypto Cloud is an extra platform, provided to you by the Universa team, highly integrated with the Universa Web client, but actually orthogonal (optional) to Universa network.

As you know, the Universa network stores the validity of smart contracts, but not the contracts themselves. So you have to keep your contracts somewhere, be it your disk drive, or maybe some external hardware wallet. But for some people, it would be more convenient to store the contracts themselves as well, and being able to easily transfer them to other parties.

graph LR subgraph Your disk subgraph Your private keys pk(fa:fa-file-o fa:fa-key Private_key_1.unikey
fa:fa-file-o fa:fa-key Private_key_2.unikey
fa:fa-file-o fa:fa-key Private_key_3.unikey) end subgraph Your smart contracts c(fa:fa-file-o fa:fa-address-card-o Smart_contract_1.unicon
fa:fa-file-o fa:fa-address-card-o Smart_contract_2.unicon
fa:fa-file-o fa:fa-address-card-o Smart_contract_3.unicon) end end subgraph Universa network uni[Sign operations for Universa network] end pk--sign contracts-->uni c--submit-->uni

Here is why the Crypto Cloud exists.

It is an integrated part of Web Client; and when you “Log In or Sign Up” in the Web Client, you actually log in or sign up to the Crypto Cloud.

graph LR subgraph Your disk pk(fa:fa-file-o fa:fa-key Private_key.unikey) end subgraph Crypto Cloud subgraph Your data, encrypted pkC(fa:fa-key Private key 1
fa:fa-key Private key 2
fa:fa-key Private key 3) cC(fa:fa-address-card-o Smart contract 1
fa:fa-address-card-o Smart contract 2
fa:fa-address-card-o Smart contract 3) end end subgraph Universa network uni[Sign operations for Universa network] end pk--decrypt-->pkC pk--decrypt-->cC pk--sign contracts-->uni pkC--sign contracts-->uni cC--submit-->uni
graph LR you((fa:fa-user YOU)) pwd(fa:fa-key your password) subgraph Crypto Cloud subgraph Your data, encrypted pkC(fa:fa-key Private key 1
fa:fa-key Private key 2
fa:fa-key Private key 3) cC(fa:fa-address-card-o Smart contract 1
fa:fa-address-card-o Smart contract 2
fa:fa-address-card-o Smart contract 3) end end subgraph Universa network uni[Sign operations for Universa network] end you--enter-->pwd pwd--decrypt-->pkC pwd--decrypt-->cC pkC--sign contracts-->uni cC--submit-->uni

Crypto Cloud uses the end-user encryption, so everything what is stored in it, is accessible only via your credentials. Neither Universa personnel nor even the CEO/CTO can access your data stored in the cloud, without having your Private key (or other credentials you use to access the Crypto Cloud).

With the Crypto Cloud, you normally don’t need to store the contracts as they are being created, altered, changing owners, new revisions created. Your Crypto Cloud credentials are the only what you need, to access the Universa smart contracts available to you – if every operation was done through the Web Client while being logged in to your Crypto Cloud account. Though, at any moment, you can export your smart contracts and private keys stored into the Crypto Cloud, or import them back.


One feature of the Crypto Cloud is the “Chats” capability. You can create a dialog with any other user of Crypto Cloud, send the messages to each other, and even exchange some smart contracts or tokens. This feature uses end-user encryption as well, but in a more advanced manner: only the participants of the chat can decrypt the information, and it is stored on the cloud in the encrypted form.


Any user of the Crypto Cloud may have one or even multiple unique nicks (or nicknames).

In regular chat/messaging platforms, a user usually has a unique ID or nick, by which they can be found; like, John Doe can use johndoe nickname in some messenger.

In the Crypto Cloud, the very same John Doe could use johndoe, john_franklin_doe and even probably [email protected]Я nicks, simultaneously but for various purposes. Really, do the people who call him john_franklin_doe need to know he is also a [email protected]Я sometimes? – or do the person who know him as a [email protected]Я, should know his real name is john_franklin_doe?

But note: to find a user in Crypto Cloud (and start a dialog with them), you must know their nick fully; searching for the nick will find a “full match” only. Due to the encryption mechanisms, there is no even a centralized list of all the registered nicks! But if you search for some nick, you can find if it is available or not.


Ideally, when you access the Crypto Cloud, you should use the same Private Key / key pair as for the Universa (they are fully compatible). To avoid storing this private key in some file (which can be copied and stolen, or lost), you can access the Crypto Cloud differently: using your nick (or any of your multiple nicks), and a password you generate.

In this case, your private key will be stored (end-user encrypted) in the Crypto Cloud; but you will get a convenience of needing only the password (and one of the nicks) to log in to the Crypto Cloud.

But note it is a Crypto-Cloud-Only feature, and you still need the private keys if you want to perform any Universa operations, without the convenience of Web Client integrated with Crypto Cloud.