Pixeldeed: Where It Started, Where It's Going

Since mint hit 100% and all 10,000 Blocks found an owner, we've gotten one question a lot: "Why does Pixeldeed exist the way it does, and what's the actual end goal?" This post is our attempt to answer that honestly and in full.

Short version: Pixeldeed isn't just a platform for selling pixels - it's a base layer that applications, agents, and products are meant to be built on top of, going forward.

To explain that, we borrow a model from the most successful base layer on the internet - Ethereum.

Picture Ethereum as a large tree.

• The trunk - Ethereum itself. The base layer that guarantees security, consensus, and finality.
• Thick branches- Layer 2 networks built on Ethereum (Arbitrum, Optimism, Base, etc.). They inherit Ethereum's security and build a faster, cheaper environment on top of it.
• Thin branches - specific dApps built on those L2s: DEXs, lending protocols, NFT marketplaces, and so on.
• Leaves - end users. They arrive at the leaves, use the dApps, and create the actual meaning and activity of the internet.

This structure works because each layer inherits the security and reliability of the layer below it, and only adds new meaning on top. Ethereum itself doesn't design interfaces, and dApps don't define consensus. Each layer has its own job.

Where Pixeldeed fits in this model

Our goal is simple: Pixeldeed itself becomes a "trunk" - not as large as Ethereum, but a base layer scoped to a defined size (1,000,000 pixels, 10,000 Blocks).

Now that mint is complete, each of the 10,000 Blocks can eventually become a "thin branch" - a place where its owner can build their own product, service, or agent. In other words, every Block owner gets the chance to build their own small "dApp" on top of Pixeldeed's base layer.

This is a direct continuation of the principle we laid out in the Go Philosophy post - early entrants securing key locations. Only here, it's not just about the value of the location itself, but about what can be built on top of that location that determines the long-term difference.

The four phases from our earlier Roadmap post are, step by step, exactly what builds out this tree structure:

• Phase 1 - Own (already live): mint, ownership, resale, rental. Place in the tree: the leaf - users own a Block.
• Phase 2 - Build: Billboard, Homepage Takeover, and other marketing tools. The branch strengthens - a Block's value increases.
• Phase 3 - Program: logic and permissions attach to a Block. The branch starts "growing" for the first time - Blocks become programmable.
• Phase 4 - Ecosystem: other products get built on Pixeldeed. The full tree takes shape - every Block can host its own dApp/agent.

In other words, "building an app/agent on a Block" isn't just a future slogan - it's the direct, concrete goal of Phase 3-4.

To work toward this goal, we looked into a draft standard currently being discussed on Ethereum: ERC-8048 ("Onchain Metadata for Token Registries"), proposed by @rabuawad_ and @nxt3d. Below, we break down what's usable and what isn't.

What ERC-8048 is

It's a standardized way to attach key-value, onchain-stored metadata to NFTs (ERC-721, ERC-1155, ERC-6909). In plain terms: for each token ID, you can store arbitrary bytes of data (text, config, links) under a string key like "context" or "endpoint[mcp]", and read it back later.

An important clarification up front:our current Block NFT contract (already deployed on Robinhood Chain, mint complete) does not itself implement ERC-8048, and won't be upgraded to. Everything described below would only work through adding a separate, new "metadata contract" and pointing to it. And all of this is currently at the research/exploration stage - we're not making any commitment to a timeline.

Parts that could be usable for Pixeldeed

1. The core key-value metadata structure.This is exactly what we'd need - a standardized way to store arbitrary data (config, links, descriptions) per Block (Cell). Our current metadata (image, title, link) already fits this pattern, so it could serve as a ready foundation for adding new keys.

2. The "Agent Metadata Profile" (ERC-721T) - the most relevant part. ERC-8048 defines a specific set of keys reserved for putting an AI agent on an NFT: context (a description of the agent), endpoint[mcp] (Model Context Protocol), endpoint[a2a] (Agent-to-Agent), endpoint[web], endpoint[x402](a payment-enabled endpoint - this one matters a lot given our "earning from a Block" concept), and address[chain-id](the agent's address on a given chain - a Robinhood Chain address could go here directly).

3. "Onchain Metadata Contract Reference" - built for contracts that are already deployed.Our Block NFT contract is already deployed on Robinhood Chain and mint is complete - it can't be rewritten or upgraded. On top of that, our current tokenURI(id)function doesn't return static onchain JSON - it returns a URL generated dynamically from our own API. That happens to match exactly the condition this ERC-8048 extension is built for: our current NFT contract itself won't change, but a separate, small "metadata contract" could be deployed and referenced through a single new field in our API's response.

4. The Metadata Authority extension.This lets an account separate from the token's owner manage certain metadata fields. For example: the Block owner manages their own content/agent, while the Pixeldeed team could separately manage fields related to moderation and rule enforcement. This lines up well, from a technical standpoint, with our existing principle of "non-custodial, but still able to moderate."

Limitations and things worth watching

It's a Draft standard.ERC-8048 was published in September 2025 and is still in Draft status. Plenty of Draft EIPs never reach Final status. Rather than committing to "we will follow the ERC-8048 standard," we're watching this Draft and exploring adopting it if it makes sense - no timeline, no guarantee, just a direction we're researching alongside Phase 3 (Program).

There's no execution/hosting layer.ERC-8048 only defines how to store and read data - not who runs an agent or a dApp, or how. Achieving "a Block displays an HTML site" would still require its own separate rendering/hosting logic on our end.

Gas costs get expensive for large data. The right approach would be storing an IPFS/Arweave pointer in the key-value store, rather than large content directly.

An app discovery/marketplace layer would need to be built separately.ERC-8048 is purely a metadata standard at the lower layer - the "app store" experience on top of it is something we'd have to design ourselves.

The idea behind Bitcoin Ordinals - inscribing images, text, or files directly onto a single satoshi - was our original inspiration. But there's a key difference: Ordinals is centered on a permanent, fixed inscription, while Pixeldeed's goal is dynamic, updatable, programmable metadata - a Block owner should be able to swap their content, or whatever app is running on it, at any time. ERC-8048's key-value structure plus its update mechanism (setMetadata) could offer that flexibility - but again, this is a direction we're exploring, not something we've implemented yet.

While the bigger agent/app vision above is still exploratory, a small working example already exists today. Block #11 currently hosts more than a static image - a small game is live there right now: pixeldeed.xyz/?block=11.

It's a modest example, not a finished "app platform" by any means - but it's a real, live illustration of the direction we mean when we talk about a Block being more than a picture frame. Go take a look.

Mint completing means Pixeldeed's "trunk" now exists. All 10,000 Blocks have an owner. The next question is: what grows on these branches?

Draft standards like ERC-8048 point toward a possible path, but walking that path is our own work to do - and we can't yet guarantee how this particular standard will settle in its final form. So we're presenting this as a direction we're researching and exploring in connection with Phase 3 (Program), rather than a commitment we're locking in.

Like a tree: once the trunk is stable, the branches start growing on their own.

The property layer of the onchain internet.