Version: 0.1 (Draft)

Author: annemnemosyne

Status: Living document

"I have only two adversaries - I will not say two conquerors, for with perseverance I subdue even them, - they are time and distance." - The Count of Monte Cristo

MapDapps is just a set of ideas that I cannot help but to share. The truth is that I am fearful for the state of the world and our place in it. Between the rise of authoritarianism, digital surveillance, and global unrest, my thoughts turn again and again to the early principles of cryptocurrency: decentralization and permissionless-ness. Exit.

And yet I watch the industry focus on gambling, speculation, and scaling the infrastructure it needs to do more of the same. What is the point in moving bits and money around if we aren't interacting with the real world in any meaningful way? We have more compute and blockspace than we know what to do with. Leaders and influencers keep saying we need to focus on applications: well, here we go.

How can we be free if the corporations that own us are replacing the workforce with automation at an exponential pace? If there are no opportunities for work, what will we do? What if we could create something out of nothing? Or rather, what if we could tap a resource that no one else has considered yet? Unmapped features are potentially valuable, and crowd-sourcing these features is not an easy task to automate or scale. It is work that human beings are uniquely suited to doing, and it is work that will be difficult to automate away entirely. I want human beings to go out into the world, explore it, share resources, and form a separate economy that is intimately linked to the real world.

But as passionately as I feel about this project, my limited skill set in combination with the exigencies of daily life have made it impossible. I need help, so I am leveraging AI to get me started. My hope is that these ideas resonate with people and maybe we can collaborate to build this protocol into something that makes humanity more free. Or maybe some human or AI takes this idea and uses it to create a panopticon. I hope not. Either way, I accomplish my goal by sharing.

This rest of this document was written with Anthropic Opus 4.6 along with my own modifications and additions. I had resisted using LLMs to help me write for a long time. I like having my own writing style and my own quirks and flaws, but I feel a sense of urgency and cannot wait until I feel the inspiration to build this the old-fashioned way. I fed the model all of my writings so far in addition to many of my private notes that I've never posted. I worked with the model to flesh out some of the main concepts and reviewed and edited it carefully to ensure that my intent has been captured and represented well.

In this document, I describe MapDapps, a protocol for building a decentralized digital map of the world through composable, community-governed layers of spatial data. I refer to The Map as the sum of all contributions to the project.

I will not accept any Metaverse smaller than a Map of the entire world that is owned by all of humanity.

Digital maps are infrastructure. Most of us cannot navigate a city, find a business, or commute to work without them. They are as fundamental to daily life as roads and running water — and yet they are almost entirely controlled by a handful of corporations.

This arrangement has consequences. Centralized map providers optimize for profit, not for public goods. They index what serves their business model and neglect what doesn't. They collect vast quantities of location data from their users and monetize it through advertising and licensing. They make editorial decisions — what gets labeled, what gets surfaced, what gets hidden — with no accountability to the communities they depict. And they are fragile: a single company's policy change, acquisition, or shutdown can erase spatial data that communities depend on.

Open-source alternatives like OpenStreetMap have demonstrated that volunteer cartography can produce remarkable results. But they struggle with sustained community engagement, have no native mechanism for compensating contributors, and lack the application ecosystem needed to compete with commercial platforms for everyday users.

The Map that the world needs does not yet exist. It should be open and composable, allowing anyone to contribute and build upon it. It should be governed by the communities it serves, not by shareholders. It should be a foundation for applications that connect people to the real world — for navigation, commerce, culture, labor, play, and coordination of every kind.

Most importantly, it would create opportunities to build entirely new markets driven by mappers, validators, explorers, and players. What if you could quit your job and be paid by the community to explore your city, ensuring the Map is correct? What if you could earn a living hunting geocaches? Do cartography and surveying sound boring? What if the interface was a game that felt like more like Pokemon GO?

The tools to build this Map are emerging from the crypto ecosystem: decentralized identity, content-addressable storage, smart contracts, DAOs, zero-knowledge proofs, and token-based incentive systems. These technologies were designed to solve exactly the kinds of problems that a decentralized map presents — coordination without central authority, trust without intermediaries, and governance without gatekeepers.

