

New protocol and paper: v3.0

Andrew Lyon - May 6, 2022

It's finally here! I've been working on the next version of the Basis protocol and paper for a little under a year now, and now it's ready!

The new version of the protocol distills down what Basis is, what components exist it in, and how they interact in a much more coherent way. A lot of the mechanisms around cost tracking and profitless exchange are the same, but many other things have changed or grown.

Read the new paper »

This version breaks things down into three types and describes the interactions between them: agents (you and me), resources (chairs, houses, widgets, etc), and blocs (what were "companies" before).

One thing worth mentioning is that in the previous version of the paper/protocol, the interactions between the Basis network and existing market systems were intertwined, which was a bit confusing: are we talking about the protocol itself, or its interactions with the outside world? This has been fixed by moving the market interactions into its own separate section, leaving the protocol itself to be described in its pure form.

The previous version detailed cost tracking in labor and resources, and this version adds one more cost tracking target: processes (which extend the ValueFlows process model). Processes describe the transformation of resources and allow the cost tracking of those transformations. For instance, refine oil(100L crude oil) might be a process with an input of crude oil and an output of gasoline, jet fuel, etc that could be priced (like a resource) based on its input amounts of oil. This allows incorporating costs of externalities of various economic processes into production.

Although not currently in the paper, the tracker model is really starting to take shape in a material way. Trackers have gone from "yeah, we should definitely figure that out" to "here's an actual proposal" which is a great step. Beyond that, an incentive model for trackers is also now somewhat solidified: when a person wants to get paid, they track their labor, so it follows that if we want to systemically incentivize tracking resources and processes, the system pays members of blocs when they do this tracking. There are some other mechanisms at play here (such as cost staging) to limit runaway effects of this, but the idea is that interacting with trackers is incentivized by the currency system.

The paper still has many blank spots as things in the project tracker are in flux, but it's a significant improvement to what it was before.

I'm looking forward to finalizing much of the ongoing discussions so new work can be started on the protocol implementation.

Help keep things moving! »

Protocol updates: a new look at what Basis is

Andrew Lyon - Oct 8, 2021

Wow, it's been over a year since the last update. It wasn't my intention to give no updates on this project for this long, but life and the complications it brings have slowed down my work on Basis. It hasn't stopped my work though, and short of death itself, few things hold the power to keep me from what I'm passionate about.

The reason for my passion is that I view Basis as a solution to an existential threat: the relationship between humanity and our environment. The larger the population of humankind on this planet, the more important this relationship becomes. It is my belief that we are gaining collective awareness of this relationship in important ways, however our current economic and social systems do not facilitate a medium for this awareness to grow or develop.

Stepping back and looking at Basis, one could call it a method of socialist organization, or a protocol for a resource-based economy, but these things are incidental. They are in support of the ultimate vision: Basis is a system of collective awareness. It's a way to measure and mediate humanity's relationship with the environment.

Although this is a recent revelation, keeping the idea of systemic collective awareness in my head while working on the project has been helpful and has opened up other possibilities for either expanding the protocol to other areas, but also removing parts that are not relevant to this goal. This work has been ongoing, and is being reflected in a new version of the project paper.

Working on a new paper

Outside of my own head, the Basis project itself lives in the paper (and partly in the project tracker as well). However, I realized a while ago that the organization of the paper and many of the concepts in it are convoluted and confusing.

I've been working on a new paper that treats Basis as what it is: a protocol. It breaks down this protocol into the components that make it up, and the interactions between these components. It also uses some new terminology that will hopefully paint a clearer picture of the different parts of the protocol. I also made the mistake in the last paper of tightly weaving together the protocol itself and other systems for interacting with the outside world. Because of this, it can be hard to tell what is Basis at its core and what is a system for interfacing with the capitalist system around us. The new paper will make these distinctions much clearer, and will segment these different parts into their own sections.

I have been working on this new version of the paper for quite a few months now. It's going well, and I'm hoping it will much more effectively communicate the inner workings of the project. Many of the ideas are still not fully formed, and will remain in the project tracker for ongoing discussion, so stop by and tell us your thoughts!

I am posting regular updates to the new paper, so if you are interested you can follow progress here.

Visualizing the protocol

On top of the paper, I believe the paper and the people reading it will benefit from more visualizations, so it's my plan to create and include them, even if simplistic. Here's a high-level view of the protocol as it exists now:

I intended to create a number of helpful visualizations when I made the how Basis works page but I'm beginning to think I approached it too much from a marketing standpoint, and I really need to remake the page as more of a guide to understanding the protocol.

