The Orion Constellation · Our Mission
The good nights
never happened
on your phone.
We're building the opposite of doomscrolling.
Most apps want your hours. The longer you stay, the more they make, so everything about them is tuned to keep you sitting there, thumb moving, going nowhere.
Explorers is built to lose you — to a rooftop, a trailhead, a friend's show across town. The feed isn't where you're meant to end up. It's just the nudge that gets you out the door.
Nothing you do here is rewarded by scrolling. You earn awards by turning up in person. Go to a show, a run, a dinner with people you barely know yet, and it lands on your profile as a badge. Over a year, your page stops being a highlight reel and starts being a record of what you actually did.
You earn it by showing up
Go to an event and the award is yours. Skip it and it isn't. The whole game rewards one thing: being there.
Your profile does the talking
Your five best awards sit in a banner at the top of your page. It's the first read anyone gets on the kind of life you keep.
Anyone can host
Spot a free Thursday? Post a pickup game, a gallery walk, a 6am run. If people come, you both got a night out of it.
Made for your people
The feed is the friends you follow, out doing things nearby. Less performing for strangers, more "you around this weekend?"
The Cassiopeia Constellation · Documentation
The idea, and
the proof.
Two papers, written to be read together. They live right here.
Also public: the application and the chain that runs the live name registry, at github.com/exp-eriencepoints.
Explorers · A Bluepaper
The Social Platform for a Decentralized Internet of People
Wyatt Marcous · July 2026
Explorers is pre-launch. Both codebases, the application and the chain, are public at github.com/exp-eriencepoints, and the project lives at explorers.box. This paper presents the idea: what Explorers is, why it should exist, and where it leads. Its technical companion, the Explorers Whitepaper, specifies how each claim made here is or will be built. When this paper defers a question of mechanics, the whitepaper is where it was deferred to.
1. The Problem
Today, the most valuable record of a person, which includes who they are, who they know, and what they do, is owned by everyone except that person.
A small number of companies control digital identity through centralized login systems, and they derive much of their power from that control. An individual's social graph belongs to the platform that hosts it. Their feed is arranged by an algorithm they cannot inspect, tuned toward an objective that is not theirs: more time on the application, because attention is the product being sold. The individual holds no durable ownership and no portability. Leaving a platform means abandoning friends, history, and reputation, which is precisely why almost nobody leaves.
The consequences have stopped being abstract. A generation raised inside engagement-optimized feeds reports historic loneliness while spending historic amounts of time "connected." And as AI floods the internet with synthetic content, the two scarcest things online are becoming a verified human being and that human's undivided attention. The current architecture of the internet can protect neither, because the current architecture is the cause.
2. The Vision
Explorers rests on one ethical premise: data should be sovereign to the user. Not as a political stance, but as a property right. A person should hold their own identity, their own social graph, and their own record of life, and choose what to reveal, to whom, and for how long.
On that foundation stands a second conviction, the one people feel first: a social platform should be built to return its users to the physical world. The good nights never happened on a phone. The feed is not a destination; it is the prompt that gets a person out the door, to a rooftop, a trailhead, a friend's show across town. On Explorers, nothing is rewarded by scrolling. Reputation is earned one way only: by showing up.
These two convictions need each other. A platform whose business runs on attention cannot afford to send its users away. Only a platform whose users own their data, their algorithm, and their graph can be structurally indifferent to how long they stay, because its business does not depend on their captivity. Sovereignty is not a feature of the offline mission. It is the precondition for it.
3. What Explorers Is
Explorers is a decentralized social media platform that prioritizes offline interaction. That sentence carries three claims, in order of importance.
A decentralized internet of people. The long ambition is a network in which every person is a sovereign node rather than a row in a company's database: identity held by its owner on a personal chain running on their own devices, connections recorded between people rather than about them, and private messages no platform can read because no platform possesses them. Not an application running on someone's internet, but a people-first layer of the internet itself.
A common ground, by design. A fully decentralized web has a known failure mode: it fragments. Sovereign individuals with no shared surfaces drift into isolated islands and echo chambers, and the network's value collapses with its cohesion. Explorers answers this with a deliberate structural choice: a shared coordination layer, the Explorers mainnet, holding exactly what must be common for the network to function: the registry of names, the shared ledger of Explorer Credits, and the public surfaces where strangers become acquaintances. Sovereignty lives at the edges; stability lives at the center. The mainnet is the town square of a city of private homes, and it is already real: its first subsystem, the name registry, runs today as a custom module on a working Cosmos SDK chain.
Events as the first expression. The offline priority needs a product, and events are its clearest form. Anyone can host: a pickup game, a gallery walk, a supper club, a ticketed show. Hosting is free, and hosts keep one hundred percent of ticket revenue net of standard card processing, because Explorers itself takes nothing. Discovery runs through a map of what is happening nearby and an algorithm the user owns and can inspect. Attendance is proven, not claimed: a ticket is redeemed once at the door, and the award it mints becomes part of a profile that slowly stops being a highlight reel and starts being a record of a life actually lived. Events are the beachhead, not the boundary. The platform they run on is general.
4. The First Thing You Do
The moment a person joins, having proven once that they are a real and unique human, the network hands them a name: a randomly generated username, registered to them on the mainnet, functional from the first second for everything a name does here.
Then comes the first real act on the platform. A name worth saying out loud is chosen, not assigned: human-friendly names are purchased with Explorer Credits on the Explorers name marketplace, and that marketplace is deliberately the first page every new user opens. Before seeing a single post, the new arrival has browsed a live network application, made a decision about who they want to be, and completed a real transaction that worked. Onboarding is not a slideshow about the system. It is the system, and choosing your own name is its first proof.
This design also settles an old problem of naming systems quietly and economically: throwaway names are free and infinite, names worth wanting carry a price, and hoarding them stops being free.
5. Identity, in Plain Language
Everything above depends on one capability: proving things about yourself without surrendering yourself. This is what decentralized identity (DID) provides.
A user's wallet becomes their account. It holds cryptographic keys instead of passwords, and credentials instead of exposed data. With it, a person can prove they are a real and unique human, prove they are over an age threshold, or prove a friendship is mutual, all without handing the underlying information to another user, a host, or a corporation. Authentication shifts from "trust a company to vouch for you" to "prove it yourself, and reveal nothing further."
Three everyday consequences follow. Explorers is a human-only network: one person, one account, enforced by credentials that cannot be duplicated or sold, on an internet where verified personhood is becoming the scarcest resource. A host running an age-restricted event never sees a birthdate; the proof arrives, the data stays home. And a friendship recorded between two people's own chains is one no platform can hold hostage, because no platform owns it.
The principle generalizes far beyond social life, and Section 9 returns to it. Concentrating identity and data in a few unaccountable hands is dangerous no matter whose hands they are. DID redistributes that power to the people the data describes.
6. How It Holds Together
This paper makes three promises, and each rests on one mechanism. The full specification of every mechanism, including exactly what runs today, lives in the whitepaper; what follows is the shape of the machine.
You own your identity and your record because they live with you: a personal chain validated by your own devices, indexing content you store on the network, under a single key that signs everything you do everywhere. Your page at your name is a live rendering of that chain, and it rests when your devices do, which a platform about offline life states without apology. (Whitepaper, Sections 2, 4, and 6.)
You can prove without revealing because identity is carried in non-transferable credentials, kept strictly separate from money. Conflating the two is where designs like this usually collapse; the separation of credentials, addressing, and value exists precisely to prevent it. (Whitepaper, Section 4.)
Value moves person to person because Explorer Credits live on the shared ledger everyone can trust, payments are approved only inside the payer's own wallet, and a name doubles as a payment handle. Keys sign; they are never typed, anywhere, by anyone. (Whitepaper, Section 5.)
Explorers is built on the Cosmos stack because Cosmos is the one architecture shaped like the thesis: many sovereign chains, connected. What Cosmos offers institutions, your own chain, your own rules, connected to everyone, Explorers extends to people.
7. Why Now
Three curves are crossing. AI-generated content is flooding every feed, making proof of personhood the rarest commodity online. The hunger for real-world connection is visibly outgrowing its tools: run clubs, supper clubs, and hobby meetups are the fastest-growing social behaviors in America, organized today over group chats and email threads that have not improved in fifteen years. And expectations about who owns personal data are hardening into law across jurisdictions. Explorers sits at the intersection: verified humans, gathered in person, on rails they own.
8. The Business
A public-good mission still requires revenue, and Explorers' model is chosen to keep its incentives aligned with its users' lives. Four streams. Names: the marketplace where every user chooses who they are, live from day one of the vanity market. Persistence: browsing and attending are free forever, and posting is free on your own devices at your own uptime; what the paid storage tier sells is availability, your content pinned and served while you are away from your machines. Placement: hosts pay for promoted visibility on the event map, which doubles as the mechanism that keeps the map uncluttered; discovery through a user's own feed is never paywalled. Registration: organizations joining formally, described in Section 9.
The pattern across all four is the point: Explorers earns when someone wants more reach or more room, never by taxing identity, friendship, or attendance. The platform profits from the network's growth, not from its users' captivity, and the sovereignty architecture is what makes that promise structural rather than rhetorical.
9. Where This Goes
The rails described in this paper are more general than the first product built on them. What follows are horizons, not commitments: each is given engineering treatment in the whitepaper, and none is promised here.
Organizations, where their people already are. Businesses and large communities registering formally on the mainnet with business-level verification, receiving their own chains with role-based access for their teams: workspace, communication, and community in the place their members already live, and the natural home of event hosting at commercial scale. (Whitepaper, Section 8.1.)
Earnings that graduate. Explorer Credits are deliberately a closed loop for individuals: bought at a fixed price, spendable, never cashable, a design chosen for trust and legal clarity. The future feature that completes the picture is redemption for verified organizations only: businesses that have passed formal verification converting Credit earnings to dollars, with all compliance concentrated at that single boundary. (Whitepaper, Section 8.2.)
Reputation you build, not inherit. Explorers began as an attempt to lend to students who had no credit history, and it ran into the wall every young borrower knows: the system cannot see you until you are already visible. A credential that proves months of demonstrated financial discipline, without exposing a single transaction, could one day give a person a portable, private, earned financial reputation. A possibility, not a product, and one that would supplement conventional underwriting rather than replace it. (Whitepaper, Section 8.3.)
Communities that lend within themselves. Verified communities pooling resources for member-to-member lending, informed by that same earned reputation. Listed last because it inherits every regulatory question lending carries, and it will remain a research direction until those questions have serious answers. (Whitepaper, Section 8.4.)
The near-term mission is deliberately narrower than the horizon: build the first social platform with nothing to gain from your captivity, prove it in one city's worth of rooftops and trailheads at a time, and let the rails earn the right to carry more.
Get out there.
Explorers · explorers.box · wyatt@explorers.box · github.com/exp-eriencepoints
Explorers · Whitepaper v1
Architecture, Implementation, and Feasibility
Wyatt Marcous · July 2026
This document is the technical companion to the Explorers Bluepaper. The bluepaper presents the idea: a decentralized social media platform that prioritizes offline interaction, conceived as the beginning of a decentralized internet of people. This paper's job is narrower and harder: to specify the system, inventory what already runs, and give engineering treatment to everything the bluepaper describes, including its horizons. Every element carries one of three labels: implemented (running today, code public), designed (specified, not yet built), or possibility (a direction the rails could support, explicitly not a commitment).
Executive Summary
Explorers is a decentralized social media platform that prioritizes offline interaction. By design, every person on the network is a sovereign node: identity, connections, and history live with their owner rather than in a company's database, and the platform's every incentive points toward the same door, the one that leads outside. The long ambition is larger than a social application: a decentralized internet of people, held together by one shared coordination layer, the Explorers mainnet, so that a world of sovereign individuals does not fragment into islands.
That idea is presented across two companion documents with a deliberate division of labor. The Explorers Bluepaper makes the case: the problem with the current social internet, the sovereignty thesis, the product as a person experiences it, and the horizons beyond it, written for a reader who has never held a wallet. This whitepaper carries the burden of proof: it specifies the system, inventories what already runs, and gives engineering treatment to everything the bluepaper describes, including its dreams. The two documents cross-reference at every seam; each defers to the other for what the other does best.
The discipline of this document is disclosure. Every element carries one of three labels: implemented, running today with public code; designed, specified but not yet built; or possibility, a direction the rails could support and explicitly not a commitment. Its limitations section names the problems that remain unsolved, because a feasibility document that omits its own weaknesses is marketing.
What is implemented today: a working application client demonstrating the complete product loop, public and runnable from github.com/exp-eriencepoints, and a sovereign Cosmos SDK blockchain whose first custom module runs the .explorers name registry under rules enforced on-chain from genesis. The chain is a local devnet, not a public network, and is never represented otherwise. Both codebases are public at github.com/exp-eriencepoints.
What is designed: the full target architecture. The mainnet holds what must be common, which is names, the ledger of Explorer Credits, organization records, and the public map. Personal chains hold what is sovereign, which is credentials, each user's content directory, and the instruments they issue. Credits are a closed loop at a fixed peg, earning nothing for engagement by design, and a new user's first act on the network will be choosing their own name on a live on-chain marketplace, so that onboarding itself proves the system works.
Sections 1 and 2 frame the system; Section 3 inventories what exists. Sections 4 through 6 specify the target architecture across identity, money, and the personal chain. Section 7 states plainly what governance is not yet decided. Section 8 engineers the horizons, and Section 9 names the open problems.
1. Purpose and Scope
The bluepaper answers why Explorers should exist. This paper answers whether it can be built, by this team, on this stack, and the answer offered is not an argument but an inventory. Version 1 exists in two public repositories: a working application client and a sovereign Cosmos SDK blockchain whose first custom module implements the platform's name registry.
- Application: github.com/exp-eriencepoints/explorers-app
- Chain: github.com/exp-eriencepoints/explorers-chain
- Project site: explorers.box
2. System Overview
The architecture is easiest to hold as a picture. The Explorers mainnet runs horizontally: one shared chain carrying what the whole network must agree on. Each user's personal chain runs perpendicular to it, crossing the mainnet at the user's address: a private street meeting a public avenue at its own corner. The content layer (IPFS) sits beneath both, storing what chains should not. This is the target geometry; Section 3 states what portion of it runs today.
The mainnet is a deliberate centralizing element inside a decentralized system. A network of fully sovereign nodes with no common surfaces fragments into islands; naming, discoverability, and shared context fail together (Bluepaper, Section 3). The mainnet therefore holds exactly the state that must be common: the name registry, the canonical ledger of Explorer Credits, organization records, and the public event map. It was built first, before any personal chain, because everything else leans on it. The build order is the architecture argument.
Personal chains hold what is sovereign: identity credentials, the user's content directory, and the instruments the user issues. They are validated by the user's own devices, with delegation and availability treated in Section 6.
The content layer stores media. A personal chain functions as a directory: it records that content exists, who owns it, and where in IPFS it lives, while the bytes themselves are stored and served by the network of user devices.
One consequence of this geometry deserves emphasis because it dissolves an apparent complexity: a user's page (the site a visitor sees at their name) is neither the domain nor the chain. It is a rendering, produced fresh on each visit: resolve the name on the mainnet, follow the pointer to the personal chain, read the directory, fetch from IPFS, display. Deleting every copy of a page loses nothing, because the page is regenerated from its sources.
3. Implemented Today
3.1 The application client
A Next.js application (React 19, TypeScript) implementing the complete v1 product loop: onboarding with simulated identity verification, home-city selection from eight launch cities, and interest selection; a real map (Leaflet, OpenStreetMap-derived tiles) spawned on the home city, with all cities' events on one shared world map; the full event lifecycle (host from the map, pay in Credits wallet to wallet, single-use QR redemption at the door, commemorative award minted to the profile); a wallet view expressing the token design in plain language; and a masonry content view of event clips.
The client's wallet, Credits, tickets, and awards are simulated: held in application state, shaped one-to-one like the chain objects specified in Sections 4 through 6, and labeled as simulated in the interface. This is a migration strategy rather than a shortcut: when a chain primitive replaces a simulated object, the product above it does not change. The workflow is verified by an automated end-to-end test covering onboarding, hosting, sale, purchase, single redemption, rejection of double redemption, award minting, and persistence across restart.
3.2 The Explorers chain
A sovereign Cosmos SDK blockchain, scaffolded with Ignite CLI, running as a one-validator local devnet. Stack: Cosmos SDK v0.53.6, Ignite CLI v29.10.1, Go 1.26.5, versions pinned in the repository. Native token: Explorer Credits, denom uexpl, minted at genesis. Deployment status: local devnet, running on the founder's machine and on any machine that clones the repository. It is not a public network, and no Explorers material claims otherwise.
3.3 The x/domains module
The name registry (Bluepaper, Sections 3 and 4), implemented as the chain's first custom module.
Messages. MsgRegisterDomain(name, displayName). Registration is free and hard-limited to one domain per address, enforced in the module's state machine rather than in any client.
Validation. Names must match ^[a-z0-9]{3,32}$: lowercase letters and digits, three to thirty-two characters, no dots. The .explorers suffix is implicit everywhere and never stored.
Queries. ResolveDomain(name) returns owner address, display name, and registration height. ListDomains returns the registry with pagination.
Rejection paths, each unit-tested: name already registered; registering address already owns a domain; name fails validation.
Genesis. The chain launches with wyatt.explorers and explorers.explorers pre-registered to two distinct accounts, plus a funded third account owning no domain, reserved for live demonstration. The one-domain-per-address rule has held from block zero: the chain has never contained a state its own rules forbid.
3.4 Serving the registry
The chain exposes the standard Cosmos REST API on localhost with CORS configured for the client. The application's Domains panel reads the live registry through this endpoint, listing names and resolving lookups. The v1 integration is deliberately read-only; registrations are submitted through the chain CLI, demonstrating the full loop (a name registered in the terminal appears in the running application within seconds). The panel degrades gracefully when the chain is offline.
3.5 Verification and reproducibility
Module rules are unit-tested; the product loop is covered by the end-to-end walkthrough; both repositories carry full commit history; the chain repository includes plain-language instructions sufficient for a non-technical reader to start the chain, register a domain, and watch it appear in the application. Reproducibility is the point: "this works" is checkable by anyone with a laptop.
4. Identity
Identity is the system's foundation, and this section consolidates its four elements: the key, the credentials, the verification that issues them, and the names people are known by. The registry element is implemented; the remainder is designed.
4.1 One key, one wallet, many ledgers
A wallet is not a place where assets sit; it is a keypair, presented through an interface. The same key that authors and validates the blocks of a user's personal chain also controls their account on the mainnet, because the mainnet address is derived from that key. The wallet the user sees is the window onto everything the key controls: Credits from the shared ledger, credentials and content from the personal chain, side by side as one coherent thing. The two-ledger architecture never becomes a two-wallet experience.
4.2 Credentials and address tokens
Two non-monetary instruments live on the personal chain, and they can live there sovereignly because neither carries double-spend risk: they are shown, not spent, and their trustworthiness comes from their issuer's signature, which no amount of tampering with one's own chain can forge.
Identity credentials are non-transferable proofs of fact: verified personhood, age threshold, verified connection. Each is presentable and checkable without disclosing the underlying data, and can never be sold or transferred, which is what makes one-person-one-account enforceable network-wide.
Address tokens are the private routing layer: each wallet's outward-facing, phone-number-like token by which a counterparty's chain locates it to open an encrypted channel or deliver an asset. Public discovery belongs to the domain registry; private reachability belongs to the address token; the two are deliberately distinct.
4.3 Verification (designed)
Verification of personhood is not performed by Explorers, by design. The approach uses established third-party identity verification, in which a user's government-issued document (driver's license or passport) is checked against the records of the authority that issued it; in the United States, driver's license data verification runs through AAMVA's network connecting state DMV records, a service offered commercially by providers such as MagTek and ID.me. Explorers never receives, inspects, or stores the document: the issuing government is the party that vouches for it, the provider relays the result, and a designated issuer then signs the on-chain personhood credential the network trusts.
Three residuals remain open and are stated as such. First, issuer custody: the key that signs personhood credentials is a trust anchor, and its custody and rotation must be designed with the same care as the rule it enforces. Second, uniqueness: a valid document proves a real person, not a new person, so one-person-one-account requires remembering, in a privacy-preserving form such as a salted fingerprint of the document identifier, which documents have already onboarded; that retention decision sits in deliberate tension with the platform's data-minimization posture and must be resolved explicitly. Third, coverage and cost: government-directory verification is strongest for United States documents, and each verification carries a per-user cost at a free signup.
4.4 Naming: assigned at birth, chosen at the market
Every new account is automatically granted a randomly generated username at registration, its working .explorers identity from the first moment, free, and fully functional: it resolves to the payment account and the personal chain like any other name. Human-friendly names are purchased with Credits on the Explorers name marketplace, which is itself an .explorers page and deliberately the first one every new user opens: the first act on the network is browsing a live on-chain application and executing a real transaction, which means onboarding itself demonstrates the system works.
The economics double as the abuse control. Random names are free and effectively infinite; desirable names carry a price paid in purchased Credits; hoarding therefore has a cost proportional to its scale, and the squatting problem that plagues free-registration naming systems is answered by the market rather than by policy. The live module's record shape was scoped so the marketplace's additional messages (transfer, listing, purchase, rental) extend it without migration. Pricing structure remains an open design decision.
5. Token Design and Payments
This section consolidates the system's monetary design: what Explorer Credits are, where they live and why, how payments execute, and how the ticket instrument works. The token exists at genesis on the implemented chain; the payment and ticket rails are designed.
5.1 Explorer Credits
Credits are the network's single currency: purchased at a fixed peg, spendable within the network on tickets, storage, placement, and names, and not redeemable for cash or cryptocurrency. This closed loop is a deliberate legal and trust posture: its shape resembles a stored-value balance rather than a currency, the fixed peg removes speculation, and the transparent ledger serves as an audit trail. Nothing monetary is ever earned by posting or engagement, which is the design's answer to the documented failure mode of engagement-rewarded social tokens.
Credits live canonically on the mainnet, and the governing principle deserves statement because it decides the entire monetary architecture: a bearer instrument must be honored by strangers, and strangers cannot trust a ledger whose only validator profits from rewriting it. Single-issuer instruments can live with their issuer; money needs the shared ledger. This is why Credits sit on the coordination layer while credentials sit at the edge.
The one designed exception to the closed loop is business-side redemption, specified in Section 8: organizations that pass business-level verification may convert Credit earnings to dollars, concentrating all money-transmission compliance at a single boundary.
5.2 Payments: request and sign
A name doubles as a payment handle. Anyone viewing a page can compose a payment to its name; the registry resolves the name to a mainnet account; the request is handed to the payer's own wallet, which displays it, signs it locally, and submits the signed transaction. The page never sees a secret; the key never travels; nothing anywhere in the system ever asks a user to type key material, and anything that does is by definition an attack. This is the custodial payment experience users already know, with the custodian replaced by a signature.
5.3 The ticket lifecycle
At launch, ticket payments are card transactions settled directly to hosts through standard processing: hosts keep one hundred percent net of card processing fees, and Explorers takes nothing. The designed rail replaces cards with Credits, wallet to wallet, no intermediary.
The instrument itself lives with its issuer. The event's chain (a host's personal chain, or an organization chain at commercial scale) is the authority on the tickets it issues: the door scan queries that one ledger, redemption is instant, single-use is final. The attendee's protection is structural rather than promissory: the ticket carries the issuer's signature, which the issuer cannot unsign, and the payment sits on the mainnet, which the issuer cannot touch. A dishonest host can still throw a bad party; they cannot claim the attendee never paid. Redemption mints the commemorative award to the attendee's profile.
5.4 Revenue alignment
The platform's four revenue streams (names, persistence, placement, registration; Bluepaper, Section 8) share one property that belongs in the technical record as a design constraint: none taxes the movement of Credits between users, and none monetizes engagement. Explorers earns when a participant wants more reach or more capacity, never as a toll inside the flow, which is what keeps the fee-free ticket claim structural rather than promotional.
6. Personal Chains and Content
Everything in this section is designed. No personal chain runs today; it is specified here so that building one is an engineering task rather than a research question.
6.1 Validation, delegation, availability
A user's devices are the validators of their chain. One device is sufficient; several give the chain redundancy and longer uptime. Alternatively, operation can be delegated to a third-party host, with a distinction the system treats as fundamental: the host runs machinery but never holds keys, so it can neither act as the user nor spend a single Credit. A delegated host can stall or serve stale data; the design's answer is that switching hosts is trivial precisely because authority was never the host's to keep, and a stalling host is in any case no worse than a sleeping phone.
Which points to the availability trade-off the design accepts openly: a self-hosted chain rests when its devices do, and with it the user's page. On a platform whose entire thesis is offline life, a page that sleeps when its owner does is a coherent behavior, stated without apology. Organic IPFS caching (every viewer briefly re-serves what it fetches) keeps popular content alive regardless.
6.2 Content: the chain as directory, availability as the product
Posting writes two things in one gesture: the content into IPFS and a signed directory entry onto the personal chain recording existence, ownership, and location. The default path costs the user nothing, because their own devices pin the content and their own devices write the chain; availability then equals their uptime. What the paid storage tier sells is therefore not space but persistence: content pinned and served by the network while the owner's devices are off. Free means sovereign self-hosting at your own uptime; paid means your page stays awake while you sleep. The incentive calibration for third-party storage contributors, compensated in Credits, remains unmodeled (Section 9).
7. Governance
Stated with the same discipline as everything else in this document: governance is the least developed part of the design, and this section exists to say precisely what is and is not decided.
Today. The devnet is founder-operated by definition: one validator, one operator, rule changes possible only by the person who runs it, checkable by anyone who clones the repository. This is appropriate for a demonstration environment and is not a governance model.
Open, and named as open. Three questions must be answered before any public deployment, and none is answered here. Who can change the mainnet's parameters and modules, and by what process. How validators are admitted and removed as the network decentralizes. And what voice, if any, Credits confer, with the current disposition being none: Credits are deliberately a medium of exchange, and importing token-weighted governance would reintroduce the plutocracy problems documented across this field. The Cosmos SDK ships a standard governance module whose adoption, adaptation, or rejection is the natural starting point for this design work.
The honest position: a network whose thesis is that the platform cannot cheat its users ultimately requires governance that binds the founder as firmly as genesis did, and designing that mechanism is a prerequisite for the public testnet milestone, not an afterthought following it.
8. Horizons, Engineered
The bluepaper's closing section names four horizons. Each receives its mechanism sketch here, because a dream that cannot survive engineering scrutiny does not belong in either document. All four are possibilities, none a committed feature, each facing regulatory and design scrutiny before any build decision.
8.1 Organization chains
An organization registers on the mainnet with formal business documentation, a process closer to a filing than a signup, and receives a dedicated chain. Its administrator issues role-based permission tokens to members: non-transferable instruments granting access to the organization's channels, documents, and functions, revocable by the issuer. The mainnet records the organization's existence; everything internal lives on its own chain. The nearest horizon, and the natural home of event hosting at commercial scale.
8.2 Business-only redemption
Individual Credits remain a closed loop permanently. The designed future feature grants one additional right to organizations that pass business-level verification (KYB) at registration: redeeming Credit earnings for dollars or USDC, with payout riding established merchant infrastructure rather than Explorers holding funds. This concentrates all money-transmission compliance at a single boundary, gives serious operators a concrete reason to register, and resolves the closed-loop tension for commercial hosts without ever opening a cash-out door to anonymous accounts.
8.3 A financial-behavior credential
A user connects financial accounts to an attestation service that observes budget adherence over a defined period; the service issues a non-transferable credential attesting to the outcome, never to the underlying transactions; the credential expires and refreshes monthly, reflecting current behavior. Verification is a standard credential check. Open questions stated plainly: who operates the attestation service and why it should be trusted; how disputes are adjudicated; under which lending regulations such a signal may lawfully be used. A research direction in verifiable-credential finance, supplementary to conventional underwriting, not a product.
8.4 Community pools
A pool as a contract on an organization chain: members deposit Credits; borrowing requires collateral plus a valid behavior credential; the credential's tier adjusts rates within governance-set bounds; repayment and default handling are contract-enforced and member-visible. Coherent precisely because it composes the three prior pieces, and listed last because coherence is not advisability: it inherits every regulatory question lending carries.
9. Known Limitations and Open Problems
A feasibility document that omits its own weaknesses is marketing. The current list:
- Pages sleep with their devices, by choice. The availability trade-off of Section 6.1 is accepted, not solved. Users who want always-on presence buy persistence or run additional devices.
- The payment ledger is public, by choice. Balances and transfers on the mainnet are visible, a deliberate trade of payment privacy for trust, auditability, and regulatory defensibility. On a platform whose thesis is data sovereignty, this is a named inconsistency, and privacy-preserving payment techniques are noted as future work rather than promised.
- Identity verification is designed but not integrated. The approach is settled (Section 4.3): third-party verification against the issuing government authorities, with Explorers never touching the document. What remains open is narrower and named: custody of the credential-issuing key, a privacy-preserving uniqueness check so one person cannot onboard twice, and coverage plus per-verification cost. The client's current verification step is a placeholder until that integration exists.
- Governance is stated, not designed. Section 7 names the open questions; it does not answer them, and public deployment is gated on answering them.
- Key custody and recovery. Sovereign keys mean sovereign loss. Recovery without reintroducing a custodian is an open problem for the entire industry, and Explorers inherits it.
- One validator today. The devnet demonstrates the state machine, not decentralized consensus. A public testnet with independent validators is a distinct, later milestone, and the mainnet's throughput ceiling is likewise acknowledged as the network's payment ceiling, with established Cosmos scaling paths when that day comes.
- Moderation at the edge. A network that cannot read private content must still handle abuse. The designed answer (a public moderator agent for mainnet surfaces, human-only accounts raising the cost of abuse) is partial and labeled as such.
- Storage-contributor incentives are unmodeled. The paid persistence tier (Section 6.2) depends on third-party contributors pinning and serving content for Credits, and the calibration that makes contributing worthwhile without inflating the price of persistence has not been designed.
10. Conclusion
The distance between a concept document and a working system is where most projects of this kind quietly die. Explorers v1 closes a measured part of that distance: a complete product loop in a designed client, and the network's coordination layer live, with the name registry enforcing its rules inside a sovereign Cosmos SDK chain from genesis. The remaining architecture is specified with its trade-offs chosen on purpose: money on the shared ledger and identity at the edge, availability as a product rather than a promise, compliance concentrated at one boundary, governance named as the discipline still owed, and a first user act that proves the system by using it. The horizons are engineered rather than gestured at; the open problems are named. The build continues in public.
Explorers · explorers.box · wyatt@explorers.box · github.com/exp-eriencepoints
The product, in four parts
Home
A wall of what your friends have been up to lately, laid out so you actually want to look. Tap a post to see the event behind it and tell people you're coming.
Map
A satellite view of what's on near you. Type your zip, narrow it to tonight or this weekend, and the events show up as pins you can tap.
Content
Short clips shot at the events themselves. Same swipe-up format you already know, except everything in the frame is something you could go to.
Profile
Your page, topped by a banner of your five best awards. The rest fills in with the events you've been to — proof of the year you actually had.
Life
The Lyra Constellation · The Demo
See it
for yourself.
The v1 loop in miniature, with stand-in content. Have a poke around.
Working Preview
A faithful miniature of
the v1 build.
This pocket version mirrors the real v1 product loop, dressed in placeholder people and posts. The full application, and the chain that runs the live .explorers name registry, are public at github.com/exp-eriencepoints.
- Scroll the Home feed and tap into the events behind posts
- Buy a ticket on the Map: Credits move wallet to wallet, no platform cut
- Open your Wallet: Credits, your ID card, your .explorers name, your tickets
- Scan a ticket at the door. Single use, and the award lands on your Profile
Explorers
Explorer Credits
Spend on tickets, storage, and names. Moves wallet to wallet, nobody takes a cut in between.
🪴 Your ID card Verified human
Proves facts about you, real person, over 18, without handing over the details. One person, one account.
✦ Your name on-chain
wyatt.explorers · the real registry runs today as a custom module on a Cosmos SDK chain. Code public on GitHub.
🎟️ Tickets (0)
Nothing yet. Find something on the map.
Event
Event
The Cygnus Constellation · Contact
Come build
this
with us.
Early user, event host, investor, or just curious — say hi.
Get In Touch
We read everything that comes in.
Want in early? Throwing events worth showing off? Backing the idea, or just wondering what this is? Drop us a line and Wyatt will write back.