And yet the crypto community has largely failed to connect its tools to the physical world. We build financial protocols, governance frameworks, and digital art platforms, but we remain disconnected from the places where people actually live. The Metaverse, as commonly imagined, is a virtual space — a retreat from reality rather than an enhancement of it.

MapDapps is an attempt to bridge that gap. The Map is the metaverse pinned to the real world, and MapDapps are the tools we use to interface with it. Every coordinate on Earth is a potential site for digital activity — for commerce, for art, for governance, for play. This protocol is an attempt to make that vision composable, open, and real.

These principles guide every design decision in the protocol. Where trade-offs arise, they should be resolved in favor of these values.

No single entity owns the Map or defines what it contains. The Map emerges from the composition of independently created, independently governed layers of spatial data. There is no "base map" that everything else depends on. There are only layers — and the protocols that allow them to interoperate.

An individual, a DAO, a corporation, a government, a game, or a machine may create a layer and add features to it. No permission is required. No approval process exists. The barrier to creating a layer should be as low as the barrier to creating a private group chat and setting permissions.

Each layer has its own governance — whether that is an individual's personal discretion, a DAO's consensus process, a company's editorial policy, or an algorithm's automated curation. The protocol does not impose governance. It provides the infrastructure for diverse governance models to coexist.

Any layer may be overlaid with any other layer. Any feature may reference any other feature on any layer. Any layer may be forked. These are protocol-level rights, not privileges granted by an authority. Just as any website can link to any other website, any layer can compose with any other layer.

In practice, layers may have differing scope and availability. Private layers may be forked from publicly available layers and then shared only with trusted parties. The mechanisms for cataloging and sharing layers of the Map are beyond the scope of this document.

The specification defines the least possible structure needed for layers to interoperate: a shared coordinate system, a common identity scheme, a basic feature structure, and three composition primitives. Everything else — schemas, governance, incentives, rendering, storage — is left to the community. The protocol is a foundation, not a framework.

The Map exists to serve people in the physical world. Every design decision should be evaluated against the question: does this help people coordinate, navigate, create, work, or play in the places where they actually live?

The layer is the fundamental unit of the Map. A layer is a collection of geospatial features — points, lines, and polygons — anchored to coordinates in the real world, along with metadata describing those features.

Layers may represent virtually anything spatial: physical infrastructure traced from satellite imagery, businesses and their operating hours, hiking trails recorded by GPS, public art installations, fictional game objects, sensor data, community resources, historical annotations, or personal notes visible only to their creator.

A layer may be public or private. It may be open to all contributors or restricted to approved members. It may be a public good or a proprietary product. It may reflect the real world with documentary precision or overlay it with art, narrative, and imagination. It may be two-dimensional or three-dimensional. It may be built by humans, by games, or by machines.

The technical specification for layers — including identity, feature structure, metadata requirements, and composition modes — is defined in MapDapps Layer Composability Model

Layers compose in three fundamental ways:

Overlay is the default. Two or more layers are rendered together in a shared view by a client application. No coordination between layer creators is needed. If two layers share a coordinate reference system, they can be overlaid. This is what makes a collection of independent datasets into a Map.

Reference creates semantic links between layers. A feature on one layer can point to a feature on another layer — a review referencing a restaurant, a historical annotation referencing a building, a game object referencing a landmark. References are one-directional and permissionless, like hyperlinks on the web.

Fork allows any layer to be snapshotted and used as the starting point for a new, independent layer. The fork retains a provenance link to its source but has its own identity and governance. Forking is how the Map evolves: it enables competing editorial standards, governance experiments, and community succession when a layer's original maintainers move on.

These three primitives — overlay, reference, fork — are sufficient to support an enormous range of applications. More complex operations like live synchronization, automated merging, and federated querying can be built on top of them at the application level.

