Getting Started

Build on
Rubric Protocol.

Integrate post-quantum AI attestation into any system in minutes. Every AI decision your system makes becomes cryptographically signed, Merkle-batched, and permanently anchored to Hedera Consensus Service.

Note

Rubric Protocol is currently running on Hedera Testnet. Mainnet launch is scheduled for Q3 2026.

Installation

Install the TypeScript SDK via npm. Works in Node.js 18+ and modern browser environments.

Terminal

npm install @rubric-protocol/sdk

First Attestation

The following example attests an AI agent output to Hedera in under 5 minutes.

01

Initialize the client

Instantiate RubricClient with your API key and target network.

          
import { RubricClient } from '@rubric-protocol/sdk';

const client = new RubricClient({
  apiKey: process.env.RUBRIC_API_KEY,
  network: 'testnet'
});
        

02

Attest a decision

Submit any AI decision event. Rubric constructs a Merkle leaf, signs with ML-DSA-65, and batches for HCS anchoring.

          
const result = await client.attestations.attest({
  agentId: 'credit-model-v3',
  leafType: 'AGENT_OUTPUT',
  data: {
    decision: 'APPROVE_LOAN',
    confidence: 0.94,
    modelVersion: '3.2.1'
  }
});

// result.attestationId  — permanent, on-chain forever
// result.sigValid       — ML-DSA-65 verified: true
// result.onChain        — anchored to HCS 0.0.8052848: true
        

03

Verify anytime

Any attestation is verifiable in O(1) via local index, or independently via HCS mirror node — no trust required.

          
const proof = await client.attestations.verify(
  result.attestationId
);

// proof.verified      — true
// proof.sigValid      — true
// proof.securityLevel — 'ML-DSA-65'
        

API Reference

REST API

All endpoints are available at https://rubric-protocol.com/verify/. Authentication via x-api-key header.

Base URL

https://rubric-protocol.com/verify/

Authentication

x-api-key: YOUR_API_KEY

Attestation Endpoints

POST /v1/attest

Submit a single AI decision event for attestation. Returns an attestationId anchored to HCS.

Field	Type	Description
agentId	string	Unique identifier for the AI agent or system
leafType	enum	AGENT_OUTPUT · HUMAN_REVIEW · RULE_APPLIED · DOCUMENT_HASH · MODEL_VERSION · DATA_RECORD · EXTERNAL_ORACLE
data	object	Arbitrary decision payload — serialized, hashed, included in Merkle leaf
attestationId	string	Optional. Provide your own ID for correlation
pipelineId	string	Optional. Link attestations across a workflow pipeline

POST /v1/batch-attest

Submit up to 100,000 attestations in a single request. Constructs a Merkle forest and writes one HCS message regardless of batch size. ~0.13s for 1,000 items.

Field	Type	Description
items	array	Array of attestation objects. Same schema as /v1/attest

Verification Endpoints

GET /v1/verify/:id

Verify any attestation. O(1) lookup via local index with HCS mirror node fallback for full independent verification. No trust required.

GET /v1/health/deep

Full system health including HCS connectivity, latency, attestation index status, and memory.

Batch & Status

GET /v1/attestations

Paginated list of all attestations. Supports filtering by agentId, leafType, and time range.

GET /v1/attestations/:id

Retrieve full attestation record including Merkle proof path, signature hash, and HCS sequence number.

Agent Management

POST /v1/agents/register

Register an AI agent. Establishes identity, capability set, and reputation baseline for routing and trust scoring.

Cryptography

Post-Quantum
Security Model

Rubric Protocol is built on NIST-standardized post-quantum cryptography. Every attestation is resistant to both classical and quantum adversaries — permanently.

Security Level

ML-DSA-65 provides NIST Category 3 security — equivalent to AES-192. A quantum computer running Shor's algorithm cannot forge or retroactively invalidate any Rubric attestation.

ML-DSA-65 Digital Signatures

ML-DSA-65 (Module-Lattice Digital Signature Algorithm, formerly CRYSTALS-Dilithium) is the NIST post-quantum digital signature standard finalized in FIPS 204. Rubric uses it as the sole signing algorithm for all attestations.

Algorithm

