This is a follow up to Balaji Srinavasan’s article on the same topic. If you want a broader context, I highly recommend you to read that article first. Without further ado, let’s start.
What Do We Want To Create?
In the initial article, a country is described based on the current understanding of the concept. But this concept, like any other concept, was built on top of other concepts. In the last 3,000 years only, we had many understandings of the “country” idea, each with its own particularities.
It is plausible, then, to consider this concept fluid, ready to adjust to new contexts.
I think there are more benefits in choosing a more loose concept, one that can be adapted, than to aim at creating a new “country”, in the current sense of the world. In a way, I’m thinking of the “next generation” type of country, in the same sense as we think about new versions of the same app.
To differentiate this concept from a traditional country, I will name it Autonomous Distributed Structure, or, in short ADS.
The basic characteristics of such an ADS would be:
- legal status (it should be recognized by, and recognize other countries)
- no fixed territory (citizens can be spread all over the world)
- common constitution and defined governance (to which all citizens should abide, just like in a traditional country)
- unified (or official) currency
- citizen identification / differentiation, for free movement purposes (the equivalent of a “passport”)
- timespan (can be undefined / ongoing, or limited, for example: 10 years)
Nice to have, but not mandatory
- cultural insignia (flag, anthem)
- official language
- learning / studying facilities (recognized by other ADS)
- health / wellbeing facilities
- financial institutions (common vehicles for currency)
The Software Paradigm
By now, you should have identified a few semantic hints that this structure borrows from software development patterns. So, we will consider this ADS to be the upgraded version of the “country” app.
Let’s see how such an app should be built, what are the intrinsic, structural features of the model itself (these are not the characteristics, or the properties of the object, we defined them in the first paragraph).
So, an ADS “app”, should have:
- clean dependencies
- composability
- open / closed APIs
- clear obsoletion pathways
Let’s try to look at them one at a time.
Clean Dependencies
Just like an app that is built on top of many different packages, an ADS should play well with whatever it uses. The most important part would be resource management, more exactly territory / land. In order to have / maintain land borders, an ADS should use legacy dependencies. It should either buy or rent (legacy methods) or create borders where there weren’t before (seasteading, or space exploration). I find both seasteading and space exploration quite expensive (but I don’t rule them out completely), so we need to rely, at least for now, on legacy methods.
That boils down to create clear rapports with the parent class / country. From this perspective, building an ADS on a country which doesn’t have clear property laws would be ineffective. In software terms, we wouldn’t even pass the dependencies step, let alone get to the building.
Composability
An ADS should be built with inter-operable components. The currency, for instance, should be easily interconnected with governance laws, which, in turn, should be interconnected with citizen identification and ADS timespan. One such component should be easily packaged and adjusted to another ADS, just like frameworks in software could be re-used in different apps.
For instance, a few ADS can share the same currency, with the same tokenomics, but they may borrow the governance “frameworks” from other ADS, or have their own.
Open / Closed APIs
An ADS should be able to respond in a deterministic way to various queries. One of these queries could be, for instance, “getCitizenship”, while other could be “getLand”. Each of these APIs could be either open or closed. Open in the sense that anyone can get a response, while closed means that only citizen in that country can access those endpoints.
The case for closed APIs has to do with privacy, which can be treated differently in different ADS.
Following the composability model, the open APIs could also be standardized across various components, meaning all ADSes can adopt the “getCitizenship” endpoint and offer a formally identical answer.
Clear Obsoletion Pathways
Following the timespan requirement, some of the features of an ADS can be obsoleted. For instance, they may modify the citizenship process, or other governance process. These features should come paired with clear obsoletion pathways for the features that are superseded, giving time and resources to citizens or wannabe citizens to adjust.
An Hypothetical Autonomous Distributed Structure
Let’s try to describe a hypothetical ADS which will feature the basic properties (sort of a “Hello World” program for the “country” app).
This hypothetical ADS would be named Nolandia (a gimmick for the “no land” property of such a country). Any person owning private property in a country which recognizes and protect private property, and free association, could “subscribe” to this country, by accessing its “getCitizenship” API endpoint. Upon acceptance, they will get the status of “Nolandians”, which will give them access to all of the benefits of the country. Such benefits could include (but not be limited to):
- access to country crypto currency
- access to country owned learning facilities
- access to country owned health / wellbeing facilities
- access to country owned living facilities (co-sharing)
The status of a Nolandian citizen will also incur obligations, along with rights, which will be adopted at the moment of receiving the citizenship, and part of the Nolandian “constitution”. One of this obligation, would be, for instance, to participate actively in the country governance.
From a legal standpoint, “Nolandia” will be a free association, which will operate through its members, who own private land, protected by the laws of the parent country in which they reside. From this point of view, there’s not much of a difference between an ADS and an union. Things will change, though, when we a go a bit further.
Nolandia’s citizens freedom of movement will be initially derived (inherited?) from the laws of the parent country, and after that it would be part of a inter-country agreement between Nolandia and each parent country in which Nolandia has citizens. And with this we are becoming a cross-country structure, or a pan-country association, and that adds a very interesting layer of complexity on top of the initial structure. We’re closer to a multi-national corporation now, and that incurs, among other things, a lot of energy spent in lowering legal friction with the countries in which the corporation operates.
Nolandia will have a cryptocurrency, called NLD, which will be accessible not only to Nolandian citizen, but also to anyone else who considers NLD to be a good investment, just like various fiat currencies are traded 24/7 in the Forex market.
Each Nolandian citizen will have a form of identification, based, in this specific example, of zkSnark (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), because Nolandia will be a country with a strong stance on privacy. That means a Nolandian citizen could be identified as such without disclosing sensitive information about that citizen (a more thorough discussion on zkSnarks is outside the topic of this article).
Nolandia, as an ADS, will be set to last 50 years, or roughly two generations, with a 10 years notice to either change the governance to extend the lifespan, or to accept its closer at the end of the initial lifespan. If Nolandia ends, all of its structures ceases to exist, including the notion of “citizenship”.
Caveats / Challenges
The biggest challenge in creating a new country will be dependency management, in other words, how to make sure the basis on which the new country is built are stable enough. Here too, like in any software development process, if one dependency fails, we have the options to replace it (move to another parent country, for instance) or build a new one (create “land” by seastading or space travel).
There is also a lot to be thought about composability, for instance about health standards (which are more and more interlinked with free movement). In a pandemic context, would the citizens of Nolandia be allowed to travel, even if the parent country chooses to stay in lockdown? My take is that yes, this should be allowed, with basic protection measures, excluding under-the-skin markup. In simpler words, people from Nolandia should be allowed to travel, if they take all necessary precaution measures (hygiene), but their travel shouldn’t be condition by vaccination (under-the-skin markup).
Another challenge is about monetary policies and how this could impact the parent country/countries financial flow. The recent crypto history shows that this tends to self-regulate, though, as adoption increases.
Final Thoughts
A new type of country is already breeding, the mere fact that we’re discussing publicly the idea is testimony to that, but it lacks the consistency and recognition to become mainstream. Hard to tell when (or even if) an ADS could become mainstream, but the context is favorable.
If dependency management will be done in a frictionless way, we may see ADSes popping out in our current lifetime, if not, maybe the kids of our kids will witness this, as seasteading and space travel will become prevalent.
Initially published on my blog.
There is an ongoing funding proposal for two of my Hive-related projects, which will allow me to support some of the costs involved. If you want to support this proposal, all you have to do is to vote it using any of the two links below:
Sign this proposal with Hivesigner
Peakd: https://peakd.com/me/proposals/165
I'm a geek, blogger and ultrarunner. You can find me mainly on my blog at Dragos Roua where I write about productivity, business, relationships and running. Here on Hive you may stay updated by following me 
Wanna know when you're getting paid?
| I know the feeling. That's why I created hive.supply, an easy to use and accurate tool for calculating your HIVE rewards | |