How might these layers compose in practice? Let's say I am a mapper in some future world where MapDapps have been built. I commute around my city by walking, biking, rideshare services, and public transit. I review the content of my city's public municipal layer that contains the locations of roads, buildings, and geographic features. The municipal layer is owned and governed by some sort of local council (or DAO?) that ensures the layer's accuracy. Mappers like me go out into the field, identify discrepancies, and are compensated in some way if my inputs are deemed valuable. I have a blank working layer that I make additions to, referencing the municipal layer until I am ready to submit a PR. For safety, I enable location sharing with a private layer that I maintain with my friends and family so they can subscribe to track my progress. I notice another friend is mapping the city and we make plans to meet for lunch. To enrich my experience, I enable a gaming layer that references the municipal map for structure and adds objectives to collect game tokens along the way. Finally, an agent of some sort organizes all of my objectives into a course it charts through the city, balancing work and fun in a practical way.

The hardest question in this project is not technical. It is motivational. How do you get millions of people to contribute spatial data to an open protocol?

Historically, there have been two models: corporate data collection (hire people or harvest user data) and volunteer cartography (ask people to contribute out of civic-mindedness). The first model produces the maps we have today — comprehensive but proprietary. The second model produced OpenStreetMap — impressive but perpetually under-resourced and struggling for engagement.

MapDapps proposes a third model: gaming abstraction.

The most successful crowdsourced mapping project in history was never marketed as a mapping project. It was Pokémon GO.

Niantic's games — first Ingress, then Pokémon GO — demonstrated that millions of people will eagerly perform cartographic labor if that labor is wrapped in gameplay. Ingress players tagged real-world landmarks as in-game portals not because they cared about geospatial data, but because capturing portals was fun. Those crowdsourced landmarks became the foundation for Pokémon GO's global gameplay. The result is a spatial dataset of extraordinary depth — over ten million scanned locations, a million new scans per week, all captured from a pedestrian perspective that street-view cars can't reach.

The insight is profound: the best mapping applications are the ones where users don't know they're mapping. The labor of contributing spatial data should be invisible, abstracted behind gameplay, exploration, and social interaction.

The problem with the Niantic model is ownership. Every scan, every tagged landmark, every GPS trace belongs to a private company. The players who generated the data have no governance rights over it.

The MapDapps idea applies the same insight within a decentralized framework. Games built on the protocol contribute spatial data to open layers rather than corporate databases. And because many players independently traverse the same areas, their overlapping data provides statistical validation that reduces (though does not eliminate) the need for formal proof-of-location protocols.

Different games can contribute to different layers, each with their own mechanics:

Exploration games generate quests that direct players toward under-mapped areas, passively collecting GPS traces and inviting players to tag features they encounter.

Verification games present existing map features and ask players to confirm or update them — is this business still open? Is this trail passable? — turning quality assurance into a competitive or collaborative activity.

AR overlay games anchor virtual objects to real-world coordinates, generating spatial scans and location data as a byproduct of interaction.

Creative mapping games invite players to add cultural, artistic, or narrative features to the Map — stories, art, memories — building the expressive layers that make the Map worth exploring beyond pure utility.

Games and mappers will generate tons of data. Forms of governance will arise to manage it all.

The protocol does not prescribe how layers are governed, but I believe there is a need for decentralized map maintenance in the form of a network of localized DAOs — digital organizations formed around geographic areas whose members have a stake in the accuracy and richness of their local map.

A local DAO might fund game development for its area, establish editorial standards for its layers, compensate contributors through its own governance mechanisms, coordinate with neighboring DAOs to establish shared conventions, and issue attestations certifying the quality of its spatial data.

This model is bottom-up by design. There is no global governance body for the Map. Standards emerge through voluntary adoption and federation between neighboring DAOs, not through top-down mandate. A DAO in LA and a DAO in Berlin may adopt entirely different governance structures, compensation models, and editorial standards — and that is fine. Their layers compose through the protocol regardless of their internal governance.

The DAO model also provides a natural home for the kinds of real-world spatial coordination that initially inspired this project: location-pinned bounties for freelance work, grants for local public goods, community-driven urban planning, and peer-to-peer labor markets organized around geography rather than platforms.

This protocol still has many problems. I have not solved anything new since I made my initial posts about MapDapps years ago.

