ACT 0:
Fill the Cargo for
the Red PlanetACT 0:
Fill the
Cargo
for the
Red Planet
About
White Paper
Prototype
Roadmap
Contact
Act 0: Fill the Cargo for the Red Planet





What do we bring with us when we imagine a new world?




Act 0: Fill the Cargo for the Red Planet is a participatory system where communities collectively curate cultural artifacts for an imagined Mars settlement. Participants submit, vote, and decide what survives—creating a permanent archive through labour-based validation.

By centering space exploration as a cultural act, the project asks: who shapes planetary futures? The archive is anchored on blockchain as permanent cultural record, exploring whether decentralised infrastructures can hold emotional and symbolic value beyond speculation—a model for community-led governance rooted in imagination and responsibility.

About


Mars is not really the subject of this project. It is an excuse.



A place far enough away that we can ask a strange question: if we had to begin again, what would we carry with us?

Because Earth is the only world we have ever lived in. Many of our ideas about value, survival, belonging —we treat them as natural facts.

But they are also decisions. Old decisions. Decisions we inherited.

By asking what we would bring to another planet, we are really asking something simpler: what are we already carrying here?

What feels essential. What we would protect. What we might finally decide to leave behind.

Space exploration is usually framed as an engineering problem. This project approaches it differently. Not as technology. But as imagination.

The Ritual

Act 0: Fill the Cargo for the Red Planet is a participatory platform.

People are invited to imagine life on Mars and respond to a set of questions. What should be protected? What should be governed? What should be remembered? Participants can also propose new questions.

Each response enters a shared pool. Participants read the responses of others and vote. Through this process, some entries are selected and placed into a cargo archive — a record of what this community chose to bring to a new world.

The platform exists for a limited time. It begins. It runs. It ends. What remains is the archive.

Blockchain as Infrastructure

The project uses blockchain in a very minimal way. Participants do not need a crypto wallet. When a cargo entry is validated by the community, it is recorded on-chain as a permanent mark. In a way, the blockchain plays a role that rituals once played. It marks a moment. It says:

This was chosen. At this time. By these people.

The decision cannot be erased. All governance, voting, and moderation happen off-chain through structured rules that distribute attention fairly and prevent dominance by a single participant. Only the final, validated cargo is recorded.

The Community

Participation happens through a referral link. The first invitations come from the core team and partner organisations. Participants can then invite others — friends, colleagues, family members. This creates a chain of connection. The first wave carries context. The second wave brings difference.

What emerges is not a statistical sample of the public, but something more specific: a network of people imagining the same future together. At this moment. In this constellation of relationships.

The Theatrical Work

Act 0: Fill the Cargo for the Red Planet is only the beginning. The cargo archive that emerges from the platform becomes the material for a future stage work. But the form of that performance is not decided yet. The archive itself will shape it.

What people chose to keep. What they valued. Those decisions will determine the work. In that sense, the platform itself is already part of the theatre. The system is the first act. The performance is its consequence.

Closing Reflection

Beginning again is never neutral. We carry with us inherited ideas about value, identity, survival, and belonging. Some are so deeply woven into our thinking that we forget they were ever choices. This project creates a space to pause and examine those inheritances.

What do we keep?

What do we release?

What new ways of living could we imagine together?

Through this process, system design becomes a kind of dramaturgy. And the question of the future becomes something we write together.









White Paper

To begin again is never neutral.


We carry with us inherited beliefs about value, identity, belonging, and survival — assumptions so deeply woven into our sense of self that we forget they were ever choices. The imagination of human settlement on Mars offers a rare opportunity: a shared question that transcends cultural boundaries and institutional contexts. What deserves to be preserved? What should be discarded? What new logic of living can we co-create?

This project addresses that question through participatory validation — a system in which geographically distributed communities collectively determine what cultural artifacts deserve to be carried forward. By creating infrastructure for symbolic decision-making, emotional resonance, and collective reflection, the project offers a space to examine our inheritances and co-author what comes next.

