Interface iAttestation<T>

interface iAttestation<T> {
    allHolders?: string[];
    anchors: {
        message?: string;
        txHash?: string;
    }[];
    attestationId: string;
    createdAt: T;
    createdBy: string;
    dataIntegrityProof?: {
        isDerived?: boolean;
        publicKey?: string;
        signature: string;
        signer: string;
    };
    description: string;
    entropies: string[];
    holders: string[];
    image: string;
    inviteCode: string;
    messageFormat: "plaintext" | "json";
    messages: string[];
    name: string;
    originalProvider?: string;
    proofOfIssuance?: {
        message: string;
        publicKey?: string;
        signature: string;
        signer: string;
    };
    publicVisibility?: boolean;
    scheme: string;
}

Type Parameters

Hierarchy (view full)

Implemented by

Properties

allHolders?: string[]

All holders are the addresses that have been given the attestation at any point in time. Used internally as an append-only audit log.

anchors: {
    message?: string;
    txHash?: string;
}[]

Anchors are on-chain transactions used to prove certain things about the attestation. For example, you can anchor the attestation to a transaction hash to prove that the attestation existed at a certain time.

attestationId: string

The attestation ID. This is the constant ID that is given to the attestation.

createdAt: T

When the attestation was created.

createdBy: string

The address of the user who created the attestation on BitBadges. Note this is used for permissions on BitBadges end and may not align with the signer / issuer of the attestation.

dataIntegrityProof?: {
    isDerived?: boolean;
    publicKey?: string;
    signature: string;
    signer: string;
}

This is the signature and accompanying details of the messages. The siganture maintains the integrity of the messages.

This should match the expected scheme. For example, if the scheme is BBS+, the signature should be a BBS+ signature and signer should be a BBS+ public key.

For custom schemes, this is often left blank (because the proof is already included in the message).

description: string

Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.

entropies: string[]

Entropies used for certain data integrity proofs on-chain (e.g. HASH(message + entropy) = on-chain value)

holders: string[]

Holders are the addresses that have been given the attestation.

image: string

Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.

inviteCode: string

The inviteCode is used to add the attestation to the user's wallet. Anyone with the key can query it, so keep this safe and secure.

messageFormat: "plaintext" | "json"

The message format of the messages.

messages: string[]

Thesse are the attestations that are signed. For BBS+ signatures, there can be >1 messages, and the signer can selectively disclose the attestations. For standard signatures, there is only 1 attestationMessage.

name: string

Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.

originalProvider?: string

The original provider of the attestation. Used for third-party attestation providers.

proofOfIssuance?: {
    message: string;
    publicKey?: string;
    signature: string;
    signer: string;
}

Proof of issuance is used for BBS+ signatures (scheme = bbs) only. BBS+ signatures are signed with a BBS+ key pair, but you would often want the issuer to be a native address. The prooofOfIssuance establishes a link saying that "I am the issuer of this attestation signed with BBS+ key pair ___".

Fields can be left blank for standard signatures.

publicVisibility?: boolean

Whether or not the attestation is displayable on the user's profile. if true, the attestation can be queried by anyone with the ID.

scheme: string

The scheme of the attestation. BBS+ signatures are supported and can be used where selective disclosure is a requirement. Otherwise, you can simply use your native blockchain's signature scheme.