Skip to content

Developers face many challenges when designing and implementing decentralized Blockchain applications. For example, many dApps contracts require reliable access to external data, such as price feeds. They also require decentralized storage for storing off-chain files to reduce on-chain storage cost. An autonomous dApp might store off-chain web pages and javascript code, and verify the authenticity of those files on-chain. Other dApps need secure peer-to-peer communications for multi-party interactions, authenticated by on-chain public keys. With these pieces of the puzzle available, it’s easy to imagine a fully autonomous decentralized exchange, a fully autonomous decentralized time-stamping service, a fully autonomous decentralized game platform. The possibilities are endless, and here is were RIFOS comes into play, RIFOS provides a set of protocols, rules, and interfaces, for accessing many vital decentralized services.

To boost the adoption of Blockchain technologies each protocol is designed to allow anyone to provide an implementation and become a Service Provider. Providers can integrate with the RIFOS ecosystem and fairly compete for user adoption. For example, a developer may design and implement a new decentralized storage network compatible with the RIF Data Storage Protocols and register it to make it automatically available to any RIFOS-enabled device that provides a storage UI.

RIFOS was launched with a set of initial protocols which we’ll briefly describe here (for more information you can browse the source code):


One of the main barriers to blockchain adoption is the inherent complexity of the technology. It’s difficult to expect a widespread adoption if users have to copy and paste long hexadecimal addresses to transfer and receive digital assets. Also, manually typing addresses is an error-prone process, where a simple typo may cause loss of funds. By adding a name resolution service, the probability of errors is significantly reduced, as well as the apparent complexity of the system. The easier the technology is to use, the faster its adoption. The RIF Identity Protocol (RDP) goal is to identify different types of resources using simple resource domain names, enabling users to buy, sell and auction these domain names easily.


In peer-to-peer networks, parties need to discover other parties and establish secure communication with them. These communication links should at least assure confidentiality (no third-party can read the messages sent), integrity (prevent a third-party from modifying sent messages), and authenticity (prevent impersonation of one of the endpoints). RIF Secure Communications aims to fulfill these needs by enabling participants to publish pseudonyms on RIF Identity and linking such pseudonyms with their public communication key and preferred connection details. All the participants maintain a Distributed Hash Table (DHT), ensuring the information is highly available and up to date.


High blockchain fees during peak congestion times have rendered on-chain payments unusable for low denomination payments, such as coffee or pay-per-view content. Moreover, the delay in minutes to ensure payment finality is, for many applications, unacceptable. These are the main reasons behind secondary off-chain payment networks, such as the Lightning Network, Raiden, or Perun, among others. However, there is an ongoing debate on the blockchain community regarding the best design for payment networks. RIF Payments is a protocol designed to use different off-chain payment networks deployed on top of RSK transparently, supporting both Smart Bitcoins and standard tokens. The provided APIs enable a uniform interaction between the user, a RIF-compatible wallet, and distinct payment networks. The RIF Payments APIs facilitates the creation of bridges between different networks. The end goal of the RIF Payments network is to produce a competitive environment, where payment networks can flourish and provide low fees and low latency, with scalability to match the volume and exceed the performance of legacy credit card networks.


Decentralized applications often need to store or consume external data in the form of files. Using the blockchain as a store for this type of information is not an option due to the limited storage capacity and high cost. Moreover, the blockchain permanently stores the data it receives; therefore, an increase in the number of blockchain applications leads to an increase of the blockchain size. Using centralized cloud storage services have known weaknesses in the context of autonomous dApps: these services cannot guarantee byzantine fault tolerance and censorship resistance. RIF Data Storage protocol supports decentralized storage networks. Existing decentralized storage solutions have different costs, topologies, incentive structures, and performance characteristics. Designs are tailored either for storing personal content or for content distribution, although some can accommodate both options. To adapt the topology to different usage patterns, RSK Data Storage provides protocols designed to support both, the storage of personal content and content distribution to favor diversity when integrating with existing solutions. This way, it can be adapted to work with future storage networks.


Distributed real-world applications built using on-chain smart-contracts need to access real-world data feeds. This need must be satisfied by a secure, tamper-proof and trust-minimized solution that guarantees a deterministic output (all miner nodes must get the same value for a specific query request) on values fetched from external sources. As an example, a distributed self-governing crop insurance application needs to retrieve weather information to decide if a payment needs to be released or not, in case of hail, flood or drought events. Blockchain protocols communicate with external systems through Oracles. RIF Data Services enables consumption of external data sources that rely on existing or new Oracle solutions, proposing an interface layer that unifies access to such services. These providers take on the responsibility of bringing the requested information to the Blockchain. RIF Data Services provides an implementation-agnostic protocol for external data consumption through Data Service Providers.


The RIFOS Platform provides a set of abstractions and protocols to support third-party implementations of each RIFOS service. Each of these implementations is known as a Service Provider. The decoupling of standardized protocols and implementations enables users to select newer, potentially more enhanced implementations as the technology evolves and new solutions emerge. This decoupling also enables external third-party providers to port their solutions and integrate them with the RIFOS ecosystem. In this context, it is necessary to provide mechanisms to register and to discover these implementations, allowing developers and clients to choose the one they wish to use for their particular use cases. RIF Explorer is a protocol designed for the RIFOS Platform that provides the functionality required to register and identify third-party implementations of the RIFOS Services on the RIFOS Platform. RIF Explorer expands the RIF Identity Protocol capabilities to allow recovering service providers’ addresses not only by domain name but also by a specified criterion, such as service type or optional meta-data. For example, a developer can design and implement a new decentralized storage network, register it in RIF Explorer and make it automatically available to any RIFOS-enabled device that provides a storage UI.


We designed the RIFOS set of protocols so that decentralized applications can rely on a coherent infrastructure. All protocols and service providers seamlessly interact with the RIF token. At RIF Labs, we have already built the first service to implement one of these protocols, the RIF Identity, on top of the RSK blockchain, to take advantage of its smart-contract capabilities, which are ideal for RIF service provision. We continue working on the design of RIF-compatible Service Providers for the rest of the protocols mentioned above. These implementations would use RIF tokens, allowing any token holder to consume the services that are compatible with the RIF OS architecture.

Follow our