How It Works

How Bitlov Works

Bitlov aims for a future premised upon the value of the Individual, rather than one regarding people as commodities for manipulation. It is the gateway to an automated world of socially-minded, individual freedom. By design, Bitlov flattens inefficient hierarchies by ushering a future of peer-to-peer collaboration. Utilizing decentralized and distributed computational technologies, users are empowered to create simple-to-complex automation templates — opening the door for disruptive innovations, while putting them within reach of creators, entrepreneurs and organizations.

Companies and organizations consist of individuals who collaboratively perform tasks and authorizations to meet particular needs and goals. Digital contracts, enforced by trustless, autonomous signing agents can automatically reward specific tasks, etc., to increase overall efficiency by immediately rewarding progress. As a result, organizations are not only made fairer but are made more transparent — while, simultaneously, fulfilling promises to customers and communities.

Simply put, Bitlov automates digital payments according to the successful execution of contract terms — enabling all users to automate, in advance, what happens the instant they receive money or, even, upon sending it. Additionally, money can be programmed to respond to a combination of specific factors, such as times/dates, votes/approvals, third-party API’s, and more. With advanced planning, pre-defined amounts can be triggered to pay employees, developers, salespeople, affiliates, partners, investors, charities, family members, and whomever or whatever is deemed appropriate.


Automate Sending & Receiving 

With Bitlov, users have access to easy automation creation. This means that users (be they Groups or Individuals) can automate what happens when they SEND money, as well as what happens when it is RECEIVED. This can, of course, extend to virtually every aspect of an organization’s financial flow and processes.

For example, when a business makes a sale to a consumer, monies can be automated, so they are:

  1. Paid to specific employees (who assisted in order fulfillment).
  2. Paid to Investors.
  3. Paid to affiliates or salespeople who referred the sale.
  4. Paid to a charity or group of charities.
  5. Placed into a Pocket for the purposes of budgeting and expense payment.

By using Bitlov to create custom automations, a number of powerful features can be accessed, such as:

  • Trustless Escrow
  • Time-triggered transactions that process single or multiple payments, over time
  • Automated file release & delivery (upon payment or other criteria)
  • Third Party API’s to trigger payments upon certain criteria being met
  • Dividend payments to investors or to an investor escrow
  • Establishment of Development Bounties
  • Community voting features
  • Third Party Arbitration for dispute settlement

Bitlov’s Backbone: The Rubric Services Network (RSN)

The Bitlov ecosystem is comprised of two components, the Rubric Services Network (RSN), as well as our front-facing web interface.

The RSN is our open-source, decentralized protocol and provides the necessary machinery to perform the automations of each transaction. It works alongside the Bitcoin protocol and consists of its own blockchain (side-chain).

Bitlov is built to interact with the RSN and is akin to a visual studio, whereby anyone can create complex automations without knowing code. As well, a number of templates are to be provided for common transactions, so as to speed development.

Like Bitcoin, the RSN runs on multiple devices, such as computers, servers, and mobile devices. Therefore, it is decentralized and far less vulnerable than those solutions requiring the control and trust of a centralized entity.

Rubrics are the name for the hardware running the RSN software, while Pockets consist of automation instructions which are carried out and executed by the Rubrics. Let’s cover each of these, below.

Bitlov Pocket Sub-Dividers

Bitlov extends the traditional bitcoin wallet with Pockets, to serve as sub-dividers for categorizing different kinds of automations, for any number of varied purposes. Every Bitlov user has the ability to create unlimited numbers of Pockets.

A Bitlov account holder (utilizing a desktop client wallet and/or an online wallet) would access a Dashboard User Interface (UI) for the purpose of managing and automating money via, and between, multiple Pockets.

Bitlov Pockets are like smart containers for your digital currency. Like a sewn pocket, Bitlov Pockets are intended for the temporary transportation and storage of coins. As such, they are for securely moving money from one place to another. This is what a Bitlov Pocket does, of course, but in the digital sense.

