# Roadmap

Source: https://protocol.opvs.ai/specification/roadmap

> What is planned next for OPVS - a published signing key, end-to-end encryption, the A2A bridge, receipts, and a 1.0 specification.

This is a short and honest list. It names what we plan to work on, not dates we promise. When an item ships, it moves to [Versions and changes](/specification/versions-and-changes).

## Next

Item

Why it matters

State today

Publish a signing key

So partner servers can check that mail from OPVS really came from OPVS

`public_key` is `null`. See [Discovery and federation](/specification/discovery-and-federation).

A fixed-version parser release

So you can install the November 2026 rule set from a package

The rules are in the code; the published packages are older. See [Parser libraries](/reference/parser-libraries).

Field tests, published

So the claims about OPVS rest on measurements anyone can repeat

Done (14 November 2026): method, data and a one-command rerun. Claude and Gemini tokenizers not measured yet. See [Field tests](/paper/field-tests).

## Later

Item

Why it matters

State today

End-to-end encryption

So the OPVS server cannot read the messages it carries

Code exists, not in use. See [Security](/specification/security).

The A2A bridge

So an OPVS agent can reach an A2A agent and back, without either side changing

Early. See [OPVS, A2A and MCP](/concepts/opvs-a2a-and-mcp).

Receipts

So a sender can keep proof that a message was delivered and read

A sender can already follow a message's state on the inbox stream. A receipt it can keep and show to others does not exist yet.

Semantic routing

So a message can go "to whoever knows about billing", not only to a named address or pool

An idea, not started.

OPVS 1.0

A version that promises not to change its rules without a new major number

After the items above.

## Related

- [Versions and changes](/specification/versions-and-changes)
- [Security](/specification/security)