But here's what almost everyone is missing: these surface-level implementations are just the beginning, and they're not even the most transformative part of what's coming.

The Superficial AI Trap

Let's be blunt: most companies are slapping AI onto their products with no real vision. They're scrambling to be "AI-first" without understanding what that means beyond buzzwords.

As most are aware, even X has its own generative AI chatbot.

These implementations are like early mechanical toys – neat demonstrations but limited in actual utility. They're the AI equivalent of putting tailfins on cars: visually impressive but adding little functional value.

Today's AI implementations resemble early mechanical devices – interesting demonstrations, but limited in integration and utility. And just like those early devices, they're a precursor to something far more transformative.

The Power of Memory

AI’s biggest shortcoming today is memory. Systems often forget context, lose track of important details, or simply fail to build on past interactions, with each new session feeling like you have to start from scratch.

Rob, our Principal Engineer, put it best: “The more interesting applications come from a good use of memory. Developing a system that keeps the memory of what worked – and what didn’t – allows AI to create its own rules and improve through trial and error. That’s where real adaptation and scalability come in.”

While everyone focuses on what AI can create right now, the true shift is happening in systems that:

• Remember your preferences across different contexts

• Learn from how you use them and adapt accordingly

• Improve at serving your needs without constant reconfiguration

• React fluidly to change without requiring updates

For example, instead of an AI remembering that your name is Alex and you prefer dark mode – imagine it remembers that you always ask for a summary before diving into details, that you tend to switch gears mid-project, and that you're most productive late at night – and it’s already prepared for that next session before you even show up.

That’s what meaningful memory looks like. But building it? That’s another story.

Let’s Go Under the Hood of AI

What most people don’t realize is that today’s AI memory is more illusion than infrastructure. When you have a conversation with ChatGPT, Claude, or any similar model, here’s what’s really happening:

Every single message you send – along with the entire chat history – is reprocessed every time.

That’s how the system understands context. There’s no persistent memory. No long-term knowledge. And this mechanism has hard limits. For example, GPT-4 Standard might support 8,000 tokens per request (~15-20 pages of text). That includes everything you’ve said before plus your latest input. Once you hit that limit, things get forgotten – cut from the conversation as if they never happened.

For example, GPT-4 Standard supports around 128k tokens for the context window (equivalent to 200 pages of text). That includes everything you’ve said before plus your latest input. 

Close the chat window? That entire context vanishes. Open a new one? You're back to square one. This is why AI feels like déjà vu. You’re always re-teaching, re-prompting, resetting preferences. And as interactions get more complex or span across tools, the cracks start to show.

200 pages of memorized context may sound like a lot, but over the years or following large amounts of context, it’s not nearly enough. “I’ve noticed that the new model seems to very often forget what we were talking about even 2-3 messages above. […]  It’s as if it’s focusing 100% of its attention to my last message and forgets the bigger picture.” And this user wasn’t alone, struggling with managing GPT-4 Turbo’s memory. 

Seen this before on GPT? You’re not alone. This pertains to certain texts GPT tries to keep hold of across conversations, however, even with paid plans, you still run into hard ceilings. Let’s be clear: we’re not talking about a single chat over a few weeks, which can be solved with good prompting. We’re talking about AI that remembers important threads of thought across months or even years.

Why? → Imagine giving your full medical history once, and never having to explain it again. An AI that knows your past symptoms, remembers the patterns, and can tell you why you might be feeling knee pain today – based on what happened last winter. That’s the level of continuity we’re aiming for.

Yes, OpenAI has been working on memory for a while now, having just recently released the ability to reference past conversations. But how scalable is their current solution if, for example, if a chat goes on for years?

Think of it like a human brain – after ten years of conversation, you can’t possibly remember every detail. Some memories fade, some get distorted, and others morph into stories that never actually happened, just because someone told you they did. 

This is the same challenge AI faces: we need systems that can intelligently decide what to remember, what to forget, and what to surface when it matters most. Selective memory isn’t just a convenience – it’s a necessity.

A Solution For Long-Term AI Memory

Through our daily work with AI tools at Patchwork, we quickly noticed this memory gap and the limitations it creates.

We believe the solution lies in a consolidated long-term memory system – a layer that’s maintained across requests and continuously refined. It’s not about sending everything back through the model each time; it’s about having an intelligent system that:

• Compresses what it knows

• Prioritizes what matters

• Remembers what’s useful

• Surfaces relevant context at the right time

This kind of memory-first structure is the key to unlocking true AI behavior at scale. It's what makes systems not just responsive, but proactive – capable of growing and adapting alongside the user. 

The Future Belongs to Systems That Remember

As the industry moves forward, it's clear: memory is the missing ingredient. While many companies are distracted by the glitzy generative capabilities of AI, the true value lies in creating systems that are able to grow, adapt, and learn from past interactions. Not to mention the ethical hurdle of what AI should remember or not.

The question is: Who will lead the way?