How do you verify that a contributor was physically present at the location they claim to have visited? Without a robust answer, any spatial contribution system is vulnerable to GPS spoofing and remote fabrication.

Proof of location is an active area of research. How could we accomplish this? Perhaps zero-knowledge proofs of GPS data, mesh-network handshakes between nearby devices, or cryptographic attestations from trusted hardware? A solution to this problem is not a requirement for the initial protocol, but as the project expands a robust method of proof of location will become necessary.

The gaming abstraction model partially mitigates this problem through statistical redundancy — when thousands of independent players generate overlapping data, anomalies are detectable — but it does not eliminate it. Robust proof of location remains the single most important unsolved primitive for decentralized mapping.

How should contributors be compensated? Per-commit token distribution is broken — it attracts sybils and incentivizes quantity over quality. DAO-managed compensation is more promising but introduces governance overhead.

The protocol deliberately leaves token economics to the application and governance layers. Different communities will experiment with different models. This is an area where the ecosystem needs experimentation, not premature standardization.

A global map with millions of layers and billions of features requires significant storage and query infrastructure. The protocol requires content-addressable hashing for integrity but does not mandate a storage backend. IPFS, Arweave, traditional databases, rollups, and hybrid architectures are all viable — and the right answer may be different for different layers.

I am not a developer. I do not have the skills to build this protocol, and I do not pretend otherwise.

I am a writer and a thinker who believes that the intersection of cryptocurrency and geographic information systems is one of the most underexplored and potentially transformative design spaces in the ecosystem. I am frustrated that we are still so disconnected from the real world. I am frustrated that the metaverse is imagined as an escape from reality rather than an enrichment of it. I am frustrated that the tools for spatial coordination exist but no one has assembled them.

MapDapps is just an idea that I hope can fulfill some of the forgotten promises of crypto and the metaverse by tying digital systems of currency, identity, and reputation to the real world. I welcome critique and suggestions.

• v0.1 — Initial draft. Consolidates thinking from prior articles and introduces the tiered composability model, gaming abstraction thesis, and DAO governance sketch.

Version: 0.1 (Draft)

Author: annemnemosyne

Status: Living document

"I have only two adversaries - I will not say two conquerors, for with perseverance I subdue even them, - they are time and distance." - The Count of Monte Cristo

MapDapps is just a set of ideas that I cannot help but to share. The truth is that I am fearful for the state of the world and our place in it. Between the rise of authoritarianism, digital surveillance, and global unrest, my thoughts turn again and again to the early principles of cryptocurrency: decentralization and permissionless-ness. Exit.

And yet I watch the industry focus on gambling, speculation, and scaling the infrastructure it needs to do more of the same. What is the point in moving bits and money around if we aren't interacting with the real world in any meaningful way? We have more compute and blockspace than we know what to do with. Leaders and influencers keep saying we need to focus on applications: well, here we go.

How can we be free if the corporations that own us are replacing the workforce with automation at an exponential pace? If there are no opportunities for work, what will we do? What if we could create something out of nothing? Or rather, what if we could tap a resource that no one else has considered yet? Unmapped features are potentially valuable, and crowd-sourcing these features is not an easy task to automate or scale. It is work that human beings are uniquely suited to doing, and it is work that will be difficult to automate away entirely. I want human beings to go out into the world, explore it, share resources, and form a separate economy that is intimately linked to the real world.

But as passionately as I feel about this project, my limited skill set in combination with the exigencies of daily life have made it impossible. I need help, so I am leveraging AI to get me started. My hope is that these ideas resonate with people and maybe we can collaborate to build this protocol into something that makes humanity more free. Or maybe some human or AI takes this idea and uses it to create a panopticon. I hope not. Either way, I accomplish my goal by sharing.

This rest of this document was written with Anthropic Opus 4.6 along with my own modifications and additions. I had resisted using LLMs to help me write for a long time. I like having my own writing style and my own quirks and flaws, but I feel a sense of urgency and cannot wait until I feel the inspiration to build this the old-fashioned way. I fed the model all of my writings so far in addition to many of my private notes that I've never posted. I worked with the model to flesh out some of the main concepts and reviewed and edited it carefully to ensure that my intent has been captured and represented well.

