Trust & Verification

How to read this page

How license-check works

Today Live the relay's entitlement is an offline license. Your PLK_KEY is a license token signed by Paramant (Ed25519) that the relay verifies locally against an embedded public key. It carries a user cap, an expiry and who it was issued to. The relay does not phone home to validate it: with no key, or an expired one, the relay simply runs as Community Edition (5 users). Nothing leaves your server to check a license.

Planned Planned to sell tiers with capabilities beyond a user-count, the design adds an online license-check. Under that model your relay calls a Paramant licensing endpoint at startup and every 6 hours. The request carries your license-key, a relay-identity (the fingerprint of the ML-DSA-65 public key your relay generates on first boot), the relay version, and a telemetry block that is off by default.

The response is a signed capability-set — which features your tier unlocks — valid for a few hours. Your relay verifies the ML-DSA-65 signature against an embedded Paramant licensing key; an unsigned or invalid response is rejected. If the licensing endpoint is unreachable, the relay keeps using its last cached capability-set for up to 7 days, then degrades to Community mode. There are no surprise lockouts: an outage on our side cannot instantly disable your relay.

Full wire-protocol specification: ADR R013 (Draft) in the public ADR directory.

What Paramant sees of your relay

With today's offline license, the answer is simple: nothing at runtime — the relay makes no licensing call. The breakdown below describes the Planned online model, so you can judge it before it ships.

Always (each check-in)

• Your license-key — how we identify your subscription
• Your relay's identity fingerprint (ML-DSA-65 public-key hash)
• Your relay's version number
• The timestamp of the check-in

Only if you opt in (telemetry, off by default)

• Aggregate user count — a number, never identities
• Aggregate transfer count per 24h — a number, never hashes
• Error rates (5xx rate, auth-failure rate)
• Uptime

Never — even with telemetry on

• File content — we do not hold your decryption keys, anywhere
• Identities of your users (emails, names)
• File hashes — they would link to specific transfers
• Source or destination addresses of your transfers
• CT-log content beyond aggregate counts

Planned Before telemetry can be enabled, the admin panel will show a preview of the exact payload your relay would send, with no hidden fields, so opting in is an informed choice rather than a blind toggle.

How to verify your deployment

You do not have to trust these statements — the public surface lets you check them.

1. Source Live

Everything that runs on your server is in the public GitHub repository under BUSL-1.1: the relay, the admin panel, the SDKs, and the license-client code that does the check-in. You can read exactly what your relay does — including every field it would send — and build it yourself:

git clone https://github.com/Apolloccrypt/paramant-relay
cd paramant-relay
git checkout v3.0.0
docker compose build   # build locally instead of pulling the published image

2. Published image Live

The Docker Hub image is built from that repository by the project's public GitHub Actions workflow. You can compare a locally built image against the published tag, or skip the published image entirely and run your own build.

3. Signed releases Planned

Cryptographically signed release artifacts (so you can verify provenance without a local rebuild) are part of the supply-chain design but not yet in place. Once live, verification will look like:

cosign verify mtty001/relay:3.0.0 \
  --key https://paramant.app/.well-known/paramant-release.pub

Release-signing and supply-chain integrity are tracked in the release-process ADR (R015, in progress) in the public ADR directory.

4. Behaviour Live

Every transfer your relay handles is appended to its own public Certificate Transparency log, a signed Merkle tree you can inspect and archive independently. The relay's logs record its outbound calls; once online license-check ships, each check-in is logged too, so you can watch what your relay sends.

What Paramant can do remotely

The remote-action model below is Planned — specified, not yet implemented. The structural limits in "Not possible", however, hold Live today, because they follow from the architecture rather than from policy.

In the design, every remote action is recorded to your relay's own CT log, where you can verify it independently: you see what was done, when, and by which Paramant role (Owner or Support). Our internal audit-trail additionally records which individual acted, but that record is private to us.

Possible remote actions (planned)

Issue a short-lived support key

A time-boxed key for debugging an issue you reported. You can revoke it immediately from your admin panel.

Offer an update

Make a new release available to your relay. How it applies follows your tier: a banner you act on, an opt-in update window, or explicit approval — never a silent push you did not agree to.

Set drain mode

Ask the relay to refuse new uploads, finish in-flight transfers, then idle — used ahead of maintenance.

Adjust your capability-set

Apply a tier change (trial extension, upgrade after payment). It takes effect on the next check-in.

Not possible — structurally Live

• Read your file content — we never hold decryption keys, anywhere
• Rewrite your CT log after the fact — Merkle-tree integrity prevents it
• Bypass your local TOTP or admin key — there is no backdoor in the source, and the source is public
• Reach your users' data or another deployment — relays are isolated by design
• Switch off your audit log — CT-log writes are not gated by any capability

Remote-action protocol: the management-plane ADR (R014, in progress) in the public ADR directory.

Open-core: what is open, what is closed

Paramant follows the open-core model used by HashiCorp, GitLab, Elastic and Sentry: the software you run is open; the service operating it is not.

Open — BUSL-1.1, public on GitHub Live

• The relay — everything that runs on your server
• The SDKs and CLI tools
• The frontend — admin panel, setup wizard, dashboard
• The license-client — the check-in code on your relay
• All ADRs, including the licensing and management-plane protocols
• The cryptographic specification and test vectors

View the public repository →

Closed — operated privately by Paramant

• The license-server — the service side of the check-in
• The internal fleet-management dashboard
• The customer and billing databases
• Support tooling and email templates

The protocols are public; only our implementation of the server side is private — the same way GitLab keeps its operations private while its core stays open. Because the protocol and the client are open, you can audit exactly what your relay says to us and what it accepts back.

The open-core split is documented in the open-core ADR (R016) in the public ADR directory.

Independent verification

Three external security audits in April 2026 reviewed the relay code; the findings and patch timeline are on the security page. A further external review of the v3.0.0 and open-core architecture is planned; results will be published there when complete.

If you are running your own audit, the public surface — relay, SDKs, frontend and the protocol specifications — is enough to verify every claim on this page for yourself.

Questions

Security reports and questions: privacy@paramant.app. For sensitive material, our PGP key and full policy are in security.txt.

General questions: privacy@paramant.app.

Commercial and license questions: see pricing or email hello@paramant.app.