Tableland is launching Pilot Program 3, a launchpad that supports builders with microgrants and support.
Announcing Pilot Program 3
Calling all builders looking to prototype & integrate the Tableland protocol into their tech stack.
By @Dan Buchholz
We’re excited to announce that Pilot Program 3 is kicking off on January 23rd! Applications are currently open, and the Tableland team will review, screen, and select teams over the next month or so. So, what exactly is the pilot program, and how does this all work?
For a great overview on why we launched the program and how it’s evolved, check out the blog post: here.
Who should apply?
The possibilities are endless! If you’re looking for an alternative to expensive, difficult to query on-chain data or a web3-native SQL database, then apply! Some key use cases:
- Gaming ⇒ For gaming developers, many have had to use centralized databases to function. Existing web3-native solutions are not performant enough for the end user experience, and it’s also impossible to store certain images / files on-chain.
- NFTs ⇒ Static PFPs or gaming assets are inherently limited. Dynamic, customizable NFTs offer new engagement models while also sticking to a web3-native database implementation. Tableland tables offer a great way to efficiently store metadata and update based on various actions.
- Tooling ⇒ This is intentionally broad. It could be anything from tooling for DAOs to NFT platforms to anything that wants to provide Tableland as a decentralized deployment option.
These are just a few common examples but all applicants will be thoroughly reviewed!
What is the process?
After applying, applications will be reviewed over the coming weeks. The Tableland team will reach out (so be sure to provide contact info!) and schedule a follow up call. Here, we’ll review your proposal, what you’re building, how you plan to use Tableland, and answer any questions about the program.
It’s 8 weeks in total and allow every team to meet other like-minded projects that are accepted into the cohort. There’s a kickoff event, cohort meetings once per week, and two “demo days” / deliverables where Rigs holders vote on projects for an additional bounty.
The Tableland Protocol
What is Tableland?
First, a quick overview. Tableland is a web3-native relational database. It’s a permissionless, serverless SQL database network that sits alongside chains like Ethereum and L2s. Smart contracts are deployed on each respective chain where other smart contracts or EOAs can create tables (ERC721 tokens) and then write SQL to them via event logs. The Tableland network of validator nodes listen to these events and materialize them in their SQLite database. Note that SQL is only processed if it’s of valid syntax and permissions.
Only on-chain addresses with the correct write permissions can mutate a table, and this can be further controlled with the use of on-chain contracts that specify “controller” access controls for what / how data can be changed. This allows for mutable data with immutable rules by using an unstoppable database.
How can I use Tableland and why?
One consideration should be: do you require mutable on-chain data that must be frequently queried off-chain?
Developers have challenges when it comes to storing and retrieving data on blockchains in a cost efficient and performant way. For instance, if you were to treat smart contracts as your database, you’re limited to data structures like mappings and structs. And more importantly, mutating this data is costly, and reading it off-chain is cumbersome. To avoid this pain, many developers end up running an off-chain database but centralized database (e.g., AWS, GCloud, etc.). Some will opt for distributed solutions that rely on IPFS, but these solutions are entirely separate from the base chain.
Tableland offers a nice hybrid: write data on-chain (inheriting the chain’s security and execution guarantees) while reading data off-chain from a decentralized database. If you need to read data on-chain, you might “mirror” only a subset of data or opt for oracles to query off-chain APIs.
Another consideration: where do you use a relational database in your tech stack?
Why do this? Many developers have to make a choice:
- Host all data on-chain, which is expensive to mutate; instead, store data in Tableland tables to reduce write costs.
- Host all data on-chain, which is challenging to query. Creating and writing to tables can be as simple as a one-time deployment where table state is updated by smart contracts and easily read off-chain using the Tableland gateway. Tables are automatically updated with each new block.
- Host some data on-chain, but use a centralized server for the rest…which detracts from the web3 value props like censorship resistance and composability.
- Host some data on-chain, but use a distributed file solutions like IPFS for the rest. Although the premise is great, file systems are meant to store files and don’t offer the performance or available features that a SQL database does (e.g., store files published on IPFS in tables).
Stay tuned over the coming weeks! We’ll start the review process and be announcing teams prior to the January 23rd kickoff. There are also some coming announcements about not only the program but also some major network changes that we’ve been working on.
Check out a primer on the engineering side of things with the engineering blog: here.