In this document, I describe MapDapps, a protocol for building a decentralized digital map of the world through composable, community-governed layers of spatial data. I refer to The Map as the sum of all contributions to the project.

I will not accept any Metaverse smaller than a Map of the entire world that is owned by all of humanity.

Digital maps are infrastructure. Most of us cannot navigate a city, find a business, or commute to work without them. They are as fundamental to daily life as roads and running water — and yet they are almost entirely controlled by a handful of corporations.

This arrangement has consequences. Centralized map providers optimize for profit, not for public goods. They index what serves their business model and neglect what doesn't. They collect vast quantities of location data from their users and monetize it through advertising and licensing. They make editorial decisions — what gets labeled, what gets surfaced, what gets hidden — with no accountability to the communities they depict. And they are fragile: a single company's policy change, acquisition, or shutdown can erase spatial data that communities depend on.

Open-source alternatives like OpenStreetMap have demonstrated that volunteer cartography can produce remarkable results. But they struggle with sustained community engagement, have no native mechanism for compensating contributors, and lack the application ecosystem needed to compete with commercial platforms for everyday users.

The Map that the world needs does not yet exist. It should be open and composable, allowing anyone to contribute and build upon it. It should be governed by the communities it serves, not by shareholders. It should be a foundation for applications that connect people to the real world — for navigation, commerce, culture, labor, play, and coordination of every kind.

Most importantly, it would create opportunities to build entirely new markets driven by mappers, validators, explorers, and players. What if you could quit your job and be paid by the community to explore your city, ensuring the Map is correct? What if you could earn a living hunting geocaches? Do cartography and surveying sound boring? What if the interface was a game that felt like more like Pokemon GO?

The tools to build this Map are emerging from the crypto ecosystem: decentralized identity, content-addressable storage, smart contracts, DAOs, zero-knowledge proofs, and token-based incentive systems. These technologies were designed to solve exactly the kinds of problems that a decentralized map presents — coordination without central authority, trust without intermediaries, and governance without gatekeepers.

And yet the crypto community has largely failed to connect its tools to the physical world. We build financial protocols, governance frameworks, and digital art platforms, but we remain disconnected from the places where people actually live. The Metaverse, as commonly imagined, is a virtual space — a retreat from reality rather than an enhancement of it.

MapDapps is an attempt to bridge that gap. The Map is the metaverse pinned to the real world, and MapDapps are the tools we use to interface with it. Every coordinate on Earth is a potential site for digital activity — for commerce, for art, for governance, for play. This protocol is an attempt to make that vision composable, open, and real.

These principles guide every design decision in the protocol. Where trade-offs arise, they should be resolved in favor of these values.

No single entity owns the Map or defines what it contains. The Map emerges from the composition of independently created, independently governed layers of spatial data. There is no "base map" that everything else depends on. There are only layers — and the protocols that allow them to interoperate.

An individual, a DAO, a corporation, a government, a game, or a machine may create a layer and add features to it. No permission is required. No approval process exists. The barrier to creating a layer should be as low as the barrier to creating a private group chat and setting permissions.

Each layer has its own governance — whether that is an individual's personal discretion, a DAO's consensus process, a company's editorial policy, or an algorithm's automated curation. The protocol does not impose governance. It provides the infrastructure for diverse governance models to coexist.

Any layer may be overlaid with any other layer. Any feature may reference any other feature on any layer. Any layer may be forked. These are protocol-level rights, not privileges granted by an authority. Just as any website can link to any other website, any layer can compose with any other layer.

In practice, layers may have differing scope and availability. Private layers may be forked from publicly available layers and then shared only with trusted parties. The mechanisms for cataloging and sharing layers of the Map are beyond the scope of this document.

The specification defines the least possible structure needed for layers to interoperate: a shared coordinate system, a common identity scheme, a basic feature structure, and three composition primitives. Everything else — schemas, governance, incentives, rendering, storage — is left to the community. The protocol is a foundation, not a framework.