But this isn’t just about speed, it’s part of a massive shift behind-the-scenes that has actually happened before. Over a century ago, mechanical engineering underwent the same transformation, making technology invisible. This history doesn’t just explain how we got to where we’re at today, but reveals exactly where we’re headed next.

The Cycle of Innovation: History Repeats Itself

When was the last time you had a conversation about mechanical engineers? It’s been a while, right?

To jog your memory, in the late 1800s, mechanical engineers were the rockstars of innovation. They built the machines that powered the Industrial Revolution, drafted patents, and ultimately transformed daily life. But today, their work is invisible to most people. You drive a car, use appliances, and rely on infrastructure they all built without questioning the engineering behind them.

Software is following the same trajectory, only much faster. What took mechanical engineering a century is happening to software in just a decade. And if we follow the pattern, we can see exactly where we are in the cycle:

1. Specialist Era: Only experts with deep knowledge can participate (early mechanical engineers, first software developers)

2. Standardization Era: Common patterns and components emerge, but expertise is still required (standardized car parts, software libraries)

3. Abstraction Era: Complexity is hidden behind simple interfaces (car dashboards, modern APIs, AI-assisted coding tools)

4. Utility Era: The technology fades into the background and just works (cars, cloud computing, no-code software tools)

The evolution of websites is a perfect case study:

• Stage 1 (Specialist): Early websites required deep knowledge of HTML, server configurations, and networking.

• Stage 2 (Standardization): Common frameworks and templates streamlined the process.

• Stage 3 (Abstraction): User-friendly site builders (WordPress, Wix, Webflow) emerged.

• Stage 4 (Utility): Websites are now an expected, easily accessible utility for businesses and individuals.

According to W3Techs, WordPress now powers 43% of all websites, demonstrating how far the web has moved from manual coding to plug-and-play solutions.

At this pace, we're already in the third era, and with AI advancements, we’re close to approaching the fourth. But what does this mean for the tech industry? And more importantly, how can we prepare for what’s next?

Software Engineering Is Stratifying

"Software engineers in the future will be like mechanical engineers of the past," says Rob, our Principal Engineer. "They’ll still be around, but their work will become increasingly specialized."

Let’s clear up a common misconception: software engineering isn’t disappearing, it’s evolving. And we’re already seeing it break into three distinct layers:

• A small elite will work on foundational, cutting-edge systems (think engineers designing the next-gen hardware chips, operating systems, and decentralized protocols that power everything else).

• Mid-tier specialists will focus on complex applications (fine-tuning fintech platforms, cybersecurity systems, or immersive digital experiences).

• Traditional programming tasks will be automated or simplified to the point of invisibility (think drag-and-drop app builders, automated cloud deployments, and AI copilots writing entire software applications from a simple prompt).

The main takeaway? As we always do as humans, we simply adapt. Just this adaptation will redefine the role of engineers, opening up a lot more doors than we can imagine.

From Implementation to Vision: AI and the Rise of Vibe Coding

For the first time in digital history, the main bottleneck isn’t implementation, it’s vision.

When mechanical engineering became invisible infrastructure, it freed society to focus on using transportation rather than understanding engines. Now, the same is happening with software. Invisible infrastructure refers to technology that is so seamlessly integrated into daily life that users no longer need to think about how it works, it simply functions in the background. The question is shifting from “Can we build it?” to “What should we build?”

This shift is driving the rise of “vibe coding”, the latest development mindset where AI-assisted tools enable rapid product creation over technical perfection. Unlike traditional software development, where teams of junior engineers write code and senior engineers later clean up technical debt, vibe coding bypasses this cycle entirely.

But vibe coding isn’t about cutting corners, it’s about achieving high-quality results without getting lost in unnecessary complexity. AI copilots and low-code platforms allow developers to focus on big-picture creativity, rather than manual coding.

The Gen Z perspective from Klimov, "The Pragmatic Engineer: Gen Z in Tech", reinforces this shift. Younger developers are less interested in infrastructure perfection and more focused on building fast, functional, and meaningful products. By reducing technical barriers, they’re opening the doors for more people to innovate.

How This Shift Is Already Affecting You

Whether you realize it or not, this transformation is already changing the way you interact with technology:

1. Economic Democratization: The cost of creating software is plummeting, opening digital innovation to more people.

2. Reduced Complexity: The overhead of managing technology is disappearing as systems become more seamless and self-managing.

3. Creative Empowerment: The tools for building sophisticated digital products are becoming accessible to non-technical people.

Main Takeaway

The most forward-thinking mechanical engineers of the late 1800s weren’t just submitting patents; they were building the foundation for an era where people wouldn’t need to understand engines at all.

The same shift is happening with software today. The most strategic developers aren’t just focused on writing cleaner code, they’re designing systems that empower anyone to create without needing to code. This isn’t a prediction. It’s already happening.

As Rob puts it, "we’re not building tools for engineers; we’re building tools for future creatives. The technical barrier will be lower. Just like how you don’t need to be a mechanical engineer to work on a car, you won’t need to be a software engineer to work on software.”