The validated responses — those that survive collective scrutiny and reach preservation thresholds — become source material for theatrical, published, exhibited, or other interdisciplinary work depending on available resources and partnerships. Through this lens, system design becomes dramaturgy. The technical architecture creates conditions for a collective performance of value assessment. The question of the future becomes a shared unfolding story, written not by individual authors but through accumulated micro-decisions of a distributed community.

The Challenge

How can communities separated by geography, institution, and cultural context reach meaningful consensus without erasing difference or deferring to authority?

System Design

A referral-based constellation where participants from different institutional contexts contribute to a shared validation pool through transparent, rule-based mechanisms.

Research Contribution

Investigating whether time and attention — rather than capital or tokens — can serve as basis for collective value assessment at internet scale.

The White Paper →

Read the full document.

The Challenge

The challenge is structural: how can such validation function when internet participation introduces inherent volatility — asynchronous engagement, unpredictable fluctuations in community size, distributed coordination — that traditional governance models cannot accommodate?

Traditional collective decision-making assumes stable, bounded groups coordinating through physical presence. These models struggle when communities are large, fluid, and distributed; when options should emerge continuously; and when multiple independent groups need to reach consensus without explicit coordination.

Internet infrastructure enables cross-community diversity at global scale. Internet participation allows voices from different contexts to overlap without geographic barriers. However, most platforms employ centralized algorithmic curation: users contribute content, but opaque algorithms determine what gets preserved. Users are content providers, not decision-makers; engagement remains shallow rather than substantive.

This system proposes participant-validated collective curation. While infrastructure remains centrally operated, validation decisions emerge from distributed human judgment through transparent, rule-based mechanisms. What gets preserved is determined by accumulated voting from participants who progressively assume validation responsibility. Participants understand how thresholds work, how votes accumulate, how cargo is determined — with validation context preserved as metadata for each entry.

Rather than passive consumption, participants perform substantive cultural labour: voting on responses, reviewing flagged content, curating neglected contributions, proposing prompts. Through progressive role levels, participants take on increasing responsibility with agency over their contribution. Influence derives from labour invested, not capital held — from effort in validation work, not tokens owned or fees paid. Participation remains accessible without financial barriers or centralised control.

System Design

The system creates a referral-based constellation in which participants from different institutional contexts — theatre groups, digital art institutions, cultural organisations, and peer-referral networks — contribute to a shared validation pool. Access is granted through institutional invite links or participant referrals, creating traceable participation pathways while enabling organic network expansion beyond organisational boundaries.

Participants submit creative responses to prompts. These responses enter a shared pool where they accumulate votes through structured attention mechanisms. When vote counts reach dynamically calculated thresholds — adapted to current participation scale — responses transition into a permanent cargo archive. Adaptive thresholds enable validation whether tens or thousands are active. The system is designed to accommodate volatile participation dynamics: communities joining and leaving unpredictably, engagement fluctuating dramatically, and group sizes varying by orders of magnitude.

The architecture comprises six interconnected mechanisms:

  1. Core Participation Loop — submission, voting, threshold validation, cargo archiving
  2. Prompt Design System — creation and maintenance of the question pool
  3. Content Review System — community flagging and moderation
  4. Membership System — referral-based access, progressive role levels
  5. System Versioning Control — adaptive governance as participation scales
  6. Blockchain Layer — ceremonial anchoring of validated cargo and participant credentials

Upon project closure, a community-elected Anchor Keeper executes a ceremonial master anchoring that permanently records all validated responses on the blockchain. Participants can claim non-transferable on-chain credentials that record their labour progression from initial registration through sustained multi-faceted contribution.

Research Contribution

This work investigates whether time and attention — rather than capital or tokens — can serve as basis for collective value assessment at internet scale. It examines how validation thresholds can adapt across fluctuating community sizes while maintaining meaningful collective consensus, how voting mechanisms can prevent attention monopolization, and how transparent rule-based systems can enable substantive validation without relying on opaque algorithms or financial gatekeeping.

