Exterior Space Challenge Q&A

Blockchain

Why on-chain? Couldn’t this be done as a Web2 project?

Let’s start with how we understand the blockchain at its core: in a peer-to-peer network, it is a protocol layer that verifiably compresses short-term consensus states into long-term durable records.

In our architecture, users interact and validate one another through a peer network made up of themselves. Every act is user-initiated and user-validated. All we need is a hard drive that belongs to everyone for final archiving—and naturally, that’s what the blockchain provides. Behavior happens within the user network; the chain is its historical record.

Essentially, this is the only way to make the space network universally accessible—to make it part of the internet itself, rather than something trapped inside a private platform. By defining layout as an open, composable format and anchoring it on-chain, spaces become durable, transferable, and verifiable—beyond any server or company.

Is this just for crypto users? Can regular people understand it?

No. We are for anyone who wants to record and share personal experiences through interactive, spatial expression—not just for the crypto community.

Regular users can sign up with one click, use an intuitive interface to build their space, collect mementos, and interact with friends—without needing to understand wallets, private keys, or any blockchain concepts.

Has the decline in NFT market popularity affected your product?

No. Our product has no inherent financial attributes, does not rely on scarcity, and does not encourage speculation. Its usage is fundamentally unrelated to NFT trading markets.

Users don’t need to understand or interact with tokens or wallets. To them, we are a tool for expressing personal spaces and memorabilia—not a platform for NFT transactions. While we do use NFTs and PDAs as an underlying data format and storage, users never need to think about that.

The decline of NFT market speculation has no relevance to us. Just as most users don’t care whether an app runs on MySQL or MongoDB, they don’t care about backend asset formats or shifts in developer-side infrastructure.

Challenge

There are some traditional challenges that one may think of, and we are answering it here

Network Effects Chicken-and-egg problem

The chicken-and-egg problem for network effects works as follows: Social platforms only become valuable for users to join if the network is already established—i.e., their friends are already on the platform.

We don't face this problem because spaces have inherent value even without social connections. Just like your physical home doesn't become worthless when neighbors move away, your digital space provides immediate personal utility. Recording life experiences and having mementos, organizing your sweet home are valuable activities regardless of who visits.

This individual value is immediately apparent: when you complete a meaningful experience (reading a book, visiting a city, achieving a fitness goal), creating a digital memento has personal value whether or not anyone else sees it. Your space becomes a repository of your experiences and a reflection of your identity.

Social features enhance the experience but aren't essential for core utility. Users join for personal expression and stay because the space grows more meaningful over time as they add memories and refine their environment. Network effects then emerge naturally as users want to share their meaningful spaces and discover others' stories.

Creative Barrier for Users

One common concern is that users may think they're not creative enough for space building.

This might be true if users were building a museum or art installation, but that's not what we're asking. Instead, users are simply organizing their home—something they already do in their daily lives. There's no special creativity required to make a space yours; it's just a matter of personal taste and preference.

Everyone arranges their physical bedroom, organizes their desk, or decorates their living space. We work the same way. We use a grid-based system for placing items by default, making space organization as simple and intuitive as moving furniture in real life.

For users who need a bit of extra help getting started with their room, beyond the welcome quest that introduces the basics, we also provide a layout template. Instead of a ready-made model room where only decorations or materials can be changed, the layout template works like a brainstorming sheet waiting to be filled. It invites and guides users to place their own memorabilia and furniture, helping them shape their own stories and spaces.

For more advanced users who want greater creative control, they can design their own artifacts or use free-form layout mode (a future feature). But the core experience requires no more creativity than organizing your physical room.

Scaling of P2P Network

One common concern is the scaling of P2P networks, as caching and coordination algorithms typically become more expensive with scale.

Our P2P network design actually gets cheaper and more reliable as it scales. Unlike traditional platforms that need more servers as users grow, our nodes are the users themselves. The most stable nodes are desktop wallpaper users who naturally stay online and therefore maintain network health.

More users means more nodes, which means the P2P network becomes more stable and resilient. In the beginning, we may need to operate more long-term nodes ourselves since we won't have enough users yet. But as the user base grows, we can reduce our infrastructure investment because the community provides the network backbone.

This creates a virtuous cycle: user growth directly improves network reliability while reducing our operational costs. It's the opposite of traditional platform economics where scaling requires exponentially more infrastructure investment.

Content Moderation

One common question about decentralized content is how to moderate it, since you cannot remove anything from user-owned spaces.

We approach this like HTML doesn't worry about what websites people create. Any content is allowed and we have no control over what users put in their own spaces—this is fundamental to true user ownership.

However, we can help users discover only the content they want to see. We have a two-layer content filtering system:

1. User self-labeling: Users can mark their spaces with content warnings, indicating what types of sensitive content are present
2. Community flagging: Other users can flag sensitive content when they visit, and each user can set their own threshold for how many flags trigger a content warning

When visiting a space marked as sensitive, the client shows a warning before entry, or blocks access entirely for logged-in underage users.

The key insight is separating the network from sensitive content discovery. Adult users can opt into a separate discovery network specifically for sensitive content, making it easier to find what they're looking for. This actually incentivizes users to properly label their content, since accurate labeling improves discoverability for their intended audience.

We also provide a separate application for parents to monitor their children's on-chain activity through blockchain event monitoring, giving families the tools they need while preserving user ownership.

Spam Prevention

We use three complementary methods to prevent spam and maintain content quality.

Network Architecture Isolation

