Uqbar is building a decentralised network on an operating system known as Urbit, an identity-driven, peer-to-peer, deterministic system that uses a functional programming language called Hoon. Urbit was originally conceived in 2002 to solve what was seen as a failure of the modern internet to live up to its expectations as a peer-to-peer network of personal servers.
The failure of the modern internet can be described as vulnerabilities and inefficiencies that occur as a consequence of using old operating systems such as Unix, which are more prone to bad state, undefined behaviour, memory leaks, and/or crashing. When we access the internet today, we use operating systems that do not allow for our identity to be transferred or traced, we cannot easily understand the state of our current system without trusting a centralised third party to give us the information, we use computer resources inefficiently and store information across a multitude of servers and interact with peers in a non-private manner, exposing our personal information.
Urbit built an identity-driven, deterministic, functional, peer-to-peer and private operating system to solve all of the abovementioned problems. Urbit’s operating system gives users an alternative way to access the internet to retain ownership of their own data and become digitally sovereign citizens, released from the shackles that centralised technology companies have over most of the internet’s population. It comes as no surprise that the Uqbar team concluded that Urbit would be the ultimate system to build a blockchain on top of. Uqbar is venturing into the unknown, by creating an zero-knowledge execution layer that settles on Ethereum but is run on top of Urbit.
Urbit and blockchain share many similar properties (in fact, Urbit uses Ethereum NFTs to record IDs) but primarily differ in the way that blockchains are purpose-built to solve the double spend problem. Urbit does not need to solve the double spend problem because there is no such concept as a fungible currency in Urbit. Instead, Urbit needs to solve a ‘double-sell’ problem, to avoid a ‘parent’ selling one ID to two sellers at the same time. As Urbit IDs act more like real estate than as a currency, it is much easier to solve this problem because the chance of one ID being sold to two parties at the same time is negligible (especially as reputation and governance exist in the system, meaning IDs implicitly have an economic stake in this imperfectly decentralised system).
Indeed, choosing to build a blockchain on top of Urbit actually solves many problems of what blockchain itself faces today, such as; fragmented middleware, expensive versioning and central points of failure. When Uqbar launches on Urbit and as an execution layer for Ethereum, it solves the above-mentioned blockchain problems to create a private, unified and composable environment for on-chain and off-chain data. To elaborate, Uqbar is interoperable with all applications built on Urbit itself. To date on blockchain, if we hold financial assets such as ERC-20s on Ethereum, it cannot be interpreted by any web2 websites (e.g. Instagram does not understand if you transfer an NFT to it).
When Uqbar launches, any financial asset on Uqbar can be interpreted by all applications outside of Uqbar in Urbit (e.g. send an NFT from Uqbar to a non-blockchain Urbit application such as a blog to be used/viewed there). Urbit and Uqbar are fundamentally recreating what the internet is and what we can do with it. Urbit is a system built as if cryptocurrency was invented at the same time that the internet was created, perfectly suited to facilitate cryptocurrency transactions. To move to the next evolution of the internet, we need to rebuild the past. Forget web3, web0 is here.
To understand how powerful Uqbar is, we first need to further understand what Urbit is, the operating system that overlays traditional operating systems such as Unix that is architected to be identity-driven, deterministic, functional, peer-to-peer and merkelisable.
One of the most powerful properties of Urbit is that it is identity-driven. Urbit has a built-in identity system in the form of PKI on Ethereum. Having the private key is having the urbit instance. This coincides with the ethos of cryptocurrency as attributable ownership of computation is a desired property in the crypto world. The internet of today does not have a canonical identity system, which allows for sybil attacks such as spam and phishing. Urbit decided to make its operating system identity-driven in order to establish cryptographic accountability in the system, which is non-existent in existing operating systems.
Within Urbit, all messages are securely signed and encrypted by the sender and verified by the receiver. Having an identity in an operating system makes life much more frictionless because it is immutable and persistent. This means that an Urbit ID will always exist and it cannot be changed in a way that is not authorised by the owner of the ID. For once, a user has an identity that can be used across an entire system, rather than needing to create a new identity and password on every website they sign up for.
A deterministic system is a system in which a given initial state or condition will always produce the same results. Urbit is a deterministic operating system — the state of the OS is a pure function of the event log. The event log in this context means a complete, ordered description of everything the OS has been asked to compute. All of the data is stored in a single binary tree of integers, and every computation it performs is a series of manipulations of some sub-tree following 12 allowed operations. This means the current state of the urbit instance is fully determined by its genesis state and the sequence of inputs given to it. This is entirely different to operating systems today that are non-deterministic and vulnerable to going into a bad state, producing undefined behaviour (often resulting in bugs), memory leaks, or crashing.
Urbit also greatly differs from existing operating systems as it is built using a functional programming language, called Hoon. One major benefit of using a functional programming language is that side-effects seen in imperative programs are minimised (such as mutable state having unintended consequences from user interactions), which makes a system more reliable and therefore easier to maintain. Functional programming languages also make it easier to reason about software, which results in it being easier to debug than other types of programming languages.
A good way of thinking about a functional programming language versus other types of programming languages is to think of mathematical functions versus computer functions. Functional programming languages closely resemble mathematical functions whereby the same input will always equal the same output, which ultimately results in it being easier to debug than other types of programming. As well as the above, functional programming also avoids mutable/shared state, which is important for concurrency and increases performance of an entire system.
Another property of Urbit that is unique to its operating system versus others is the way in which the network topology is defined a-priori and completely via a peer-to-peer (p2p) network. The location of a computer in the Urbit network is defined by its name (at genesis). All communication is fully encrypted leveraging the built-in identity system (PKI). This makes it trivial to do peer-discovery, software distribution and identity verification.
Finally, state in Urbit is represented as a single binary tree. All of the data/code in Urbit is stored in a single binary tree of integers, and every computation performed in Urbit is a manipulation of some sub-tree. For those already familiar with cryptocurrency, a binary tree data structure is also used in blockchains (merkle trees). This makes Urbit an ideal system to build a blockchain on top of.
By understanding the architecture of Urbit and what makes it unique from the properties mentioned above, such as the deterministic, functional, identity-driven, peer-to-peer and merkelised nature of the system, we can begin to understand what makes it a lucrative operating system to build a decentralised network on top of.
Firstly, Urbit is deterministic. This is the exact same computational model that is used in blockchains. The same inputs will always equal the same outputs. The operating system of Urbit is as reliable as the Uqbar decentralised network itself, an ideal combination.
Secondly, Urbit is unified. The structure of Urbit means all applications are encoded in the same way that they are in the state. This means that smart contracts written for Uqbar are eventually available to the wider Urbit computer. For example, one could write a smart contract on Uqbar that is a financial application, which receives oracles updates of values directly from an application built on Urbit, like a weather app. Or, a smart contract on Uqbar could be written that executes upon actions being taken outside of the blockchain (e.g. an NFT is minted to an address when an Urbit ID purchases an item on a shopping application on Urbit).
The point to understand here is that data that exists on Uqbar and Urbit is interpreted in the same way. Any financial assets that a user holds on Uqbar will be able to be understood by any Urbit application. Applications on Uqbar and Urbit execute in the same way and are understood by each other’s environments, unifying the on-chain and off-chain world for the first time.
Thirdly, Urbit is intrinsically private. Urbit uses a public key infrastructure (PKI) called Azimuth, which exists on the Ethereum blockchain, recording ownership and public keys of Urbit IDs. Ames (Urbit’s encrypted p2p protocol) encrypts every message sent on Urbit using symmetric-key encryption derived from the public key of the peers. One concludes that all communication on Urbit has at least the same privacy guarantees as messaging someone on Signal. All communication and data transfer on Urbit (DMs, blog posts, file-transfer, etc.) is private.
However, it should be noted that whilst the data of the communication (ciphertext) is private to both the sender and receiver, the metadata (to and from address of each packet) can be ‘watched’ by middlemen. However, users in Urbit have an assurance that the ciphertext of the communication itself is private (e.g. a user saying hello to a friend cannot be read by anyone but the friend in Urbit). This in itself offers stronger privacy guarantees than what exists now in web2 (or web3).
In the future, it is likely that a privacy network will be built within Urbit, which could ‘mix’ addresses (Urbit IDs) to make it extremely difficult for any third party to work out an identity based on types of packets it receives and further enhance privacy guarantees when using Urbit.
Fourthly, Urbit is identity-driven, much like a decentralised network itself. Urbit’s PKI Azimuth is used as a decentralised ledger for what are known as Urbit identities. The fact that Urbit leverages a blockchain already for identities shows the clear link between both technologies. Urbit decided that a blockchain was the best technology to store IDs, which is necessary to use the Urbit network. Azimuth is a parallel system that can be used as a generalised identity system for any Urbit application. All users have an identity in Urbit. Once an identity is linked to an Urbit instance, it cannot be unlinked as an Urbit ship acquires its identity at boot and retains it for its lifespan. In order to use a different identity in Urbit you would need to boot a new ship. This is somewhat similar to how decentralised networks work today, whereby a public address is needed to interact with any blockchain.
However, Urbit made one key critical breakthrough in decentralised identification. In Urbit, an ID (for the most part in the form of an NFT, apart from moons or comets) is needed to access the network. The amount of IDs that exist in Urbit is limited, hence identity is scarce. Scarce identities are inherently valuable because only a limited amount exists. This differs from a centralised network, which can disperse identities at will with no extra cost. Not only that but IDs can be transferred and traced, meaning a user can take their identity with them wherever they go within the system. This powerful concept is a breakthrough in decentralised identification, which is another example of how well suited Urbit is for building a blockchain on.
Fifthly, Urbit is perfect for software versioning and distribution. It becomes very efficient to distribute software using Urbit because all users have an identity, therefore users are able to send and receive data with just one signature. Application developers are able to easily ship different versions of their product and send the different versions to different IDs. For example, contract developers could A/B test applications on the blockchain itself to experiment with their products by sending different versions to different Urbit IDs. Testing different versions of smart contracts for different users is not possible on blockchains that are built on existing operating systems today.
Another advantage of using Urbit for a blockchain is that it gives developers the optionality to charge different users different prices. To elaborate, it is easy to verify blockchain state within the bounds of a single application. It is possible to verify that a payment was made by a specific Urbit ID, to then automatically send some data or software to that Urbit ID in response. This is somewhat possible with the existing stack (non-Urbit), except that wallet addresses and contact addresses are not linked by default, so some bookkeeping is necessary.
Applications could offer different pricing packages for users dependent upon their use of the application and actions taken. Separately to the above, applications that exist in Urbit outside of the Uqbar blockchain could request payment from a user via Uqbar blockchain itself. An application developer could receive payment on-chain and then ship the software off-chain. Software versioning and distribution on Urbit is a perfect match for a blockchain to leverage as it provides more flexibility for application developers and a better user experience for users.
Now we know what Urbit is and why it makes sense for a blockchain to be built on top of, we can put the pieces of the puzzle together to understand the similarities and differences of Urbit and blockchains as they exist today.
Firstly, the similarities. Both Urbit and blockchains have multiple design similarities with each other, which include:
A p2p networking layer
Public key infrastructure as identity
A functional system
A permissionless system
However, blockchains have a value transfer layer that Urbit currently does not have, which is the major difference between the two technologies. For example a blockchain is built specifically to solve the double spend problem. Satoshi Nakomoto, the creator of Bitcoin, solved the double-spend problem, which was an ubiquitous problem within the cypherpunk space at the time in order to remove the necessity of having a “trusted third party” for digital currency.
In particular, Satoshi came up with a system, known as blockchain, which had within it a sybil resistance mechanism (Proof-of-Work), a consensus algorithm for nodes to adhere to (Nakamoto consensus), game theory (cost of attack is more than cost of work) and a currency to reward those that verified transactions on the blockchain (Bitcoin). Soon after the invention of Bitcoin, Ethereum was created. Ethereum introduced the notion of building a virtual machine on top of a blockchain, which paved the way for ‘smart contracts’ in the blockchain space.
Since then, there has been a vast amount of blockchains that have experimented with sybil resistance, consensus, game theory, virtual machines and currencies in different ways.
The double spend problem that Bitcoin originally solved that accounts for most of blockchains success, is a similar but somewhat different problem to what Urbit calls the ‘double sell problem’. Bitcoin and its relatives are designed to secure a complete, interdependent, collective transaction history. Bitcoin uses UTXO to verify whether or not a transaction is valid by looking at a history of previous transaction inputs. Urbit does not have such a thing as UTXO because Urbit ships are non-fungible and have no collective history or dependencies, which removes the need for a ‘chain’.
Another major difference between Bitcoin and Urbit is the way in which both have different hierarchies; Bitcoin has a completely flat, trustless and decentralised system whereas Urbit is more hierarchical. ‘Parents’ in Urbit can theoretically sensor ‘ships’ that are spawned from them (e.g. DoS) and as a result, Urbit could be argued to be more centralised than a permissionless blockchain such as Bitcoin.
However, it should be noted that ships that spawn from parents do have the optionality to take their ship elsewhere (e.g. if a provider is denying a ship service, the ship has the option to transfer its identity to another provider, which enhances the decentralisation of the whole system). In this way, Urbit is imperfectly decentralised with a less flat hierarchy than what Bitcoin has. Uqbar noticed an opportunity to build a value-transfer layer on top of Urbit that is completely flat and permissionless.
A value transfer layer whereby every transaction is recorded on a universal ledger, able to be read by anyone. However, blockchains as they exist today are not perfect. If Uqbar was not built on top of Urbit, it would likely run into the same types of problems that most blockchains experience today on existing operating systems. .
Fragmented middleware / non-unified environments
A major downside of blockchains is the incapability of each to provide any service outside of consensus on internal state changes (accounts and balances). For this reason, if an application wants to do more than just tracking state changes of accounts that live on a blockchain, it must leverage a middleware protocol. However, middleware protocols that are built to enhance the capabilities of decentralised applications are often networks themselves and require a completely different skill-set to run and maintain.
Consider this, a decentralised application would like to use a middleware protocol such as an oracle network to update the value in a smart contract of an event taking place outside of a blockchain (e.g. the weather temperature), as well as an RPC network to read the state of the internal blockchain (e.g. account balances). Most likely right now, an application developer would have to learn the tools of each middleware protocol in order to utilise it in the most secure way possible. As you can imagine, every time another middleware protocol is used by an application, it gets more and more difficult to manage. There is not one unified middleware protocol that is capable of providing any middleware service (e.g. oracle, RPC, cloud, analytics, etc.) for an application.
Expensive versioning
To understand what we mean by expensive versioning, we must first define versioning. Versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. Due to the intrinsic nature of a blockchain being fully focused on solving the double spending problem, it cannot easily iterate on versions without a fork taking place, due to the consensus required in order to change what version all nodes follow. There is no way in a blockchain to distribute software to specific identities. All nodes must upgrade in order to avoid forking of a blockchain.
Censorable
Realistically today, although most decentralised applications are deployed in decentralised networks, most users interface with decentralised applications through a server (or node) that is hosted by a centralised party (e.g. AWS or Infura). For example, most DeFi applications might be accessed through a website that is hosted by AWS, or an interaction with a blockchain can only be made through a centralised provider that relays transactions from a user to the blockchain.
Uqbar is a decentralised network that leverages the best properties of Urbit’s operating system and blockchains to create a self-sovereign, private, functional, unified and composable environment for on-chain and off-chain data
Uqbar is going-to-market as a zero-knowledge execution layer (‘Layer 3’), using Starknet as a settlement layer by posting proofs to Starknet’s ‘Layer 2’ for verification. Uqbar is a highly scalable, customisable and composable decentralised network that is leveraging Urbit’s performance and capabilities (networking, identity, databases, authentication, and software distribution) to build an execution layer on top of Urbit’s operating system that settles transactions on Starknet. Uqbar’s permissionless network is architected through shards, flexible time-to-finality, inter-shard interoperability, inter-shard composability, customisable data availability, a unified developer experience, privacy and on-chain governance.
Shards (Towns)
Shards are called towns in Uqbar and each town has different rules and regulations. For example, sequencing times and data availability methodology across towns will likely look vastly different. Some towns might require fast sequencing times for fast finality, whereas others might not require such fast sequencing times if finality does not need to be sub-second.
How data is made available across shards will likely be different too. For example, some towns might use validiums for data availability, whilst others might use volitions for data availability, and so on. The important thing here is that each town does utilise a data availability solution to avoid itself from becoming ‘locked’ (e.g. from nodes not being able to compute the balance of every account at a given state because data is not available, therefore a new state is unable to be propagated).
Flexible Time-to-Finality Finality
Finality across towns in Uqbar is customisable and each town will have a different time-to-finality depending on its own requirements. Shards that want faster finality (e.g. a CLOB) will likely require node operators that have specialised resources for executing proofs. There are two types of finality in Uqbar, business and settlement finality.
When it comes to business finality, Uqbar classifies this as the time it takes for x transaction to be sent to a sequencer and for a sequencer to verify x transaction. The second type of finality in Uqbar can be defined as ‘settlement finality’. Settlement finality occurs after business finality and once a sequencer has batched all transactions from users, submitted them to a prover, had a proof generated by a prover that then submits the proof to Starknet, posted state changes the transaction caused to Starknet for data availability and finally called the settlement contract on Starknet to record and update the new stored state of a particular shard.
In a nutshell, business finality is once a sequencer has received and signed confirmation to a user on Uqbar (execution layer), whereas settlement finality is when the settlement layer (Starknet) has verified (via a contract on Starknet) that a proof being generated is valid. Having a proof verified on a settlement layer gives a user a higher guarantee that their transaction will not be rolled-back or tampered with.
Figure 1 — Uqbar’s Transaction Lifecycle and Data Flow using Starknet as a Settlement, Consensus and Data Availability Layer
Inter-shard Interoperability
Trust-minimised bridging is possible between towns in Uqbar. Users send assets to a ‘burn’ smart contract in their ‘origin’ town and include what destination town they would like to bridge their assets to in the payload. After a user has indicated their cross-town intent, the ‘burn’ smart contract increments the nonce of the origin town to keep track of the sequence of the transaction.
Afterwards, the destination town claims the asset from the source town by providing a merkle proof of the burn state, which is verified via a settlement contract on the Layer 2 (Starknet). When a user’s bridging transaction is verified by the settlement layer (Starknet) the user is able to bridge the assets and amount specified in the original burn transaction payload to be used on the destination town.
Inter-shard Composability
There is no such thing as slots or epochs in Uqbar. Transactions are sequenced depending on rules and regulations governing a town. This unlocks experimental composability across towns. Composability leverages atomicity, meaning either a transaction executes within a given timeframe, or it doesn’t. In the context of Uqbar, it is possible for towns to have different ‘clocks’, meaning town clocks do not have to be synchronised.
As a result, it is possible to bridge to another town from a source town, send a proof to the destination town and have it sequenced before the destination town has itself sequenced transactions to Starknet L2 to be settled. Because there is no such thing as a clock in Uqbar, synchronous composability across towns is possible, a property that is not possible in other asynchronous execution layers.
Customisable Data Availability
Data availability is a crucial element of Uqbar’s architecture because full nodes need to be able to verify the correctness (integrity) of state updates to the settlement layer (Starknet). The zero-knowledge proofs guarantee computational integrity (i.e. that the proof was generated correctly) but it does not guarantee integrity of the data used in the actual proof generation. If a block producer proposes a block without all the data being available, it could reach finality whilst containing invalid transactions. To avoid this, a data availability solution is needed for zero-knowledge execution layers such as Uqbar.
Data availability can range from on-chain (where all transaction data is posted on-chain and verified by all nodes) or off-chain (where data is stored/made available in another layer and a cryptographic commitment is published that proves the availability of the data in an off-chain location). There are many solutions to solve the data availability problem off-chain (when data is being withheld when blocks are being proposed) and they range from data availability sampling, to data availability proofs to data availability committees.
In Uqbar, each ‘town’ (shard) will have the opportunity to customise and choose their own data availability solution depending on their needs. For example, one town might choose to use validiums for data availability, whilst another town might use volitions for data availability. The economics for data availability solutions per town will be different and will depend on the option a particular town has chosen. Any data availability layer solution comes with a cost that towns can weigh trade-offs of before deploying on Uqbar. Uqbar towns will always have the data availability layer option of Ethereum as a failover (on-chain) if other solutions (off-chain) are not optimal for their needs.
Figure 2— Data availability customisation options available to Uqbar’s execution layer
Unified developer experience
For Uqbar developers, infrastructure is inherently built in for free (e.g. p2p messaging, identity, version control is taken care of, developers just need to focus on the business logic). This makes it a suitable base layer to build complex applications on (e.g. games). The outcome of only needing to focus on business logic is increased speed of innovation. This is as a result of application developers spending less time on platform management (like they do now in web2 and web3) and more time on actual contract logic (as all platform, network, identity, etc. is automatically handled for them by Urbit).
Uqbar application developers are programming front-end and back-end in the same language (Hoon). This again amplifies the speed of innovation on Uqbar as any deployed Hoon code could be front-end or back-end, which can be re-used by any other developers depending on their needs. Essentially all developers and all applications speak the same language, front-end and back-end, which is Hoon. This unified developer experience greatly increases collaboration and innovation in Uqbar’s ecosystem.
Privacy
All of the data/code in Uqbar (and Urbit) is stored in a single binary tree of integers. Every computation performed in Uqbar (and Urbit) is a manipulation of a sub-tree of integers. As Uqbar is a binary tree of integers, it is easily merkalisable and therefore suitable for merkle trees. Merkle trees create the ability to prove certain data is included without sharing all the data, which makes it very suitable for zero-knowledge proofs. Zero-knowledge proofs involve one party (a prover) proving the truth of a statement to a second party (verifier), without the prover revealing all of the statement’s contents or revealing how they discovered the truth.
Ultimately zero-knowledge proofs facilitate privacy as users can prove a statement (e.g. a user wants to transfer x amount of assets from one wallet to another) without giving away to the verifier the exact metadata (e.g. the amount of assets or what the asset is in the transfer). The verifier is able to verify that the user in this example can indeed transfer their assets to another wallet without knowing the amount of assets or what the asset is. After verification, the transaction is executed on-chain, all-the-while a user is assured that their activity on-chain is undiscoverable by outside parties. In this sense, all users are assured that their transaction data is private on Uqbar.
On-chain Governance
As it stands right now, most on-chain governance in Uqbar is being done in a relatively centralised way by Uqbar’s development DAO that mainly makes decisions on upgrades of the Uqbar’s settlement layer smart contract on Starknet. However, in the future it is likely that Uqbar’s governance will decentralise over-time. For example, governance might be used to vote on towns being proposed to launch on Uqbar in the future.
Decentralised / Permissionless
Any validator can become a prover or a sequencer. In practice, there will likely be a spectrum of some at-home sequencers and some professional node operators, depending on the frequency of proving required by a town. In the future, any town will be able to propose to launch on Uqbar and any validator will be capable of becoming a sequencer or a prover on the network.
After understanding what Urbit is, the problems of traditional operating systems it solves, the similarities with blockchains it has and why it is the ultimate operating system to build a blockchain on, we can begin to envision the types of unique use-cases that Uqbar will spawn. In particular, it is likely Uqbar will propagate a new era in DAO tooling, NFTs beyond the blockchain, web3 (social media) and gaming.
When it comes to DAO tooling as a use-case, Uqbar will enable communities to form in a much more decentralised manner than ever before. For example, it will be possible for DAO members to activate an Urbit desktop that has programs pre-installed that are specific to the DAO (e.g. an application to vote in governance).
Uqbar will unleash a new era for NFT use-cases too, as we begin to see NFTs being integrated wholly and natively into applications that exist outside of Uqbar’s blockchain (e.g. use an NFT to obtain discounts at a supermarket site). NFTs created on Uqbar can be used across Urbit wherever an owner can authenticate their Urbit identity. It is not hard to imagine a variety of use-cases that come about as a consequence of NFTs being able to be used beyond the blockchain. Another example might be that an NFT is required in order to co-program smart contracts that a DAO is developing through an integrated development environment that exists as an application on Urbit. The potential basket of use-cases here is really unlimited.
Any communities that develop on Uqbar will be able to communicate natively with each other through decentralised social media applications built on Urbit. For example, a decentralised venture capital community can coordinate decisions on a communication platform such as Escape and then propose a confirmation of transaction intent on the Uqbar blockchain via Escape. Uqbar will be able to natively interpret intent from community members on applications that exist off of the blockchain.
In turn, Uqbar nodes have the ability to execute upon transaction intent signalled on communication platforms outside of Uqbar. Identity, transactions and applications will all be natively integrated through one operating system. Not to forget that all applications on Uqbar are self-hosted and private, so all communication channels have no way of being surveilled by intermediaries. In the not so near future, centralised communication channels such as Discord and Twitter could become obsolete.
Uqbar will unlock creative use-cases that were not possible previously too, due to the sheer execution power that Uqbar has as a result of being built on top of Urbit. In particular, because of the unified and zero-knowledge environment that Uqbar capitalises on, creative use-cases such as gaming and visual art experiences will improve monumentally as Uqbar’s native networking and unified functional programming experience orchestrates unprecedented composability. Today, NFTs often only represent data that is hosted elsewhere (e.g. an NFT has a hyperlink, which directs to a JPEG file hosted on IPFS). Tomorrow, on Uqbar, NFTs will represent data that is hosted natively, on Urbit or Uqbar, fully scalable, online and available.
Uqbar’s Testnet and Ziggarut Developer Suite launched on September 25 2022, when it was announced by Hocwyn-Tipwex at the Assembly conference in Miami. Developers are currently building their first unified, private and composable applications on Uqbar. If all goes well, Uqbar is planning to launch their Mainnet in Q2 2023.
To conclude, Uqbar is a decentralised network that leverages the best properties of Urbit and blockchains to create a private, unified and composable environment for on-chain and off-chain data. Uqbar is recreating the internet by building a blockchain on top of Urbit’s operating system, an identity-driven peer-to-peer, deterministic system that uses a functional programming language called Hoon. Uqbar itself acts as an execution layer as part of a modular blockchain stack, which is likely to settle transactions on Ethereum to begin with.
There are many similarities between the Urbit and blockchain stack that have not been assembled together to create one unified experience before. Uqbar is venturing into the unknown and embarking on a mission to solve existing problems of blockchains such as fragmented middleware, expensive versioning and points of centralisation by building a blockchain on top of Urbit, which fundamentally solves most major problems of blockchains whilst enabling new types of use-cases that are not possible in blockchains today.
We cannot begin to imagine the new types of use-cases that will be possible on Uqbar that come about as a result of combining two groundbreaking p2p technologies in Urbit and blockchain. However, it is not hard to anticipate a variety of use-cases that simply do not exist on the internet today. Financial assets that natively integrate with applications outside of the blockchain. Reputations being built with intrinsic value through accessing applications with Urbit ID that can be used within Uqbar. Art that is actually stored on the blockchain. Synchronous, multiplayer actions being taken by members of DAOs.
The amount of use-cases that will be unlocked with Uqbar is unlimited. Uqbar is fundamentally recreating what the internet is and where it came from.
Acknowledgements:
Thanks to Erwin Dassen, Gary Lieberman, Brian Crain, Jennifer Parak for their contributions, thoughtful insights and review of this article.
Xavier Meegan is Research and Ventures Lead at Chorus One.
Medium: https://medium.com/@xave.meegan
Twitter: https://twitter.com/0xave
Chorus One is one of the largest staking providers globally. We provide node infrastructure and closely work with over 30 Proof-of-Stake networks.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
YouTube: https://www.youtube.com/c/ChorusOne
Uqbar is a one-stop coding environment that makes writing and deploying smart contracts simple, efficient, and secure.
Website: https://uqbar.network/
Twitter: https://twitter.com/uqbarnetwork
Discord: https://discord.com/invite/G5VVqtjbVG
GitHub: https://github.com/uqbar-dao
Blog: https://mirror.xyz/0xE030ad9751Ca3d90D4E69e221E818b41146c2129
At Chorus One, we pride ourselves in being a full-stack partner to the protocols we choose to operate and support. This goes beyond the highly available infrastructure we provide to secure and maintain networks. It includes assisting in ecosystem-building via our ventures and business development teams, as well as participating in network governance and — most notably — deep research. Since our inception, we have been at the forefront contributing to core topics of interest in Proof-of-Stake such as liquid staking.
In recent months, we have shifted a big part of our research focus onto a complex topic that underpins the core fabric of any crypto protocol: MEV (Maximal Extractable Value). This emerging field deals with the value that can be extracted through reordering transactions in the block production process. (A collection of resources on MEV can be found here).
MEV has become an ubiquitous topic for many ecosystem participants. Primarily being a validator, our position in the network places us at a spot within the MEV supply chain that comes with great power, thus also great responsibility. Generally speaking, our mission is to maximize freedom for crypto users and to contribute to the creation of long-term sustainable, user-owned decentralized network infrastructure. Since MEV is a crucial domain that — if not adequately dealt with — might threaten the mission we are set towards; we recognized that we should leverage our expertise and resources to contribute to the MEV space in a way that ultimately benefits networks and their users.
The goals we want to contribute towards in the MEV space are two-fold. On one hand, we aim to make visible and help minimize extraction of value from users through e.g. front-running, sandwiching, and other exploitative practices. On the other hand, we strive to redistribute revenues from non-exploitative MEV that comes into existence from market inefficiency to our delegators that contribute security to the underlying network.
The rest of this article lays out the core pillars of our approach to MEV providing examples of our existing and planned engagements in the area.
What is MEV and how does it impact networks and their users?
Before deciding how we should engage with MEV, we seek to understand what we are dealing with. We are proponents of the open-source crypto ethos and don’t want to keep the information we are gathering to ourselves, but rather share it with the wider ecosystem. Thus, the first pillar of our MEV policy is Transparency. We are actively researching, building dashboards, and publishing other materials to create a shared understanding and to help lighten up the “dark forest” that is MEV.
Our exemplary work in the MEV Transparency domain: Dune Analytics Ethereum MEV dashboard, MEV Extraction Twitter bot, various MEV-related articles (e.g. our series on MEV on Solana).
How can we help to minimize negative externalities of MEV?
As a result of our research effort, we deeply understand MEV in the context of the ecosystems we are a part of. We recognize that MEV can pose negative externalities to users and ultimately the protocols they are trying to utilize. We are actively engaging to help minimize negative externalities in various ways, depending on how deep our engagement in the respective ecosystem is. This can include creating awareness and participating in the dialogue around MEV, research on related problems, as well as supporting and building solutions seeking to minimize exploitative MEV and to decentralize MEV extraction.
Our work in the Network Sustainability domain: operating and participating in public discourse and communities of block building solutions such as Flashbots, investments in projects seeking to minimize front-running (including e.g. Anoma and Osmosis). We have additional projects in this domain in the pipeline and are looking into operating infrastructure to help decentralize block building and relayer infrastructure.
How can we optimize and distribute MEV rewards to our delegators?
It would be hypocritical to say we are in this for the good of it only. There are clear incentives associated with engaging in MEV. Practically speaking, we are looking to optimize the return we can achieve through MEV and pass it through to our delegators creating a differentiated service while helping to improve network usability, security, and ultimately sustainability via the first two of our MEV pillars (see also Phil Daian’s early post “MEV wat do?” on this topic).
For institutional clients that want to offer staking to their users, we are happy to assist in navigating the space and finding the optimal solutions as part of our white label staking services.
If you are building in the MEV space, are trying to understand how MEV will affect your protocol, or are interested to work with us on research topics, feel free to reach out to us through the appropriate channels:
Research: research@chorus.one
Ventures: ventures@chorus.one
Sales: sales@chorus.one
In September, we hosted Steakwallet-rebranded Omni in the first episode of our monthly Twitter Spaces series. Below are highlights of the 50-minute long Q&A, featuring Omni’s CEO Serafin Lion Engel, CTO Alex Harley, and Chorus One’s CCO Felix Lutsch as we explored the unique features of the Omni wallet and how to choose the right validator.
Q: Serafin and Alex, why don’t you first start with an introduction to Omni?
A: So Omni is what we like to call the next generation of wallet that makes using Web3 as easy as ever. It’s basically your one-stop shop for everything Web3. It’s a wallet where you can do anything you need to do in order to use Web3 all in one place and it’s fully self-custodial. So anything, from staking to liquid staking, to depositing, to yield vaults, or onto lending protocols like Aave to multi-chain NFT support, and now alternative bridges and swaps. You can hook up your Ledger… We support more than 25 protocols at this point, all major EVMs, non-EVMs, and Layer 2s alike. There’s a lot of heavy lifting going on under the hood in order to make it as seamless as it is, but we’re very proud of our UX. We think that’s really what differentiates us and we think it’s a very next generation experience for a multi-chain ecosystem. Yeah, that’s only in a nutshell.
Q: Alex, what are some of the other features on the app that folks right now must not be using or must not be knowing about?
A: So with this Omni release, we really chose features that we felt were very important to UX, to rally around. So obviously, there was a lot of work over the last few months getting this [Steakwallet] rebrand out the door, but we wanted to make sure it wasn’t just a rebrand and that it would be a totally new wallet experience too. I would say, in my opinion, the biggest feature we added was the ability to do trustless and non-custodial swaps and bridges. So we partnered up with DEX and bridge aggregators across a range of different networks to allow people to easily swap and trade assets from inside Omni. We view this as a key unlocker for users. One of the main problems we had for Steakwallet users, previously, is that we had all these amazing opportunities for things to do like depositing into Yearn or seamless staking. But if they had one asset, say FTM on Phantom but we had something amazing going on Polygon, it was impossible for them to actually access that. So adding that in the app for us is a total game changer right now, because we have this whole concept of exploring networks.
We have a dedicated Content Team in-house to bring the latest and greatest of each network right to your home screen. Now people can see something fun to do or interesting like a cool APY or something and swap from an asset they actually have to get to that. Right now, we’ve partnered with three different aggregators and we’ll be adding more in the coming months. Bespoke networks like Tezos, NEAR and some other L2s are coming up; people will be able to jump to those straight from their wallet.
The second thing we added was our Ledger support. And we’re pretty proud of this because we have total feature parity for every network. So you can actually use your Ledger with every network we support. You can even use it for wallet connect applications. So you can vote on snapshot for example, which is quite cool, via Omni wallet. And then the third and final big feature we added was our multi validator support. Historically, we just wanted to offer people what we perceived as like the best yield for a token.
And as we went down this journey, we found that there are many yields. For individual tokens, you can lend Aave on USDC, or you can deposit into Yearn, for example. Or maybe a better example is Proof-of-Stake gas tokens: You can often stake them. You can also lend them. So part of expanding the capabilities of any one token was of course diversifying yield opportunities, but also diversifying who you can stake with. We didn’t want to be so opinionated and force people to stake with our specific validator of choice. On Omni today, you can choose who you want to stake with. And of course, we show you all the information like voting weight and this kind of stuff so you can make educated decisions.
Q: We briefly spoke about the providers that you work with. So you have a bridging provider and you also mentioned Yearn, Aave, and also the multi-validator support. If someone is on Omni right now, they can choose the list of validators they want to stake with. Was that a conscious choice to provide a list of validators? How did you guys plan that out on Omni?
A: Yes, that was a conscious choice. We originally started with one trusted partner and we just got so much inbound interest. Same with these other features I mentioned — like the Ledger support, the bridging and swapping support. We received a ton of user feedback that these would be great features to add. Again, same with the multi validators stuff. We did not want to be so heavy-handed and force users to choose one validator. It’s a great thing from a network security perspective. People want to balance their stake for personal security in case of slashing events. For network security, we don’t want to stake too heavily with a single validator.
Now that we have this multi-validator feature, our setup is such that we still present to users an opinionated list of high quality validators, especially on certain networks. Phantom comes to mind, where there’s basically 100% slashing risk for delegated funds, and that’s not a position that we want to put users in where they could potentially, in the worst case, lose all of [their funds]. So we basically partner with validators who have slashing insurance. We want to recommend validators we feel are of high quality in this space, while also giving users, at the end of the day, the absolute choice so they can delegate to who they feel strongly for.
We don’t want to be a centralizing force in the Web3 stack and we want to give users as much choice as possible. So we always have safe defaults that we set that we think are maximizing safety and convenience, but also have a positive offset for the space at large.
Q: Right. Even from the perspective of decentralization, it’s very important to not have a single point or a single recommended validator for any particular service — which is why you also have this question of centralization and Proof-of-Stake and whatnot. Felix, what are the most important factors that a user may think of when they choose to stay with a particular validator? Is it the brand name? The security they offer? The community they have around them? What do you think is the most important factor?
A: I think there’s a lot of things that you could look at as a user if you’re looking at a validator. There are also different kinds of customer profiles depending on what you are interested in. You might choose your validator just based on that. Security is one. Say, you want to make sure your funds are safe, you would want to make sure the team that is running the validator has a secure setup — such as using different data centers, using state-of-the-art infrastructure. Of course, that might also not be that easy for you to figure out as a simple retail user. What people tend to do is to look at the track record of a validator: how have they performed on other networks or in the past? What other networks do they support? Who is working with them? By simply looking at a validator’s website, you can usually get a bunch of the information. I think many are also just driven by the brand — whatever that means. That can mean a lot of things for different people.
Some validators might be more involved in the community, helping you understand a bit more about the staking model of the network. Or, they might do other things for the network’s community that you would appreciate — such as contributions in terms of research, looking at what’s happening in the network, just keeping people up to date through a bunch of newsletters. There is deeper research on certain topics that might be of interest to you — be it MEV, liquid staking or whatever you’re interested in. Ultimately, one [of the ways a user may choose their validator] is because of the tool that the validator team is building. Open source stuff is often hard to fund, obviously because it’s open source and there’s maybe no business model attached to it. The validator can be a good party to build these kinds of things and have the business model around the delegations that it’s getting.
Sometimes, validators contribute to the code base of the network or build block explorers or other tools that help developers or users really interact with the network. So if you’re someone that has tokens, it makes sense for you to look at who you think contributes most to the network’s ecosystem at large and the adoption of it. Delegate to them and, ideally, also delegate to multiple validators if it’s possible [for security].
NB: This article is an abridged version of the conversation between Chorus One and Omni. For the full conversation, replay the Twitter Space here.
Fertile land and ripe opportunities. We’re not talking about a utopic piece of land but about the world of blockchains.
Built on blockchain technologies and integrating crypto economies, Web3 is building a more decentralised, open, and utile version of the World Wide Web. Still in its infancy, we haven’t even scratched the surface of how this gamut of revolutionary technologies can transform our lives. It is inevitable that higher user experience demands, coupled with the gradual adoption of blockchain technologies, will bring in more innovative use-cases and of course, need more people.
But then come gender diversity issues. Those aren’t new in the blockchain space and the cryptocurrency industry, neither are we the first ones nor are we the only ones to talk about it. As the table grows longer, women should be taking more seats to tap into the immense career opportunities and economic growth at hand. But alas…
Economic freedom in Web3 will be powered by crypto, an industry that is at the cusp of and was born from two male-dominated industries — finance, and technology.
A “Women’s story in the cryptosphere” survey by BDC Consulting established that whilst 35.4% of the respondents worked in the crypto industry, only 15.7% got involved in crypto through their main job as most (36.7%) entered the market through inspiration by friends or colleagues.
In 2019, as cryptocurrency ownership had nearly doubled from the previous year to a considerable 14% in the US, the country’s male population owning crypto equalled 19% of men whilst the rate stood at only one out of every 10 women. Two years later, Pew Research confirmed that the figure remained the same for American women whilst the percentage of American men engaged with crypto rose by three points.
For Bitcoin in particular, women contribute to only 21% of all investments despite stats shared by Buy Bitcoin Worldwide stating that more than 70% of women have heard about the Satoshi Nakamoto-pioneered currency.
So how did an industry as young as Crypto carry a 20th-century gender gap problem into the 21st century? How did it become an overwhelmingly male space? Is it because it is the fruit of the union between two male-dominated industries? Or is it because we never really thought about this problem as we were busy moving fast and breaking things?
We may not have all the answers to this question, but we can contribute — in our own way as an organisation striving for equality and diversity — to encourage more women to take a seat at the widening table.
At Chorus One, our aim is to provide women with the needed support and resources in their exploration of the Web3 field. It is a valid dream, a valid target, and a valid goal to accomplish.
Thus far, Chorus One has provided 23 scholarships worth $53K across three different cohorts. In 2022, we sponsored 10 students from DappCamp, an Ethereum focussed bootcamp, with the objective to support aspiring women engineers. We’ve already hired two of them full-time at our company: Full-stack Engineer Maria Varvaroi, and Research Analyst Thalita Franklin.
WATCH: Female founder Preethi Kasireddy takes Chorus One CEO and Epicenter Podcast host Brian Crain on a deep dive into 21-day cohort-based Web3 course, DappCamp.
And there is so much more in the pipeline — hackathons and podcasts, among other initiatives. We aim to invest up to $150,000 in the next 12 months in lieu of this initiative and we look forward to collaborating with like-minded teams.
Speaking about barriers for women in Tech, a survey conducted this year revealed that almost 50% of the female-only respondents felt “visible allies within a tech organisation would attract them when looking for a new role”.
In another report by Deloitte, 94% of the women respondents feared that their chances of getting promoted would be hurt by requesting flexible working arrangements. What’s worse, less than half feel at ease even discussing mental health issues at work.
At Chorus One, the well-being of our team is a top priority. Our fully-remote company culture enables team members to structure their own working hours and context with the maximum autonomy possible. With unlimited PTO, anyone on the team can take a break whenever they want and need.
We’ve also fostered a safe space to accommodate the company’s growing number of women and make it easier for new female recruits to familiarise themselves with staking and the blockchain industry. We are improving but we’re not done.
WATCH: Diversity is not just a buzzword at Chorus One.
With the rolling out of Equal3, we hope to inspire more organisations to introspect and contribute to changing gender inequality perceptions in the tech industry. Chorus One’s Equal3 programme sets out to welcome the women of today and assist them to become the builders of tomorrow’s improved Web3 and crypto ecosystems.
