Reasons the relay will refuse a party's attempt to join a ceremony session.
SESSION_NOT_FOUND — no such session. It expired, or the host ended it
before this party acted on the nudge.
PARTY_ALREADY_CONNECTED — this partyId is already on record in the
session.
SESSION_IN_PROGRESS — the ceremony has already exchanged wire messages.
The remaining parties hold MPC round state that a fresh connection cannot
reconstruct, and nothing was buffered while the partyId was vacant. This
is what a party that dropped mid-ceremony hits on reconnect, since its own
disconnect released the partyId.
NOT_ACCOUNT_SIGNER — the session belongs to a Salt account this party is not a signer on
or it does sign on but the partyId it claimed belongs to a different signer.
A valid JWT is not sufficient to join a session;
it has to be the JWT of the signer holding that party index.
The relay can also refuse a join with NOT_REGISTERED, and a host attempt
with NOT_REGISTERED or INVALID_SESSION_TYPE. Those are deliberately absent
here: each means this SDK sent something malformed — it registers the party on
connect and passes the session type itself — so they are bugs to fix rather
than conditions an application can act on, and they propagate untyped.
Refusals of a host attempt are CeremonyHostError, not this type.
The two are disjoint: a join is judged against the signer set snapshotted
when the session was created, while hosting is what performs that lookup —
so only hosting can fail because the account could not be resolved or read.
Reasons the relay will refuse a party's attempt to join a ceremony session.
SESSION_NOT_FOUND— no such session. It expired, or the host ended it before this party acted on the nudge.PARTY_ALREADY_CONNECTED— thispartyIdis already on record in the session.SESSION_IN_PROGRESS— the ceremony has already exchanged wire messages. The remaining parties hold MPC round state that a fresh connection cannot reconstruct, and nothing was buffered while thepartyIdwas vacant. This is what a party that dropped mid-ceremony hits on reconnect, since its own disconnect released thepartyId.NOT_ACCOUNT_SIGNER— the session belongs to a Salt account this party is not a signer on or it does sign on but thepartyIdit claimed belongs to a different signer. A valid JWT is not sufficient to join a session; it has to be the JWT of the signer holding that party index.The relay can also refuse a join with
NOT_REGISTERED, and a host attempt withNOT_REGISTEREDorINVALID_SESSION_TYPE. Those are deliberately absent here: each means this SDK sent something malformed — it registers the party on connect and passes the session type itself — so they are bugs to fix rather than conditions an application can act on, and they propagate untyped.Refusals of a host attempt are CeremonyHostError, not this type. The two are disjoint: a join is judged against the signer set snapshotted when the session was created, while hosting is what performs that lookup — so only hosting can fail because the account could not be resolved or read.