Our most powerful anti-spam mechanism is built into the architecture itself. Content discovery happens through space and artifact networks, where connections are based on similarity or relevance, and generated locally on clients. Users can regenerate these links (with time limits), meaning active users will naturally remove connections to spam content.

Crucially, these links are unidirectional—each artifact or space can only establish outgoing links to others, not incoming ones. This means spam content cannot actively inject itself into the network since it can only be discovered if legitimate users choose to link to it. This architectural design makes spam content highly ineffective in our network, as it becomes naturally isolated from the discovery mechanisms that drive engagement.

Owner Control & Community Flagging

When spam messages are left in a user's space, the space owner has full authority to remove any content and maintain a blacklist. When users flag spam content sources, this information is saved publicly on the blockchain, allowing each client to fetch flagged user (and how many flags each user has received) lists and apply filters to their own spaces.

Users can also change their permissions so that messages can only be left by friends, but everyone can still visit and leave gifts like petals.

Time-based Rate Limiting

Any user content post have a time limit (1 minute for example), which is verified by the P2P network. There's no way someone can have intense life experiences happening 1000 times per second. This method primarily saves blockchain storage costs while naturally preventing automated spam.

Technical Difficulty

At first glance, the system may seem complex. However, it's actually straightforward because we're not building a financial network that handles sensitive transactions. Instead, we have a single source of truth for each space: the owner. As long as modifications follow pre-defined logic—which can be verified locally by any node—every node will record it and batch upload to the blockchain.

This fundamental design choice eliminates most distributed systems complexity. There's no Byzantine Generals problem, no complex consensus mechanisms, no complex coordination, and no state conflicts between competing parties. Each space owner controls their own domain, and other nodes simply verify that changes follow the rules. By making users the owners of their spaces rather than tenants of a platform, we eliminate entire categories of problems that other projects struggle to solve. The result is a system that's both more technically feasible and more aligned with user interests.

P2P Network Is Not That Hard

Our P2P network doesn't require consensus among all nodes because this isn't a financial network—it's a personal expression network. The space owner is the single source of truth for what changes in their space and its history. Other nodes simply verify that changes are reasonable.

When batch-writing to the blockchain, we only need small-group (which are typically long-term nodes and desktop wallpaper user node) consensus using PBFT. If anything goes wrong, the next update can still correct any differences. For any conflicts (two valid branches), the space owner decides which should be the "true" history.

Financial actions (buying furniture, forging artifact, updating artifact styles) are infrequent and interact directly with the blockchain using existing, proven solutions.

For live visits, WebRTC connections work simply: every visitor connects to the host's node, and the host remains the single source of truth for what happens in their space. This ensures live visits scale well and public spaces work even with many simultaneous visitors.

In summary, the P2P network only needs to:

• Gossip to propagate information
• Perform simple local verification
• Batch upload using PBFT in small groups (with long-term/desktop nodes as writers)
• Help establish WebRTC connections for live visits
• In the future: cache content and relay blockchain transactions

The complexity comes from coordination, not computation—and we've eliminated most coordination requirements through our single-owner architecture.

Cross-chain Is Not Actually Complex

We're not launching with cross-chain features, but our architecture is already chain-neutral by design. Users from different blockchains can interact normally through the P2P network, which simply batches updates to different chains when needed.

The P2P layer abstracts away blockchain differences—users see a unified experience regardless of which chain stores their data. When we add cross-chain support, we only need to:

• Add different upload methods in the P2P network for each blockchain
• Support chain-specific interactions in clients for infrequent financial actions (buying furniture, forging artifacts, updating artifact styles)
• Deploy furniture and monument/quests on multiple chains as we launch them

All of these are straightforward implementations with existing solutions.

If users want to put their Ethereum assets in the Solana space, they have to transform the assets, since our design follows the principle of one wallet = one space. This can be done by wrapping or bridging the assets to the target chain, which is a standard bridge technology with existing solutions.

Users won't need to understand which chain their data lives on, just like they don't need to understand which server hosts a website. The complexity is hidden behind a unified interface.

Blockchain State Management Is Actually Simple

Besides infrequent financial actions (buying furniture, forge artifacts, updating artifact styles) which interact directly with the chain using existing solutions, all other blockchain state is asynchronous. We use the blockchain purely as a "hard drive" to store information, not as a real-time database.

Users always retrieve information first from the P2P network for recent data, then from the blockchain for older archived data. There's no complex state synchronization or real-time consistency requirements—just eventual persistence to permanent storage.

The only technical challenge is optimizing PDA rent costs to keep storage affordable, which is a straightforward economic optimization problem rather than a complex distributed systems challenge.

This approach eliminates the typical blockchain state management problems like transaction ordering, state conflicts, and real-time consistency that plague other applications trying to use blockchains as databases.

Memorial/Quest Chain Programming Is Not Complex

These chain programs are essentially just templates for creating artifacts with the correct data structure.

Memorial programs don't perform verification—they simply generate artifacts from user input. All validation happens client-side because users have the right to decide what they want to express. This makes the on-chain logic trivial: just format user data into the proper artifact structure.

Quest programs do perform verification, but they only need to check structured data from the history in trace system. The verification logic is typically simple: "Did this specific history entry happen?" or "Does the user have X number of interactions with Y furniture type?"

Since trace data is already structured and validated when written, quest verification becomes straightforward data queries rather than complex validation logic.

Both systems avoid the complexity that makes smart contract programming difficult: no complex business logic, no financial calculations, no state conflicts between users. They're just data formatting (memorials) and simple history checking (quests).