RKP-1 - Full On-Chain

Overview

RKP-1 (Full On-Chain) is ROOTKey’s highest-integrity data processing protocol. Every data operation - creation, validation, or versioning - is recorded directly to the Polygon blockchain via a smart contract transaction. The result is a permanent, tamper-evident, publicly verifiable audit trail that requires no trust in any third party, including ROOTKey. Any entity with blockchain access can independently verify the integrity and existence of a record without contacting ROOTKey or relying on ROOTKey infrastructure. This protocol is designed for scenarios where the integrity of data is itself a compliance requirement, and where the provenance of records must withstand adversarial scrutiny - legal proceedings, regulatory audits, or multi-party disputes.

Architecture Overview

Client Application
        │
        ▼ HTTPS / JSON
  ROOTKey REST API
        │
        ▼
  Smart Contract Layer
        │
        ▼
  Polygon Blockchain  (Mainnet)
        │
        ▼
  Publicly Queryable via Polygonscan

Each API operation triggers a smart contract transaction that writes a cryptographic record to the Polygon blockchain. Anchoring is asynchronous: the API responds immediately with the operation in PENDING state and its transaction hash, and the record is marked as anchored once the transaction is mined. The on-chain record includes:

SHA-256 hash of the data payload
Timestamp of the operation (block timestamp)
Vault and asset identifiers
Originating wallet address

On-chain records are immutable - they cannot be altered, deleted, or invalidated after submission. They are publicly queryable via Polygonscan, independently of any ROOTKey service or API.

Request Limits and Throughput

Parameter	Value
Maximum requests per second	10
Maximum payload size per request	35 MB
Burst allowance	2x/10seconds

For the limits the API applies to requests, and how to handle them, see Rate Limits.

Performance Indicators

Metric	Value
Polygon block time	~2 s

The API accepts a request and returns its transaction hash before the transaction is mined, so request latency is independent of anchoring. Time to anchor confirmation depends on the anchoring queue and on Polygon network conditions.

Confirmation time is subject to Polygon network conditions.

Validation Capabilities

RKP-1 validation is fully decentralised:

Validation Type	Supported
Independent third-party verification (no ROOTKey required)	Yes
On-chain proof of existence	Yes
On-chain proof of integrity (hash match)	Yes
Smart contract auditability	Yes
Historical record traversal	Yes
Deletion or amendment post-submission	No (by design)

Any auditor, regulator, or counterparty can verify a record by querying the Polygon blockchain directly using a standard block explorer. No API key, no ROOTKey account, no trust assumption required.

Strengths

Maximum auditability - full chain-of-custody on a public, permissionless blockchain
Decentralised trust model - no single party controls verification, including ROOTKey
Immutability by design - cryptographic guarantees, not policy-based controls
Independently verifiable - auditors and regulators can verify without vendor cooperation
Zero-trust compatible - aligns with zero-trust architecture principles at the data layer
Permanent proof - the on-chain record does not depend on ROOTKey storage or vendor continuity (verifying it still requires the original data)

Weaknesses

Higher latency to confirmation - an operation is only anchored once its transaction is mined
Higher cost per operation - each write incurs a gas fee on the Polygon network
Throughput constraints - bounded by block time; not suitable for high-frequency write workloads
No data deletion - records are permanent; requires careful data classification to avoid writing personal data on-chain (GDPR implications)

Typical Use Cases

Legal and Regulatory Documents

Contracts, compliance filings, and regulatory submissions requiring cryptographic proof of existence, integrity, and timestamp.

Financial Records and Audit Trails

Transaction logs, financial statements, and audit trails where tamper-evidence is a regulatory requirement under frameworks such as MiFID II or SOX.

Supply Chain Provenance

Product authenticity certificates, quality records, and multi-party custody chains anchored immutably for each transfer event.

Critical Infrastructure Logs

Operational logs for critical systems - energy, healthcare, public services - where regulatory bodies require tamper-evident records.

Intellectual Property Registration

Proof-of-existence for IP assets, design files, or proprietary content prior to formal registration processes.

Multi-party Agreement Evidence

Binding records of agreements, SLAs, or operational decisions involving multiple organisations that each require independent verification rights.

Compliance Alignment

Framework	Alignment
NIS2 Directive	Supports Article 21 obligations - integrity, availability, and auditability of critical information assets
ISO 27001 (in progress)	Aligns with Annex A controls: A.8.15 (logging and monitoring), A.5.33 (protection of records), A.5.36 (compliance with policies)
eIDAS	On-chain timestamps provide electronic evidence of existence at a point in time (not a qualified electronic timestamp under Article 42)
GDPR	Requires architectural consideration - personal data must not be written on-chain; hash-only patterns are GDPR-compatible
DORA	Supports digital operational resilience requirements for financial entities through immutable audit trails

ROOTKey is actively pursuing NIS2 alignment and ISO 27001 certification. Contact us at [email protected] for the current compliance posture, available security documentation, and pending certifications.

Get started with a free account

Start with a test API key, then go live with a live key. No commitment required.

Request a technical briefing

Discuss your architecture, compliance requirements, and protocol fit with our engineering team.

Introduction

Quickstart

Connectors

Integrations

Ecosystem Guides

Protocols