On resources and raw materials

Andrew Lyon - Jul 31, 2020

Tracking of resources and raw materials is a vital part of Basis, but what does that mean? How does it work?

A good place to start might be reading our post on cost tracking without money. But in case you haven't (or don't want to), the idea here is that for each product we know the exact resources it took to make it. So if we make a chair, we might know how many grams of wood it took to make, how many grams of iron or steel were used in the screws that hold it together, how many liters of diesel fuel it took to ship it, etc.

When we have this broken down for us, there are a number of great things we can do both individually and systemically. On the per-product level, we can make decisions based on things that a price obscures: do I want the chair that used more wood or the chair that used more fossil fuels? Having this information makes it easier for producers and consumers to make more ecological decisions based on their own preferences.

But taking it further, if a you want to buy a chair, it makes sense that the ultimate price of the chair might be the sum of the labor it took to produce it. However, the chair also has a resource cost. What if we had the ability to set a price on various resources based on things like scarcity and known externalities?

All of a sudden this opens up a lot of possibilities. As a network, we could slowly set a higher price on things like fossil fuels over time, which puts an incentive on the entire network to find more efficient energy methods. A region that suddenly has a shortage of water could raise the price of all water consumed in that area as a rationing method.

So we know what we can do with this information, but getting the information is tricky. Every resource we would want to track is effectively a product in the network. So a chair and a liter of crude oil are the same concept in the system. What we have to do then is to effectively tell the system we want to track a particular resource type and connect all those matching products to that resource.

This brings up a number of really interesting questions:

