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:Source configuration from authority
Your client should accept a deployment object rather than embedding addresses inside methods.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: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