feat(sidecar): sign-tx task family (gov vote / submit-proposal / deposit)

[bdchatham]

Problem

The sidecar's task engine today exposes lifecycle, query, and one-shot mutation tasks but no chain-transaction-signing tasks. To enable in-pod governance operations (the migration target for slanders/seienv once validators move to Kubernetes), the sidecar needs a task family that signs and broadcasts Cosmos SDK messages using the mounted operator-account keyring.

seienv today SSHes into validator hosts and runs printf "12345678\n" | sudo /root/go/bin/seid tx gov vote ... — works for EC2 + systemd, doesn't translate to containers. The sidecar should sign in-process using Cosmos SDK libraries, not shell out to seid. Precedent: sidecar/tasks/generate_gentx.go already imports sei-cosmos/client/tx and sei-cosmos/crypto/keyring and signs gentx transactions via library calls.

Impact

• Final on-cluster execution piece for K8s validator governance flows.
• Establishes the pattern for future tx-signing tasks (staking, distribution, IBC).
• Replaces the SSH + seid tx shell-out pattern from slanders/seienv.

⚠️ Security posture during the gap before authn lands

This task family is being shipped before sidecar API authentication (sister issue: "Sidecar authn + authz middleware on mutating endpoints"), which is the explicit last item in this sequence per a deliberate team scheduling decision.

The current deployment posture treats the sidecar API as accessible only to actors with kubectl-exec / port-forward / cluster-network access — parallel to today's SSH-key boundary on EC2 hosts in the seienv flow (anyone with the SSH key has equivalent power; here, anyone with cluster network access does).

Operators MUST NOT expose the sidecar API to multi-tenant clusters or untrusted in-cluster workloads until the authn issue lands. Acceptance criterion below includes a warning comment at the top of each new task handler referencing the authn issue.

Relevant experts

• blockchain-developer — Msg semantics, fee/gas calculation, account sequence handling
• platform-engineer — task engine integration, idempotency, error handling
• security-specialist — review of pre-authn warning comments + chain-confusion guard

Proposed approach

Library-based signing (NOT shell-out to seid binary) using the SDK packages already in go.mod. Pattern follows sidecar/tasks/generate_gentx.go.

1. New task types in sidecar/engine/types.go:
   • TaskTypeGovVote — params: proposalId, option (yes|no|abstain|no_with_veto), keyName, memo (opt), gasFees (opt)
   • TaskTypeGovSubmitProposal — params: proposalType (initially software-upgrade), proposal-specific subparams, keyName, deposit, memo, gasFees
   • TaskTypeGovDeposit — params: proposalId, amount, keyName, gasFees
2. Handlers in sidecar/tasks/gov_vote.go, gov_submit_proposal.go, gov_deposit.go. Shared helper sidecar/tasks/sign_and_broadcast.go:
   • Builds client.Context from sidecar env + keyring factory (sister issue: "production keyring backend")
   • Constructs tx.Factory, marshals the typed Msg, signs, broadcasts via the existing sidecar/rpc/client.go
   • Returns {txHash, height, rawLog} in the task result
3. Account sequence/number resolution: query the node's auth module via the RPC client at sign time. Cache per-key for the duration of a single task; do NOT persist across tasks (avoids stale-sequence retry hazards).
4. Chain-confusion guard: every handler refuses if params.chainId != os.Getenv("SEI_CHAIN_ID") — defense against accidental cross-chain key reuse.
5. Idempotency: relies on existing engine UUID dedupe (sidecar/engine/engine.go:91-138). Critical: a retry with the same caller-supplied UUID after a successful broadcast must NOT re-broadcast. Documented loudly in the task type docstrings.
6. Per-Msg typed param schemas (not a generic signAndBroadcast with raw Msg bytes) — better validation, better audit, easier authn-policy enforcement when authn lands.
7. OpenAPI schema update: sidecar/api/openapi.yaml adds new task type enum values + per-type param schemas.
8. Client SDK helpers in sidecar/client/tasks.go: SubmitGovVoteTask(...), SubmitGovSubmitProposalTask(...), SubmitGovDepositTask(...).

Acceptance criteria

• Three task types implemented with typed params
• Shared sign_and_broadcast.go helper used by all three handlers
• OpenAPI schema updated
• Client SDK helpers added in sidecar/client/tasks.go
• Chain-confusion guard test (vote with wrong chain-id rejected)
• Idempotent-retry test (same UUID twice → same tx hash, no double-broadcast)
• Stale-sequence retry test (sequence refreshed on retry, not cached across tasks)
• Integration test against a local seid devnet: vote, submit-proposal, deposit
• Pre-authn warning comment present at top of each new handler file referencing the authn issue
• README and OpenAPI carry "unauthenticated — see authn issue" notice until authn ships

