📘
Supported API key types: Secret

Description

Create or update the project's attestation schema, specified by a projectId. If the attestation schema does not exist, this endpoint will create a new attestation schema for the given project and return a 201. If it does exist, it will be updated and return a 200.

By default, Spearmint attestations can be used to verify whether an address is allowed or not allowed to invoke a gated smart contract function. You can think of vanilla attestations as a general admissions ticket.

But perhaps you want to go further and add custom rules for each ticket holder (e.g., how many tokens each address can mint, or how much each address should pay per token). One way to do this would be to store extra attributes for each address on-chain in your smart contract, but that is highly inefficient in terms of gas and storage. With Spearmint, you're able to store these attributes off-chain and enforce them on-chain in a tamper-proof way.

Using this endpoint, you can set an attestation schema (along with default values for each field) that applies to all of the entries in your project. After setting an attestation schema, you can specify the attestation data for each entry using the create or update entry endpoint.

The attestation schema must define the names of each field, along with a valid data type and a default value. You can specify a maximum of 10 fields, and the structure must be flat (nested fields are not allowed). The schema must contain at least 1 field.

Request body example

[
  {
    "name": "validAt",
    "type": "uint256",
    "defaultValue": "1625097600"
  },
  {
    "name": "quantity",
    "type": "uint256",
    "defaultValue": "100"
  }
]

Currently supported data types

address
bool
int8 - int256 (the default value should be serialized to a string)
uint8 - uint256 (the default value should be serialized to a string)
bytes1 - bytes32
bytes
string

Updating the attestation schema

IMPORTANT: Sometimes, you might want to change the schema to add or remove certain fields. If you have already set attestation data for entries that conform to your existing schema, those will become invalid after updating the schema. Although the old attestation data for your entries will persist (you'll still be able to see them when using the get entry endpoint), any future signatures served for those entries will use the default values from the new schema for their attestation data unless they are corrected. All existing attestation data will become obsolete.

Note that this does not apply to Merkle proofs, as the attestation schema and attestation data for each entry is frozen at the time of Merkle tree generation.

Request interface

{
  data: Array<{
    name: string;
    type: string;
    defaultValue: string | boolean;
  }>;
};

Response interface

{
  data: Array<{
    name: string;
    type: string;
    defaultValue: string | boolean;
  }>;
};

{
  error: {
    message: string;
  };
}