Every API ARCWELL exposes is read-only. That is not a limitation we plan to lift, it is a guarantee we print on the label. When the only thing a data service can do is observe, an entire class of abuse stops being possible. This note covers what the data layer provides and why it is shaped this way.
01.Why read-only is a feature
Records enter the registry through one channel only: signed submission by an authorized organization via the portal. The API tier sits downstream and can query, stream, and export, never mutate. If an API key leaks, the blast radius is disclosure within the record's existing visibility policy, not tampering with the ledger.
02.Source attribution by default
Every field the explorer shows carries its source and the time it was recorded. Third-party rule or screening results are displayed with the provider, the rule set, and the check time, clearly labeled as outcomes of a check, not certifications. Consumers of the API get the same attribution in every payload, because a number without provenance is just a rumor with formatting.
03.Webhooks and exportable audit reports
Monitoring teams subscribe to webhooks for anchor confirmations, new flags, and correction events. Auditors export complete, self-verifying report bundles: record metadata, hashes, timestamps, and the verification history needed to re-check every claim offline. The explorer renders the same data for humans, searchable by organization, series, status, and time.
Every number we show carries its source and its timestamp. Everything else is decoration.
Read-only infrastructure is trust infrastructure. When your auditors, partners, and regulators can all check the same records independently, and none of them can change what they see, the record starts to speak for itself.
Filed under Data, ARCWELL Research, Protocol team, ARC network. ARCWELL is a software and verification service; nothing here is investment, legal, or compliance advice.
