Set your attestation schema

This section is optional, but highly encouraged, as it allows you to leverage the full potential of Spearmint's attestations.

By default, Spearmint attestations served via the Attestations API 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.

Your project's attestation schema can be set using the create or update attestation schema endpoint. In the future, you will be able to configure this within the app.

On the Project subtab of the Developers section, you'll be able to see the attestation schema (if set), along with a struct you can use in your smart contract to parse the attestation data.

With an attestation schema in place, you'll be able to use the create or update entry endpoint to set attestation data for any entry that should deviate from the defaults defined here.

Attestation schemas are supported for both signatures and Merkle proofs. For Merkle proofs, the schema and attestation data for the entries are frozen at time of Merkle tree generation, which means that for any changes to the schema and attestation data to take effect, a new tree must be generated.

Learn more on how to utilize attestation schemas in the subsequent pages!