Skip to content

What is DEXR?

In any environment with multiple instruments, partner institutions, and automated systems, every connection between two systems requires integration: matching data formats, negotiating access, maintaining dependencies. As the number of participants grows, so does the integration surface — adding a new instrument or partner means integrations with existing systems.

DEXR replaces that topology with a shared coordination layer. Each system integrates with DEXR easily — writers push encrypted payloads, readers pull. Adding a new participant requires N integration, not N × M.

What DEXR Does

DEXR is a neutral coordination registry — it brokers encrypted reference between parties, not the underlying files. The data stays in the sender's own storage.

The exchange works in two steps:

  1. A writer encrypts using the recipient's public key a reference (a download URL, an upload URL, or a set of small values) and addresses the encrypted payload in DEXR to a specific reader.
  2. A reader queries DEXR for the payload addressed to them, decrypts it using their private key, and follows the reference to retrieve the actual data from wherever it lives.

DEXR stores only encrypted ciphertext. The registry cannot read what it holds — even if the registry itself were compromised, payload contents remain protected. The actual files stay in the sender's own storage; DEXR only hands the reader the address.

The Encryption Model

DEXR uses a sealed-box model based on NaCl/libsodium (X25519 key exchange, XSalsa20-Poly1305 encryption). A writer encrypts using the reader's public key, so only the reader's private key can decrypt. There is no shared secret, no passphrase negotiated between parties, and no point at which DEXR or any intermediary holds the plaintext.

This design provides defense in depth: server-side access control determines who is allowed to retrieve a payload; end-to-end encryption ensures the contents are unreadable to anyone other than the addressed reader, regardless of what happens at the access control layer.

DEXR in the Five-Stage Workflow Pattern

Handoffs — of data, material or responsibility — are where integration complexity lives. The receiving system might be a lab instrument, a partner institution's compute environment, an edge device in a remote facility, or an automated pipeline — any of which may run on different infrastructure, speak different protocols, be owned by a different organization, or some or all of these. DEXR handles that boundary without requiring any of those systems to connect directly to each other.

This is possible because many workflows decompose into a sequence of five-step tasks.

Step 1. Capture: collects information from the entity — person or thing — commanding the work. Whether a researcher or an autonomous agent, this step captures from the entity the details of the task. The format for this capture step is tailored to the user, not the recipient.

Step 2. Convert: handles the transformation from a form native to the user to a run control artifact, a form native to the exector — the test machine, model/simulation, or whatever equipment will perform the task.

Step 3. Exchange: is mediated by DEXR. The writer pushes the encrypted payload and an artifact, often a physical object with a barcode or other identifier, is delivered to the executor. The barcode is scanned, triggering the reader to download and decrypt the payload.

Step 4. Execution: follows the content of the run control artifact. This artifact describes the executor's control plane: one-or-more input files, start conditions, end conditions, etc. — everything the executor must know to perform the task.

Step 5. Cleanup: finalizes the execution and prepares the system for the next object and the next task. In many contexts, the output from the executor is a result file. In addition to providing the run control artifact, the DEXR payload also provides information needed to push that result file into its final location, trigger the next event, or perform any other task.

See How Carta Works → for a full walkthrough of this pattern using Carta.

DEXR as an Entry Point

DEXR installations are independently deployable. An organization can adopt DEXR to solve a specific coordination problem — connecting instruments to a workflow, automating a handoff to a partner, delivering data to an edge device — without adopting the full Carta platform.

Because DEXR operates at the boundary where Carta hands off to the outside world, it is also a natural starting point. Organizations that adopt DEXR for one coordination problem often find Carta useful for the stages surrounding it: capturing the intent that drives the handoff, converting that intent into the artifact DEXR delivers, and recording the results that come back.