Skip to main content

SDK strategy

The PressChain protocol architecture includes a Protocol SDK as a platform component, but the current repositories do not expose a single public package surface that should be documented as a finished, versioned SDK install today. Rather than invent package names or methods, this documentation treats the existing integration primitives as the current developer contract: V3 authority configuration, contract ABIs, JSON-RPC, canonical model types and PressKey.

Build a thin local client

A small application adapter can give your product an SDK-like boundary now:
Keep transaction authorization separate:
This separation maps cleanly to a future canonical SDK while keeping signing boundaries visible.

Source configuration from authority

Your client should accept a deployment object rather than embedding addresses inside methods.
Add contracts as their deployment authority becomes stable. Do not predeclare an address simply because a Solidity file exists in the repository.

Reuse canonical models

Where possible, generate TypeScript or application models from the canonical Rust record semantics instead of creating incompatible field names. Important shapes include Capsule records, Evidence records, Contributor records and the broader Trust Object.

Normalize errors once

An SDK boundary is the right place to turn low-level RPC reverts into domain errors:
UI components should not need to decode ABI revert data directly.

What a canonical SDK should eventually provide

A mature PressChain SDK should make these tasks consistent:
  • network and deployment resolution
  • canonical bytes32 validation
  • Capsule and metadata helpers
  • evidence and contributor reads
  • transaction intent construction
  • PressKey integration
  • economic rule resolution
  • event decoding
  • model serialization
  • typed domain errors
The key requirement is convergence on protocol authority, not adding a convenience wrapper around stale constants.

Migration-friendly design

If you hide raw RPC and ABI details behind a small application client today, moving to an official SDK later becomes a boundary change instead of a full application rewrite. Avoid leaking contract tuple order and provider-specific quirks throughout your UI.