The Map exists to serve people in the physical world. Every design decision should be evaluated against the question: does this help people coordinate, navigate, create, work, or play in the places where they actually live?

The layer is the fundamental unit of the Map. A layer is a collection of geospatial features — points, lines, and polygons — anchored to coordinates in the real world, along with metadata describing those features.

Layers may represent virtually anything spatial: physical infrastructure traced from satellite imagery, businesses and their operating hours, hiking trails recorded by GPS, public art installations, fictional game objects, sensor data, community resources, historical annotations, or personal notes visible only to their creator.

A layer may be public or private. It may be open to all contributors or restricted to approved members. It may be a public good or a proprietary product. It may reflect the real world with documentary precision or overlay it with art, narrative, and imagination. It may be two-dimensional or three-dimensional. It may be built by humans, by games, or by machines.

The technical specification for layers — including identity, feature structure, metadata requirements, and composition modes — is defined in MapDapps Layer Composability Model

Layers compose in three fundamental ways:

Overlay is the default. Two or more layers are rendered together in a shared view by a client application. No coordination between layer creators is needed. If two layers share a coordinate reference system, they can be overlaid. This is what makes a collection of independent datasets into a Map.

Reference creates semantic links between layers. A feature on one layer can point to a feature on another layer — a review referencing a restaurant, a historical annotation referencing a building, a game object referencing a landmark. References are one-directional and permissionless, like hyperlinks on the web.

Fork allows any layer to be snapshotted and used as the starting point for a new, independent layer. The fork retains a provenance link to its source but has its own identity and governance. Forking is how the Map evolves: it enables competing editorial standards, governance experiments, and community succession when a layer's original maintainers move on.

These three primitives — overlay, reference, fork — are sufficient to support an enormous range of applications. More complex operations like live synchronization, automated merging, and federated querying can be built on top of them at the application level.

How might these layers compose in practice? Let's say I am a mapper in some future world where MapDapps have been built. I commute around my city by walking, biking, rideshare services, and public transit. I review the content of my city's public municipal layer that contains the locations of roads, buildings, and geographic features. The municipal layer is owned and governed by some sort of local council (or DAO?) that ensures the layer's accuracy. Mappers like me go out into the field, identify discrepancies, and are compensated in some way if my inputs are deemed valuable. I have a blank working layer that I make additions to, referencing the municipal layer until I am ready to submit a PR. For safety, I enable location sharing with a private layer that I maintain with my friends and family so they can subscribe to track my progress. I notice another friend is mapping the city and we make plans to meet for lunch. To enrich my experience, I enable a gaming layer that references the municipal map for structure and adds objectives to collect game tokens along the way. Finally, an agent of some sort organizes all of my objectives into a course it charts through the city, balancing work and fun in a practical way.

The hardest question in this project is not technical. It is motivational. How do you get millions of people to contribute spatial data to an open protocol?

Historically, there have been two models: corporate data collection (hire people or harvest user data) and volunteer cartography (ask people to contribute out of civic-mindedness). The first model produces the maps we have today — comprehensive but proprietary. The second model produced OpenStreetMap — impressive but perpetually under-resourced and struggling for engagement.

MapDapps proposes a third model: gaming abstraction.

The most successful crowdsourced mapping project in history was never marketed as a mapping project. It was Pokémon GO.

Niantic's games — first Ingress, then Pokémon GO — demonstrated that millions of people will eagerly perform cartographic labor if that labor is wrapped in gameplay. Ingress players tagged real-world landmarks as in-game portals not because they cared about geospatial data, but because capturing portals was fun. Those crowdsourced landmarks became the foundation for Pokémon GO's global gameplay. The result is a spatial dataset of extraordinary depth — over ten million scanned locations, a million new scans per week, all captured from a pedestrian perspective that street-view cars can't reach.

The insight is profound: the best mapping applications are the ones where users don't know they're mapping. The labor of contributing spatial data should be invisible, abstracted behind gameplay, exploration, and social interaction.

The problem with the Niantic model is ownership. Every scan, every tagged landmark, every GPS trace belongs to a private company. The players who generated the data have no governance rights over it.

