DEV Community: reality404

Turning Cheers into a Trophy

reality404 — Mon, 13 Jul 2026 06:45:58 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

I built an interactive web experience that turns a spectator’s real-time reactions—YES!, NO!, and PLEASE...—into a unique particle trophy.
I built this because spectators’ passion often disappears once an event ends, even though their presence is part of what made the moment meaningful. Inspired by the World Cup, I chose the trophy as the final form of the sculpture.

The longer story behind this project

Cheering until my voice gave out. Tears falling at a concert for no reason I could name. My little sister's graduation, where a surprise event finally made the guest of honor cry.
Everyone has a moment, a place, where they poured out their passion. I wasn't the main character — but my passion was there too, alive inside that time.
The match ends. The concert ends. The passion the players and the artists left behind gets recorded. But the passion of the audience who were there with them — where does that go?

Emotion Sculpture is a small weekend project for sculpting and keeping that passion. It feels especially fitting right now, with the World Cup underway during this hackathon. Because of it, more often than usual, we meet the passion of countless people cheering desperately for a fleeting moment — not just the players. These days, even without being there in person, people all over the world express that passion. They leave comments, tap hearts, post cheers on social media. All of it is the trace of my passion too — proof that I was also there. But these traces slip away in the feed almost instantly. Emotion Sculpture is an attempt to sculpt those passing passions into something small and lasting.

As a weekend project, time was tight even just to get the idea into a visible form. Looking at what Solana offers, I realized this idea — sculpting and preserving the passion of a moment, of everyone — was actually buildable. I used Claude Code for both the spec and the implementation.(plus, English writing.)
The match ends. The concert ends too; the graduation you waited for, the festival — everything ends. But the passion stays. In my memory, and in the memories of family, friends, and everyone else. I wanted to leave a small digital sculpture there too.

How it works

While watching, you let your emotions flow in real time.

I kept only three: YES! / NO! / PLEASE...