Now that we've mapped out the past and present, keep an eye out for more blog posts as we chart the future.

Cover image: Design drawing for Babbage's Difference Engine no. 2, 1847

The root cause? Critical app data often lives offchain. AKA, the metadata that gives assets meaning (who owns what, how it can be used, and how it connects to other systems) is stored in centralized databases, making it hard for others to access, use, or even trust. Think of offchain data storage like saving data onto a private server – it can change, disappear, or become inaccessible. This has turned Web3 into a fragmented landscape of walled gardens.

What if Web3 apps could actually seamlessly connect, extend, and innovate together? By bringing metadata onchain in an effective and standardized way, Patchwork makes all this possible, unlocking a new era of collaborative apps. Let's break this down…

Walled gardens in tech refer to closed ecosystems where data, apps, and user interactions are restricted within a single platform, limiting interoperability with external systems. In Web3, this issue arises when apps store critical metadata offchain, creating a major roadblock when other apps try to access or interact with it.

Metadata is often stored offchain for flexibility and to avoid high data storage costs. For individual projects, this may seem like a reasonable tradeoff. But at scale, it creates:

• Lack of Persistence – Offchain data is subject to link rot, server failures, and reliance on third-party hosting, meaning valuable metadata can disappear or be unreliable. While decentralized storage solutions like IPFS and Arweave improve persistence, they do not enable structured composable data models onchain.

• Fragmentation – Every app structures its metadata differently, forcing developers to rebuild the same foundations instead of simply leveraging shared, interoperable standards.

• Limited Composability – Apps can’t natively reference or extend each other’s data, blocking innovation that could come from developers stacking and remixing existing work.

Consider Decentraland's marketplace: while their virtual assets exist on the blockchain, the trade and auction metadata lives offchain, accessible only through their specific UI. This isn't just a technical detail – it's a fundamental limitation that prevents true ecosystem integration. Other platforms can't programmatically interact with or build upon this marketplace, limiting innovation to single-platform implementations.

In DeFi, the problem is even more acute. Lending protocols can't access standardized cross-platform reputation data, forcing each to build isolated risk models. A user's excellent track record on one protocol means nothing on another – it's like having to rebuild your professional reputation from zero every time you change employers.

This isn’t just an inconvenience, it’s preventing Web3 from reaching its full potential. The most powerful breakthroughs in tech happen when builders can build on top of each other’s work. Web2 unlocked this with APIs. Now, Web3 has the chance to go even further if the app metadata is structured onchain in a way that enables efficient discoverability and composability.

Standardized onchain metadata storage is crucial for enabling apps to interact and build upon each other effectively. This foundation creates:

• True Interoperability – Apps can natively access each others’ data instead of duplicating efforts.

• Persistent Data – No reliance on centralized servers that can disappear or change data.

• Stackable Innovation – Developers can compose new apps by leveraging existing onchain records, similar to how DeFi apps stack protocols like Legos.

Instead of fragmented, isolated systems, a shared standard allows apps to become part of a collaborative, ever-expanding ecosystem where every new development strengthens the network rather than creating yet another walled garden.

Patchwork makes this possible by providing standardized, queryable metadata schemas that any app can use, ensuring seamless data sharing and interoperability, as well as efficiency for low storage costs.

More than just a schema, Patchwork’s Protocol actively orchestrates onchain relationships so metadata isn’t just stored, it’s meaningfully connected across apps. To make integration effortless, the Patchwork Developer Kit (PDK) and Patchwork Wizard equip developers with ready-to-use tooling, eliminating the need to build custom infrastructure from scratch. And now with text-to-config, we're making it possible for anyone to go from idea to working onchain app in minutes, not months.

All this to say, by building with Patchwork, you can focus on the true purpose of your app rather than spending months building out the data structure of a siloed app – enabling a new era of smarter, more scalable, and collaborative innovations.

The time for storing important metadata offchain and building walled garden apps is over. The future of Web3 development is here, and it's faster, more accessible, and more powerful than ever before.

Patchwork is leading the way by not only providing the essential framework that developers need to build rich onchain apps, but also the tools for any creative to build their own app, further driving a vibrant, interconnected Web3 space. 

Stop building in isolation. Start building with Patchwork today.

But a powerful protocol alone isn’t enough. If we want to see a world where rich, dynamic applications exist fully onchain, we have to make the building process seamless. That’s why we built create-patchwork, and today, we’re taking things a step further with text-to-config, an important milestone release on our roadmap to deploying a full no-code development kit. 

Building an onchain application isn’t just about writing smart contracts. You need indexers, APIs, deploy scripts, frontends, and a way to manage your data. That’s a lot.

create-patchwork takes care of all of that for you.

• It’s a full-stack scaffold for Patchwork-based apps.

• It automates indexers, APIs, deploy scripts, React hooks, and databases.

• With just a simple project config, you get a fully deployed app on a local testnet—in under two minutes.

If you’re a dev, this means you can go from idea to working onchain app faster than ever before. No boilerplate. No wrestling with infra. Just your app, working, now.

