Create an Attestation
After determining the Schema and potential Modules to use, and after the deployment and registration of your Portal, you can begin creating Attestations.
Attestation registration
Attestation registration at the Portal level takes 2 parameters, defined as follows:
Property | Description |
---|---|
attestationPayload | The payload to attest |
validationPayload | The payloads to validate via the modules to issue the attestation |
attestationPayload
is defined in Solidity as follows:
Property | Description |
---|---|
schemaId | The identifier of the schema this attestation adheres to |
expirationDate | The expiration date of the attestation |
subject | The ID of the attestee, EVM address, DID, URL etc |
attestationData | The attestation data |
Manually registering an Attestation in the AttestationRegistry
contract
AttestationRegistry
contractTo register an Attestation into the AttestationRegistry
contract, you need to go through the Portal you have previously deployed an registered, using the attest function:
When attesting, the registry performs a set of integrity checks on the new attestation:
verifies the
schemaId
existsverifies the
subject
field is not blankverifies the
attestationData
field is not blank
Using a blockchain explorer
Instead of drafting the smart contract call by hand, you can benefit from a chain explorer interface. Let's use the Linea Sepolia explorer, Lineascan.
Retrieve the address of the
Portal
contract you previously deployedAccess the Portal contract on Lineascan
Got to the "Contract" tab
Got to the "Write" tab
Connect your wallet and fill the attest form with the parameters described above
Send the transaction
Using the official Verax SDK
We have seen rather manual ways to create an Attestation, now let's focus on the easiest way: via the Verax SDK.
Check this page to discover how to instantiate ethe Verax SDK.
Once you have an SDK instance, you can create an Attestation like this:
Attestation Metadata
When creating an attestation, you simply need to specify four properties, as outlined above, however, the attestation registry itself automatically populates the other fields in the attestation metadata at the point at which it is created. The full list of attestation metadata is included below:
Property | Datatype | Description |
---|---|---|
attestationId | bytes32 | The unique identifier of the attestation |
schemaId | bytes32 | The identifier of the schema this attestation adheres to |
replacedBy | uint256 | The attestation ID that replaces this attestation |
attester | address | The address issuing the attestation to the subject |
portal | address | The address of the portal that created the attestation |
attestedDate | uint64 | The date the attestation is issued |
expirationDate | uint64 | The expiration date of the attestation |
revocationDate | uint64 | The date when the attestation was revoked |
version | uint16 | Version of the registry when the attestation was created |
revoked | bool | Whether the attestation is revoked or not |
revocationDate | uint64 | If revoked, the date it was revoked / replaced |
subject | bytes | The ID of the attestee e.g. an EVM address, DID, URL etc. |
attestationData | bytes | The raw attestation data |
The attestationId is derived from an internal auto-incremented counter, converted from uint32 to byte32. This corresponds to the total attestations issued. Moreover, the ID is prefixed with a chain identifier. This way, an attestation issued on Arbitrum cannot have t he same ID as an attestation issued on Linea, which is great in terms of cross-chain discovery!
Once the attestation is successfully created in the registry, an AttestationRegistered
event is emitted with the attestation ID, and subsequently picked up by indexers.
Last updated