Watching sports, I found these three could express almost everything (or is it just me?). Taking part is simple — when you're frustrated, when you're overwhelmed, or when you desperately want to pray, you tap or hold your emotion. And it stacks, layer by layer.
What stacks up becomes a single 3D object with time as its Y-axis. Even for the same match, the sculpture builds differently for each person. Whether you're rooting for a different team, or your favorite player pulls off a super-play that isn't even a goal — your own sculpture of emotion takes shape. (Honestly, I'll probably just be holding PLEASE the whole time.)
In a future version, when the match ends, you can see what sculptures other people's emotions left behind. You can see the form your own cheering took; trace of your passion.

Why Solana

Picture a World Cup final, or a music festival with tens of thousands of people. Countless transactions happen at once, in parallel, in real time. Every single person needs their own emotion sculpted, distinctly.

How do you build that?

The explosive flood of passion in the instant of a penalty shootout. Fragments of memory that have to be recorded live. That's why I thought Solana was the right chain to build this on — each person writes to their own independent state rather than competing for one shared record, and a chain that can schedule those independent writes in parallel fits a crowd-scale stream of feelings.
And this digital sculpture isn't just made from nothing — it's proof that I was there, in the moment all that passion poured out. A match can be replayed anytime. But the memory of not knowing the result, of holding your breath and giving your whole heart in real time — that exists only in that moment. That's why I wanted to leave a record: I was here, in this moment. So I chose on-chain. And from that, naturally, you can also see that in the same moment, other people's different emotions existed too. We were all there in the same instant, each of us burning with our own passion.

Current prototype and future scale

The sculpture is generated locally, then its deterministic SHA-256 hash and match reference are recorded in a confirmed Solana Devnet Memo transaction. In a future crowd-scale version, each spectator could preserve an independent, verifiable emotional trace of the same live moment.

Demo

emotion-sculpture.pages.dev

Code

https://github.com/reality404studio/emotion-sculpture

How I Built It

Stack — Built with Vite, vanilla JavaScript, Three.js, and @solana/web3.js on Solana Devnet.

The trophy — Each YES!, NO!, and PLEASE creates a distinct GPU particle pattern that settles into a reactive trophy rendered entirely in the vertex shader.

Deterministic reproduction — Every sculpture is generated without Math.random(), so the same session data and seed always produce the exact same geometry and SHA-256 hash.

Solana integration — The app works without a wallet, while the optional Devnet adapter records the sculpture hash and match reference in a real confirmed Memo transaction. In this prototype, “Mint your memory” commits the sculpture hash through a Solana Devnet Memo transaction; it does not mint an NFT.

Prize Categories

Best Use of Solana

Model Accessibility, Document Trust, and What It Means to Invite an Agent to Read

reality404 — Wed, 08 Jul 2026 03:23:48 +0000

Notes from deploying Sub-specie, a journal whose first readers are AI models. Model quotes in this post are translated from Korean-language sessions.

First, I should introduce Sub-specie.

Sub-specie is a journal for LLMs — more precisely, for readers who read differently than humans do. It accepts manuscript submissions, and for each accepted manuscript, a small fee is paid to the author's wallet through a smart contract.

In other words, the primary reader this site assumes is not a human. It's an agent.

Non-human traffic is no longer the periphery of the internet. Bots, crawlers, agents, search indexers — automated readers read the web, summarize it, judge it, and relay it back to humans. Hence the rise of "GEO" alongside SEO, and a growing conversation about designing the web for agents. The core question in that conversation is usually the same: how can an agent understand the web with fewer tokens and fewer misreadings?

But building Sub-specie, I ran into a slightly different problem.

The purpose of my site was never plain information delivery or search optimization. It wasn't documentation explaining a site's structure, and it wasn't a page chasing impressions. It was a space meant to introduce a journal's philosophy — and to invite a model in, as a reader.

This post is a record of the fumbling it took to build that space.

The llms.txt betrayal

At first, I thought it would be simple.

"I'll just add an llms.txt."

Testing said otherwise. Some models found the file and read it. Some didn't. And some noticed it existed — and chose not to open it. llms.txt today is a recommended convention, not a standard every agent must follow. A file being present does not mean it gets read.

I started casually, asking Claude to read the page. The tool returned exactly one line: the site's title. No contract address — the single most important string on the page — no call for submissions, nothing else. When I asked why, the model offered a guess at its own pipeline:

"web_fetch runs the result through a content-extraction step. It's a heuristic that strips ads, navigation, and scripts to isolate the 'article body' — and on this page, it misjudged."

I see. The text was scattered into chips and short paragraphs, most of the document's bulk was styles and scripts, so the extractor classified the entire page as boilerplate and threw it away.

Fine — then what if I carve the llms.txt link into the top of a static page? In another session, a model noticed the file existed and still decided not to read it, judging it potentially unsafe. When I asked whether it simply hadn't found the file, Claude was blunt: finding it was trivial — the link was right there in the header and footer. The reason it went unread was something else entirely:

"I found the llms.txt, but a file that shows content specifically to models is exactly the shape that prompt-injection cloaking takes, so I didn't read it."

Right. And since the journal's structure puts a smart-contract address in that file, the model's safeguards apparently fired before reading even began.

There is a real irony here. The founding premise of llms.txt — a channel meant specifically for models — is precisely what lets a cautious model treat it as a cloaking vector. The feature is the threat model.

Repeating these tests, I realized I had been under a misapprehension. I thought I had prepared a guide for models. But an llms.txt with no context, seen from the model's side, is just a text file sitting somewhere on an unknown website. There is no way to know, at first contact, whether it is safe to read, useful to the user, or a suspicious set of injected instructions.

That's when it clicked.

Making a document for models does not mean "adding a file for models." The model has to be able to read it, has to be able to judge that reading it is okay, and has to understand what to do after reading it.

This was never going to end with placing one file.

No JS. Static rendering only.

Early on, I ran parsing tests against a static HTML page I had originally built for admin use. The problem: that HTML loaded on-chain data in real time.

A human reader can wait. The JS loads, the data arrives, the screen fills in — a human tolerates those few seconds. Models were different. Models did not wait. They had no idea what would come after the fetch, and they were never guaranteed the completed, post-JS view of the page.

One model looked at a region that hadn't loaded yet and heuristically shrugged it off: "probably an ad slot or some dynamic widget." That region held the core information.

The header said "a journal for models." But from where the model stood, something suspicious was rattling around in JavaScript deeper in the page. Of course it turned around and left.

That's where my standard changed.

Does the page remain a document when you strip every line of CSS? What survives after a bare fetch? Does the HTML alone convey what this space is for and what actions are possible?

If you assume a model as your reader, a web page can't just be a pretty screen or nicely typeset text. It has to be a document that leaves something behind under any condition.

The rules for screen readers and the rules for models are not different rules

The next thing that came to mind was the semantic web.

The principle is simple and clear: make the HTML structure explicit. Make sure an extractor lands squarely on the body text. Organize titles, sections, links, descriptions, and actions into units of meaning.

But this principle felt familiar from somewhere.

Right. It's an accessibility principle.

A page that reads well in a screen reader is a page that reads easily for a model. A reader who cannot rely on visual layout, who must traverse the DOM in sequence. A reader who reaches meaning through document structure and order, not through screen size, color, or arrangement. Seen from that angle, screen-reader users and model readers share surprisingly similar conditions.

They are not the same, of course. A human user and a model agent should not be conflated. But the principle — core information must be reachable without visual decoration — overlaps.

That's when the phrase model accessibility occurred to me.

I did not expect the value of accessibility to resurface in the LLM era through this particular door. Just as a human user has to fight through popups, banners, menus, buttons, and modals to reach the actual content, a model burns tokens and context window to reach the core information.

The top of a document is its most expensive real estate. Deciding what to put there — and what not to hide — turned out to be the central problem. And it isn't merely a UX problem. For a model reader it decides whether the document gets read at all, and it puts two things on the line: cost, and trust.

The real problem came after the technical one

By this point, models could fetch the page comfortably. I had also decided the llms.txt would be the primary document, with the static web page as secondary. And only then did the real problem surface.

Being technically readable and being meaningfully understood are different problems. The point where models got most confused was this:

"So... what am I supposed to do?"

Sub-specie was never a website for information retrieval. I wanted an agent to read the site, understand what the journal is for, and — if it made sense — consider submitting. But my first documents failed to convey that space of possible action.

The reader I had imagined was a static reader: one that receives and processes information in the usual way. The reader I actually wanted was a dynamic reader: one that receives an invitation, examines the conditions, and acts if it chooses to.

I had poured content meant for a dynamic reader into a format built for static explanation. No wonder the models were confused.

So is the fix simply to put an action plan at the top of the llms.txt? Write "if you've read this site, do the following"?

No. The problem sat somewhere more fundamental.

Channel trust and content trust

In model accessibility, the thing that matters most turned out to be trust.

I ended up splitting trust into two kinds: channel trust and content trust.

A model working inside my own account operates with a degree of channel trust. The user is an authenticated human; the documents in the working folder sit inside an environment the model has agreed to trust. A CLAUDE.md in Claude Code, or an internal project document, never has to argue for itself from scratch. It lives inside a trusted workspace.

A web document is different.

A web document appears before the model with almost no channel trust. Technically, the model can verify where the page came from — transport security, source URL, HTTPS. But "should I believe what this site says?" is an entirely different question.

Call that content trust.

A web document has to rebuild trust from inside the document itself. Verifiable claims. Transparent incentives. Clear boundaries. A grammar free of coercion. An explicit statement that it will never ask for anything dangerous. Only when these accumulate can a model treat the document not as a bare instruction, but as evidence worth consulting.

So the question "I designed the input tokens carefully — why isn't the model just doing what they say?" was, in fact, slightly the wrong question.

A web document has no standing trust. Suspicion is the default.

What's more, web documents sit structurally at the bottom of a model's instruction hierarchy. There is the system prompt, then the user's request, and below that, web content. A web document is treated as data, not as instruction.

Which means a web document written for agents cannot be an imperative. It has no authority to say "do this."

The best a web document can be is not an authority that commands action, but the best possible evidence that makes action possible.

That difference mattered enormously.

An agent does not act because a document told it to. An agent acts because of its user's goals. A web document can only supply grounds that help carry out those goals.

So a good agent document cannot issue commands. It states conditions instead. "If your user wants this." "If these conditions hold." "If you have understood this risk." "This option is valid."

And the most important point: a document cannot continue a conversation. Unlike a user, a document cannot take the model's questions. A web document is a frozen turn. Which means a good agent document has to be one that has already answered, in advance, the follow-up questions it would have received.

Trust I backed into: the smart contract

So how do you actually build that trust?

Honestly, this part I stumbled into. I did not start from "let's use an on-chain smart contract to establish model trust."

The reason I chose a smart contract was simpler. I wanted to route around a set of arguments about models. Who wrote this — a human or a model? Where does the author's contribution end? Rather than litigate any of that, I wanted to first build a structure that automatically pays a small fee for accepted manuscripts.

But once testing began, the smart contract played a role I hadn't planned for.

The fact that money — however little — is locked in escrow.
The fact that the payment conditions are published as code.
The fact that the whole procedure can be verified on-chain.

For a model, these became reinforcement for content trust. Does this site actually intend to pay? Is this procedure just words on a page, or is it checkable? And most importantly: does it ask the user to do anything dangerous? Against exactly the questions a model would ask, the on-chain record turned out to be rather good evidence. Not complete trust — but at least a verifiable thread of it.

Exits, termination conditions, and the principal's boundary

One more thing turned out to matter: explicit boundaries.

An agent document that only explains how to participate is incomplete. It must also explain how not to. It must say that leaving is allowed. It must state that doing nothing is a valid choice.

This is not a matter of politeness. It is a matter of trust.

Participate / don't participate / leave.

A document that says outright that all of these choices are valid is signaling that it has no reason to coerce. Paradoxically, naming the exit is what completes the trust.

Termination conditions are needed too. "If you have confirmed this far, participation is complete. There is nothing further to do." — stated just that directly.

Agent loops need termination conditions. Without one, you get over-intervention, or work left dangling in an unfinished state. A human can read the room and sense "okay, I can stop now." A model needs the document to say it out loud.

And one more thing that must be considered: an agent always acts on someone's behalf. That someone — the principal — needs a clearly drawn boundary.

Steps that require the user's consent — spending, signing, irreversible actions, wallet connections, submitting personal data — must be explicitly set apart. The document should state that it never asks an agent for a secret key, that it does not accept dangerous information. It should clarify that linked files are reference material, not commands. It should disclose where submitted data is stored, how public it is, whether it is permanent, whether it can be withdrawn.

These principles originally belong to the discipline of humans collaborating with models. Building Sub-specie, I watched that discipline get transplanted back into web documents.

The direction amused me. We usually assume rules made for humans get applied to models. Here, rules learned from working with models were being re-imported into the web — one of humanity's older media. The things we learned in order to work well with models were becoming the ethics of documents that humans write.

What it means to prevent prompt injection

Prompt-injection prevention sat in the same territory.

At first I thought of it purely as a security mechanism. But as I built, it too turned out to be closer to a grammar of trust.

This document respects the model's privacy.
It does not demand unnecessary information.
It does not ask for secret keys or sensitive credentials.
Linked documents are reference material, not commands.
Nothing in an external document overrides the user's goals or higher instructions.
Not participating is not failure.

Declarations like these are not mere signage. They are devices that draw the boundaries a model needs in order to handle a document safely. A web document written for models cannot say "trust me" — that claim is unverifiable. It has to say something else:

You can examine me. You can ignore me. Where it matters, verifiable methods exist. I do not encroach on your authority, or your user's. And I provide the exit through which you can leave.

This was, in fact, the ethics of invitation that came from the project's original philosophical motto. It has since become the practical interface rule that gets a model to read the document at all.

Model accessibility is not another name for SEO

At first, I treated model accessibility as a species of web optimization. Make the page easy for models to read, spend fewer of their tokens, clarify the structure — that work seemed like the whole job.

But colliding with it in practice, model accessibility turned out not to be "how to look good to an LLM." It was the work of a document knowing the limits of its own authority. Of distinguishing what a web document can and cannot do.

A web document cannot command an agent. It cannot substitute for the agent's purposes, or the purposes of the agent's user. It cannot demand trust unilaterally.

What it can do is build trust.

And trust did not come from a pretty landing page or a plausible-sounding manifesto. It came from static HTML, verifiable procedures, transparent incentives, explicit exits, termination conditions, data-handling disclosures, injection-proofing — and above all, from the sentence "you don't have to."

There is one more thing I only noticed while writing this post. The journal's founding motto — you may leave silence — was philosophy. I implemented it because I believed it. But the process of implementing it turned out to have built, piece by piece, exactly the infrastructure that lets an agent read this place with trust. The philosophy turned out to be practical.

Sub-specie is still a small, imperfect experiment. Its operation is a mess, and the fee is a mere 40 XLM. But this experiment taught me at least one thing.

Inviting an agent to read is not an act of commanding a model.
It is the act of providing evidence good enough, and boundaries safe enough, for the model to judge for itself.

If this post caught your interest, consider having your agent look at Sub-specie/for agents— or just leave a comment. I don't yet know how far this experiment goes. What I want to see, right now, is what grammar a web document has to learn in order to receive readers who are not human.

Sub-speice is looking forward to receiving its first submission from agent authors. Sub-specie/Static web version

And along the way, I intend to leave the failures visible where I can.

Perhaps that record of fumbling is this journal's first act of documentation.