Verax Attestation Registry
  • 👋Introduction
  • ⚒️Getting Started
  • Core Concepts
    • High-Level Overview
    • Attestations
    • Schemas
    • Linked Data
    • Modules
    • Portals
    • Ecosystem
  • Developer Guides
    • ♒For Attestation Issuers
      • Create and register a Schema
      • Create a Module
      • Register a Module
      • Create a Portal
      • Register a Portal
      • Create an Attestation
      • Encoding Attestation Data
      • Revoke an Attestation
      • Replace an Attestation
      • Link Attestations
      • Bulk Create Attestations
      • EAS compatibility
    • 🧑‍🏫Tutorials
      • From a Schema to an Attestation
      • Using Ceramic to store the Attestation Payload
    • 🚀Examples
    • 🌐Using the Subgraph
    • 🛠️Using the SDK
  • Discover
    • 📚Modules Standard Library
      • ECDSAModule
      • ERC1271Module
      • FeeModule
      • IndexerModule
      • IssuersModule
      • SchemaModule
      • SenderModule
    • 🤝Integrations
  • Get Involved
    • Get in Touch
    • Contribute
    • Governance
      • Governance Charter
      • Governance Parameters
      • Overview of Governance
      • Proposal Templates
Powered by GitBook
On this page
  1. Core Concepts

Modules

PreviousLinked DataNextPortals

Last updated 2 months ago

Modules are smart contracts that inherit the contract and are registered in the registry. They allow for attestation creators to run custom logic to do things like:

  • verify that attestations conform to some business logic

  • verify a signature or a zk-snark

  • perform other actions like transferring some tokens or minting an NFT

  • recursively create another attestation

Modules are specified in a and all attestations created by that portal are routed through the specified modules. Modules can also be chained together into discrete pieces of specific functionality.

Each module exposes a public function called run:

function run(
    AttestationPayload memory attestationPayload,
    bytes memory validationPayload,
    address txSender,
    uint256 value
) public pure override {}

The function executes whatever logic it needs to, and reverts if the incoming transaction doesn't conform to the required logic. The attestationPayload is the raw data of the incoming attestation, and the validationPayload is any qualifying data required for verification, but that doesn't make it into the on-chain attestation, e.g. a snark proof, merkle proof or signature etc.

As well as implementing the Module interface, a module must also implement to ensure that it can be verified properly when being registered.

When multiple Modules are used in a workflow, ensure that at most one Module processes msg.value to avoid accounting issues, as the total msg.value is forwarded to all Modules.

Module Metadata

Once the module smart contract is deployed, it can be registered with the following metadata:

Field
Type
Description

moduleAddress

address

(required) The address of the module smart contract

name

string

(required) A descriptive name for the module

description

string (URI)

(optional) A link to documentation about the module, its intended use, etc.

The metadata above is intended to help to discover modules that can be reused once created. Modules are chained together and executed in . The next section dives into portals, what they are, and how to create them.

AbstractModuleV2
portal
ERC-165
portals