The research contributes:

  1. Adaptive threshold models for internet-scale participation with fluctuating community sizes — maintaining meaningful collective consensus when participation varies by orders of magnitude
  2. Labour-based validation architecture where influence derives from effort rather than capital — demonstrating that substantive collective curation can occur without financial barriers or token-based governance
  3. Architectural patterns for cross-institutional collaboration that preserve participant agency without centralised control — enabling distributed communities to coordinate validation across organisational boundaries through transparent, rule-based mechanisms

Beyond its specific theatrical application, this approach informs distributed cultural governance, commons-based cultural production, and participatory archiving in contexts where communities must coordinate across boundaries without centralised authority. It demonstrates that internet-scale collective validation can maintain human judgment and accessibility while adapting to the inherent volatility of distributed participation.

The system addresses a gap in existing participatory infrastructure: most systems either require stable, bounded communities (limiting scale and diversity) or rely on algorithmic curation or capital-based mechanisms (creating opacity or financial barriers). This work proposes a third path: transparent, participant-validated collective curation that adapts to volatile participation through responsive threshold mechanisms while maintaining accessibility and human agency.

The White Paper →

Read the full document.
Prototype

Three prototypes. Three layers of the same system.


The submit and vote flow demonstrates the participant experience — how the fictional frame of the Mars mission carries across screens, how a first-time contributor moves from arrival through submission to collective validation.

The ticket pool simulator demonstrates the underlying mechanics — how adaptive thresholds, vote distribution, and ticket dynamics interact across different community scales and participation patterns. It is a research tool for investigating the system's behaviour before the real platform is built.

The blockchain anchoring prototype demonstrates the permanence layer — how a moderation decision made in a web interface can produce a verifiable record on a public blockchain, without requiring participants to interact with cryptocurrency.

These prototypes do not represent a finished product. They demonstrate the core mechanics described in the white paper and surface findings that will inform the next phase of development.

Prototype 1

Submit and Vote Flow

Prototype 2

Ticket Pool Simulator

Prototype 3

Blockchain Anchoring

Prototype 1 — Submit and Vote Flow

This prototype demonstrates that the fictional frame of a Mars mission can carry a participant from arrival through submission, voting, and collective validation in a single coherent session.

Try the Submit and Vote Flow →

What this prototype tests

This prototype models the first-time participant experience — the onboarding flow from arrival to first vote. It is not the everyday returning experience. In the real system, a returning participant would enter directly into the voting field with their existing ticket balance, seeing a fresh daily snapshot of entries. The first-time flow is distinct: it begins with a mandatory submission, which earns the participant their first vote ticket and positions them as a contributor before they become an evaluator.

The prototype tests whether this onboarding arc feels coherent and meaningful — whether the fictional frame of the Mars mission carries through each screen, whether the submission-to-vote-to-manifest progression feels natural, and whether a first-time participant can navigate the full loop without instruction.

User experience design — including interface design, gamification mechanics, visual identity, and onboarding flows — has not been developed in this phase. This prototype demonstrates functional flow and narrative coherence only. Full UX and UI development will require a dedicated design team in the next phase.

What was built

Six interconnected screens modelling the complete first-time participant journey:

welcome.html — entry point. The participant agrees to terms and enters the mission.

submit.html — submission flow. The participant selects a category and receives a daily prompt. One prompt appears per category per day. The participant completes the sentence, confirms their entry, and is told which labour their contribution feeds. On submission, one vote ticket is issued.

viz.html — the voting field. A spatial map of coloured orbs distributed across organic ink blot territories. Each territory represents a labour group. Each orb represents a submitted entry within that labour. Tapping an orb reveals a card showing the entry text, labour label, and current vote count. The + button selects the view mode — random, popular, oldest, newest, neglected. A live feed ticker at the bottom can be toggled on or off.

