OptionalallAnchors 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.
The attestation ID. This is the constant ID that is given to the attestation.
When the attestation was created.
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.
OptionaldataThis 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).
Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.
Entropies used for certain data integrity proofs on-chain (e.g. HASH(message + entropy) = on-chain value)
Holders are the addresses that have been given the attestation.
Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.
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.
The message format of the messages.
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.
Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.
OptionaloriginalThe original provider of the attestation. Used for third-party attestation providers.
OptionalproofProof 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.
OptionalpublicWhether or not the attestation is displayable on the user's profile. if true, the attestation can be queried by anyone with the ID.
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.
Deep copies the object and returns a new instance.
Compares this object's fields to another object's fields for equality. Equality is determined by comparing the JSON representations of the objects.
If normalizeNumberTypes is true, then all number types will be compared as strings (i.e. "1n" === "1" === 1). Else, they will be compared as their native types (i.e. 1n !== 1 !== "1").
OptionalnormalizeNumberTypes: boolean
All holders are the addresses that have been given the attestation at any point in time. Used internally as an append-only audit log.