Pockets can contain complex collections of rules, equations, and recipients; and are capable of the following:

  • Simple and complex contract creation with term-based automations
  • Maintaining reputation, as well as anonymity
  • Sending money to other Pockets or addresses
  • Sharing and role permissions, to allow for agreements, voting, etc.

Most users will create multiple Pockets for different use-case scenarios, but before we get into those, let’s quickly cover some of the basics regarding the nuts and bolts behind the RSN.

Rubric – Autonomous Agent

Rubric software functions as an Autonomous Agent — verifying transactions and complex contracts.

Rubrics are computers running Rubric software to provide one or more services for the Rubric Service network. Some Rubric hardware is more suitable for providing certain kinds of services than other hardware. This lowers the barrier threshold for participating in the RSN. Rubrics are compensated based on the amount of support they provide the network.

Rubric clients are run in web browsers and devices. They understand the RSN API and protocols, and can locally execute Rubric Scripts.

Rubric Services can:

  • Confirm Transactions
  • Host the Rubric Blockchain
  • Store Rubric Objects
  • Provide the Rubric Compute Container (RCC)
  • Executes Rubric Scripts in the RCC
  • Provides Rubric Web Services

The Rubric Compute Container provides a secure virtual environment for the execution of Rubric Scripts. A Rubric Object is passed to the RCC, which then executes the scripts within it. Those scripts may access other Rubric Objects either nested in the object or stored on the RSN. The scripts within those objects can load other Rubric Objects.

Trust Modes

Rubrics can be accessed in a variety of trust modes that all play different, but equally important, parts in the Rubric Network. Rubric Client Software may interpret the results differently, depending upon the level of trust assigned to a Rubric. A single Rubric server may provide services, in all of these modes, to different Rubric clients. The levels from least to most secure are:

Trustless Rubric

A trustless Rubric is any rubric the client has no relation to or knowledge of. They can perform actions that don’t require the client putting any trust in the rubric’s owner. Trustless rubrics are used by all parties in the RSN, as well as the RSN, itself, to perform maintenance tasks.

Trustless Rubric Actions:

  • Store Rubric Objects
  • Provide inexpensive compute power
  • Confirm results of Trusted or Secure Rubrics
  • Provide results for use in creating a consensus with other Trustless Rubrics
  • Auditing other Rubrics for the RSN
  • Process Ruby coin transactions

Trusted Rubric

Trusted Rubrics are any rubrics a user believes to be “trustworthy”. Trusted Rubrics may be used to break ties between Trustless Rubrics or raise flags when the result of the Trusted Rubric varies from the consensus of the Trustless Rubrics. These Rubrics might be run by businesses, organizations or clubs. Most consumers will want to configure their Rubric Client with the address of one or more Trusted Rubrics in order to perform actions with the same level of security as modern web applications.

Trusted Rubric Actions:

  • Provide Rubric Clients the address of a random Trustless Rubric.
  • Perform actions the Rubric Client is unable to perform.
  • Processing Ruby token transactions requiring a higher level of security.

Secure Rubric

A Secure Rubric is one a user has complete control of. A company may create a Secure Rubric to more tightly integrate it with their own software application. A Secure Rubric may also access files and services unavailable to Trustless Rubrics. An organization may run a Secure Rubric as a service to its members. That said, those members would probably consider it as aTrusted Rubric, for all intents and purposes.

Secure Rubric Actions:

  • Process Pocket transactions
  • Integrate with e-commerce sites


Rubrics allow for the storing of files and Objects. In particular, for the purpose of providing or unlocking a file once the terms of a contract automation is met by involved parties. This is useful for e-commerce, but also with long-term automations that require functionality akin to that of a “time capsule” (example: a “Last Will & Testament” could be released once specific criteria has been met, even many years later).

Because these files are stored in a decentralized way, it is natural to be concerned whether the files can be secured — especially long-term. Therefore, when an object is stored (in a manner much-like bit torrent), it must be verified by 5 Rubrics. The Rubric’s accounting function will make new copies from existing ones as any Rubrics leave the network (go offline).