Tagging a product as a resource effectively means that the resource will cost more. How do we incentivize members (whether they are tagging their own product or someone else's product) to provide this information?
Once it's proposed that a product might be tagged as a resource, what process is in place to either confirm or deny this connection? The process necessarily needs to be democratic, but participation needs to be incentivized. How do we reward members for lending their time to this internal service, but also reward for accuracy?
How do we collectively decide what to track? Crude oil might be good to track, but once it's transformed into gasoline, diesel, jet fuel, etc it doesn't necessarily make sense to track each of those separate products as having a "crude oil" content. It would make more sense to capture that transformation and have each of those separate outputs be their own tracked resource. Where do we stop, though? Do we need to know how many screws make up a chair or can we be content knowing the steel content of that chair instead? What resource transformations do we build into the system? How do we incentivize the tracking of these transformations by the companies that perform these tasks?

While these questions aren't necessarily a burning priority for the project (might be quite a while before resource management is a problem we have), it's good to start thinking about these issues.

If you're interested in systemic resource management, join our discussions on the resource plan or resource tagging.

July 2020 Basis project status update

Andrew Lyon - Jul 15, 2020

Hey, y'all. Wanted to give a quick project update on direction and progress.

Core

As you all undoubtedly know, the Basis core project is now underway. There are a number of pieces being worked on right now. First, economics, determines how costs flow through the system and as they move from company to company. This work is going well and is coming up on having a first version done. The idea here is that costs cannot be destroyed, only assigned to resources that are passed on to other producers ("companies"): everything has a cost to produce, and that cost moves with it through the economic network.

The next portion of the core after economics is governance. This is the concept of democracy and voting in the system: self-determination. When we talk of voting, it's not the horrid First Past The Post one-person-one-vote we're all familiar with, but ideally a wide range of voting mechanisms (referendum, consensus, council, STV, etc) that people can mix and match to meet their needs. The problem with voting is its inherent reliance on various cryptographic primitives and algorithms that might change when moving between storage mechanisms. In other words, voting itself cannot be modeled in the core because of the core's deliberate shirking of integrating with any one particular storage mechanism/blockchain. As such, work is going to be done on effectively creating a voting user in the core that can take action on behalf of the result of a vote which happens elsewhere. This will allow us to start testing various situations where "a vote was held and decided" without needing to explicitly model that voting scenario.

This is all part of the effort to make Basis a self-determined network: the goal is to remove all admins or special privileges and instead give every user the same amount of power.

Once we have to ability to model successful votes, a number of wonderful new possibilities opens up without the need for an authoritarian presence in the network. Things like mediating usage of shared resources or determining who can do what within a company.

A new model for companies

We went over this extensively in the last post, but it's worth touching on again. The project is moving toward a more general model of companies that incorporate the ideas of what used to be regions. While this leaves a few questions unanswered, it also answers many others that were lingering from the old model. Overall this is a positive change and worth the effort to restructure.

Two of the biggest remaining questions surrounding this are

How does banking operate within this new system?
How does this change the concept of property usage and management in Basis?

A lot of ongoing work is happening to answer these questions.

Cybernetics

A new avenue of exploration has opened up to the project, and that's the idea of cybernetics. While many view cybernetics as a way to fully automate an entire economy, our use is much more minimal. The idea is to use a number of metrics about how companies in the network perform to automatically adjust how much costs they can command. In effect, it's a systemic control that optimizes how much societal investment a company should have depending on its ongoing performance. The goal is to incentivize things that are good for the network and reward companies for doing these things by allowing them more of what would be the equivalent of "purchasing power" in the capitalist market.

While this remains a somewhat new field to the project, I suspect over time it will become more important as more avenues open up for systemic self-regulation.

The paper

It's worth mentioning that in the last month or two, the project has undergone a lot of philosophical changes and most of these are absent in the paper. If you've read the paper, to get the most up to date understanding of the pending changes in the project, check out the "paper" label in the project tracker.

That's it! Thanks for reading. As always, if you have questions or ideas, the Basis community is here for you, or feel free to join in on any of the ongoing discussions in the project tracker!

Rethinking regions and companies: an exploration in self-organization

Andrew Lyon - Jul 10, 2020

The concept of regions in Basis is as old as the project itself. Originally intended as a container for federation, the idea is to group people, companies, and assets into somewhat blurry geographical spaces (for instance a city or county). After some incredibly interesting feedback and discussion about the project, I'm no longer convinced this is the best way forward.

Regions as they exist in the project are somewhat brittle. There's a concept of individual members, companies, and regions. If we define things in these terms, it can make sense on a small scale, but there are issues with this model:

If I'm a member of a company in region A, but my housing is in region B, I'm breaking the geographical model of regions.
If two regions want to build something together (a bridge over a river that divides them) or invest into a public company together, it breaks the geographical model.

In the paper as it exists now, there's a small section that's basically a TO-DO describing how regions might overcome these problems and coordinate their efforts on an extra-regional scale. In other words "we'll figure out these strange and difficult problems later." There's a discussion issue going over how membership might work in a more fluid way, but it still suffers from some similar problems.

On top of this, regions have this idea of asset management and permissions surrounding it, but when I started to build out the company model in more detail, I realized companies have this same concept. Who gets to use what, and in what capacity? The decision making processes around assets are identical for both companies and regions. Hmm.

Lastly, regions can own assets, which naturally means regions (like companies) can incur costs. How are those costs handled? What is the meaning of these costs if they are regional vs assigned to a producing entity?

Rethinking regions

What if we merge the idea of companies and regions and slightly alter how membership works? Let's define a new model for companies.

A company is a container of agents and assets. An agent can be either an individual member (a person), or another company. The assets of that company are owned collectively by the people making up that company (including the people members of its sub-companies) and use of those assets and permissions surrounding use is decided based on criteria set by those people. Any agent can be a member of any number of companies.

As an example, a farming company might have a number of farmers (either individual farmers or farming companies) that owns some amount of land and productive equipment like tractors. The members of that larger company all have a say in how the farm land is managed over time, how the land is divvied up between them, who gets use of what tractors and for how long, etc. Some of these farmers might also be members of a housing company that owns houses and apartments, which would give them access to local housing. Both companies might have their own membership criteria, such as working or residing in the particular area the company covers.

Already we've devised two companies that a region might have encompassed in the previous model, but in such a way that farmers get to decide farmer things, and members needing housing get to decide on housing things. The two groups might intersect, but they also might not. Regions forced the intersection, and gave an office worker a say over farm land & equipment, which in most cases doesn't make sense.

I want to note something: if company X has three members, person A and B and company Y, and company Y has two members, person A and C, then A, B and C all have an equal say in the issues relating to company X. A being a member of both X and Y doesn't change A's decision power in relation to the other people. In other words, membership might be agent-based (people or companies), but ultimate decision power rests only with people (companies as entities have no decision power).

Rethinking capital distribution between companies

One thing that struck me when mulling this model over was the idea that regions aggregated capital in such a way that all market-derived profits from all the companies in a region fed into a larger regional pool that could be used for anything, whether buying farmland, houses, or tractors from the capitalist markets. While this is not an issue when the network gets critical mass and can produce all of its needs internally, it is certainly a concern when interaction with the outside market system is essential.

With the new company model, the idea of automatic pooling of regional profits gets eroded. Farms that make a market profit might keep the profit in their own farming company, and people who need housing wouldn't have the money to buy/build houses. What is to be done?

What if every company has its own pool of capital, and each membership in a company acts as a vector for capital distribution between these pools?

Let's say I'm a member of two companies: a farming company that has 100 members, and a housing company that has 1000 members. In a sense, I have a 1/100 say in the farm company and a 1/1000 say in the housing company. If the farm makes a profit of $1000 (and we can tell profit easily and immediately because we track all costs of production) then it would follow that I have a say in $1000 / 100 of that capital, or $10. Because I'm a member of two companies (the farm and housing company) that $10 capital would automatically be split between them both such that they each get $5.

On the flip side, let's say the housing company I'm a 1/1000 member of has more housing than is needed to house all members, so they rent units out on the market at a profit-generating rate. If the housing company makes $8000 of profit in a month, it follows that I control $8000 / 1000 of that capital, or $8. Half of this becomes available for the farm company I am a member of.

In this way, membership in companies becomes a vector for market purchasing power to move freely between companies, and does so without distributing to members individually. In effect, production is still profitless internally and market success in one company is shared with others through membership.

You might ask what happens if I'm a member of three or four companies. Does the $10 profit from the farm split four-ways equally? Can I choose the ratio to which this distribution occurs? This is an interesting question and a lot of dynamics around it arise that I've discussed in this comment in the project tracker (see "Concerns with this model" section). Discussion here is welcome either in the project tracker or the project reddit.

Rethinking banking

Although banking was somewhat loosely defined in the regional model both in the paper and another post, with this new concept it now becomes even more loosely defined. I've made some attempts at discussion but am ultimately not sure of where this will land. Feedback, ideas, and discussion are all greatly appreciated.

The goal of the banking system is to facilitate

Seamless transactions between member companies and the market system in a way that integrates cost-tracking.
Conversion of internal credits to market currency (USD for instance) so members can personally buy things not produced in-network.

In other words, if capitalism and socialism are two different languages, banking is the translator between them.

The first item, seamless transactions, is a matter of being able to send capital from an internal pool to a market entity, which is mostly a solved problem.

Conversion of credits into market currency is the difficult problem. Effectively, for stability in the network's beginnings, you'd want a stable conversion rate (at likely a 1:1 ratio or perhaps something like 1000:999). This means having capital systemically set aside for withdrawals such that one credit is backed by one dollar. Where does this capital live? How many actual banks/credit unions are involved, and if multiple (which seems prudent), which funds come from which?

How this is managed on a systemic level is an interesting problem and remains a topic of discussion and thought.

Conclusions

This new model of the general company is magnitudes more flexible than the previous idea of regions and is able to really capture the associations people might have in ways that don't make assumptions. Keep in mind, the old model could be easily implemented in the new model, so if it's something people want, they are able to decide that for themselves.

It's important to note that the most difficult parts of the problems we're solving revolve around capital itself, and that at the point capital is no longer required, ie the network can provide its own collective needs internally, large amounts of the system can simplify.

There is one piece we touched on above that hasn't been solved in this post. All companies will have costs they manage, and producing companies will have upper limits on how much costs they can manage at any given time. However, there are necessarily going to be public companies (ie, planned) that have costs themselves which are not required to flow through to the outputs of that company (ie, not consumer-demand driven). For instance, if a number of people band together and say "we want public pharma research" this new pharma company might have some amount of costs available to it that do not need to be covered via consumption. Where do these costs go if not covered by customers, and how are they handled? This is an important question and we'll tackle it soon.

Cost derivation: In-kind cost tracking in moneyless production

Andrew Lyon - May 23, 2020

I've been asked many times what Basis does, and when I say it tracks costs of production without money, it can cause confusion. How can something cost anything without money?

When you think about the price of some thing (say, a chair) what does that price mean? In our current system, it means that at each node in the economic network (the logging company, the lumber yard, the chair factory, the reseller) there was some process that took place that essentially derived the cost of the Thing they were selling by tallying up the inputs they bought. That's not the only story though: they add (or subtract, in many cases) another value, which is the margin of the sold item.

So for each company involved in making the chair, the price looks like inventory + labor + margin. Now repeat this for every hop of the supply chain until you're driving home with your brand new chair in your McLaren F1 after having paid the chair's price of $35.99.

What does $35.99 mean? Nothing! The chair didn't cost $35.99 to make, otherwise there would be no margin on any of the sales in the supply chain. But what if there was no margin? If all companies involved made no profit or loss, what does $35.99 mean? Effectively, it's an aggregate sum of the labor and resources that went into building and shipping the chair and its constituent inputs (yes, I know of marginal economics, but if you want to argue that price isn't derived from labor and resources, then you're just proving my point even more that price is meaningless).

Now, let's say we want to deconstruct that $35.99. I want to know how much wood is in it. I want to know how much fuel was used to transport it and its inputs. I want to know the costs of leadership, machining, sales, accounting, etc. How would we do this? We would need to open the books of all the companies involved and trace back from the moment it was sold back to the logging company. But this is an impossible task, because even if you could obtain this data from just the participants in the direct supply chain, there are offshoots that need to be accounted for. For instance, the logging company might have used a chainsaw to cut down the tree used in your chair. The cost of that chainsaw is imbued in the chair, so now you have to examine the entire supply chain for the chainsaw! And what about the truck that delivers the chair to the showroom? A complex machine with a vast supply chain (not to mention the fuel it uses to operate, which also has its own supply chain). All of a sudden, deriving cost requires traversing data on a vast network with recursive temporal loops and shifting complexity.

This is where Basis comes in.

Disaggregate cost tracking

Basis operates on a company level (ie, the single node of the economic network). It knows the inputs and outputs of a company (by facilitating the orders between them) and using this information accurately tracks costs, in disaggregate, of labor by occupation and resources (raw and semi-raw materials).

Now when you buy your chair, it no longer costs $35.99, but rather it costs 4kg wood, 3L diesel fuel, 4g silicon, 0.3 hours of logger time (at $20/hr), 0.6 hours of machinist labor (at $22/hr), etc etc.

But, why?

The purpose of doing this is not just to derive a fancy way of determining price, but to collect and store information on the cost of producing something. If we know how much fossil fuels were burned to transport it, or how much money was spent on marketing to convince you to want it, or what wages people were paid to build it, both producers and consumers could make much more informed decisions based on ecology and personal preference.

Pair this with production that doesn't rely on profit for continued existence, and you have an economic system that, while realistically will not account for all externalities, at least does not grossly incentivize them.

So what does a "price" in Basis look like?

A bit like this:

{
    "labor": {
        "ceo": 1.2,
        "cfo": 0.6,
        "machinist": 2.3
    },
    "labor_hours": {
        "ceo": 0.03,
        "cfo": 0.02,
        "machinist": 0.115
    },
    "resources": {
        "wood": 5612,
        "steel": 12,
        "diesel": 0.87
    }
}

The final price would be a combination of the labor costs in addition to resources costs. Resources is a measure of the amount of each resource in standard units, not its final price. The price of resources is democratically decided at both the global level and regional level, such that the per-unit cost of each resource becomes effectively a labor cost (credits) and can be added to the labor values sum.

So above, if wood was 0.0004 credits/g, steel was 0.1 credits/g, and diesel 1.5 credits/L, then our total cost in credits would be 1.2 + 0.6 + 2.3 + (5612 * 0.0004) + (12 * 0.1) + (0.87 * 1.5) = 8.8498. If you have 8.8498 credits, the great job, you can afford to buy this widget.

In the cost list, labor_hours is currently just used for tracking and has no bearing on pricing.

(Apologies for the douchey header image, our marketing team has mandated that all blog posts have a picture)

May 2020 Basis project status update

Andrew Lyon - May 18, 2020

Hi, everyone. I know the project has seemed quiet recently, but there's a good reason for this: I'm spending a lot of time working on the next steps. This is somewhat of a continuation of our last post and also a general update on the project direction.

ValueFlows

I've decided to move forward with integrating ValueFlows into Basis. This is a fairly intricate process of deciding which parts of the existing project should remain and which should be replaced by the rust-based ValueFlows vocabulary I spent a good amount of time building out.

Not only is this about replacing code (more on this later) but also about gaining a deeper understanding of ValueFlows and how it fits together. This consists of me re-reading the ValueFlows website over and over and pestering the creators ceaselessly (thank you, Lynn and Bob).

So far the experience and thought put into VF is helping immensely, not just with data structures but with my own thought patterns. It's truly an excellent economic vocabulary.

Holochain

I've decided to move forward without Holochain. There are a few good reasons for this, but the main reason has to do with Basis requiring some about of data consensus. Holochain's agent-based verification is truly a revolutionary way of building distributed applications, and there are parts of it that would be extremely useful for the goals of Basis, but in its current form it's not ready for our use.

The main problem we're facing is that companies in Basis require an exact accounting of inputs and outputs, and this needs to happen on the company level. In Holochain, this can only really happen on the agent (ie, personal) level. In other words, if someone in the company orders 100 widgets and someone else works 12 hours, it's fairly difficult to attribute those costs to the various outputs of the company, because they are effectively siloed to those individuals. There needs to be some built-in way to have consensus on data for it to work for Basis, even if just on the company level. I've toyed with the idea of using blockchain for data consensus within companies and Holochain for everything else, however I think at this point it makes sense to limit complexity and move forward with what we know works.

This could change in the future, and this brings me to my final update.

Basis core

The current implementation of Basis tightly couples data types, logic, and a blockchain such that they are all inseparable. This means that if we eventually want to leave Exonum as the blockchain layer for the project, we have to essentially do a lot of ripping and reprogramming. It also makes the project's core logic harder to test because it has to be wrapped in a blockchain to operate effectively.

To mitigate this, Basis core has been created and will be the place the Basis data structures and logic live. No storage, no config, no blockchain, no third-party services. The goal is to be operationally functional, meaning all operations require the needed data to be passed in. This provides a barrier between the essence of Basis and whatever transactional medium it uses.

This will help in a few extremely important ways:

The next version of Basis can be built without having to worry about getting it working within a blockchain. This speeds up development significantly.
Basis can be tested in a functional and self-contained manner.
The blockchain layer can be "swapped out" down the road without disrupting the core logic of Basis. This could be Exonum, Holochain, Substrate, etc.

Given that Basis is undergoing a fairly large change of integrating ValueFlows, this is a good time to focus on separating out the core logic into its own project.

This is an exciting change. While it's an up-front investment in research and build time, It's going to make the project stronger and make development faster in the long run.

ValueFlows, Holochain, and blockchain

Andrew Lyon - Apr 5, 2020

After spending some time sharing the Basis project with others, I ended up catching wind of some really interesting projects that could augment the abilities of Basis quite a bit.

ValueFlows

The first, and probably most impactful, is ValueFlows. It's effectively a language/vocabulary to describe economic networks and processes, evolved from the REA system of accounting. After reading through the website and documentation, I realized that it's a much more detailed and thought-out set of processes than what exists in Basis. Interestingly enough, I did a lot of research before starting Basis to find "standards" or best practices for ordering systems and supply chain automation, but had trouble finding anything that felt applicable.

ValueFlows is the exact thing I wish I had found before starting work on Basis. That said, none of it was wasted work, but rather it would be taking the incomplete work I had already started and finishing it with some level of standardization.

On top of this, while Basis touches on the idea of resource tracking, one thing it has yet to model is the concept of resource transformation. In other words, crude oil might be a tracked resource, but once refined, it is used up and transformed into several other different types of resources. Transformations are modeled into ValueFlows, although there's not a mechanism to make sure the outputs match the inputs, which Basis tries to do very carefully, so transformations would still need some level of standardization and scrutiny.

Also, ValueFlows isn't just theoretical, but is being used in productive capacities in various companies. It's a wonderful place to start if building economic software.

Holochain

While talking to the authors of ValueFlows, Lynn Foster and Bob Haugen I came across an interesting project call holo-rea. Effectively, this is a ValueFlows implementation on top of Holochain.

I had not heard of Holochain before, so I did a deep dive. It looks like a blockchain if a blockchain had infinite sharding and eventual consistency. It's almost built from the perspective of complete distribution and infinite scalability and moving towards data consensus, as opposed to blockchain, which starts with data consensus and tries to move toward scalability.

Essentially, Holochain isn't a cryptocurrency with "smart" contracts, but rather an agent-based networking platform that offers application validation. Each participant has their own personal blockchain (entries are data + header with hash of data and reference to previous header) and when transactions are submitted to the network, they are verified by a set of peers determined by the hash of the transaction before being saved into a distributed hash table (DHT).

Immediately, this brought up a lot of questions for me and how this might work in the context of Basis. Holochain has some pros and cons, which I will try to list exhaustively here.

Pros

In theory, scales infinitely. Because there is no data consensus between all participants, only the members of a particular transaction need to hold that data (although the transaction itself is still verified by other members of the network). Scalability is important to us because while cryptocurrencies might get away with only matching Visa's peak tx/s, we're building a system that will hopefully scale to far beyond that, and having artificial limits imposed up-front represents technical dead-ends that will be difficult to reconcile when the time comes.
Supports private transactions where the body of the transaction does not leave the node, but rather the header is broadcast and stored by the network.
Has the concept of many different inter-operating networks. A company might have its own private network that deals with internal matters and connects to the greater network which would be more public.
Handles network partitions more gracefully than blockchains. If a segment of the network is disconnected in a blockchain, participants might keep submitting transactions without knowing they are partitioned from a larger network. Upon reconnecting and joining the larger network again, the smaller network's history will be obliterated. Holochain handles this much more gracefully because it doesn't need absolute data consistency. The two networks will merge when the partition is healed without any data loss.
Truly distributed. Blockchain participants build centralized consensus via distributed mechanisms. Holochain uses distributed validation and storage. There is no centralization of data.
Holochain apps are built in Rust <3 (Basis is built in rust already).

Cons

Represents an entirely new and challenging paradigm when dealing with data. For instance, because all data is agent-centric, there's no built-in concept of a group in Holochain. In Basis, groups (companies, regions, etc) are essential. Companies have members, and members can perform actions such that it looks like the company itself is acting in its own agency. In effect, given the tools Holochain provides, we have to work backwards toward data consensus on a group level. This is currently a blocker for thinking about using as a platform for Basis. Word has it group agents are planned, although I'm not sure what the scope of this project is yet.
Extremely new, and therefor somewhat unproven. The ideas behind blockchains haven't really stood the test of time yet, but if blockchains are teenagers, Holochain is a toddler (this is not meant to put it down in any way).
Documentation lacking. I've found a lot of the documentation to be much less detailed than desired, specifically about how transactions are validated and what data is available to them when this happens. A lot of this knowledge seems to be floating around in the forums. That said, I don't blame the Holochain team because the project is evolving so quickly that accurate and up-to-date documentation would divert a lot of resources that could otherwise go into building a stable platform.

What's next?

I'm convinced at this point that Basis should be build on top of ValueFlows. I'm also convinced that Holochain will be involved in the project in some capacity, although right now I'm not sure what that will be. Will this mean building Basis on top of Holochain? Does it mean building Basis on top of holo-rea?

It might be possible to use a blockchain in the places where blockchains are useful and Holochain where scalability is needed. Can the two coexist and interoperate?

I'm meeting with the lead dev of holo-rea soon, and we're hopefully going to do a deep dive on Basis, ValueFlows, and Holochain and figure out how all the pieces fit together.

While the above projects have made the immediate future of Basis a bit more uncertain, they came at a great time (during early formation). The ideas and goals behind Basis are the same as they were before, but now there are more tools to help make that vision come to life.

Inner workings of banking (a rough draft)

Andrew Lyon - Feb 15, 2020

This will be short and sweet, but I just wanted to go over some recent changes to the banking section of the paper. And when I say changes I mean actually writing it in the first place.

There are two main problems:

What price do we charge for products leaving the network into the market?
How do we make sure that we make more capital than we spend?

The two problems are very related, and both have the same solution: currency tracking. Where before, products and services were costed based on labor and resources, now we track a separate category as well: currencies.

So if a bank lends $10000 to a member company, and they use that to buy steel from the market to make their widgets, the widgets will have not only labor content (of the workers making them) but also currency content. If we buy $100 worth of steel and use it to make 5 widgets, then each widget has $20 worth of currency cost. If another member company orders one of these widgets, the widgets cost (including the currency cost) is added to the company's overall costs, and their productive outputs will also have the currency cost imbued in them, and the cost moves through the internal economy.

Given that we know the conversion rate of network credits to local currency, and we know how much actual currency is included in the product (because we tracked it), it follows that we also know the at-cost market value of the product.

So if we want to sell this product into the market, we know what we must price it at in order to cover all costs of production. Everything above that price becomes regional profit. As far as what price to use, it would be nice if there was a way to automate this, however in all reality the company itself would be responsible for setting this based on their industry-specific knowledge. The regional production cost would serve as a pricing floor (possibly a soft one, TBD).

There's more detail and nuance in here, but a good amount of it is covered in the paper's new banking chapter! Keep in mind this is still evolving and may change in a way that makes this post irrelevant.

Duality, housing, and markets: strategies for socialist growth

Andrew Lyon - Feb 14, 2020

The paper references the concept of duality a few times and it seems it would be a good idea to address this in detail. When talking of duality, what's meant is two different modes of operation: a mode for members and a mode for non-members (the market system).

In short, the duality refers to the network giving benefits to members (at-cost products, services, housing, means of production, voting rights) but treating non-member market participants as if the entire network is a for-profit company. This concept is the fuel that grows the network over time.

Vectors for duality

Here are some of the places the network can gain from the market:

Housing. If there are vacancies in housing owned by a region, the region can rent those units out at market rate, pocketing the difference between the cost and the market rent.
Means of production. Just like housing, warehouses, factories, office buildings and other productive assets can be rented out at the market rate.
Banking. While banking works slightly differently for member companies, they essentially get a 0% interest rate. Individuals and companies transacting with the regional bank would be charged market-rate interest for loans, allowing the bank to profit.
Companies. To members, all products and services from member companies in the network are provided at-cost. However, when member companies interact with the market system, although they do not make "profit" or even directly handle capital/currency, they charge market rate for their products and services, which goes directly into the regional bank.
Public companies. If the region decides to open a school that's fully funded by the region itself, members can use the school free, however non-members would be charged tuition at market rate.
Public market. The market that all member companies' products and services are listed on is also a vector for duality: free for in-network companies and members, but market companies pay usage fees.

Housing and cost of living

Housing is one of the most important things on the list above, so it's worth writing about as its own section. While we won't talk in this post specifically about how housing might work in this system, we can certainly talk about housing costs.

Housing in the market system, like all things, is subject to supply, demand, and pricing which tends to drive property and rent values up over time.

By socializing housing, property by property, as regional mortgages are paid off, the costs drop significantly. The monthly cost of a regionally-owned house with no mortgage on it would be cost of insurance, property taxes, and ongoing maintenance. This is key to the growth of the socialist network: as time goes on costs of market housing rise while costs of regional housing stay similar (taxes and insurance may rise in cost, but trivially compared to the cost of a mortgage), creating an ever-growing differential in costs of living between members and non-members.

This differential allows member companies to pay lower wages to themselves to out-compete market companies while retaining their standard of living. As costs of production lower due to lower wages, regional profits of products and services sold to the market rise, allowing more purchasing of housing and productive assets for member use.

First Basis project update

Andrew Lyon - Feb 2, 2020

After working on Basis for just about a year, I wanted to finally start sharing the results of the work. The project has gone through several spiritual evolutions, and in the process of all the change, I've found what I think are a core core set of ideas that can act as the foundation.

The first and most thought-out idea so far is the cost tracking mechanism. The idea that anyone can look at any product and know exactly how much labor and resources into it is not just exciting for economists, but has huge implications for a system where production is expressly social and based on need. Regardless of the system in use, it also allows us to estimate various externalities of production such as direct carbon output.

Secondly, the original version of Basis had the idea of various elected boards/councils that ran various regional services. This was a blueprint for a society, and since then, has been largely generalized to separate concepts: voting and permissions. One of the ultimate goals of Basis is to allow various groups of people to call votes and to have the results of those votes enforced by the system. So instead of setting up guidelines for a society and hoping that the patterns are self-enforcing as time marches on, instead the idea is to give members the ability to set and enforce their own guidelines. For an example, the members of a particular region might vote to give a council of 10 people a set of permissions (for instance, the permissions to manage regional assets), and at least 7 of the council members will have to agree in order for a transaction making use of that permission to be registered. In other words, the permissions of the system can be enforced by the voting mechanism itself, thereby limiting corruption of elected officials and making sure they are accountable to their voters. This also makes it so permissions can be revoked if voters are not happy with their representatives. So in general, we set up permissions for various regional or system-wide abilities, and assign those permissions through direct or liquid democracy.

Asset management is another major generalization. Instead of the idea of a housing board, and a means of production board, and various other boards for handling various other regionally-owned things, we just set up general asset management and let the people of a region manage assets their own way.

The last update worth noting is the idea of public companies. In the original paper, there were various services set up and codified that required elected supervision. Instead, the concept of pre-determined public services is being replaced with the idea of public companies and public projects. Instead of mandating that a school be public, instead the people of the region can decide this for themselves. Should a school charge tuition or should it be run off of the regional funds? Perhaps the region covers 50% of the school's costs, and the rest is up to members to pay the tuition. Or perhaps a region wants a hospital where all care is covered 100% by the region's funds. Maybe a bridge is built and the members of the region think 50% should be a regional cost and the other 50% should be covered by bridge toll. Public companies and public projects allow these setups to be created without being rigid about what should be created and what shouldn't.

These are some examples of the project-wide changes that give people the power to shape their own lives. Basis has been evolving more and more to better align itself with the ideas of libertarian socialism: free association, direct democracy, worker self-management, voluntary participation, and prosperity through common ownership. This is why I am finally happy to release and I'm now looking for people who want to contribute to the project, either in code or in ideas.

Please see our roadmap if you're interested in helping out!