vote.html — vote confirmation. The selected entry is displayed for review. The participant confirms their vote, spending one ticket. After the first vote is cast, the Pre-Launch Manifest becomes accessible.

cargo.html — the Pre-Launch Manifest. A board showing validated cargo units organised by category. Each unit holds 5 entries. When a unit fills it is sealed and a new one begins collecting for that category.

mission-protocol.html — the rules of the mission within the fictional frame. Accessible from the navigation panel.

field-orders.html — the participant's available tasks according to their current role level. Active tasks are linked and accessible. Tasks belonging to higher role levels are shown but locked.

The navigation and dashboard panel — accessible via the hamburger icon — shows all main destinations alongside the participant's live status: Sol day, crystal state, vote tickets remaining, entries submitted, and entries confirmed in the manifest.

What this confirmed

The fictional frame of the Mars mission holds coherently across all six screens. The spatial voting field — orbs distributed across labour territories — gives the validation process a visual and emotional presence that a list-based interface would not. The progression from submission to vote to manifest feels purposeful: the participant contributes first, then evaluates, then sees the collective result.

This prototype and the blockchain prototype together demonstrate the complete journey of one entry. This flow shows how entries move from submission through community voting to "Awaiting Manifest." The blockchain prototype shows what happens when "Awaiting Manifest" becomes permanently anchored. The two prototypes are two acts of the same story.

Terminology note

The white paper refers to the validated archive as the cargo archive. In this prototype it is presented as the Pre-Launch Manifest — the same concept expressed within the fictional Mars frame. Validated entries are grouped by category into cargo units of 5. This is a container size, not a limit — when one unit fills, the next begins.

Awaiting Manifest means the unit is full and the entries have passed the community validation threshold. These entries are waiting for the ceremonial batch anchoring at project closure, when the Anchor Keeper seals the manifest permanently on the blockchain.

Collecting means the unit is still accumulating validated entries and has not yet reached capacity.

How to try it

Begin at welcome.html. Read the mission brief and agree to the terms to enter.

You will arrive at the submission screen. Select a category — one prompt is available per category, refreshing daily in the real system. Complete the sentence and confirm. One vote ticket is issued.

Navigate to the voting field. The map shows coloured orbs distributed across ink blot territories. Purple orbs are your own entry and cannot receive your vote. Tap the + button to select a view mode. The map has two pages — tap > to explore the second. Toggle the circle bottom left to turn the live feed ticker on or off.

When you find an entry you want to support, tap it and proceed to vote confirmation. Confirm your vote to spend one ticket.

After your first vote is cast, the Pre-Launch Manifest becomes accessible via the menu. Each browser session allows up to 3 submissions and 3 votes.

Known limitations

Session storage only. Refreshing or closing the browser resets the session.

No pre-screening, duplicate detection, or content flagging. In the real system, entries are checked for exact duplicates and harmful content before entering the pool.

The voting field shows a fixed dataset of seeded entries, not a live community pool.

The crystal progression system — Amorphous, Nucleating, Crystallising, Faceted, Set — is partially implemented and will be refined with full UX development.

The returning participant experience — direct entry to the voting field with existing ticket balance — is not modelled in this prototype.

See also

Prototype 2

Ticket Pool Simulator

Prototype 3

Blockchain Anchoring

Prototype 2 — Ticket Pool Simulator

This simulator reveals how threshold models, view modes, and ticket dynamics interact — and what a healthy validation system looks like before a single real participant joins.

Try the Ticket Pool Simulator →

What this prototype tests

This simulator tests how the ticket pool and cargo validation mechanics behave across different parameter combinations — exploring threshold models, vote distribution, and participation dynamics before the real platform is built. Rather than demonstrating a user-facing feature, it is a research tool: a way of making the system's interdependent mechanics visible and testable through controlled simulation.

