Submit pipeline

The admission path is message-centric and fail-closed.

Admission steps

  1. verify the Ed25519 message envelope
  2. structurally validate MessageData and the selected body
  3. apply the correct authorization rule for the message family
  4. run stateful validation
  5. admit to the mempool if all checks pass

Authorization split

Ordinary user messages require a delegated Ed25519 key registered to owner_address with sufficient scope.

Special cases:

  • SIGNER_ADD and SIGNER_REMOVE derive authority from custody proofs.
  • STORAGE_CLAIM requires finalized settlement verification. First successful application does not require a delegated key registered to owner_address.

All three families still require Ed25519 envelopes for transport integrity. Duplicate STORAGE_CLAIM replay stays marker-idempotent after settlement verification, so an already-consumed claim remains a no-op regardless of current delegated-key state.

Dual authorization

MERGE_REQUEST_REMOVE has a dual authorization path — the only message type with this pattern:

  1. Requester withdrawal — the original owner_address may close their own merge request without any target-project membership
  2. Maintainer closure — the target project owner or any collaborator with WRITE+ permission may close any merge request targeting that project

Both paths require a registered key with SIGNING scope.

Execution placement

Account-level messages execute first in serial order.

Project-level messages execute second, grouped by project_id in byte-lexicographic order.

There is no relay-era account pre-pass for injected system messages because Makechain has no injected system messages.