CRYSTALS-Dilithium · Module lattice-based · FIPS 204

Security Level

NIST Category 3 · ~AES-192 equivalent

Public Key Size

1,952 bytes

Signature Size

3,293 bytes

Keypairs are generated once per node, encrypted at rest with AES-256-CBC using a passphrase, and never transmitted. The public key is published to HCS on initialization. All attestation batches are signed before HCS submission.

Merkle Forest Architecture

Individual attestations are not written to HCS one-by-one — that would be prohibitively expensive at scale. Instead, Rubric constructs a Merkle forest: a set of individual Merkle trees, one per pipeline or batch group, whose roots are then combined into a single forest root.

This means a batch of 100,000 attestations produces exactly one HCS write. The forest root represents the entire batch cryptographically — any individual leaf can be proven against it.

// Merkle forest construction (simplified)
const forest = new MerkleForest();

// Each item becomes a typed, nullified leaf
leaves.forEach(l => {
  const leaf = sha3_256(
    canonical_json({ type: l.leafType, data: l.data, nullifier: l.nullifier })
  );
  forest.addLeaf(leaf);
});

// One forest root — one HCS write
const { forestRoot, sigHash } = forest.computeRoot();
await hcsClient.submitMessage({ forestRoot, sigHash, zkProof: null });
  

Each leaf includes a nullifier — a unique value that prevents duplicate attestation attacks. Direction bits on proof paths ensure every leaf position is unique and tamper-evident.

Hedera Consensus Service Anchoring

The forest root and signature hash are submitted to HCS topic 0.0.8052848. Hedera's hashgraph consensus provides an immutable, globally-ordered timestamp — the attestation exists permanently in the public record.

Verification requires only the attestationId. Rubric maintains a local O(1) index for instant lookups. For fully independent verification, any party can query the HCS mirror node directly — no reliance on Rubric infrastructure required.

EU AI Act

Article 12
Compliance Guide

The EU AI Act requires providers and deployers of high-risk AI systems to maintain detailed records of system operation. Article 12 mandates automatic logging sufficient to enable post-hoc accountability. Rubric Protocol is designed to satisfy these requirements by default.

Enforcement Timeline

Article 12 record-keeping requirements apply from August 2026 for high-risk AI systems. Systems processing personal data, making consequential decisions (credit, employment, healthcare, law enforcement), or operating in critical infrastructure are subject to these requirements.

What Article 12 Requires

Article 12 of the EU AI Act mandates that high-risk AI systems automatically generate logs that enable monitoring for the duration of operation. Specifically:

Requirement	Rubric Implementation
Automatic logging of operation	Every decision submitted via /v1/attest is automatically recorded with timestamp, agent identity, and decision payload
Recording period and content	Attestations are permanently anchored to HCS — immutable, with Hedera consensus timestamp as authoritative record
Traceability of decisions	Each attestation includes agentId, leafType, pipelineId, and full data payload — complete decision lineage
Integrity of records	ML-DSA-65 signatures prevent tampering. Merkle proofs enable independent verification of any individual record
Access for competent authorities	Regulator portal provides read-only access to attestation records with cryptographic proof of authenticity

Audit Trail Architecture

A complete audit trail for an AI decision looks like this in Rubric Protocol:

01

Decision event captured

Your AI system submits the decision to Rubric PROOF with full context — model version, input hash, output, confidence score, and any rule applied.

02

Cryptographic commitment

Rubric constructs a SHA3-256 Merkle leaf with nullifier. The leaf is signed with ML-DSA-65. This creates a tamper-evident, quantum-resistant record of the exact decision state.

03

On-chain permanence

The Merkle forest root is submitted to Hedera Consensus Service. The HCS timestamp becomes the authoritative, globally-ordered record of when the decision occurred.

04

Regulator access

Competent authorities can query any attestation by ID and receive a cryptographic proof of authenticity — verifiable independently without Rubric's involvement.

Important

Rubric Protocol provides the technical infrastructure for Article 12 compliance. Organizations remain responsible for determining which AI systems are high-risk under their specific use case and for implementing appropriate governance processes. Consult legal counsel for compliance advice.

Federation

Multi-Node
Architecture