The system described in the white paper introduces a set of interdependent mechanics — ticket issuance, vote distribution, adaptive thresholds, cargo transitions — that interact in ways that are difficult to predict through design reasoning alone. Small changes in one parameter produce unexpected effects elsewhere. The simulator makes these interactions visible and testable.

It models one version window — the period between system governance adjustments, up to 60 days — at a community scale of up to 200 active participants each day. This reflects the realistic early and mid-phase scale of the project rather than hypothetical large-scale scenarios.

The simulator deliberately simplifies some aspects of the real system. Popular, oldest, and newest view modes use a shared daily window rather than individual per-participant snapshots. Participation follows a base growth trend rather than modelling wave-based community joins. Version transitions are not simulated — each run models a single version period with fixed parameters. These simplifications are intentional — they isolate the variables under study and keep the tool usable on standard hardware.

"Submitted entry" throughout this simulator refers to what the white paper calls a "response."

What the simulator revealed

Running the simulator across different parameter combinations produced five findings that directly inform how the real system should be configured and monitored.

Finding 1 — No single view mode is sufficientNeglected mode alone produced zero cargo in testing. Popular mode alone starves the long tail — the same entries keep accumulating votes while newer or less visible entries never surface. The multi-modal approach described in the white paper is not just a design preference — it is mathematically necessary for healthy validation.

Finding 2 — View mode effectiveness depends on community sizeWith 20 participants, popular mode significantly outperformed random. With 200 participants, random outperformed popular. The optimal view mode mix is not fixed — it shifts as the community scales.

Finding 3 — Window size can override threshold differencesWith popular mode and window size 20, fixed threshold K=5 and logarithmic threshold produced almost identical cargo rates. The attention bottleneck matters more than the threshold model when viewing is concentrated.

Finding 4 — Unused ticket rate is the hidden dragThe gap between peak ticket pool and votes cast is the clearest early warning sign of system stress. A large ticket pool with low cargo rate means a significant portion of participants are holding tickets they never spend.

Finding 5 — Cargo rate % is the primary health indicatorNot average votes per submitted entry, not ticket pool size, not daily votes cast — the ratio of cargo to total submitted entries tells you immediately whether the system is functioning. A healthy cargo rate sits between 10–30%. Below 5% the system is stagnating. Above 40% the threshold may be too permissive.

How to use it

Community shape

Days, Initial participants, Daily growth %, Participation volatility %

Community size fundamentally changes how the system behaves. When the community is small — around 20 participants — the ticket pool is limited and sensitive. As the community grows toward 50 active participants per day, the submission pool expands faster and more entries compete for the same votes. At around 100 active participants, the question shifts from threshold calibration to attention distribution — how do submitted entries stay visible long enough to accumulate votes across multiple days.

The Participation volatility parameter adds realistic irregularity on top of the base growth trend. Use this to test whether the system remains stable when participation is uneven, as it will be in any real internet-based community.

Participation behaviour

Submission rate %, Submission multiplier, Daily vote rate %, Unused ticket rate %, Ticket issuance multiplier, Ticket expiry

Not every participant is equally active. Some submit regularly and vote every day. Others join, submit once, and never return. Others are present but passive — they hold tickets they never spend. The unused ticket rate captures these passive participants: their tickets accumulate in the pool and eventually expire unused, reducing the effective vote supply.

The submission multiplier simulates participants submitting more than once per day — up to the system maximum of three entries. The ticket issuance multiplier represents the bonus ticket system: active participants who complete tasks, maintain streaks, and contribute to governance earn additional tickets beyond the base issuance.

Ticket expiry determines how long a ticket remains valid. A short expiry window creates urgency. A longer window gives passive participants more time to engage, but means unused tickets sit in the pool longer before clearing.

Validation mechanics

View mode, Window size, Threshold model and its parameters

When enough participants independently make similar choices — selecting the same entry across different days, different view modes, different attentional contexts — the entry crosses the threshold and enters the cargo archive. The threshold number is the final gate, but the real validation is the entire journey.

