Results & learnings from the Tableland Pilot Program — a collaborative, funded experience for web3 builders.

@Dan Buchholz | @September 10, 2022

Before reading, check out each team’s final product demos here! And if you’re interested in the second iteration of the Pilot Program, apply here.

The Tableland Pilot Program was a 7 week program launched during Season 4 (the season ran from June 6 to October 12) and featured a number of builders. From established organizations testing out a web3-native relational model to solo developers building on the Tableland protocol — all in all, it was a great experience. As this was its first instance, it was Pilot Program 001, or PP001, for short. The primary focus was to find developers that are excited about web3 and have a clear cut idea of what they want to build. For those familiar with the Tableland Rigs NFT, this aligns clearly with its goal: to be a developer-first NFT. And for the community members who are Rig holders, there were also Snapshot votes for their favorite projects.

The idea behind the Pilot Program is to bring builders into the Tableland community or help those who are already part of it. It involved a rather straightforward application process; simply, fill out a form, and the Tableland core team conducted a final interview for those who made it past the initial screening. Around a week later, the program kicked off with a final subset of teams and was modeled after a pseudo-hackathon-accelerator program.

Tableland is a protocol for web3-native relational data; it’s a permissionless, collaborative database. As such, the structure of PP001 followed a similar design, and this how the core Tableland team operates, in general. Melvin Conway would be proud. Teams were provided direct access to the Tableland team in a group Discord channel and dedicated Notion space — both of which were openly readable and comment-able by anyone in the program.

Additionally, weekly red/green standups (for personal / work roundtable sentiment) were held. One component of this was discussion about what everyone was building, and over time, each team demoed their products to the broader group. This openness allowed teams to be collaborative, from helping each other troubleshoot various code-related questions / issues to simply getting to know one another. From a deliverable perspective, there were two primary requirements: an initial concept proposal / video walkthrough, and final product overview / video demo. Otherwise, the Tableland core team was always there for support, but the goal was to let developers move at their own pace and just build. At various intervals during PP001, there were Snapshot votes held that allowed teams to showcase their projects to the Rigs holders community, who then voted on their favorite projects — and the top projects received additional bounty funding.

Since PP001 was, well, the first program, there were a number of small tweaks throughout. The collaboration and ideas brought forth by the teams was highly valuable and shaped PP001 mid-flight (pun intended) as well as future iterations of the program. Aside from the actual program, the teams had invaluable feedback for product gaps and features, which quickly triggered the core team into action. Overall, it was a tremendous group — smart, thoughtful, collaborative, and just good people.

There were two primary tracks: “Developer” and “Partner” (which is being renamed to “growth” in PP02). For the developer track, these were small teams that may have had some established product, like a DAO or a WIP project, but there was no requirement for what they had to build, besides the fact it did need to use Tableland. Some chose to add Tableland to their existing product, and others chose to create something entirely new and unrelated.

Note that the first two projects listed — metabadge and Chain Runners derivative (”Extension Runners”) — were the winners of both the first and second snapshot votes.

One of the more established projects was metabadge. It’s a Soulbound Token (”SBT”) protocol (with a nice UI generator) that also offers tangential SBT products that are geared for flexibility; their product allows anyone to easily create SBTs. The gist of SBTs is that they’re non-transferrable. If you were to earn some credential, like a skill accreditation for Solidity programming, this skill cannot be transferred to someone else. However, if you were to mint an NFT that corresponds to some accredited skill or participation, the default feature of NFTs is that they can be transferred. If you buy an NFT on some marketplace, that act is, quite literally, transferring ownership.

The goal of metabadge is to create SBTs (and less restrictive versions thereof) to help ensure skills and related SBT use cases are easily enabled. A protocol for issuing non-transferrable tokens. The metabadge app allows SBT issuers to add web3-native metadata for each badge (such as a score, an expiration date, a name, etc.). Namely, there are deployed badge contracts and a frontend plus off-chain infrastructure, which enables this capability, and each Badgeset has its own Tableland table associated with it so that the issuer can configure unique attributes in the table.

This was all made possible and deployed using Tableland’s smart contracts on Polygon, and future versions of the product will likely include “choose your chain” functionality (Ethereum mainnet, Optimism, etc.).

Check out the final deliverable & demo: here.

Chain Runners is a popular NFT project, and it has an extremely active community of builders. The Chain Runners loves to build derivatives of the NFT itself, but it’s difficult to discover everyone’s creations and links them together. When datadanne — a Chain Runners community member — discovered Tableland, there was an immediate realization that a web3-native relational database could truly benefit the Chain Runners ecosystem.

Thus, Extension Runners was born: turning an existing NFT (Chain Runners) into a dynamic NFT where you can pick and choose which of your NFT's traits are displayed. Holders of the original Runners can claim the extensions, which cannot be sold nor traded since they’re designed to be a utility token for existing owners. In other words, an extension is bound to the original NFT, so if an owner sells the original, the extension comes along with it.

