About
Protocol
Walkthroughs
Integrations
Intro to NFT Metadata
Tutorials
Smart Contracts
Concepts
Playbooks
Learn
Create an Immutable Table
Tableland supports many ways to mutate table rows, or lock a table's entire state.
Overview
Tableland is designed for mutable data. Once a user or app creates a table, they are the default table controller
. A controller owns and has control over all mutation operations on a table. This means only the controller
can write to (insert, delete, or update rows/data), while any other address is able to read or query a table.
However, because tables are ownable assets on the actual EVM chain, a controller may wish to transfer ownership of the table to another address. That is, every table created in Tableland is also minted as an ERC721 token on the base chain. Upon transferring a TABLE
ERC721 token, then gives this new address permission to mutate or otherwise control the table (including the ability to GRANT
access to others).
But, what if a table own wants to "lock" access to the table permanently? This can easily be done by removing access to the table for any and all addresses, including one's own address. This can be done in practice by "burning" the table token. To "burn" a token is to permanently and irreversibly remove that token from circulation, and in practice this can be done by transferring the token to a burn or null address, such as 0x0000000...
(the zero address).
Luckily, the ERC721 contract that Tableland uses for tables has a handy burn
method, which can be called by its owner (controller
) to burn the table's token (while the table data remains intact). This essentially makes the table un-ownable, rendering the table immutable because no one has permissions to mutate it anymore!
Boom, we now have an immutable, fixed state for our table! This is great for things like immutable NFT metadata, or for table versioning, or other scenarios where we need a permanent, immutable reference to rows and columns of data.
Burn a Table with Etherscan + Goerli
Let’s assume you’ve already been through both the JavaScript SDK or CLI tutorial and created a table with the prefix mytable
. In practice, recall this prefix has the chainId
and table’s minted tokenId
appended to the prefix using underscores. For example, mytable_5_37
is a table on Goerli (chain 5
) and with token id 37
.
0x0
address by calling the burn
method. DO NOT call burn
with any tableId
you wish to keep. Tableland has no way of retrieving a burned table; it will be immutable and forever owned by the 0x0
address.Let’s walk through the steps to use Etherscan to read and write to the Goerli blockchain, burning the table mytable_5_37
:
- Go to the Tableland deployed smart contract on Goerli’s Etherscan (here) and navigate to the Write as Proxy tab.
- Click on Connect to Web3 to initiate the MetaMask connection flow.
- Select the desired account and click Next.
- Click Connect to connect your wallet to Etherscan.
- Refresh the page, click Connect again, select MetaMask, and then proceed after seeing the following message.
- Note: Etherscan doesn’t have the best user experience when it comes to the connection workflow.
- Verify you’re connected to the Goerli network.
- Each of the accordion tables (numbered 1-17) are actually methods on the deployed smart contract. This UI is a way to directly interact with it. Scroll down to #2, which is the
burn
method. - Enter the
tokenId
of a table that you want to make immutable — in this example, the table name wasmytable_5_37
, so thetokenId
is37
. - Proceed with the MetaMask flow by clicking Confirm — this will sign the transaction and send it to the blockchain. In other words, by clicking Confirm, you’ve authorized the table can be
burn
ed, sending it to the0x0
address where no one will ever be able to transfer or alter it. Only proceed if you wish to lose ownership forever. - Once the transaction confirms, the table is officially immutable! Click on View your transaction to see the results.
Or, if you chose not to burn
any tables, check out the example below, which burned the table mytable_5_37
.