The simulator models three parameters that govern this layer: view mode determines how entries are discovered, window size determines how many entries compete for attention on any given day, and the threshold model determines what level of accumulated consensus counts as meaningful validation.

Reading the results

Total cargo · Final sub pool · Cargo rate % · Total tickets expired · Peak ticket pool

Cargo rate % is the primary indicator. A rate between 10–30% suggests the system is functioning with meaningful selectivity. Below 5% the system is stagnating. Above 40% the threshold may be too permissive.

Total cargo and Final sub pool together tell you the shape of the archive. A large final sub pool alongside low total cargo means many entries are waiting but not reaching threshold.

Total tickets expired is the unused ticket problem made visible. If this number is high relative to total cargo, a significant portion of the ticket supply is being wasted.

Peak ticket pool shows the maximum ticket backlog reached during the run. A very high peak relative to votes cast per day signals that tickets are accumulating faster than they are being spent.

Run the same parameters multiple times — participation volatility and random view mode introduce randomness, so consistent patterns across multiple runs are more meaningful than any single result.

See also

Prototype 1

Submit and Vote Flow

Prototype 3

Blockchain Anchoring

Prototype 3 — Blockchain Anchoring

This prototype proves that a human approver can trigger a permanent blockchain record from a standard webpage, with no crypto knowledge required. Cost per transaction: less than half a cent.

Try the simulation →

What this prototype tests

  • Whether a signed blockchain transaction can be triggered automatically from a webpage, without any manual wallet interaction from the user
  • How a project-controlled wallet can be linked to a backend and perform anchoring autonomously
  • The full flow from moderation decision to on-chain record — what that moment actually looks like end to end
  • What the minimum viable on-chain data looks like — what needs to be stored on-chain to make the record meaningful and verifiable

What was built

Two versions were developed in sequence. The first is a simulation — a fully functional moderation and anchoring interface that generates realistic anchor records locally, without any blockchain connection. The second (real version) replaces the simulated layer with a real smart contract deployed on Polygon Mainnet, producing actual on-chain transactions.

The real version consists of three connected components:

  • A smart contract (DataAnchor.sol) deployed on Polygon Mainnet that receives and permanently stores the submission ID, data hash, approver identity, and timestamp
  • A Node.js backend that holds the project wallet, signs transactions automatically, and sends them to the blockchain via the smart contract
  • An admin interface (p1-admin.html) with an Approve & Anchor button — when clicked by a human approver, it triggers the full chain: PHP generates the data hash, calls the Node.js backend, which signs and sends the transaction, and returns the real txHash and block number to the interface

The smart contract is intentionally minimal. It stores four fields per record, restricts write access to the project wallet, and emits a queryable event on each anchoring. The onlyOwner modifier means only the project wallet can call the anchor function. The getAnchor function lets anyone read any record by its index — public, no restrictions.

How to try the simulation

The demo loads with three submitted entries in different states. Two are ready for anchoring, one is still a candidate with insufficient votes.

Refresh reloads the moderation queue from the database without changing any data.

Reset demo restores the database to its default state — clearing all anchor records and returning submitted entries to their original statuses.

Approved by dropdown lets you select the approver identity. Three roles are available — adminID (manual, full access), committeeID (manual, designated reviewers), and schemeID (automated, no human input).

Ready for moderation lists all submitted entries that have accumulated enough votes to cross the threshold. Click Approve & Anchor to anchor that entry.

Last response shows the raw data returned after each action — submission ID, data hash (SHA-256 fingerprint), and transaction hash.

Real test results

The simulation was then connected to a real smart contract deployed on Polygon Mainnet. The same admin interface, the same Approve & Anchor button — but this time each click produced a permanent on-chain transaction.

Transaction 1 — contract deployment test
Triggered directly in Remix IDE to confirm the smart contract was correctly deployed and functional. View on Polygonscan →

