Back to Blog
Technical

Building on Protocol Labs: Our Technology Stack Explained

Which Protocol Labs components the platform actually depends on, and what each one is doing.

Suraj Kumar
November 15, 2025
9 min read

The Protocol Labs Ecosystem

Almost nothing in the storage layer is ours. This post is the inventory. It covers what each Protocol Labs component does here, and the one part of the storage layer that is ours, the sealed envelope every upload is wrapped in.

IPFS: Content Addressed Storage

At the core of Ekayana is IPFS (InterPlanetary File System). The API talks to Kubo through its RPC, behind IPFS Cluster, which keeps the pin set in step across the platform's peers.

  • Every stored object is identified by the hash of its bytes, as a CIDv1.
  • An upload is sealed before it is added, so its CID names the encrypted envelope rather than the file.
  • Sealing gives every upload a fresh key, so identical files do not deduplicate, and one upload reveals nothing about another.
  • Any modification changes the content identifier, so tampering is evident.
typescript
// Upload to IPFS as a multipart form, with no SDK involved
const body = new FormData();
body.append('file', file);

const res = await fetch('https://api.ekayana.io/api/upload', {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}` },
  body,
});

const { cid } = await res.json();
// A synchronous upload also returns the CID in the X-CID response header.

IPNS: Names That Move

A CID never changes, which is the point, and a dataset that gets revised needs a name that can. The platform creates an IPNS name for a file on request and moves it when a new version is uploaded, keeping every earlier CID as a version.

IPLD and DAG-CBOR

The sealed envelope is a DAG-CBOR map of four fields, the format version, the nonce, the ciphertext and the wrapped content key. UCAN tokens are DAG-CBOR too, which is why a token's identifier is the CID of its bytes.

Multiformats

CIDs, multibase strings and multicodec prefixes come from the multiformats family. The same family gives did:bio documents their Multikey encoding, in which z6Mk marks an Ed25519 key.

UCAN: Decentralized Authorization

User Controlled Authorization Networks give three properties.

  • Permissions travel in signed tokens, so a signature can be checked without asking the issuer.
  • Delegation chains pass permissions along without a central authority.
  • Capabilities are defined precisely, so control is fine grained.

Ekayana implements UCAN 1.0 in its own pq-ucan crate. The service still records every pass and checks it for revocation before it acts, so on this platform a pass is presented to the API rather than verified offline.

Architecture Diagram

Application LayerResearcherwalletEkayana APIBrowser applicationNext.jsAuthorization LayerUCAN 1.0 (pq-ucan)wallet-signed delegationsSession keysbrowser key signs read invocationsIdentity Layerdid:bio documentsW3C DID 1.0Owned subjectswallet-created PDAsbio-did-registrySolana programStorage LayerPrivate IPFS clusterpinned on every peerSealed payloadsAES-GCM, ML-KEM-1024 wrapPostgresrecords, passes, sessionsIntegrationDataversedemo and HarvardBioAgentsElizaOSOpenAI / AnthropicAI routes, agent modelauthorizederive and anchorseal and storeproxy
Ekayana's layers, with the Protocol Labs components in the storage layer

Why This Stack?

  • Integrity you can check. Every object is named by its hash.
  • Open specifications. DIDs, UCAN, IPFS and the multiformats are published, and more than one team implements each of them.
  • Active development. The upstream projects are maintained by Protocol Labs and the wider community.

Learn more in our Protocol Labs Integration documentation.

Ready to Get Started?

Explore our documentation to learn how to integrate Ekayana into your research workflow.