Skip to main content

​
Capsule lifecycle

A Capsule lifecycle is easier to reason about when publication is treated as a sequence of verifiable commitments rather than one large form submission.

​
1. Prepare publication material

The application starts with the article or content artifact plus canonical metadata. Normalize the content format that will actually be hashed. If your CMS injects dynamic markup at delivery time, decide which canonical representation is being committed. The same rule applies to media. Hash the exact bytes represented by the metadata reference.

​
2. Resolve identity and authority

Before preparing a write, resolve the PressKey account, active protocol role, bond state and outlet context. capsule.publish is a public economic action for Author, Journalist or Editor roles and requires identity, an active bond and the standard fee class under the V3 action policy. Client preflight is for UX. Protocol enforcement remains authoritative.

​
3. Persist durable artifacts

Upload or store the canonical article representation, metadata envelope and any initial evidence. Avoid temporary URLs that expire before the transaction is mined. At this point, the application should have deterministic hashes for everything it intends to commit.

​
4. Authorize publication

Construct the transaction using the approved Capsule contract and current deployment manifest. Confirm chain ID and PressKey account immediately before authorization. The docs intentionally do not invent a publication function signature where the active core implementation has not been confirmed as public authority. Generate calldata from the ABI shipped with the approved deployment.

​
5. Confirm chain state

A successful wallet submission is not yet the same thing as a confirmed publication. Track the transaction receipt and then read the resulting Capsule by its canonical bytes32 ID. Persist the transaction hash and block coordinates in your application audit trail. After the Capsule exists, other registries can safely refer to it. Typical follow-up work includes:
  • attach co-authors, sources or other contributors
  • attach official evidence from authorized actors
  • accept community or dispute evidence through the appropriate flow
  • render metadata and cover media
  • begin revision tracking
The V3 evidence and contributor registries explicitly reject missing Capsules.

​
7. Revise rather than rewrite

Journalism changes. Corrections, updates and developing stories are normal. The protocol design includes revision state so later changes can remain linked to the original publication rather than erasing it. An application should make the distinction visible: “current article” is an application view, while the protocol history can preserve what changed and when.

​
8. Keep historical context queryable

Do not discard inactive contributors, replaced metadata or superseded projections simply because the current UI does not show them by default. An audit or Explorer view may need the full history.

​
Failure recovery

A publication pipeline should be restartable. If the artifact upload succeeds but the transaction is rejected, the stored artifact can remain unreferenced or be garbage-collected later. If the transaction succeeds but the UI times out, the app should recover by transaction hash or known publication identifiers rather than asking the user to sign again immediately. Idempotent orchestration is safer than optimistic duplicate writes.