Parsec.1 family

This is the first implemented and practically usable parsec protocols family which makes full Internet connectivity protection and (since version 1.3), also the defence from TLS/SSL & DNS attacks also lead by ICANN domain squatters. See why parsec? for more information on existing threats, and the Parsec’s raison d'être.

Supported versions

version service authentication blockchain backed action on DNS squatting
1.1 Pre-Shared Key no Detect and block access
1.2 Pre-Shared Service contract origin yes Detect and block access
1.3 service name, UNS2 contract yes repel attack, keep safe connection

Important. Parsec.1.2 combined with UDNS also allow to repel attacks from ICANN-backed domain squatting. Parsec 1.3 does not depend on DNS at all so it does not need UDNS.

General description

Parsec.1 is command protocol that uses binary buffers of the same type as Universa Blockchain uses BOSS. Therefore, any media capable of exchanging binary data can be used to connect protocols to. TCP/IP, UDP, HTTP, HTTPS, Web sockets, even Bluetooth or RS485. Parsec does not require any other/external channel security by itself, so it actually does not need HTTPS, but still makes use of it to avoid limitation in browser applications.

Parsec.1 family client could effectively be executed from the browser page even on the mobile devices, for example, using JavaScript+WASM library we provide.

The client packs command and arguments into the binary block, sends it to the service and receives the binary block containing the answer. Then it decodes the answer that could carry any information, also passing exceptions (errors) from the remote part.

Important feature of 1.x protocols is that the client must know something in advance to connect to the service to avoid phishing and compromising user. The table above shows what information is used to authenticate the service. It also means that it is not possible to connect to unknown service. As with HTTPS, user needs to know at least the service name.

Guest level commands

Guest level interface is available immediately, it is not protected and used to establish protected parsec session. Because guest commands are not protected and could be used to attack to the service, these are designed to be simple and not resource consuming. Any service commands that needs I/O, consume time and any other resources in considerable amounts are placed into session level commands.

Get service information

This command reveals information on the service, including supported parsec flavors and versions:

info() -> {
    parsec: {
        versions: ["1.1", "1.2", "1.3"]

Service must provide at least one 1.x version in the info.parsec.versions answer to be eligible for parsec.1 connections.

Connect to parsec.1.1

Client has service URL and key addresses hardcoded in its software or obtained from some other source, including Universa-based smart contract or some other trusted source. Then it establishes the parsec session with it.

Connect to parsec.1.2

Client should have service URL and parsec service contract origin hardcoded in its software, or obtained from other trusted proprietary source. Then it obtains the fresh version of the contract:

getServiceContract(knownHashId?: string) -> { serviceContract?: Uint8Array }

If the client has cached service contract, it can send its hashId to speed up processing. Service returns actual parsec service contract or an empty response if knownHashId is present and equal to current service contract.

Client software process the received contract:

  1. Check its origin is the same as known to the clint;
  2. Check the contract state in the Universa network – it should be active (APPROVED;
  3. Retrieve the list of parsec key addresses to use with the session;
  4. Cache the contract for further usage.

If the response is empty and the cached contract is still valid, test 2 still should be performed, as in the case of successful attack to the service hardware (for example, taking over the physical servers) owners may update service contract in the blockchain effectively canceling intruders from exploiting the service.

Connect to parsec.1.3

Client uses a hardcoded service name, or get it from some proprietary trusted source. Then it retreives UNS2 contract directly from the Universa Blockchain, and checks it against several nodes to get the distributed trust on it. From the UNS2 contract client extracts:

  • current IP addresses or HTTP/HTTPS URLs of the service (the URLs could be changed if under attack, and the IPs can be changed when switching the providers);
  • current set of Parsec service key addresses.

Note that the Universa network is not DNS or TLS dependent, so the client capable of direct HTTP connections could always connect to the Universa network and retrieve the current service location and keys. The webpage-embedded clients should be able to access at least one Universa network node, as it is restricted to HTTPS connections, the single node could tunnel its access to the blocked part of the Universa network, making Parsec.1.3 exceptionally stable as long as there is access to even just a single Universa node (as the service can dynamically add IPv6/v4 mirrors and publish current map with UNS2 contract).

Refreshing service key addresses

parsec session commands may sometimes respond with a parsec_unknown_service_key error. In that case the client software should refresh its service key address from the available sources, e.g. reload service contract for 1.2, reload UNS2 contract for 1.3, or get the key addresses elsewhere or ask from the user for 1.1.


We actively use parsec in our projects written in typescript (borwsers, mobile browsers and nodejs are supported), kotlin (also for android), and scala as servers. Some of it is already published and some is not yet, but we can provide access to a closed beta upon request.

Browser-side javascript and Node.js

WASM-based npm module

Scala and Kotlin clients: available beta version

We have several applications in development that use scal and kotlin libraries, also for Android 8+. It is not yet published as a separate productis, so please ask support to get access to closed beta.

Scala server: available beta

We have several production services that run it in scala, but it is not yet extracted to the independent library. It consist of core libary that is framework-independent, and separate implementation of session adapter interface that uses postgres and scala.anorm. Session adapter could easily be implemented for any stack as it just creates and retreives permanent session parameters.

We use parsec in with scalatra minimalistic server, as all parsec needs is a single PORT request handler with form-multipart parameters.

Please ask support to get access to closed beta test of public libraries.