Out of scope

• Authn middleware (separate issue, scheduled last)
• Staking (MsgDelegate / MsgUndelegate), distribution (MsgWithdrawDelegatorReward), IBC — same pattern, separate issues if needed
• Multi-msg transactions (single Msg per task for now)
• EVM transactions

References

• Coral session 2026-05-11
• Reference impl: sidecar/tasks/generate_gentx.go (in-process SDK signing already in this sidecar)
• Reference impl: sei-cosmos x/gov/client/cli/tx.go (the seid CLI's own impl — direct copy-shape target)
• Existing RPC client: sidecar/rpc/client.go
• Idempotency machinery: sidecar/engine/engine.go:91-138
• Predecessor: slanders/seienv cmd/vote.go, propose.sh
• Sister issues: operator-keyring CRD surface (sei-protocol/sei-node-controller), production keyring backend (this repo), seictl gov CLI (this repo), sidecar authn (this repo)

Sequencing

Phase 1, step 3 of 5 in the governance-flow migration. Depends on steps 1 (CRD operator-keyring in sei-node-controller) and 2 (sidecar keyring backend). Blocks step 4 (seictl CLI commands). Step 5 (authn) is the final hardening pass and lands after this.

[bdchatham]

Workstream cross-reference

This issue is part of a 5-issue sequence to migrate Sei validator governance flows from slanders/seienv (SSH + seid tx on EC2 hosts) to in-cluster execution via seictl + the sidecar API.

Step	Issue	Scope
1	sei-protocol/sei-k8s-controller#219	CRD validator.operatorKeyring surface
2	#162	Sidecar production keyring backend
3	#163 (this issue)	Sidecar sign-tx task family (gov vote / submit-proposal / deposit)
4	#164	seictl gov CLI subcommands
5	#165	Sidecar authn + authz middleware (deliberate last step)

Per a team sequencing decision, steps 1–4 ship the core flow; step 5 closes the authn gap as the final hardening pass. The pre-authn warning comments + README notices called for in this issue should reference #165 directly.

[bdchatham]

Design doc merged (#166): docs/design/in-pod-governance-signing.md

Implementation specifics for this issue are captured in Component C — Sign-tx task family: three task types (gov-vote, gov-submit-proposal, gov-deposit) with typed param schemas, shared SignAndBroadcast helper signature, full tx.Factory setup pattern, idempotency contract — persist tx hash before broadcast (load-bearing), software-upgrade Content-wrapped MsgSubmitProposal shape (Sei is on gov v1beta1, NOT v1 — no MsgSoftwareUpgrade), chain-confusion guard against SEI_CHAIN_ID AND /status.node_info.network, sign mode (SIGN_MODE_DIRECT), default gas/fees in usei (seienv's --fees 20sei is a latent bug), task result schema, OpenAPI updates, pre-authn warning notice template.

Cross-section context (security posture during pre-authn gap, alternatives rejected — block-mode broadcast, cached sequence, shell-out to seid) lives in the same doc.

[bdchatham]

Rev2 update (design doc merged in #167)

The API shape changes per rev2: task type and class move from request body into the URL path so the upstream kube-rbac-proxy can map paths to RBAC resource attributes.

Before (rev1)	After (rev2)
POST /v0/tasks body {type: "gov-vote", params: {...}}	POST /v0/tasks/governance/gov-vote body {...params...}
POST /v0/tasks body {type: "gov-submit-proposal", params: {...}}	POST /v0/tasks/governance/gov-submit-proposal body {...params...}
GET /v0/tasks/<id>	GET /v0/tasks/<id> (unchanged)

Additional changes for this issue:

• Each task type now declares a TaskClass (lifecycle | governance) at registration. The routing handler validates {class, type} against the registry — mismatched class returns 400 (defense-in-depth for proxy-side bugs).
• Caller attribution: the handler reads X-Remote-User / X-Remote-Group / X-Remote-Extra-* headers (set by the upstream kube-rbac-proxy after a successful TokenReview + SubjectAccessReview) and persists submittedBy, submittedByGroups, submittedAt on the task record. GET /v0/tasks/{id} returns submittedBy + submittedAt.
• Pre-authn warning notice template updated to reference kube-rbac-proxy (not in-process middleware). Notice still lands here and gets removed when feat(sidecar): authn + authz middleware on mutating endpoints #165 ships.

The sign-tx task semantics (typed Msg params, tx.Factory setup, idempotency contract with pre-broadcast tx-hash persist, chain-confusion guard, usei-denominated default fees, task result schema) are unchanged from the original issue scope. Only the API surface shape evolves.

See docs/design/in-pod-governance-signing.md Component C delta for full code-grade detail.