Reference
Protocol Quick Reference
This page is not normative
This page is not considered a core part of the Vultron Protocol as proposed in the main documentation. Although within the page we might provide guidance in terms of SHOULD, MUST, etc., the content here is not normative.
This page is a single-stop summary of the Vultron Protocol's state machines, message types, and their interactions. It is intended for implementers who want a consolidated view before diving into the detailed, normative pages.
The authoritative source for everything summarized here is the Vultron Protocol Specification, with the Formal Protocol pages — States, Messages, and Transitions — carrying the formal treatment and the protocol requirements the normative statements. Where this page and any of those disagree, the specification wins.
State Machines at a Glance
Every Participant tracks five state machines (§12.2 Capability Sets). Two of them, the vendor fix path (VFD) and the public state (PXA), together make up the Case State (CS), which the formal protocol pages write as one six-letter string.
| State Machine | Scope | States | Initial | Terminal |
|---|---|---|---|---|
| RM — Report Management | Per Participant | Start (S), Received (R), Invalid (I), Valid (V), Deferred (D), Accepted (A), Closed (C) |
S (Start) |
C (Closed) |
| EM — Embargo Management | Per case | None (N), Proposed (P), Active (A), Revise (R), eXited (X) |
N (None) |
X (eXited) |
| PEC — Participant Embargo Consent | Per Participant, per embargo | Uninvited, Invited, Agreed, Declined, Timed out; signatory and lapsed are reads, not states | Uninvited | none; a row is frozen once its embargo's register entry is final |
| VFD — Vendor fix path (CS) | Per Participant | Three one-way binary substates in order vfd: Vendor aware (v→V), Fix ready (f→F), Fix deployed (d→D) |
vfd |
VFD |
| PXA — Public state (CS) | Per case | Three one-way binary substates in order pxa: Public aware (p→P), eXploit public (x→X), Attacks observed (a→A) |
pxa |
PXA |
The specification names the EM states Revise and eXited as Revised and Exited (§7.1 States); the shorthand letters are the same. PEC is specified in §9 Participant Embargo Consent (PEC) State Machine and explained in the Embargo Lifecycle.
The formal protocol's triple
The Formal Protocol pages model the RM, EM, and CS machines and write a Participant's state as the triple \(S_i = (q^{rm}, q^{em}, q^{cs})\), where \(q^{cs}\) is the six-letter CS string vfdpxa that combines VFD and PXA.
PEC is not part of the triple.
The triple is the form the transition tables below use.
Reading CS states
Each CS substate is monotonic: it changes in one direction only
(lowercase → uppercase) and never reverts. The full CS state is the
combination of all six substates, always written in the order
vfdpxa. A dot (\(\cdot\)) is a single-position wildcard — e.g.
\(Vfd\cdot\cdot\cdot\) matches any CS state whose Vendor-awareness
substate is V, regardless of the public substates.
Message Types at a Glance
Occasion table
Each row of the occasion table is a situation in a case, with the ActivityStreams 2.0 (AS2) activity that conveys it, whom to send it to, who may send it, and the section that documents it. The table is generated from the semantic registry, the list of patterns that semantic extraction matches each inbound activity against.
Report
| When… | Send | Send to | Sent by | Distinguished by | Details |
|---|---|---|---|---|---|
| a Reporter has written up a vulnerability and is about to submit the report | Create(VulnerabilityReport) |
an actor outside any case | any actor (usually: reporter) | — | Create report |
| a Reporter submits a vulnerability report to a Vendor or Coordinator | Offer(VulnerabilityReport) |
an actor outside any case | any actor (usually: reporter) | — | Report Submission (RS) |
| a report receiver has read a submitted report | Read(Offer(VulnerabilityReport)) |
an actor outside any case | the addressee of the vulnerability report offer (usually: vendor, coordinator) | — | Report Acknowledgment (RK) |
| a report receiver judges the report valid | Accept(Offer(VulnerabilityReport)) |
the case manager | a participant (usually: vendor, coordinator) | — | Validate report |
| a report receiver judges the report invalid | TentativeReject(Offer(VulnerabilityReport)) |
the case manager | a participant (usually: vendor, coordinator) | — | Invalidate report |
| a report receiver closes a report no case holds | Reject(Offer(VulnerabilityReport)) |
an actor outside any case | the addressee of the vulnerability report offer (usually: vendor, coordinator) | — | Close report |
| a Participant accepts the case for further action | Join(VulnerabilityCase) |
the case manager | a participant | — | Report/Case Accepted (RA) |
| a Participant defers further action on the case | Ignore(VulnerabilityCase) |
the case manager | a participant | — | Report/Case Deferred (RD) |
Case proposal
| When… | Send | Send to | Sent by | Distinguished by | Details |
|---|---|---|---|---|---|
| a report receiver asks a Case Actor Service to open a case for a report | Create(CaseProposal) |
an actor outside any case | the case proposal's author (usually: vendor, coordinator) | — | Create case proposal |
| a Case Actor Service agrees to open the proposed case | Accept(CaseProposal) |
an actor outside any case | the addressee of the case proposal | — | Accept case proposal |
| a Case Actor Service declines to open the proposed case | Reject(CaseProposal) |
an actor outside any case | the addressee of the case proposal | — | Reject case proposal |
Case and participants
| When… | Send | Send to | Sent by | Distinguished by | Details |
|---|---|---|---|---|---|
| the Case Manager has opened a case for a submitted report | Create(VulnerabilityCase) |
a participant | the addressee of the case proposal or vulnerability report offer | — | Create case |
| the Case Owner links a further report to an existing case | Add(VulnerabilityReport)[target=VulnerabilityCase] |
the case manager | the case owner | — | Add report to case |
| the Case Manager records the new Case Owner once a case ownership transfer is accepted | Update(VulnerabilityCase) |
a participant | not handled | — | Update case owner |
| the Case Owner offers a CVD role on the case to another participant | Offer(CaseParticipantRole)[context=VulnerabilityCase] |
the case manager | the case owner | — | Offer case participant role |
| a participant accepts a role offered to it on the case | Accept(Offer(CaseParticipantRole)[context=VulnerabilityCase]) |
the case manager | the addressee of the case participant role offer | — | Accept case participant role |
| a participant declines a role offered to it on the case | Reject(Offer(CaseParticipantRole)[context=VulnerabilityCase]) |
the case manager | the addressee of the case participant role offer | — | Reject case participant role |
| the Case Owner proposes to transfer ownership of the case to another actor | Offer(Offer(VulnerabilityCase)) |
the case manager | the case owner | — | Propose case ownership transfer |
| the Case Manager offers the case to the actor the Case Owner proposed | Offer(VulnerabilityCase) |
a participant | the case manager | — | Offer case ownership transfer |
| an actor accepts an offer of case ownership | Accept(Offer(VulnerabilityCase)) |
the case manager | the addressee of the vulnerability case offer | — | Accept case ownership transfer |
| an actor declines an offer of case ownership | Reject(Offer(VulnerabilityCase)) |
the case manager | the addressee of the vulnerability case offer | — | Reject case ownership transfer |
| the Case Owner withdraws its proposal while the offer of case ownership is open | Undo(Offer(Offer(VulnerabilityCase))) |
the case manager | the case owner | — | Withdraw case ownership transfer |
| the Case Manager invites an actor to join the case | Invite(Actor)[target=VulnerabilityCaseStub] |
a participant | the case manager | — | Invite actor to case |
| an invited actor agrees to join the case | Accept(Invite(Actor)[target=VulnerabilityCaseStub]) |
the case manager | the invitee | — | Accept invite to case |
| an invited actor declines to join the case | Reject(Invite(Actor)[target=VulnerabilityCaseStub]) |
the case manager | the invitee | — | Reject invite to case |
| the Case Manager has replayed the case ledger to a newly joined Participant | Invite(Actor)[target=VulnerabilityCase] |
a participant | the case manager | — | Send Full-Case Invite |
| a Participant asked by a Full-Case Invite judges the case valid | Accept(Invite(Actor)[target=VulnerabilityCase]) |
the case manager | the invitee | — | Accept Full-Case Invite |
| a Participant asked by a Full-Case Invite judges the case invalid | TentativeReject(Invite(Actor)[target=VulnerabilityCase]) |
the case manager | the invitee | — | Tentatively reject Full-Case Invite |
| a Participant asked by a Full-Case Invite closes the case | Reject(Invite(Actor)[target=VulnerabilityCase]) |
the case manager | the invitee | — | Reject Full-Case Invite |
| the Case Manager has admitted a new Participant to the case | Announce(VulnerabilityCase) |
a participant | the case manager | — | Announce vulnerability case |
| a Participant ends its participation in the case | Leave(VulnerabilityCase) |
the case manager | the case owner or a participant | — | Close case |
| the Case Owner reinstates a removed Participant | Add(CaseParticipant)[target=VulnerabilityCase] |
the case manager | the case owner | — | Add case participant to case |
| the Case Owner removes a Participant from active participation | Remove(CaseParticipant)[target=VulnerabilityCase] |
the case manager | the case owner | — | Remove case participant from case |
| the Case Manager creates a participant record, such as the inert record for the invitee of a stub Invite | Create(CaseParticipant) |
a participant | not handled | — | Create case participant |
| the Case Manager changes a participant record, such as moving the CASE_OWNER role on an ownership transfer | Update(CaseParticipant) |
a participant | not handled | — | Update case participant |
Embargo
| When… | Send | Send to | Sent by | Distinguished by | Details |
|---|---|---|---|---|---|
| the Case Owner terminates the active embargo | Remove(Event) |
the case manager | the case manager or the case owner | — | Embargo Termination (ET) |
| the Case Manager ends the active embargo, on its own decision or on the Case Owner's | Remove(Event) |
a participant | the case manager | — | Tell a participant the embargo has ended |
| the Case Manager states the terms of the embargo in force | Announce(Event)[context=VulnerabilityCase] |
a participant | the case manager | register status of the named embargo ACTIVE |
Announce embargo |
| the Case Manager has applied an Embargo Termination a Case Owner sent before the end time | Announce(Event)[context=VulnerabilityCase] |
a participant | the case manager | register status of the named embargo TERMINATED |
Announce embargo termination |
| a Participant proposes embargo terms for a case with no active embargo | Invite(Event)[context=VulnerabilityCase] |
the case manager | the case manager or an active participant | EM state NONE or PROPOSED |
Embargo Proposal (EP) |
| a Participant proposes revised terms for the active embargo | Invite(Event)[context=VulnerabilityCase] |
the case manager | the case manager or an active participant | EM state ACTIVE or REVISE |
Embargo Revision Proposal (EV) |
| the Case Manager asks a Participant to answer embargo terms another Participant proposed | Invite(Event)[context=VulnerabilityCase] |
a participant | the case manager | — | Ask a participant about proposed embargo terms |
| a Participant agrees to proposed embargo terms | Accept(Invite(Event)[context=VulnerabilityCase]) |
the case manager | the invitee | EM state PROPOSED |
Embargo Proposal Acceptance (EA) |
| a Participant agrees to a proposed embargo revision | Accept(Invite(Event)[context=VulnerabilityCase]) |
the case manager | the invitee | EM state REVISE |
Embargo Revision Acceptance (EC) |
| a Participant refuses proposed embargo terms | Reject(Invite(Event)[context=VulnerabilityCase]) |
the case manager | the invitee | EM state PROPOSED |
Embargo Proposal Rejection (ER) |
| a Participant refuses a proposed embargo revision | Reject(Invite(Event)[context=VulnerabilityCase]) |
the case manager | the invitee | EM state REVISE |
Embargo Revision Rejection (EJ) |
| the Case Manager abandons an open embargo proposal once the case is public, an exploit is public or attacks are observed | Undo(Invite(Event)[context=VulnerabilityCase]) |
a participant | not handled | — | Withdraw an embargo invitation |
| the Case Owner decides to activate a proposed embargo | Accept(Event)[target=VulnerabilityCase] |
the case manager | the case owner | — | Activate embargo |
| the Case Owner decides to reject a proposed embargo | Reject(Event)[target=VulnerabilityCase] |
the case manager | the case owner | — | Reject embargo proposal |
| a Participant bound by the active embargo stops complying with it | Leave(Event)[context=VulnerabilityCase] |
the case manager | a participant | — | Withdraw from embargo |
| the Case Manager has created a case and, with it, an embargo such as the default embargo | Create(EmbargoEvent) |
a participant | not handled | — | Create embargo event |
| the Case Manager creates a participant's consent row for an embargo, such as the UNINVITED row a proposal writes | Create(EmbargoConsent) |
a participant | not handled | — | Create embargo consent |
| the Case Manager changes a participant's consent row, such as an invitation timing out, the rows carried over at activation or a change of its own consent | Update(EmbargoConsent) |
a participant | not handled | — | Update embargo consent |
Case status
| When… | Send | Send to | Sent by | Distinguished by | Details |
|---|---|---|---|---|---|
| the Case Manager records that the public knows of the vulnerability | Add(CaseStatus)[target=VulnerabilityCase] |
a participant | the case manager | pxaState = Pxa |
Public awareness in a case status |
| the Case Manager records that an exploit for the vulnerability is public | Add(CaseStatus)[target=VulnerabilityCase] |
a participant | the case manager | pxaState = PXa |
Exploit public in a case status |
| the Case Manager records that attackers are exploiting the vulnerability | Add(CaseStatus)[target=VulnerabilityCase] |
a participant | the case manager | pxaState = pxA |
Attacks observed in a case status |
| a Vendor becomes aware of the vulnerability | Add(ParticipantStatus)[target=CaseParticipant] |
the case manager | the case manager or the case owner or the participant status's author (usually: vendor) | vfState = Vf |
Vendor Awareness (CV) |
| a Vendor has a fix ready | Add(ParticipantStatus)[target=CaseParticipant] |
the case manager | the case manager or the case owner or the participant status's author (usually: vendor) | vfState = VF |
Fix Readiness (CF) |
| a Deployer has deployed the fix | Add(ParticipantStatus)[target=CaseParticipant] |
the case manager | the case manager or the case owner or the participant status's author (usually: deployer) | dState = D |
Fix Deployed (CD) |
| a Participant learns that the public knows of the vulnerability | Add(ParticipantStatus)[target=CaseParticipant] |
the case manager | the case manager or the case owner or the participant status's author | caseStatus.pxaState = Pxa |
Public awareness in a participant status |
| a Participant learns that an exploit for the vulnerability is public | Add(ParticipantStatus)[target=CaseParticipant] |
the case manager | the case manager or the case owner or the participant status's author | caseStatus.pxaState = PXa |
Exploit public in a participant status |
| a Participant observes attacks that exploit the vulnerability | Add(ParticipantStatus)[target=CaseParticipant] |
the case manager | the case manager or the case owner or the participant status's author | caseStatus.pxaState = pxA |
Attacks observed in a participant status |
General
| When… | Send | Send to | Sent by | Distinguished by | Details |
|---|---|---|---|---|---|
| a Participant suggests an actor that the case should include | Offer(Actor)[target=VulnerabilityCase] |
the case manager | a participant | sender is not the case owner | Suggest actor to case |
| the Case Owner decides to invite an actor to the case | Offer(Actor)[target=VulnerabilityCase] |
the case manager | a participant | sender is the case owner | Ask the Case Manager to invite an actor |
| the Case Manager presents a suggested actor to the Case Owner | Offer(CaseParticipant)[target=VulnerabilityCase] |
a participant | the case manager | — | Offer case participant |
| the Case Owner approves a suggested actor | Accept(Offer(CaseParticipant)[target=VulnerabilityCase]) |
the case manager | the case owner | — | Accept case participant offer |
| the Case Owner declines a suggested actor | Reject(Offer(CaseParticipant)[target=VulnerabilityCase]) |
the case manager | the case owner | — | Reject case participant offer |
| the Case Manager tells a recommender that the actor it suggested will be invited | Accept(Offer(Actor)[target=VulnerabilityCase]) |
a participant | the case manager | — | Accept actor recommendation |
| the Case Manager tells a recommender that the Case Owner declined the actor it suggested | Reject(Offer(Actor)[target=VulnerabilityCase]) |
a participant | the case manager | — | Reject actor recommendation |
| a Participant posts a note to the case | Add(Note)[target=VulnerabilityCase] |
the case manager | an active participant | — | Add note to case |
| a note's author or the Case Owner withdraws a note from the case | Remove(Note)[target=VulnerabilityCase] |
the case manager | the case owner or the note's author | — | Remove note from case |
Faults and acknowledgments
| When… | Send | Send to | Sent by | Distinguished by | Details |
|---|---|---|---|---|---|
| a Participant has received a message it cannot process | Create(ProcessingFault) |
the case manager | not yet checked | — | Create processing fault |
| the Case Manager has refused a participant's assertion because a precondition did not hold | Reject(Activity) |
a participant | the case manager | — | Refusal notice |
Ledger replication
| When… | Send | Send to | Sent by | Distinguished by | Details |
|---|---|---|---|---|---|
| the Case Manager has committed a case event to the case ledger | Announce(CaseLedgerEntry) |
a participant | the case manager | — | Announce case ledger entry |
| a received ledger entry does not chain onto the Participant's own ledger | Reject(CaseLedgerEntry) |
the case manager | an active participant, including one that has left the case | — | Reject case ledger entry |
Formal message set
The formal message set is \(M_{i,j} = M^{rm} \cup M^{em} \cup M^{cs} \cup M^{*}\), each defined in §4 Semantic Layer — Message Meanings in the specification. The table below lists each type with the wire activities that carry it, and is generated from the same registry as the occasion table. The state transition that emits each type is on Messages, and the response the formal protocol expects from a recipient is on Transitions.
The formal set and the wire vocabulary are many-to-many (Mapping status).
Several types share one wire activity, as EP and EV share Invite(Event), and the occasion's section states what tells them apart.
A type whose row reads "none" has no wire activity of its own: Faults and Acknowledgments describes the fault reporting and the cumulative hash-chain acknowledgment that replace such types.
State Transition Summary
The tables below give the sender-side transitions — the state change a Participant undergoes when it emits each message. Full sender and receiver transition tables (including error and out-of-embargo cases) are in Transitions.
RM transitions
| From | Event | To | Message |
|---|---|---|---|
A |
(already accepted) | A |
RS |
R |
invalid (\(i\)) | I |
RI |
{R,I} |
valid (\(v\)) | V |
RV |
{V,A} |
defer (\(d\)) | D |
RD |
{V,D} |
accept (\(a\)) | A |
RA |
{R,I,D,A} |
close (\(c\)) | C |
RC |
EM transitions
| From | Event | To | Message |
|---|---|---|---|
{N,P} |
propose (\(p\)) | P |
EP |
P |
reject (\(r\)) | N |
ER |
P |
accept (\(a\)) | A |
EA |
A |
propose revision (\(p\)) | R |
EV |
R |
reject revision (\(r\)) | A |
EJ |
R |
accept revision (\(a\)) | A |
EC |
{A,R} |
terminate (\(t\)) | X |
ET |
CS transitions
Each substate advances once, in the order shown, and never reverts.
| From | Event | To | Message |
|---|---|---|---|
| \(vfd\cdot\cdot\cdot\) | Vendor aware (\(\mathbf{V}\)) | \(Vfd\cdot\cdot\cdot\) | CV |
| \(Vfd\cdot\cdot\cdot\) | Fix ready (\(\mathbf{F}\)) | \(VFd\cdot\cdot\cdot\) | CF |
| \(VFd\cdot\cdot\cdot\) | Fix deployed (\(\mathbf{D}\)) | \(VFD\cdot\cdot\cdot\) | CD |
| \(\cdot\cdot\cdot p\cdot\cdot\) | Public aware (\(\mathbf{P}\)) | \(\cdot\cdot\cdot P\cdot\cdot\) | CP |
| \(\cdot\cdot\cdot\cdot x\cdot\) | Exploit public (\(\mathbf{X}\)) | \(\cdot\cdot\cdot\cdot X\cdot\) | CX |
| \(\cdot\cdot\cdot\cdot\cdot a\) | Attacks observed (\(\mathbf{A}\)) | \(\cdot\cdot\cdot\cdot\cdot A\) | CA |
Cross-model interactions
Public/exploit/attack CS transitions can force an embargo to end: a
Participant that learns the vulnerability or an exploit for it is
public SHALL initiate embargo termination (ET), and a Participant
that becomes aware of attacks SHOULD do so. Conversely, a
Vendor receiving a report (RS) it did not previously know about
transitions \(vfd\cdot\cdot\cdot \xrightarrow{\mathbf{V}}
Vfd\cdot\cdot\cdot\) and responds with both RK and CV. See
Transitions for the full set of
coupled transitions.
Actor Roles Summary
All Participants share the same message vocabulary and the same five state machines; roles differ in where they start and which messages they typically originate. The roles are defined in §2.2 Roles in the specification; see States for the per-role reachable state spaces and start states. Finder is not a protocol role: an actor that discovers a vulnerability and reports it holds the Reporter role (ADR-0078).
| Role | RM start | Typically sends | Typically receives |
|---|---|---|---|
| Reporter | A (Accepted) |
RS (the initial report), embargo proposals (EP/EV), observations (CP/CX/CA) |
RK, CV, RM status, embargo negotiation |
| Vendor | S (Start) |
CV (own awareness), CF (fix ready), own RM status (RV/RA/RC…), embargo messages |
RS, RK, embargo negotiation, CS updates |
| Coordinator | S (Start) |
RS (forwarding reports), GI, embargo proposals, CP |
reports and effectively any message type — a Coordinator facilitates across Participants |
| Deployer | S (Start) |
CD (fix deployed), acknowledgments |
CV, CF, RS |
| Observer | S (Start) |
observations (CP/CX/CA), acknowledgments, embargo consent |
every case-scoped message; an Observer tracks state but drives no VFD transition |
Who may send what
- A Participant MUST be in RM Accepted (
A) to send a report (RS) to someone else. - Vendor Awareness (
CV) SHOULD be sent only by Participants with direct knowledge of the notification — the Participant who sent the report to the Vendor, or the Vendor itself on receipt. CF(Fix Readiness) is usually sent by a Vendor andCD(Fix Deployed) usually by a Deployer, but the protocol does not forbid other Participants from relaying them.
Where to Go Next
- Vultron Protocol Specification — the normative definition of every state machine, message, and role summarized here.
- States — full state definitions, reachable/unreachable states, and per-role state spaces.
- Messages — message-type definitions, descriptions, and the combined "Message Type Redux" table.
- Message Types — the occasion table, from a situation in a case to the wire activity that conveys it.
- Transitions — complete sender and receiver transition functions, including error handling and cross-model interactions.
- Protocol Summary — the formal protocol tuple pulled together.
- Protocol Specification — the normative RMB/EMB/CSB requirements referenced throughout the transition tables.