Basis: a protocol for a post-capitalist economy (v3.0)
Or: How I learned to stop worrying and produce without profits and private property
(Last update: March 26, 2024)
Part 1: Introduction
Chapter 1: On capitalism, and why alternatives are needed
As various parts of our modern economic system inevitably fail, it will be important to quickly find alternatives. This paper, and the system it describes, is a step in the direction of finding new modes of relating to each other in a way that balances self-determination, personal fulfillment, productivity, and ecology.
When asked the question “What is capitalism?” some might say it’s a system of distributed production. Or a set of property relations. However, in the more general sense, it’s an economic protocol.
You “own” a thing. You rent it to others. They buy things and transform them into new things. If they sell the new things for more than the cost of buying and transforming them, they win. If they sell for less, they lose. The protocol itself is almost painfully simple.
Yet hidden in this simple protocol is worlds of complexity. The driving force of profit – selling things for more than it cost to make them – has the side-effect of incentivizing pushing the costs involved in producing things onto other people (externalities). This could be anything from dumping toxic waste into a river to selling products that are designed to fail a few days after the warranty expires. When your systemic survival as an economic entity depends on making one number go higher than another one, most entities will do just that regardless of the negative effects suffered by those around them. There’s another effect to this as well. If one entity decides it wants to do the right thing and not externalize its costs onto the rest of society, it now has to compete with other entities who do externalize their costs. This might work if wealth distribution were even enough for consumers to make informed, responsible decisions, but more often than not distribution is uneven and people are forced to think in terms of personal survival much more than the greater good. Economic entities that take more wholistic approaches to production are often forced into obscurity by the forces of competition and uneven wealth distribution.
Thus, capitalism actively incentivizes externalities both individually and systemically. And so, although praised for its simplicity and effectiveness, more complex systems must grow out of capitalism as control mechanisms. In a sense, capitalism itself is only simple because it externalizes its complexity onto those who are subject to it. Now we have governments and states that work tirelessly to not just counteract the negative externalities of capitalism, but to resist (with limited effectiveness) the onslaught of the holders of capital who wish to see restrictions lifted and more wealth diverted toward them. On top of this, these states also need to enforce another quite expensive aspect of capitalism: absentee ownership of property. In effect, this is the ability to exercise control over something you’ve never once used in a productive or even personal capacity. Simple in theory, complex and expensive to enforce in reality.
What’s needed is a more balanced approach to economics. There are very important aspects of capitalism (or, rather, markets in general) that are worth preserving, such as the ability to act as a distributed signal processing mechanism. However, this paper will show that distributed economic signal processing can be done without profit and without absentee ownership of property. It will also outline more effective methods of signal processing than simple prices (which erase massive amounts of useful economic data).
Chapter 2: The Basis protocol
There’s a somewhat unexplored space between a planned economy and a capitalist market system. The positive attributes of planning – democratic participation and production for use (as opposed to production for profit) – can exist alongside the best part of a market system: autonomous distributed production. Basis is an analysis of this space; a non-authoritarian journey into the intersection of building things to satisfy a known need, preserving ecology, and celebrating free association.
At its core, Basis is a protocol that defines a transactional economic fabric and provides detailed cost tracking on top of this fabric. It allows agents of an economic network to request products and services from each other in a way that automatically accounts for labor and resource content much more accurately than money and prices. As a result, all products output by this network have not just a list of all the different occupation hours/wages that went into producing them but also both the details on the resources used (and by what quantities) and the processes that transformed these resources. All productive transactions in this network are transparent to participants. This means for any given product, anybody can see its entire supply chain: what companies were involved, what wages were paid, where the resources were originally sourced, and more.
Basis also defines a currency system, the ability to democratically price resources and processes independently of their extraction costs (for instance, participants might democratically raise the price of fossil fuels as a mechanism for lowering their usage globally), and the means for determining use of property outside of market mechanisms.
Lastly, in Part 3 of this paper, we will explore not just the described system as a big fat what-if but also the path to transition from here to there and many of the mechanisms that will get us there.
Part 2: Protocol definition
Chapter 1: A high level view of Basis
Basis – a protocol for post-capitalist production – can be broken down at a high level into three main components: agents, resources, and blocs. All other actions or parts of the protocol are in support of the interactions between these three components.
An agent represents a single person participating in the protocol. Agents are the initiating force behind any movement within the protocol: from performing labor to voting to consuming products. All actions within the protocol are driven by agents.
Resources are anything that can be used or consumed. This could be a chair, a tractor, a factory, a river, a beach condo complex…anything that might be used or consumed in a productive capacity or for normal use by individuals.
Blocs are groupings of agents and resources. All productive activity, cost accounting, use of shared resources, and protocol-based group decision-making happens through blocs. A bloc can have just one single member, or can have millions of members. A bloc can be a productive entity, a geographic grouping of people and resources (a town, for instance), or any other grouping people wish to associate under.
It’s important to note that this part of the paper assumes the Basis protocol is ubiquitous. It focuses solely on the dynamics of the protocol itself. Part 3 of the paper will outline methods of interacting with systems outside of the protocol and detail how value translations are made.
Economics
As most of this protocol revolves around economics, it’s important to outline some of the ultimate goals of the economic relations in Basis.
Production is engaged in without profit or exchange of currency. Blocs track costs directly, and assign these costs to their products and services. Costs are separate groupings of labor, tracked resources, and tracked economic processes. Blocs then assign these costs to their products, and they are only able to assign costs already assumed by the bloc: inputs and outputs must match. When another bloc orders one of these products, the product’s cost is transferred from the producing bloc to the ordering bloc. No exchange of currency happens. When an agent consumes a product, the costs of that product are removed from the system. This direct cost tracking avoids the need for currency within the productive system and eliminates the idea of profit.
When a bloc marks a product as available for agent consumption, it is given a price. This price can be set independently of the cost of the product (for instance if demand drops, the bloc can set a clearing price). However, the bloc does not realize any difference between the cost and the price because the currency used by the consuming agent is destroyed on spend.
In the absence of profit and a strong link between price and cost, another mechanism must act as the feedback mechanism for blocs. Basis uses a cybernetics system that adjusts a bloc’s “allocation” (how much costs it can assume in total at any given point) based on its overall, ongoing performance.
As a final note, the economic vocabulary used in the Basis protocol are an extension of the ValueFlows 1 protocol, a Resource-Event-Agent (REA) accounting system that allows defining flows of resources through productive networks. Many of the processes or actions described in the Basis protocol will reference various portions of ValueFlows.
Two-layer organization
Basis defines two main layers of operation. The inner layer is the primary productive system. This is the layer that blocs and resources exist inside of. This is where detailed cost tracking occurs, and all transactions within this layer are transparent.
The outer layer is where things like setting network parameters, making consumer purchases, secondary market exchanges, and other actions occur. In other words, this is the layer where things happen when agents are not engaging in primary production. Things that happen in this layer are private by default.
The distinction between layers is important because while much of what happens in the outer layer affects the inner layer (for instance, consumer purchases acting as a demand signal), the meat of the protocol focuses on the processes and interactions of the inner layer: profitless production.
Chapter 2: Agents
An agent is any individual who wishes to be a part of the Basis protocol. The particulars of how somebody becomes an agent is left to Part 3. For our purposes here, we will assume that somebody is an agent for no other reason than they wish to be one, and leave it at that.
All agents are equal within the Basis protocol. They all have the same abilities and privileges. This includes equal abilities to freely associate with other agents, equal decision-making power in the blocs they are associated with, and equal treatment regarding access to and management of the resources around them.
Every action within the protocol, whether direct or indirect, is driven by an agent acting as an agent of the protocol. While this is probably true of most protocols, it’s worth stating.
Agents and identity
Basis requires the use of an identity protocol for agentship. This ensures various aspects of the protocol are the same for everyone. For instance, without identity the protocol would not be able to determine if someone cast multiple votes in a decision.
For this, Basis relies on its sister protocol, the Stamp project. Not only does Stamp provide an identity system for agentship within Basis, but it provides the necessary mechanisms for democratic structures of blocs.
Accounts
An account is a protocol-defined electronic storage for the protocol’s currency, credits. These would be analogous to bank accounts that can be accessed via the web or a mobile app. Agents can have any number of accounts and can transfer their credits freely between them.
Chapter 3: Resources
A resource in Basis, which extends the concept of a resource as modeled by ValueFlows, can be anything that’s useful in a productive sense, either as an input to production or an output of production. A resource could be a house, a river, a chair, a factory, a farm, a tractor, etc. It’s important to note that in Basis, resources must be explicitly entered. There must be intention behind a resource existing in the system.
By default, Basis assumes that ownership of all resources described in the protocol is shared by all agents equally. An agent in India is an equal owner of the factory in Canada, and an agent in Hawaii is an equal owner of widget batch #506771 produced by Widgets”R”Us in Africa.
Instead of ownership, Basis defines two other relations to resources: stewardship and use.
Stewardship
Stewardship is a relationship between a bloc and a resource. Stewardship allows determining how a resource can be used or consumed. This can include setting time limits on use, determining costs of use, and any other facet that might arise. For instance, a farming guild bloc might have tractors available for local farmers to use. A chair production bloc might make their chairs available to order for other blocs or for consumption by agents. Blocs don’t have to be productive either: a housing bloc, which stewards houses or apartments, can determine the rules for use of their units. A municipal bloc might set hours of acceptable use on a public park.
The distinction between stewardship and ownership can be thought of as the distinction between ad-hoc and bureaucratic. Stewardship can shift and change over time, where ownership much more rigid.
Use
Use is a relationship in which a resource is in active consumption by either an agent or another bloc. Usage of a resource might often happen by members of the bloc in stewardship, but this isn’t a given, and anyone can use a resource within the bounds set by the steward.
Usage could be something like living in a house, renting a car, taking a bus, operating a lathe, etc.
Determining stewardship
The system we use for distributing “property” and resource stewardship is somewhat simple: agents and blocs negotiate this amongst themselves. There is no protocol-defined criteria for who stewards what and why. Trying to devise a framework which can determine optimal placement of resources for any set of people or circumstances is futile, and any attempt would be brittle. So we don’t.
As a general guideline, resources are best stewarded by the groups of people in use of them. However, while Basis strives to quantify some forms of use, it’s impossible to do so for all types of use, so participants must determine this for themselves. And to a large extent, people already do this in the current system.
Reassigning stewardship
TODO:
Resource costs
As mentioned, resources in Basis extend resources in ValueFlows. Basis adds two properties to VF resources: who is in current use of the resource and a set of costs associated with the resource.
What exactly costs are is expanded in more detail in the costs section of the paper, however it’s worth mentioning here. Costs are useful to think about in the context of usefulness of resources: a building that took labor and resources to construct, an inventory item for a factory that’s consumed for the creation of another product, or even some set of land that requires ongoing maintenance like a forest or a park. Almost all useful resources generally have some cost associated with them.
Note that while resources can hold a cost, the bloc in stewardship of that resource is responsible for the cost.
Chapter 4: Blocs
A bloc is a grouping of agents and resources. The agents that are part of a bloc are known as “members” and the relationship between a bloc and a resource is known as stewardship.
All blocs are cooperative entities controlled by their members. Leadership (if any) must ultimately be selected by individual agents, and all policies regarding membership of blocs must be ratified by the members. As such, Basis defines a bloc as a bottom-up power structure that puts individual agents in ultimate control of the groups they are members of.
Blocs and agents are freely-associating entities: any agent can join any bloc as long as the entities involved consent to the association.
Blocs are free to use whatever organization structure they see fit. There is not any predetermined pattern or framework blocs must follow, with the caveat that the members in a bloc have ultimate power regarding the bloc. Blocs can use a traditional top-down structure where members select a board/council that determines overall direction and leadership, or blocs can be run as a collective where everyone is involved in making every decision. Blocs can have vesting schedules for new members. They can be set up as multi-stakeholder entities (for instance, shared control between workers, customers, vendors, and/or the public).
Membership in a bloc is completely decided by the bloc itself. Membership might be determined by geographical location, interest or skill in a particular sector of production, and can even depend on things like compulsory ordering of a service every month (which could be structured as a membership fee or even a tax in the case of a municipal bloc). Some blocs might require membership in sister blocs: perhaps you cannot be a member of the Duluth Housing bloc if you are not also a member of the Duluth Municipal bloc.
Bloc structure
Blocs are necessarily controlled by their members. How this control is shaped is determined by the bloc itself, however this structure must be formally defined via Basis’ sister protocol, Stamp. Stamp provides a cryptographic system for defining group control of an entity.
In essence, each bloc maintains a group identity defined by Stamp, and that identity is used to formalize membership and also control of the bloc. In other words, agents become members of a bloc by the bloc blessing them with some form of cryptographic control of the bloc.
Stamp also allows group members to act on behalf of the bloc in ways predetermined by the bloc itself, making it so responsibilities and powers can be delegated to an individual agent.
The relationships and powers Stamp can express in the context of group control of an entity are effectively endless.
Bloc voting
TODO:
Bloc allocation
Every bloc has an allocation. This is a variable number that determines the upper limit on costs that the bloc can assume. If the bloc’s total costs (the sum of all the bloc’s pending wage costs, resources, and processes) reaches this number, the protocol prevents the bloc from taking on any new costs, be it ordering inventory, paying wages, or any other ways that blocs can take on new costs. The allocation can be thought of as the total amount of societal debt that a bloc may take on.
The total costs of a bloc can be determined by taking the costs of all the bloc’s labor costs, resources, and all the bloc’s processes and summing them together. This gives a final cost object, which can be converted into a final number.
Once a bloc’s total costs reaches its allocation, a bloc must find a way to unload its costs. This would happen via other blocs or consumers ordering products or through direct member taxation.
The actual allocation value is determined by the investment and cybernetics systems defined by the protocol.
Allocation overage
TODO:
Cost staging
TODO:
Chapter 5: Costs
Cost tracking is the core of Basis; its primary function. How costs are interpreted or acted upon is important, but secondary to the actual gathering of costing information.
When people think of a cost, they often think of a number, and usually a price. Basis expands this concept of cost into something much more dimensional than a number. It tries to answer the question “what did it cost to make something?” How much labor? How much raw materials? What transformational processes did resources/raw materials go through to become the final product?
Costs in Basis are not a number, but rather separate collections of individual values bundled together. By default, this includes:
labor-hours: Hours of labor, grouped by occupation. Occupations are managed as network-global parameters.labor-wages: Credits paid to workers, grouped by occupation. Occupations here are the same dataset as those managed inlabor-hours.resources: Generally raw/semi-raw materials, grouped by the resource/raw material type, and optionally broken down further by extraction location. Resources are extensions of ValueFlows resources.processes: Economic processes that transform resources (such as “refine oil”). Processes are extensions of ValueFlows processes.
Note that this is known as in-kind 2 cost tracking.
Resources and processes tracked as part of costs objects are not exhaustive. While it generally makes sense to track every kind of labor that goes into building something (so workers can be remunerated), it doesn’t necessarily make sense to track every single resource type or every single economic process. The general idea is to track resources that are scarce so their consumption rates are known and to track resources/processes that have known externalities so their costs can be internalized.
For instance, we know that burning gasoline has externalities relating to carbon output. We could track the process of burning gasoline, however doing so would require a lot of overhead. Instead it might make sense to track just gasoline, assume that it’s in almost all cases going to be burned, and assign the externality cost to the resource itself.
But how do we get gasoline? This is where processes come in. Not only can processes in Basis be assigned an externality cost, but they can also transform resources: crude oil is consumed by the process of “refining” and becomes gasoline, jet fuel, etc.
Distinction between tracked processes and bloc processes
It’s worth noting that the processes blocs use when producing are determined by the bloc and are independent of the concept of tracked processes described above.
For instance, a bloc might have the process build chair it uses when producing chairs, but build chair does not need to be a network-wide tracked process in order for that bloc to use it. In other words, blocs are free to track internal processes in any way they deem fit, however cost resource transformations (crude oil -> gasoline, jet fuel, etc) can only happen through network-tracked processes which are created and maintained via democratic process.
Cost representation
Here’s an example of what a cost object might look like:
{
labor_hours: {
president: 0.2578
accountant: 0.0965
miner: 1.0363
}
labor_wages: {
president: 15.468
accountant: 3.86
miner: 36.2705
}
resources: {
iron: 8.5
gasoline: 2.9
silicon: 0.03
}
processes: {
refine: {crude oil: 5.8, methane: 0.5}
}
}The actual labels like president, iron, refine, etc will generally not be names, but rather be network-specific uniform resource identifiers that point to a part of the network’s global storage. We use names here for the purposes of simplicity to show how costs are structured.
Cost extensions
The protocol allows cost objects to be extended to track other types of costs. For instance, currency (covered in part 3).
This accomplishes two things: it keeps the Basis cost tracking core lean and simple, and it allows tracking cost types that the protocol’s creators couldn’t think up at the time of creation.
Mathematical operations on costs
Even though costs are not single numeric values, they can still have a number of mathematical operations performed on them. Here are a few examples:
Addition
Costs can be added to each other. As an example:
{
labor_hours: {
lumberjack: 3
}
labor_wages: {
lumberjack: 60
}
resources: {
wood: 500
gasoline: 4
}
processes: {
refine: {oil: 8, methane: 0.7}
}
}
+ {
labor_hours: {
trucker: 1.5
}
labor_wages: {
trucker: 37.5
}
resources: {
diesel: 3
}
processes: {
refine: {oil: 9, methane: 0.8}
}
}
----------------------------------------
{
labor_hours: {
lumberjack: 3
trucker: 1.5
}
labor_wages: {
lumberjack: 60
trucker: 37.5
}
resources: {
wood: 500
gasoline: 4
diesel: 3
}
processes: {
refine: {oil: 17, methane: 1.5}
}
}Subtraction
Costs can also be subtracted from each other, although costs with negative values are invalid and will result in an error.
{
labor_hours: {
lumberjack: 3
trucker: 2
}
labor_wages: {
lumberjack: 60
trucker: 50
}
resources: {
wood: 500
gasoline: 4
}
processes: {
refine: {oil: 8, methane: 0.7}
}
}
- {
labor_hours: {
lumberjack: 1
}
labor_wages: {
lumberjack: 20
}
resources: {
wood: 200
gasoline: 1
}
processes: {
refine: {oil: 2, methane: 0.1}
}
}
----------------------------------------
{
labor_hours: {
lumberjack: 2
trucker: 2
}
labor_wages: {
lumberjack: 40
trucker: 50
}
resources: {
wood: 300
gasoline: 3
}
processes: {
refine: {oil: 6, methane: 0.6}
}
}As mentioned, costs with negative values are invalid, so
{ labor_hours: { carpenter: 15 } }
- { labor_hours: { carpenter: 5, trucker: 3 } }
-----------------------------------------------
{ labor_hours: { carpenter: 10, trucker: -3 } }would result in a protocol error. To allow this would be unfair to our friend, the trucker, whose labor would be negated.
Multiplication
Costs can be multiplied by a decimal value:
{ labor_hours: { carpenter: 2 }, resources: { wood: 5 } }
* 3.5
-----------------------------------------------------------
{ labor_hours: { carpenter: 7 }, resources: { wood: 17.5 } }Division
Costs can be divided by a decimal value as well:
{ labor_hours: { carpenter: 16 }, resources: { wood: 12 } }
/ 4
-------------------------------------------------------------
{ labor_hours: { carpenter: 4 }, resources: { wood: 3 } }Incentives
We’ve talked about what types of costs can be tracked, but we haven’t covered why a bloc would bother tracking costs. What do they get out of it?
In essence, the system pays them to track the costs. For instance, how does Basis know to pay a worker their wage? Well, they would track that cost in the system, and as a result they would get payment. The same principle works for all cost tracking: when a bloc tracks the cost, the workers of that bloc get paid.
The exact mechanisms at play here are covered in the cost staging section, which balances the incentive to create new costs with the base goal of meeting a social need.
Chapter 6: Cost and resource flows
Now that we know what costs are and the information they track, let’s look at how costs (and resources) are tracked and how they move through the system.
Bloc cost tracking
Costs are tracked by blocs in two main ways: costs are created when workers perform labor and costs are assumed from other blocs when ordering products/inventory. Looking at this from a high level, a bloc orders inventory, applies labor to it, and creates a product. The resulting cost of the product would be cost_inventory + cost_labor (see the section on cost addition).
So if a woodworking bloc with one worker orders 50kg of lumber with a cost of
{
labor_hours: {
miller: 0.5
trucker: 0.1
}
labor_wages: {
miller: 15
trucker: 2.5
}
resources: {
lumber: 50
diesel: 0.5
}
processes: {
refine: {oil: 5}
}and then applies 10 hours of labor to make five chairs, we get the total costs:
{
labor_hours: {
miller: 0.5
trucker: 0.1
woodworker: 10
}
labor_wages: {
miller: 15
trucker: 2.5
woodworker: 200
}
resources: {
lumber: 50
diesel: 0.5
}
processes: {
refine: {oil: 5}
}If the woodworker wishes to assign each of the five chairs the same cost, then we take the above cost and divide by 5:
{
labor_hours: {
miller: 0.1
trucker: 0.02
woodworker: 2
}
labor_wages: {
miller: 3
trucker: 0.5
woodworker: 40
}
resources: {
lumber: 10
diesel: 0.1
}
processes: {
refine: {oil: 1}
}This is the cost of each chair. Now, if another bloc needs a chair, when they order one from our woodworker, the cost of that chair is removed from the woodworker’s costs and assigned to the ordering bloc’s cost because the cost is associated with the chair resource and as the chair flows through the system, so does the cost.
This is an example of how costs are created and assigned to resources. Blocs are free to manage costs however they see fit with a few constraints enforced by the protocol:
- Costs out must equal costs in. Blocs cannot remove, reduce, or otherwise modify the amount of costs (other than adding to them).
- A bloc must not exceed its allocation.
Bloc processes
At a lower level, a bloc can use processes as a way of breaking down flows of resources and labor internally. A process is an activity that transforms economic inputs to outputs. In Basis, processes extend the concept of processes in ValueFlows by adding a set of costs associated with that process. A bloc can have as many processes as it wants, each with a set of associated costs.
In the above example, our chair maker might have a process for unload lumber shipment, which yields usable lumber which can be used in the make chairs process.
It’s important to note that as resources have costs, so do processes. For instance, make chairs might first have the cost of the lumber added to it, and then the labor of the chair maker. Once the chairs are created, the total cost of the make chairs process might be assigned equally to the chairs.
It’s important to note the distinction between tracked processes and bloc processes.
Labor and Wages
When an agent performs labor for a bloc they are a member of and if they track this labor within the protocol then they will receive wages in the form of credits. The exact arrangement of how the wage is arranged is between the member and the bloc: it could be hourly, it could be salary, it could be project or commission based, some combination of all three, or something entirely different. The protocol does not enforce any form of arrangement, but it does allow the bloc or the member to register the labor and provides methods for compensating it with credits.
This is how labor_hours and labor_wages are created and tracked in the protocol: agents get paid for their work by creating labor transactions.
For details on when labor transactions are created versus when credits are paid, see the section on cost staging.
Orders
So far we’ve alluded to things like “a bloc orders inventory” but we haven’t talked much about orders or how they work. Basis defines a transactional fabric to facilitate blocs ordering products from each other. An order is an expression of intent from one bloc to another that communicates that a resource or service is needed (and the ordering bloc is willing to take on a specific cost in exchange for that resource/service).
So if one bloc needs lumber to make their widgets, they might find another bloc that produces lumber and they create an order in Basis for what they need. If the lumber bloc approves, then the order is finalized and the lumber (and the costs associated with them) are transferred to the widget bloc. This is a simplistic example and ignores things like logistics, but the general idea is that Basis facilitates the expression of intent and movement of costs between blocs.
Orders are the drivers of flows of value through the system. Orders move resources and costs between blocs and facilitate production.
Orders in Basis are a direct extension of Agreements and Intents in ValueFlows.
Transparency
All orders, processes, resources, and transactions that affect all of these things are completely transparent to any agent of the network.
This means that the order book for any given bloc can be viewed by any other company. While this might seem radical to the casual reader, the reasoning behind it is that if demand can be sensed directly (via knowing the incoming orders for any given products), profit becomes vestigial. One primary goal of Basis is to eliminate the profit mechanism in production, and what better way than to allow for reading demand directly?
Chapter 7: Trackers (occupations, resources, and processes)
We’ve covered the flows of costs and we’ve covered how labor is tracked, but we still need to detail how occupations, resources, and processes are categorized as well as the incentives blocs have for tracking them.
Trackers
Anything that can be tallied as part of a set of costs is described by what is called a “tracker.” A tracker is an intent created by the agents of the network that guide costs to incorporate certain information.
Trackers come in three different classes: occupations, resources, and processes. Each class is structured as a hierarchical tree: a top-level node that can have unlimited children, with each child capable of having unlimited children, and so on.
Every tracker in the network has a set of standard fields that all trackers share, as well as any number of translations for that tracker:
Translatable {
translations: {
en-US: {
name: <english tracker name>
description: <english tracker description>
}
<localized names/descriptions> ...
}
}
Tracker: Translatable {
id: <unique id>
parent: <unique id>
children: [ <unique id> ... ]
<type-specific data> ...
}TODO:
Occupations
TODO:
Resources
Processes
Converting costs to a single value
TODO: make note in wages section that 1 labor hour = 1 credit
Although costs are tracked as separate collections of distinct values, it’s important that they are able to be summed into one aggregate number: a total cost. This allows blocs to get a quick sense for their overall cost amounts, which factors into determine how much of their allocation is used.
Deriving this total value is simple in the case of labor and labor_hours, we simply sum the values together. For instance, in the object above, we would have 12.89 + 3.38 + 41.45 + 0.2578 + 0.0965 + 1.0363 or 59.1106.
The tricky bit comes when we convert our resource values into a cost, and this is where tracked resources and tracked processes come in: they allow categorizing a resource within the cost tracking system such that a standard unit can be assigned a cost value. Thus, if in our example above, iron is tracked in grams, and the cost-per-gram is 0.3 then the iron cost would be 8.5 * 0.3 or 2.55. If done for all resources in the costs set, we can add this to our labor costs and find our total aggregate cost value.
Chapter 8: Investment
Investment determines the allocation of a bloc, allowing that bloc to take on greater or lesser costs.
Agent investment
TODO:
Cybernetics
TODO:
Product pricing
So far we’ve talked a lot about costs. Does this mean that every product purchased by a consumer will be provided at-cost? No, and there two facets to this.
First, for agents, the system will optimize for providing products at-cost. In other words, companies that do sell products for exactly their cost will be rewarded. That said, companies can set whatever prices above or below cost they want. The difference from a moneyed market however is that when a bloc sells a widget for 10₡ that only cost 8₡ to produce, it doesn’t realize the extra 2₡: the credits are still burned on purchase.
So why let companies set arbitrary prices at all? It enables things like clearing inventory for products that didn’t sell well, and also it enables inventory control for higher-value items. Member companies don’t realize the delta between cost and price as a gain or loss, but rather it is used as a signal to determine if the production of that particular product should be expanded or contracted. In other words, we retain the signal mechanism from pricing without using it as a distribution mechanism.
This system of pricing is described in “Towards a New Socialism” 3
Chapter 9: Bankruptcy
What happens to a bloc when its allocation is reached and it has no incoming orders? What happens if the last member of a bloc leaves and that bloc still holds costs?
Where are these costs transferred to?
TODO:
Chapter 10: Currency, credits, and UBI
Every agent has the ability to accrue the network currency (credits, ₡) in any number of accounts they wish to manage. Credits can be spent on goods and services provided by companies in the Basis system. Credits differ from money in that they are destroyed when spent. Credits do not circulate the primary economy, and only exist within the accounts of agents.
Labor credits
Labor credits are created by performing work within a productive bloc and are transferred to the agent once that work has been validated by the bloc. This creation and transfer has two effects: the value of the credits is added to one of the agent’s accounts, and the labor cost of that amount is added to the bloc’s set of costs.
While it might be somewhat clear that credits share some DNA with labor vouchers, there are some significant differences.
Credits do not expire. There is no attempt made by the monetary system to limit individual accumulation of credits in any way.
Secondly, credits are freely transferable, privately and anonymously, to other members. This allows for secondary markets, which Basis has no desire to control or eliminate in any way. If your toaster breaks, why buy a new toaster when you can buy your neighbor’s for half the price? It’s not ecological to force everyone in the system to buy everything new. It’s also futile to attempt to eliminate secondary markets completely. So we don’t bother.
The case for non-transferable credits is that people might sell their labor in the secondary market and therefor the secondary market must be eliminated. If we have a situation where people feel compelled to sell their labor in the secondary market instead of the primary market, Basis is a failed system. What we need instead of control and force is strong incentives to participate in the primary economy. For instance, someone selling their labor in the secondary economy would need enough credits to buy the equipment they need up-front whereas if they are a producing member in the main economy, they might be given an up-front allocation (ie, a social investment). Secondly, member companies cannot pay people directly in credits because they don’t handle credits, so if you’re selling your labor in the secondary economy only those who are also operating in the secondary economy can hire you.
UBI Credits (Universal Basic Income)
UBI credits are earned simply by being an agent in the Basis protocol and accrue on a regular schedule. UBI credits act differently to labor credits in a few ways:
- UBI credits are printed and paid out whenever participants wish to claim them, and are paid based on how much time has elapsed since they were last claimed.
- Labor credits and UBI credits are not interchangeable. They are distinct currencies.
- UBI credits are paid into a special account that is attached to each agent.
- The UBI account has a ceiling value which caps the maximum amount of credits the account can hold. For instance this ceiling value might be 12 months’ worth of periodic value. This effectively limits UBI from accumulating endlessly if it’s not spent.
- Unlike labor credits, UBI credits cannot be transferred to other members. It is always attached to one person.
UBI Governance
TODO:
Consumer purchases
TODO
Anonymity
While the transactions between member companies are transparent and freely observable by any member of the network, there are a few cases where privacy is offered:
Consumer purchases. Whether a member or a non-member, purchasing goods from a member bloc is anonymous. The order is viewable by members, but looks like it came from the Basis system directly and is not tied back to the originator in any way. Only the user and the bloc have the full information on the order.
TODO:
Part 3: The Real World
Chapter 1: Interfacing with the outside world
Great, so we’ve detailed a protocol that will slowly alter the course of our global productive system into a much more intentional, ecological direction. Now what?
Here we will explore how might Basis function not just in a fantasy world but within our existing one. We’ll detail purchasing of external market goods, selling of network goods into the market, the banking system that makes this possible, and the incentive structures that allow the network to grow steadily.
After all, this protocol is no good if it cannot interface with the outside world.
Chapter 2: Banking
Banking provides the actual interface between the Basis network and the outside market system.
TODO:
Chapter 3: Currency interfacing
TODO
Currency tracking
When a company needs to buy something from capitalist markets, it spends currency out of a capital pool to do so. The cost of this currency, like all other costs, is tracked by Basis. This is covered in more detail in the banking section.
TODO
UBI
UBI can only be spent on non-currency costs of products and services. In other words, if an apple has a cost of 3₡ + $2, the UBI can pay for the apple’s three credits, but the $2 of currency value will have to be covered by credits obtained through labor. The reason for this is that currency costs are an obligation to the market that must be paid back by value creation. If this obligation is not met, the network will go bankrupt and fail. This has another interesting side effect though: producers are incentivized to obtain their inputs to production in-network because it means their outputs will have less currency and consumers will be able to afford them at a higher rate. In other words, a systemic incentive on productive self-sufficiency.
Chapter 4: Transitioning existing companies
TODO:
Chapter 5: Network self-sufficiency
TODO:
References
Foster, Lynn & Haugen, Bob, & et al. (2020, June 6). A vocabulary for the distributed economic networks of the next economy. ValueFlows. https://valueflo.ws/↩︎
Wikipedia (2021, August 11). Calculation in kind. https://en.wikipedia.org/w/index.php?title=Calculation_in_kind&direction=next&oldid=1030707980↩︎
Cockshott, W. P., & Cottrell, A. (1993). Chapter 8 - The Marketing of Consumer Goods. In Towards a new socialism. Essay, Spokesman.↩︎