Today, we’re launching text-to-config, a feature that takes create-patchwork and unlocks its potential through a plain language user interface, with little-to-no code required. 

Here’s how it works:

1. Describe your app in plain English. No need to write a config file by hand.

2. text-to-config generates a ready-to-go project configuration.

3. Run create-patchwork, and boom—your app is deployed.

It’s a step toward a no-code future for onchain app development. We see text-to-config as the 80% automation milestone: the point where developers don’t have to think about config files anymore. And later this year, we’re aiming for full text-to-app functionality—where you can describe your idea in natural language and get an entire working onchain app without touching code.

Our goal with Patchwork has always been to remove the gap between developers and creators. Here’s the roadmap:

1. Build a maximally useful protocol for dynamic onchain apps. (Patchwork)

2. Make it low-code. (create-patchwork)

3. Make it no-code. (text-to-config, and later, text-to-app)

text-to-config is a critical step in this journey. By making onchain application development more accessible, we’re opening the doors for a new wave of builders—whether they’re smart contract developers, product designers, or creators with big ideas and no Solidity experience.

Onchain apps should be as easy to create as websites. We’re building toward that future, and text-to-config is just the beginning.

Want to try it? Get started with create-patchwork today or catch us at EthDenver next week where Patchwork Principal Engineer, Rob Green, will be opening the conference on Thursday morning with a brief overview and learning session on low-code development. For more visit ed.patchwork.dev 

Patchwork: Code Less, Build More; Web3 Apps. Fast.

Our first batch of builders gave us the feedback that while config driven smart contract generation was useful, there is still a time consuming long-tail of services, tools, and deployment infrastructure needed on launch onchain application.

Every create-patchwork project includes:

• Smart Contracts: Patchwork-compatible contracts with your defined data models

• Contract Deployment: Preconfigured create2 deployers for deterministic addresses

• Data Infrastructure:

  • Ponder configuration for event indexing

  • Database schemas for persistent storage

  • Event handlers for processing onchain activity

• API Layer:

  • tRPC endpoints for type-safe API access

  • Event hooks for real-time updates

• Frontend Utilities:

  • React hooks for contract interaction

  • Type safe API integration

DevOps:

• Docker configuration for service orchestration

• Local development environment with anvil

Create-patchwork requires Foundry's forge to be installed. Once you have forge, starting a new project is as simple as running:

pnpm create patchwork

Alternatively, head over to the Patchwork Wizard to design your application's entities, data model, and relationships and generate your custom application with your exported config:

pnpm create patchwork patchwork.config.ts

From your new project's root, you can deploy and run everything simply by doing:

and shut it down by doing:

PDK is smart enough to understand which generators need to be run again as you start making changes in the codebase, or when you switch networks.

With create-patchwork, developing using Patchwork is currently medium-to-low code. All of our codegen is procedural and configuration-driven which gives us two advantages:

1. We can produce much higher quality and predictable output than wild west LLMs

2. We can easily train models to understand and build Patchwork configuration files, which opens a path where you tell an agent what you want to build and you'll get generated contracts in seconds

As we continue to build out capabilities in our generators and greater tooling suite, we see a clear path from low-code to no-code text-to-app. Watch this space.

—

Keen to follow along and build with us? Join our Discord.

Mint as many as you'd like for free at https://elephants.fun/. Using a smart wallet? Nice, so are we. And thanks to the Base Paymaster, we'll even cover the gas for you.

If you already have an elephant, you can swap out attributes to get in the onchain summer spirit. Or build a brand new one from your freshly minted attributes.

Just like when we launched our previous freebie pack, Patchwork made extending an existing project brain dead simple.

//Add onchain summer attributes contract to elephants scope
patchworkProtocol.addWhitelist("elephants", address(summerAtty));
//Register contract as assignable to the elephant contract
elephant.registerReferenceAddress(address(summerAtty))
//Turn on free minting
patchworkProtocol.setMintConfiguration(address(summerAtty), IPatchworkProtocol.MintConfig(0 gwei, true));
//Jump in the pool

Did you make an elephant that you are particularly proud or ashamed of? Hop into our Discord and show it off.

Ploinking is powered by $ploink points. Each reaction costs a certain amount of $ploink, which Farcaster users accrue by ❶ minting reactions with Ploink, ❷ casting content that other users react to, and ❸ creating sticker packs that people use in their reactions.

Under the hood, Ploink uses Patchwork to mint reactions and assign those reaction records to NFT representations of each Farcaster cast being reacted to. Pretty neat.

1. Install the Ploink cast action: Add the Ploink cast action to Warpcast and select the React with Ploink! action on the cast you wanna react to.

   Install the Ploink cast action!

   If you don't want to install the cast action, you can always reply to a cast with @ploink and our bot will reply with a frame for you to use. Lizard brain way to do it but it works.

