Skip to main content

​
Contracts

PressChain splits protocol behavior into domain contracts instead of treating one contract as the entire application. This lets publication state, evidence, contributors, roles, finance and provenance evolve behind explicit interfaces. The protocol repository currently organizes Solidity code into domains including Capsules, identity, provenance, finance, governance, rights, RSS, trust, voting, storage and PressKey-related protocol components.

​
Capsule registries

Current Capsule source includes:
  • CapsuleContentRegistryV1
  • CapsuleMetadataLocatorV1
  • CapsuleContributorsRegistryV3
  • CapsuleEvidenceRegistryV3
  • CapsuleRevisionsRegistryV1
Older V1 contributor and evidence implementations also remain in source history, but new documentation follows the active V3 implementations where they exist. The V3 evidence and contributor contracts depend on a Capsule core interface exposing getCapsule(bytes32) and capsuleExists(bytes32).

​
Never guess an address

Contract names are stable concepts. Deployment addresses are environment-specific facts. Use an approved deployment manifest or the canonical network configuration for addresses. Avoid examples such as:
Prefer:
Your loader can verify the manifest network, chain ID, protocol major and optional manifest hash before returning it.

​
ABI discipline

Use the ABI matching the deployed contract version. A client should not silently call a V3 address with a V1 ABI because the function names look similar. For a lightweight front end, it is reasonable to ship minimal read ABIs containing only the functions the app actually calls. Keep the source contract and version noted beside the ABI generation process.

​
Domain boundaries

A contract boundary communicates meaning. For example, CapsuleContributorsRegistryV3 enforces contributor attachment, source designation and active share accounting. CapsuleEvidenceRegistryV3 owns evidence records, votes and finalization. An application should preserve those concepts in its own data model. Flattening all related records into a generic attachment table makes later policy and audit work harder.

​
Read before write

When building a transaction, read current state immediately before authorization. Check whether the Capsule exists, whether a contributor is already attached, whether evidence is active or already finalized, and whether the connected account has the required relationship. Contracts will enforce their own invariants, but a preflight saves the user from approving predictable reverts.

​
Events are integration contracts too

Indexers depend on events as much as front ends depend on view functions. Preserve indexed identifiers and transaction coordinates when projecting events. For example, the V3 evidence registry emits EvidenceAdded, DisputeEvidenceSubmitted, EvidenceVoted, EvidenceFinalized and EvidenceActiveSet. Those events provide enough information to drive an evidence activity timeline while view calls remain the final read for current state.

​
Version-aware clients

An application that supports more than one deployment should make version selection explicit. Do not choose an ABI based on whether a call happens to revert. A deployment registry should answer:
  • which protocol major is active
  • which contract version is deployed for each domain
  • at which address
  • at which block it became authoritative
  • whether a previous deployment is read-only, deprecated or retired
That makes upgrades observable instead of accidental.