Skip to main content

Data

Hypercerts represent a complex dataset that is distributed across multiple sources. When minting a hypercert, the creator must provide a URI to an object containing the hypercert data. Our default storage solution is IPFS, but the data object can be stored on any storage provider.

tip

Take permanence into account when providing the dataset. The hypercert metadata cannot be updated, so referencing any arbitrary domain name will most likely lead to a broken link in the future.

Overview

The following table gives an overview of the different data objects we maintain, their source, and where they are stored.

Data ObjectStorage TypePurpose
AttestationsCaching DBQuick access to EAS data
Attestation schemasCaching DBQuick access to EAS schemas
FractionsCaching DBEfficient query for fraction ownership and state
HypercertsCaching DBQuick retrieval of hypercert data
SalesCaching DBEfficient query for sales

Data Flow: Hypercert Minting and Access

Retention

Cached data

A database maintaining cached data is used to allow performant access to on-chain state and data stored on IPFS. The database is provided by Supabase and we rely on their backup solutions. In case the database goes down, all data can be restored from archival nodes and IPFS.

Local cache

On every environment the transactions parsed and data fetched from IPFS are cached in a Postgres database colocated with the indexer. The indexer is deployed on Railway and the schema can be introspected on the staging or production endpoints.

Static data

Static data like marketplace listing, blueprints and user profiles are stored in a separate database. Like the cached data, the database is provided by Supabase and we rely on their backup solutions.