Note that utility means owners can add mutability to the traits displayed on their NFT. That is, Tableland powered the trait mutability. In order to toggle a Chain Runner trait, an on-chain function call was made to the Tableland registry smart contract to mutate an offchain table (in the Tableland network). Plus, a nice UI made it easy to toggle the traits themselves, which allowed the Runner to have these applied / saved after writing the data to Tableland.

Check out the final deliverable & demo: here

Zettel’s goal is to bridge web2 data to web3 to enable composability. There is a major inefficiency that has become apparent in the flourishing of a web2 internet — it is difficult to manage state across each and every application. A Tweet saved here, a browser bookmark of article there, some note in Notion somewhere, but the information is siloed and makes it extremely difficult to stay organized.

With Zettel, it enables web2 data to become composable. You can even try out their app here: https://app.zettel.ai/.

It can also be viewed from the lens of a de-platformed personal information management (PIM) system that separates data from individual apps, so they can be easily shared and used across different applications. Under the hood, Zettel used Tableland to create a composable, web3-native API. This allows developers to focusing on building experiences while the frontend calls the API for easy composability across applications — all using this decentralized API model.

Check out the product demo (here), their docs (here), or even test it out the Zettel frontend “terminal” yourself (here).

The Rebel application is launching soon, which offers a ton of cool web3 features that includes NFT collection management. The developers behind Rebel built a novel, open source use case using Tableland. The builder — Michael Boyle — created a called Non-Fungible Comments (”NFCs”) with the idea that comments should be composable. In a similar thought process with Zettel, comments are siloed in each web2 app. A comment on some frontend in one doesn’t translate to the other, which is leaky information.

With NFCs, the comments are composable. But, rather than writing comment to on-chain storage variable, the comments themselves use Tableland, which writes them to the Tableland network of tables. This allows NFT holders to discuss items in a collection in a nested commenting format and also token-gate the ability to comment on items such that only holders of a given NFT could contribute comments. A spam protection guard. All of this was made possible using Tableland contracts deployed on Optimism:

In the future, there are plans to potentially use Tableland elsewhere, but in the meantime, be sure to check out the Rebel app (here) and the NFCs demo (here).

Gaming is one of the best composability use cases out there. One asset should be able to exist in another. A huge benefit of a web3-native gaming protocol like DOPE WARS is to be able to use an existing set assets and tools to help lower the friction of game creation. They offer a number of products, and their games revolve around the Grand Theft Auto and an OG videogame Drugwars. Here’s a view into their existing ecosystem:

For the pilot program, facesOf.eth was the primary developer (who is also involved in Rebel). The goal was to create a familiar game for the DOPE WARS ecosystem called PAPER, Rock, Scissors. Note that PAPER is a bit of a play on words since DOPE WARS does have its own utility $PAPER token. The idea was to allow users to play and wager in a game of skill of the classic rock, paper, scissors game:

Check out the DOPE WARS ecosystem (here) and an overview of PRS (here).

For the partner track, these companies were adding Tableland to various products, which was more about converting their traditional database usage to Tableland. A web2 to web3 porting process.

SURREAL is metaverse experience builder. They have created a number awesome experiences, and during the pilot program, they used Tableland as part of an in-game avatars minting process. Each Avatar is tokenized as an ERC721 token and deployed on Polygon; the avatar’s metadata was deployed to Tableland. Thus, upon connecting a wallet (optional for web2-only players), the avatars owned by that wallet appear in-game.

In particular, the Avatar NFTs generated were dynamic in nature. Users modify the avatar on the SURREAL platform, and saving the updated were reflected in the metadata stored on Tableland. Here are some awesome in-game screenshots of what’s possible with Tableland where users can customize the Avatar NFT and save its attributes to Tableland.

As an experienced web3 agency, dapphaus set out to use Tableland in their web3 Decentraland game: Dim Sum Heroes. It’s a Decentraland experience where users take turns matching tiles and earning points on a large shared game board. The gameplay is similar to the Match-3 type games and the points earned by the players are persistent, and stored on traditional database architecture (SQL). These points may be later redeemed for Decentraland wearable NFTs.

Their goal was to translate and serve the SQL portions from Tableland, and since many of our gameplay and accounting operations are traditional SQL, it made for an easy transition. Check out a screenshot of the game itself, where upon finishing the matching game, the Tableland-stored leaderboard is updated. A globally, interoperable game state / leaderboard!

This was just the first of many Pilot Programs. Each and every team learned about Tableland, got up to speed on how to use it, and built real applications in just under two months! For those interested in following suit, check out the second Pilot Program (PP002) and apply!: here