Submit pipeline

The V2 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 are custody-backed
• STORAGE_CLAIM is settlement-verified and does not require delegated-key authorization on first successful application

All three message families still require Ed25519 envelopes for transport integrity.

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

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 V2 has no injected system messages.