Rubric Protocol operates as a federated network of independent nodes. Each node maintains its own ML-DSA-65 keypair and participates in threshold consensus before HCS anchoring.

Current Network

2 nodes — US East (Vultr) · EU Central (Hetzner CCX23)

V2 Target

5 nodes — US East · EU Central · Asia Pacific · Canada · US West

Consensus

ML-DSA-65 threshold signatures · 3-of-5 for V2

Throughput

2.9M attestations/day at V2 · Linear horizontal scaling

Node Requirements

Each federation node requires:

Resource	Minimum	Recommended
vCPU	2 cores	4 dedicated cores
RAM	4 GB	16 GB
Storage	40 GB SSD	160 GB NVMe
Network	100 Mbps	1 Gbps
OS	Ubuntu 22.04+	Ubuntu 24.04

Threshold Consensus

Before any Merkle forest root is submitted to HCS, participating nodes must reach threshold consensus. Each node independently signs the forest root with its ML-DSA-65 key. Once the threshold is met (currently 2-of-2, V2: 3-of-5), the combined signature is anchored.

This means no single node can submit fraudulent attestations — consensus is required. Geographic distribution across jurisdictions also ensures no single regulatory action can take down the network.

SDK

@rubric-protocol/sdk

TypeScript SDK for direct integration. Full type definitions, AttestationsService, StorageService, and federation-aware routing built in.

npm install @rubric-protocol/sdk

Client Reference

    
import { RubricClient } from '@rubric-protocol/sdk';

const client = new RubricClient({
  apiKey: 'YOUR_API_KEY',
  network: 'testnet' // | 'mainnet'
});

// Services
client.attestations  // AttestationsService
client.storage       // StorageService
  

AttestationsService

Method	Description
attest(params)	Submit single attestation. Returns attestationId, sigValid, onChain
batchAttest(items)	Submit array of attestations. One HCS write regardless of size
verify(id)	Verify attestation by ID. Returns verified, sigValid, securityLevel
get(id)	Retrieve full attestation record with Merkle proof
list(filters)	Paginated list with agentId, leafType, date range filters

Examples

Batch attestation for high-volume systems

    
// Attest 10,000 decisions in one HCS write
const results = await client.attestations.batchAttest(
  decisions.map(d => ({
    agentId: 'logistics-optimizer-v2',
    leafType: 'AGENT_OUTPUT',
    data: d
  }))
);

// results.forestRoot  — single Merkle root for entire batch
// results.hcsSequence — HCS sequence number
// results.items[]     — individual attestationIds
  

Pipeline linking — connect decisions across a workflow

    
const pipelineId = 'loan-review-2026-03-09-001';

// Step 1: Model output
await client.attestations.attest({
  agentId: 'credit-model-v3',
  leafType: 'AGENT_OUTPUT',
  pipelineId,
  data: { score: 742, recommendation: 'APPROVE' }
});

// Step 2: Human review
await client.attestations.attest({
  agentId: 'underwriter-portal',
  leafType: 'HUMAN_REVIEW',
  pipelineId,
  data: { reviewerId: 'U-4421', decision: 'CONFIRMED' }
});

// Both linked by pipelineId — full decision lineage on-chain
  

Build onRubric Protocol.

Installation

First Attestation

Initialize the client

Attest a decision

Verify anytime

REST API

Base URL

Authentication

Attestation Endpoints

Verification Endpoints

Batch & Status

Agent Management

Post-QuantumSecurity Model

ML-DSA-65 Digital Signatures

Algorithm

Security Level

Public Key Size

Signature Size

Merkle Forest Architecture

Hedera Consensus Service Anchoring

Article 12Compliance Guide

What Article 12 Requires

Audit Trail Architecture

Decision event captured

Cryptographic commitment

On-chain permanence

Regulator access

Multi-NodeArchitecture

Current Network

V2 Target

Consensus

Throughput

Node Requirements

Threshold Consensus

@rubric-protocol/sdk

Client Reference

AttestationsService

Examples

Batch attestation for high-volume systems

Pipeline linking — connect decisions across a workflow

Build on
Rubric Protocol.

Post-Quantum
Security Model

Article 12
Compliance Guide

Multi-Node
Architecture