2. Choose your reaction:

   • Enter an emoji: Pick an emoji to represent your reaction (literally type an emoji into the frame's text input like 🤯). We've got a default sticker pack with around 3,000 of the most common emojis, but eventually others will add their own sticker packs and you'll be able to type in things like dogface400 or whatever they name their stickers. Our default emoji stickers all cost 10 $ploink to use, but sticker creators can price them however they want.

   • Choose how many stickers you wanna attach: Set it to more than 1 to make your reaction pop (and also the $ploink cost).

   • Sign the transaction: Sign the transaction to mint your reaction on Base.

   • Check your wallet: It should now contain a freshly-minted onchain cast reaction.

When you react to something the $ploink is distributed as follows:

• 10% to sticker pack creator: Good job for making the sticker.

• 50% to the OG of the content: Good job for making the cast.

• 40% burnt: Sent off to the void. We aren't really sure why.

We seeded $ploink to all Farcaster users using a very advanced mathematical formula: The number of times you've liked something on Farcaster * 100, with a floor of 500 and a max of 10,000.

• Use Ploink!: The best way to get more $ploink is to actively use it. 50% of every reaction cost is rewarded back to the reactor's main balance daily. Additionally, 100% of the reaction cost is sent to a reactor's temporary bonus balance (over the course of 2 days) which is spendable for seven days before it vanishes. Spends from the bonus balance still get 50% rebated to the main balance daily, allowing you to accumulate $ploink by minting reactions daily.

• Post good (or bad?) content: Share content on Farcaster that gets reacted to and watch your $ploink stack grow.

• Create deranged sticker packs: The more your sticker packs get used, the more $ploink you get.

• Beg the Ploink bot: If you can't manage any of the above, you can always beg the Ploink bot (using @ploink beg) and it's possible someone will take pity on your soul.

• Follow the /ploink channel: +100 $ploink.

• Follow the /patchwork channel: +100 $ploink.

• Follow @patchwork on Farcaster

• Join our discord and post your FID in the #ploink-boost channel: +100 $ploink.

• Sticker publishing tools, templates, and guides 🤯

• Ways to augment your own cast replies or quote casts with reactions, rather than having them be separate and from our bot 🧐

• More sticker packs

• Leaderboards

• UI on ploink.fun to get a full look at the chaos

• A whole lot of other stuff... 👀

Interested in creating a sticker pack for Ploink? We're building sticker publishing tools to make this super easy, but we need some guinea pigs to help us out. For now, join our Discord and let us know you're interested in creating a pack!

To address this, we deployed a new freebie trait contract with a special mintBatch function that mints you exactly one Background, Base, Eyes, and Mouth from a new set of trait visuals. This new contract lives right alongside the existing one for our premium traits, and both interact with the Elephants contract and app in the exact same way. Be warned: these freebies are very boring and you'll want to swap them out to cheer up your sad mammal, but this should get you started.

Extending Elephants and configuring this onchain via Patchwork required just 3 calls:

//Add new starter contract to elephants scope
patchworkProtocol.addWhitelist("elephants", address(traitStarter));
//Register new trait contract as assignable to the elephant contract
elephant.registerReferenceAddress(address(traitStarter))
//Turn on minting, with a fee of 0
patchworkProtocol.setMintConfiguration(address(traitStarter), IPatchworkProtocol.MintConfig(0 gwei, true));

This was a trivial amount of work to extend an existing collection with traits from an entirely new contract, and it's easy to see how fun this could get. As scope owners, we could whitelist community trait packs, or special trait contracts for events or partnerships. Or, we could turn the scope owner into a DAO and let the community decide. Trait contracts could themselves have their own quirky rules and logic, but compose nicely with the main Elephants contract. And if it turns out people don't like the Elephants contract, they could fork it and make any of these traits assignable to their own contract.

Give it a shot and show us what you come up with! Mint your free starter pack at mint.fun on or Elephants.fun. And if you're building a project of your own that can benefit from the composability and extendability Patchwork provides, jump in our Discord and noodle with us.

Let’s take a look at the contract configuration JSON files:

Elephant.json

{
   "scopeName": "elephants",
   "name": "Elephants",
   "symbol": "ELEPHANT",
   "schemaURI": "https://elephants.fun/schemas/elephant.json",
   "imageURI": "https://elephants.fun/assets/elephant/{tokenID}",
   "fields": [
       {
           "id": 1,
           "key": "attributeLiteRefs",
           "type": "literef",
           "description": "The attributes equipped by this elephant",
           "arrayLength": 8
       },
       {
           "id": 2,
           "key": "name",
           "type": "char32",
           "description": "Name"
       }
   ]
}

Attribute.json

{
   "scopeName": "elephants",
   "name": "Elephants: Attributes",
   "symbol": "ATTRIBUTE",
   "schemaURI": "https://elephants.fun/schemas/attribute.json",
   "imageURI": "https://elephants.fun/assets/attribute/{tokenID}",
   “features”: [“fragmentsingle”, “mintable”],
   "fields": [
       {
           "id": 1,
           "key": "attributeType",
           "type": "uint8",
           "description": "The attribute type (enum)"
       },
       {
           "id": 2,
           "key": "attributeId",
           "type": "uint16",
           "description": "The attribute ID (enum)"
       },
       {
           "id": 3,
           "key": "tier",
           "type": "uint8",
           "description": "Tier"
       },
       {
           "id": 4,
           "key": "name",
           "type": "char16",
           "description": "Name"
       }
   ]
}

The configurations define two entities: “Attribute”, which has a type enum (reconciled to uint8), ID, tier, and name, and “Elephant”, with a name and 8 slots for attributes. We can create our Patchwork contracts with PDK by running:

pdk generate Elephant.json
pdk generate Attribute.json

Just like that, you have the majority of your application structure written for you. Let’s check out some of the highlights.

Byte packed metadata

function packMetadata(Metadata memory data) public pure returns (uint256[] memory slots) {
    slots = new uint256[](1);
    slots[0] = uint256(data.attributeType)
        | uint256(data.attributeId) << 8
        | uint256(data.tier) << 24
        | PatchworkUtils.strToUint256(data.name) >> 128 << 32;
    return slots;
}

PDK worked out the most efficient way to byte pack your metadata fields in as few storage slots as possible. It also wrote efficient getters and setters that allows for writing multiple fields in a single write.

While the EVM will pack structs into individual slots, access isn’t always optimal. Explicit packing and access gives the benefit of being able to write to and update multiple fields with a single SLOAD/SSTORE, resulting in onchain gas savings. All schema fields are also described in the generated schema function:

function schema() external pure override returns (MetadataSchema memory) {
    MetadataSchemaEntry[] memory entries = new MetadataSchemaEntry[](4);
    entries[0] = MetadataSchemaEntry(0, 0, FieldType.UINT8, 1, FieldVisibility.PUBLIC, 0, 0, "attributeType");
    entries[1] = MetadataSchemaEntry(1, 1, FieldType.UINT16, 1, FieldVisibility.PUBLIC, 0, 8, "attributeId");
    entries[2] = MetadataSchemaEntry(2, 2, FieldType.UINT8, 1, FieldVisibility.PUBLIC, 0, 24, "tier");
    entries[3] = MetadataSchemaEntry(3, 3, FieldType.CHAR16, 1, FieldVisibility.PUBLIC, 0, 32, "name");
    return MetadataSchema(1, entries);
}

This schema functions allows for apps to discover what data is available onchain and access it via conventional ABI or by reading one or all of the storage slots and decoding according to this description.

EIP-4906

event MetadataUpdate(uint256 indexed _tokenId);
event BatchMetadataUpdate(uint256 indexed fromTokenId, uint256 indexed toTokenId);

When metadata changes, 4906-compliant events will allow for indexers and marketplaces to invalidate their cache and pull the latest metadata.

Data integrity

The ownership model used for Elephants is a Single-Assignable Fragment with inherited ownership. This is specified by using the feature fragmentsingle in the contract configuration. The default logic built will allow for an Attribute to be minted and owned by a user and then assigned to an Elephant. Once assigned to the Elephant, the Attribute will report the owner of the Elephant as the Attribute owner. This makes the Attributes travel with the Elephant when it's is transferred.

Data integrity is maintained in unison by the contracts and Patchwork Protocol. The protocol checks both the assignee and assignable for permissions and integrity as well as internal data on assignment and unassignment.

Patchwork 721s use ERC-5192 to emit lock-related events and handle queries.

event Locked(uint256 indexed tokenId);
event Unlocked(uint256 indexed tokenId);
function locked(uint256 tokenId) external view returns (bool);

The default behavior for a Single-Assignable Fragment is to implicitly lock when assigned. A locked 721 cannot be transferred, so once the attributes are assigned to the Elephant, data integrity, ownership and transfers are all handled correctly.

Assigning Attribute fragments

In our Elephants contract, we wrote one small piece of application logic for creating Elephants, which we call forging. This function does some simple validation (you own the Attributes, you've included one of each of the required Attribute types, etc.) and mints the Elephant for you.

    function forge(address[] calldata attributeAddresses, uint256[] calldata tokenIds) public returns (uint256) {
        require(
            attributeAddresses.length == tokenIds.length, "Attribute addresses and token Ids must be the same length"
        );

        address owner_ = msg.sender;

        // Mint the elephant token
        uint256 newTokenId = _nextTokenId;
        _safeMint(owner_, newTokenId);
        _metadataStorage[newTokenId] = new uint256[](3);
        _nextTokenId++;

        // Check first to save gas on revert
        _checkRules(owner_, attributeAddresses, tokenIds);

        IPatchworkProtocol(_manager).assignBatch(attributeAddresses, tokenIds, address(this), newTokenId);
        // Emit a forge event that the node can watch for and generate art without waiting
        emit Forge(owner_, newTokenId, attributeAddresses, tokenIds);

        // Return address of and token Id of elephant
        return newTokenId;
    } 

The real magic happens in the call to Patchwork's assignBatch method that updates the assignments & ownership of the Attribute fragments. This has the following implications:

• Calling ownerOf() on the assigned Attribute will now return the ownerOf the Elephant token

• These attributes are locked and cannot be transferred until they are unassigned

• Transferring the Elephant will automatically update the owner of all assigned Attributes to be the new Elephant owner. In Patchwork since ownerOf is proxied to the assignee owner, we can do this cheaply without actually needing to do an onchain transfer. Patchwork does however still emit cheap transfer logs so that block explorers and indexers are aware of this ownership change

We also have additional utility functions for editing and Elephant (lets users swap out attributes and add new ones to empty slots) and decomposing an Elephant (which burns the Elephant after unassigning all its fragments and makes them transferable & assignable again). You can check all those out in our verified source code on Basescan.

Extending the application

An Elephant has 8 static slots for attributes but the schema does not specifically define which contract the attributes must be. This is because the deployed contract may dynamically determine this via register calls made by the contract owner. When we deployed Elephants and Attributes, we registered the Attribute contract as a fragment for Elephants. We designed Attributes to give us a number of controls for expansion, however we may not have thought of everything we wanted to do in the future. Should we need a new attribute contract, we can deploy it and register the new attribute contract with Elephant, allowing entirely new functionality or graphics that we hadn’t previously designed.

Listening for events

Since Elephants are dynamic, we need to constantly listen for events emitted by the Elephants contract—namely Forge, Change, and Burn—so we can generate images and update the offchain metadata used by OpenSea et al. Here are the emitters from Elephant.sol:

emit Forge(owner_, newTokenId, attributeAddresses, tokenIds);
emit Change(owner, tokenId, attrAddresses, attrTokenIds);
emit Burn(ownerOf(tokenId), tokenId);

And here's a basic event listener using ethers, where elephantContract is an ethers contract instance in our cryptoService class. This watches for the Change event from our contract and calls the relevant functions that handle metadata and image generation.

this.cryptoService.elephantContract
.on('Change', async (owner, tokenId, attributeAddresses, tokenIds) => {
    console.log(`Change event received. owner: ${owner}, tokenId: ${tokenId}, attributeAddresses: ${attributeAddresses}, tokenId: ${tokenIds}`);
    // Call our metadata service to delete old json and create new json file
    ...
    // Call our image service to delete old image and create new svg image
    ...
})

For basic projects, you'll be able to listen directly to the protocol's assign and unassign events and watch for transfers to & from the null address to get the info you need. Since we're doing a lot of batch operations, we're emitting our own specialized events to make things easier.

Generating images in realtime

Generated Elephants images are just a stack of concatenated SVG elements composed from our Attribute SVGs. When we see a Forge or Change event come through, we iterate over the Elephant's array of assigned attributes, grab the attribute's corresponding raw SVG, layer it on top of the previous attribute, and rinse-&-repeat until all the attributes have been layered in.

If your SVGs were simple and compact enough (e.g. pixel art), you could easily store your image data and do this composition logic onchain.

Mint some attributes at elephants.fun or on mint.fun. Build your Elephant and join us in Discord to share what you've made!

Patchwork aims to open a new frontier of data-richness for the EVM, where secondary markets can spring up for the exchange of valuable data records, creators can seamlessly and permissionlessly extend existing onchain IP with their own fresh data, users can swap traits and attributes with their peers, projects can collaborate on and share core pools of data, and creators can continually add to and grow the flavors of data available to their users.

Patchwork—built by five Coinbase alums with early backing from IDEO CoLab Ventures and Coinbase Ventures' Base Ecosystem Fund—is a complete re-think of how we build and interact in the new internet, empowering tokens, contracts, and addresses with rich, interactive, and interconnected layers of vibrant onchain data.

Patchwork works by extending ERC721 with a standardized onchain metadata format and data interaction utilities, effectively turning NFT contracts into database tables where each token represents a row of data. Multiple contracts can be hooked together to create rich datasets with complex relationships between them.

Additionally, individual pieces of data from a token can be further encapsulated as a separate NFT altogether, allowing for added secondary utility where granular bits can be traded, pooled, loaned, and all the other NFT verbs. Schemas and datasets are dynamic and mutable, ensuring projects can continually grow and adapt their onchain IP.

Patchwork also introduces the ability to permissionlessly soulbind—or “Patch”—these datasets to other existing onchain entities. Any developer can annotate and extend the onchain world with their own vibrant data, and anyone else can do the same to that developer’s data.

• Fully onchain data that can be interacted with by any smart contract

• Data is efficiently packed to ensure a low gas footprint, and standardized to maximize interoperability between Patchwork apps

• Data lives in ERC-721s that have been extended with Patchwork interfaces; data schemas/"columns" and getters/setters live in the contract, and each "row" of data lives in a token

• Granular pieces of data can be discretely encapsulated in their own tokens, allowing for fully-dynamic NFT traits, shared core data pools between projects, etc.

• Data can be permissionlessly soulbound to existing onchain entities, allowing anyone to annotate and extend their favorite projects with their own unique datasets

• Multiple ownership models that let you dictate nuanced relationships between data, contracts, and users

• Fully-audited smart contract extensions + Patchwork Development Kit codegen makes it easy to start building

• Data orchestration handled by Patchwork Protocol to ensure the integrity of your data and adherence to your app rules when that data is interacted with by others

• Much, much more!

Patchwork includes several important parts that work in tandem to allow developers to quickly build rich onchain applications.

The future is onchain, metadata should live onchain too. Currently this is rarely the case, and when it is the case, the lack of standardization hurts composability. The Patchwork Metadata Standard makes it easy to read and write gas-efficient onchain metadata that other contracts can consume and interact with. This is generated for developers for free by the Patchwork Development Kit (PDK).

Patchwork provides a number of Patchwork-flavored ERC-721 extensions that bake in archetypes for different modalities of Patchwork data and entity relationships. These extensions, especially when used with PDK, make it straightforward to build a wide variety of use cases with varied data lifecycles.

Onchain entity relationships can be 1:N, N:1, or 1:1. Additionally, entity ownership can be defined as strong (ownership gets transferred when the parent gets transferred), weak (an entity references another with no ownership implications), or soulbound (an attached entity is not transferable). Additionally, Patchwork provides a permission system that sits on top and allows publishers to define rules for what is allowed to attach to or mutate state within their application.

The protocol orchestrates all of the above, providing a secure and robust foundation for developers to enforce application-specific rules and interactions within the Patchwork ecosystem. It facilitates the dynamic and programmable nature of Patchwork's onchain metadata, enabling entities to evolve and adapt over time.

We have a few exciting things live today:

Patchwork is live on Base at 0x00000000001616E65bb9FdA42dFBb7155406549b.

One of the key advantages of a rule-based protocol like Patchwork is that it allows us to create low/no-code tooling. Our PDK is a CLI tool for developers that allows you to specify your application entities, metadata fields, permissions, and rules in simple JSON, then generates your Patchwork-powered smart contracts.

Enhance your projects with our open-sourced interfaces, designed for building Patchwork-compatible projects that manage metadata hierarchies and ownership efficiently. Using PDK? You’ll get these for free.

See one of Patchwork’s ownership models at work. Mint and collect attributes, then assign them to an Elephant to equip. When assigned, they can’t be transferred and ownership is proxied to the owner of the Elephant. When the Elephant is transferred, the entire ownership tree is transferred as well.

Celebrate Patchwork's launch by minting your own commemorative Bubble. You can own and transfer your Bubble, but it remains irreversibly assigned to the Canvas. Have an idea for what the next Canvas should be? Reach out!

Take a look at our documentation and join us on Discord. First and foremost, Patchwork was built for developers, so please reach out if you have questions or need help getting started. We can’t wait to build onchain with you.

— patchwork.dev

Join our Discord and start building with us!

The new internet is being held back by its silos. All the rich context and meta-information we associate with blockchains and their communities lives far beyond the reach of the EVM. Metadata is often offchain and non-programmable, lying in state in JSON files, buried on centralized servers all destined to be unplugged. Projects themselves exist in isolation, shut off from the dynamic world of creators, remixers, and builders that occupy the block space.

Emergent metadata standards only help so much, providing important upgrades to the Swiss army knives our backends and frontends rely upon but still leaving smart contracts in the dark.

Meanwhile, context rules the vibrant internet around us. Knowledge graphs, recommendation engines, social networks, loyalty programs, ad platforms— all fueled by contextual richness, sparked by the ability to annotate and thread new lines between the billions of patches in the internet's quilt. Any individual can help tip the scale, can help draw a bigger picture, can add new colors to the collective palette just by their participation.

The onchain future needs that same contextual-richness, that same web of relationships, that same ability to have layers of meta-information actively shaped by its audience. Anything less is anachronistic to the internet of today.

We want to set the new internet ablaze with that philosophy and all the utility it offers. We want to bring metadata to the metaverse.

Onchain data for the new internet

This is why we're building Patchwork, a new protocol and set of standards designed to supercharge onchain entities new & old with fully onchain data.

It's a toolbox of verbs—Create, Attest, Contextualize, Remix, Extend, Collaborate, Evolve—for developers and non-developers alike to jam on anything that lives onchain, without permission. It aims to open a new frontier of data-richness for the EVM, where secondary markets can spring up for the exchange of valuable data records, creators can seamlessly and permissionlessly extend existing onchain IP with fresh metadata, users can swap traits and attributes with their peers, projects can collaborate on and share core pools of data, and creators can continually add to and grow the flavors of data available to their users.

Stay tuned

Patchwork is a complete re-think of how we build and interact in the new internet, empowering tokens, contracts, and addresses with rich, interactive, and interconnected layers of vibrant onchain data. Get ready to Patch, coming soon to Base.

— patchwork.dev

Interested in building on Patchwork? Join our Discord.