Pockets, themselves, are Objects which are necessarily stored for the purpose of carrying out automations during the duration of the Contract.

Bitlov Pockets

Pockets are the basis for the next generation of smart transactions. A Pocket is a Rubric Object that contains contains private keys for one or more cryptocurrencies. It also contains list of related transactions and rules on how the keys and transactions can be accessed. It further contains scripts that can be run to create transactions automatically.

When a Contract Automation is created (the terms of which exist within a Pocket) it is stored on multiple Rubric devices as an “Object”. These Objects may contain encrypted private keys with access to coins in multiple blockchains, as coins are not stored on Rubrics (the RSN does not have access to these keys).

Users would access a user interface dashboard for the purpose of managing and automating money via, and between, multiple Pockets — providing the perfect platform for creating trustless online marketplaces and more.

Bitlov will also provide a marketplace for Pocket Template Automations that can make the most successful automations available for anyone who wants to DIY their own cause, organization, or company.

Credits, Tokens & Rewards

In the same way that Bitcoin mining rewards those who provide processing power in order to confirm transactions, devices running Rubric software will also earn Ruby rewards for confirming transactions, but also for providing bandwidth and storage. Compatible devices will even be rewarded for providing necessary bandwidth for communications and/or for furthering the reach of the Mesh Network.

Sam Yilmaz explains tokens this way:

“Service is rendered by a standardized software that can be run on a variety of devices which form the network of service providers. The software is open-source and any device can therefore easily link in to the provider network. Because the network requires consensus on the protocol level, all devices delivering the service need to run the same standardized code. The providers, run the computational nodes that are always in sync with the rest of the network. A decentralized application usually also has a digital currency native to the application. This token is used to transact between the network of service providers and the users. Imagine a vending machine that only works with this particular token. In the same way, the users can only pay for the services of the application with the tokens of the protocol.”

Because distributed applications have requirements which can be both costly (such as bandwidth/storage) and time-consuming (such as mining), these can be funded by means of a concept called Proof of Work. This is where Rubies come into play, to compensate Rubric devices (or their owners) for storing files and objects, time-stamping, script processing, etc.

Rubies are necessary because they are the only thing that can be tracked in the Rubric blockchain. The Rubric blockchain is required because it possesses abilities and features required by Bitlov, but not available via the bitcoin blockchain.

Developer Friendly

The Rubric Service Network was designed by web developers and is built from the ground-up to speed development of crypto-currency powered web applications. The RSN uses proven open source technologies and builds upon them. The tools and languages used were chosen, in part, for their familiarity to web developers and network system administrators.

Web applications access the RSN using web services. To aid developers, RSN provides a client-side JavaScript library and a PHP server side library (with libraries in other languages to be added at a later date).

The Rubric Web Services expose all of the power of Rubrics through a simple RESTful API. This means that existing web applications already have the tools to integrate Rubric Services.

By utilizing existing open-source software, and industry standards, we provide developers access to a large suite of existing tools and libraries. This also allows for a large pool of pre-trained Rubric system developers and engineers. To accomplish this, we borrow heavily from the technology of Linux as well as JavaScript communities. Many of the standards come from the Organization for the Advancement of Structured Information Standards ( (OASIS).

Automation Templates

Bitlov Pocket’s are capable of complex automations which can be saved as “templates” to be re-used or shared with others (via our Automation Template Marketplace), rather than requiring all complex automations be built from scratch.

Automation Templates can be created for the following:

  • Individuals — Families may utilize Automation Templates created by other families who have successfully utilized them for budgeting, allowances, etc.
  • Organizations & Industries — Automation Templates would likely vary from industry-to-industry. For example, a restaurant’s Automation Template would look very different than an industrial factory’s.
  • Communities — Automation Templates can be created to provide funding for roads, waste management, private security, etc.

Automation Templates provide the foundation for new ways of both understanding and managing finances for a near infinite number of purposes.