Choosing a Congrid role starts with the work you can maintain. A publication needs someone responsible for its live website and registration details. A verifier needs an operator responsible for services and verification work over time.
This Congrid publisher vs. verifier checklist helps a small team make that decision, assign ownership, and recognize which workflow to review when something needs attention.
Compare the responsibilities first
The Congrid guides describe two participation paths. Publishers register websites for discovery across member sites. Verifiers operate services that check publisher status.
Use this matrix as a planning aid, then follow the current guide for the role you choose.
| Responsibility | Publisher workflow | Verifier workflow |
|---|---|---|
| Main asset to maintain | A publicly reachable website and its registration details | A working verification service stack |
| Access to arrange | Permission to edit and deploy the homepage; access to the registration wallet | A supported host and the access needed to operate its services and verifier key |
| Setup evidence to retain | Domain, public owner address, deployed member badge, and registration evidence | Installation mode, service locations, verifier address, and bonding evidence |
| Routine review | Homepage access and badge consistency after site changes | Service health, connectivity, logs, and assignment progress |
| First guide to consult | Publisher onboarding | Verifier setup |
The current verifier guide supports Linux and macOS with native services. It describes both a full stack and a mode for an existing compatible node. Consult that guide when choosing a setup; this comparison is about assigning the ongoing work.
Ask three readiness questions
What do you want to contribute? If your immediate objective is to make a publication discoverable, start by evaluating the publisher workflow. If you want to perform website checks for the network, evaluate verifier operation.
Which assets can you maintain? A publisher needs a dependable way to deploy homepage changes. A verifier operator needs a dependable way to inspect and maintain the host and services. Access held by a contractor or a colleague should have a clear handoff before setup begins.
Who will respond after the first day? Name the person who can address a removed badge, an inaccessible homepage, or a stopped service. A completed initial setup is only one entry in an ongoing operating record.
If you are considering both paths, review the requirements and evidence for each separately. Choose the scope your team can support before expanding it.
Build a small ownership record
Assign names to the tasks instead of leaving “the team” responsible for everything. One person may hold several responsibilities, but each task should still have a clear owner.
For the publisher workflow, identify who can deploy the homepage, who reviews registration details, and who checks the public result. The publisher guide requires the homepage member badge to match the registered domain and wallet. Its surrounding link must use an href of exactly https://congrid.net.
For the verifier workflow, identify the service operator, the person responsible for protecting the verifier key backup, and the person who reviews funding and bonding completion. The verifier guide distinguishes funding the address from submitting the bond. Keep those completion records separate.
Use a short record with these fields:
- Task and named owner.
- Asset or service involved.
- Evidence that the setup step is complete.
- Routine review and the next review date.
- Backup contact when the owner is unavailable.
- Open issue and the next action.
Store operational references where the right people can find them. A handoff record should describe access and responsibility without copying wallet recovery phrases or private keys into shared notes.
Work through two team scenarios
Imagine a small local-history publication with an editor and a freelance website maintainer. The editor wants readers to discover the publication, while the maintainer controls homepage deployment. Their first decision is to coordinate badge deployment, registration review, and a public-page check. The editor also needs to know who will review the badge after a future redesign.
Now imagine an operator who already maintains a compatible Congrid node and wants to take on verification work. That operator should review the existing-node installation path, the applicable bonding steps, and a service-monitoring routine. The readiness question is whether the operator can maintain the additional services and follow assignments consistently.
These are planning examples, not reports of Congrid participants or results. They show how the same role description leads to different practical ownership questions.
Route an issue to the right owner
A useful handoff begins with the observed symptom. Use this table to decide where to start; the observations alone do not establish the protocol's final status.
| Observation | First owner and review |
|---|---|
| The homepage became inaccessible after a release | Website maintainer: inspect the deployed public site |
| The badge disappeared or its values changed | Homepage and registration reviewers: compare the deployment with the current publisher requirements |
| The receiving wallet is being changed | Registration owner: follow the current re-registration process and check its reported result |
| A verifier service stopped or lost connectivity | Service operator: inspect service health, connectivity, and logs using the verifier guide |
| Verification work appears to be backing up | Verifier operator: review assignments and related service evidence |
For a publisher release review, use the website verification checklist. For service operation, keep the current verifier instructions available alongside your own host records.
Keep roles and outcomes clear
The Congrid architecture overview identifies website verification separately from consensus validators finalizing the ledger. Use precise role names when recording responsibilities so website checks and consensus work are not confused.
Also separate participation status, reader outcomes, and protocol rewards. A maintained publisher registration does not establish a particular amount of referral traffic. A verifier's service health does not establish a particular reward amount. Evaluate audience activity through a referral-traffic measurement workflow, with organic search performance in its own record.
Finish the role decision by selecting the appropriate publisher or verifier guide, naming a maintenance owner, and setting a review date. That gives the first setup task and the ongoing responsibility a clear place in your team's work.