Hyper Core can integrate an external ledger only through an append contract with these semantics:
- Input: caller-supplied stable event ID plus exact canonical event bytes.
- First append durably records one immutable event and returns a verifiable opaque reference.
- Same ID plus byte-identical event returns the original reference, without a second record.
- Same ID plus different bytes is an explicit conflict/refusal.
- The service never rewrites or re-signs the caller event.
- A receipt must support later inclusion/durability verification.
The current Storage Put hash is intentionally randomized by fresh HPKE encapsulation, so it cannot provide this identity/idempotency layer. VOID transaction IDs alone do not expose the required event semantics.
Could the protocol add a separate Append RPC (or document an equivalent production API), including its atomicity/failure and retry rules? This would make Starshine usable as a ledger adapter rather than only encrypted object storage.
Hyper Core can integrate an external ledger only through an append contract with these semantics:
The current Storage Put hash is intentionally randomized by fresh HPKE encapsulation, so it cannot provide this identity/idempotency layer. VOID transaction IDs alone do not expose the required event semantics.
Could the protocol add a separate Append RPC (or document an equivalent production API), including its atomicity/failure and retry rules? This would make Starshine usable as a ledger adapter rather than only encrypted object storage.