Transaction 2 — Node.js backend test
Triggered via Terminal to confirm the Node.js backend could sign and send a transaction automatically using the project wallet, without any manual MetaMask interaction. View on Polygonscan →

Transaction 3 — full end-to-end test
Triggered through p1-admin.html — the actual moderation interface. A human approver clicked Approve & Anchor. PHP generated the data hash, called the Node.js backend, which signed and sent the transaction to the smart contract on Polygon. View on Polygonscan →

Each transaction cost less than half a cent. Each one is permanent and publicly verifiable by anyone, without relying on this server or the project team.

Link to the PDF report →

What this confirmed

The prototype confirmed that the anchoring layer of Act 0 is technically viable.

  • The full flow works end to end — a human approver clicks a button in a standard webpage, and a permanent verifiable record appears on a public blockchain. No crypto knowledge required from anyone in the process.
  • A project-controlled wallet can sign and send transactions automatically in the background. Participants never interact with blockchain infrastructure directly.
  • The minimum viable on-chain data is sufficient. Storing only the submission ID, data hash, approver identity, and timestamp produces a record that is both lightweight and fully verifiable. The actual content stays off-chain — only its cryptographic fingerprint is anchored.
  • The cost is negligible. Each transaction costs less than half a cent on Polygon Mainnet. The ceremonial batch anchoring at project closure remains financially trivial.

What remains

  • The single-entry anchoring tested here will be replaced by a ceremonial batch transaction at project closure — anchoring all validated cargo entries simultaneously via a Merkle tree structure, as described in the white paper
  • The project wallet management and signing infrastructure will be rebuilt within the full system architecture, with proper security and process management
  • The dual-network strategy — Polygon for accessibility, Ethereum mainnet for permanence — still needs to be implemented and tested
  • Transaction error handling and retry logic needs to be added for production reliability

See also

Prototype 1

Submit and Vote Flow

Prototype 2

Ticket Pool Simulator

Closing

These prototypes are a beginning, not a conclusion.

The submit and vote flow raises questions about onboarding, experience design, and how the fictional frame sustains engagement over time. The simulator reveals dynamics that require further calibration — threshold parameters, window size, participation volatility — as real community behaviour is observed. The blockchain prototype establishes a foundation that will need to scale from single-entry anchoring to ceremonial batch transactions at project closure.

Further investigation, a dedicated development team, and structured user research will build on what is demonstrated here. The system is not yet built. But the ground has been prepared.

Roadmap

Where we are now

  • Akademie Schloss Solitude web residencies granted
  • High-level system design complete and documented in the white paper
  • Three core prototypes built and documented
  • Conceptual and technical foundation established

Pre-production

  • Secure funding
  • Low-level system design and technical architecture
  • UX and UI design
  • Gamification research and design
  • Platform development and internal testing
  • Structured user research with real participants
  • Partner outreach and onboarding
  • Seed prompt design
  • Guest curator invitations

Launch and mission

  • Partner communities invited in waves
  • New prompts arrive from guest curators at intervals
  • System monitored and governance parameters adjusted across version transitions
  • Cargo accumulates
  • Mission runs 4 to 8 months depending on invited communities size

Closure

  • Final voting period
  • Anchor Keeper elected by the community
  • Ceremonial batch anchoring executed
  • All validated cargo and participant credentials recorded permanently on the blockchain
  • Cargo archive sealed
  • Retrieval system made available

After

  • Archive publicly accessible
  • Cargo material developed into theatrical, published, exhibited, or other work depending on resources and partnerships
  • The work is presented
  • The ship has departed
Contact

A few words from the maker

Hi, I'm Lam Lai. I made this project during the Akademie Schloss Solitude web residencies. What you see here is the result of that research period: the system design, the white paper, and three working prototypes.

The project is still in development. If something here resonates with you, I'd love to hear your response. A reaction, a question, a thought. Thank you!

lamlaifa@gmail.com

To see my other work, visit lamlai.com