The MapDapps idea applies the same insight within a decentralized framework. Games built on the protocol contribute spatial data to open layers rather than corporate databases. And because many players independently traverse the same areas, their overlapping data provides statistical validation that reduces (though does not eliminate) the need for formal proof-of-location protocols.

Different games can contribute to different layers, each with their own mechanics:

Exploration games generate quests that direct players toward under-mapped areas, passively collecting GPS traces and inviting players to tag features they encounter.

Verification games present existing map features and ask players to confirm or update them — is this business still open? Is this trail passable? — turning quality assurance into a competitive or collaborative activity.

AR overlay games anchor virtual objects to real-world coordinates, generating spatial scans and location data as a byproduct of interaction.

Creative mapping games invite players to add cultural, artistic, or narrative features to the Map — stories, art, memories — building the expressive layers that make the Map worth exploring beyond pure utility.

Games and mappers will generate tons of data. Forms of governance will arise to manage it all.

The protocol does not prescribe how layers are governed, but I believe there is a need for decentralized map maintenance in the form of a network of localized DAOs — digital organizations formed around geographic areas whose members have a stake in the accuracy and richness of their local map.

A local DAO might fund game development for its area, establish editorial standards for its layers, compensate contributors through its own governance mechanisms, coordinate with neighboring DAOs to establish shared conventions, and issue attestations certifying the quality of its spatial data.

This model is bottom-up by design. There is no global governance body for the Map. Standards emerge through voluntary adoption and federation between neighboring DAOs, not through top-down mandate. A DAO in LA and a DAO in Berlin may adopt entirely different governance structures, compensation models, and editorial standards — and that is fine. Their layers compose through the protocol regardless of their internal governance.

The DAO model also provides a natural home for the kinds of real-world spatial coordination that initially inspired this project: location-pinned bounties for freelance work, grants for local public goods, community-driven urban planning, and peer-to-peer labor markets organized around geography rather than platforms.

This protocol still has many problems. I have not solved anything new since I made my initial posts about MapDapps years ago.

How do you verify that a contributor was physically present at the location they claim to have visited? Without a robust answer, any spatial contribution system is vulnerable to GPS spoofing and remote fabrication.

Proof of location is an active area of research. How could we accomplish this? Perhaps zero-knowledge proofs of GPS data, mesh-network handshakes between nearby devices, or cryptographic attestations from trusted hardware? A solution to this problem is not a requirement for the initial protocol, but as the project expands a robust method of proof of location will become necessary.

The gaming abstraction model partially mitigates this problem through statistical redundancy — when thousands of independent players generate overlapping data, anomalies are detectable — but it does not eliminate it. Robust proof of location remains the single most important unsolved primitive for decentralized mapping.

How should contributors be compensated? Per-commit token distribution is broken — it attracts sybils and incentivizes quantity over quality. DAO-managed compensation is more promising but introduces governance overhead.

The protocol deliberately leaves token economics to the application and governance layers. Different communities will experiment with different models. This is an area where the ecosystem needs experimentation, not premature standardization.

A global map with millions of layers and billions of features requires significant storage and query infrastructure. The protocol requires content-addressable hashing for integrity but does not mandate a storage backend. IPFS, Arweave, traditional databases, rollups, and hybrid architectures are all viable — and the right answer may be different for different layers.

I am not a developer. I do not have the skills to build this protocol, and I do not pretend otherwise.

I am a writer and a thinker who believes that the intersection of cryptocurrency and geographic information systems is one of the most underexplored and potentially transformative design spaces in the ecosystem. I am frustrated that we are still so disconnected from the real world. I am frustrated that the metaverse is imagined as an escape from reality rather than an enrichment of it. I am frustrated that the tools for spatial coordination exist but no one has assembled them.

MapDapps is just an idea that I hope can fulfill some of the forgotten promises of crypto and the metaverse by tying digital systems of currency, identity, and reputation to the real world. I welcome critique and suggestions.

• v0.1 — Initial draft. Consolidates thinking from prior articles and introduces the tiered composability model, gaming abstraction thesis, and DAO governance sketch.