Isolate cosmos-sdk dependency in a separate Go submodule

Start by inspecting the root go.mod and the proposed submit/go.mod boundary, then review cmd/apex/main.go and the listed submit files. Verify how the core interface can avoid cosmos-sdk types and how the two modules would be tested independently. Done means cosmos-sdk is isolated in submit/, read-only core builds without it, and the submission interface remains usable.

Summary

The core apex codebase must not import cosmos-sdk. All cosmos-sdk-dependent code (transaction construction, signing, gas estimation) must live in an isolated Go submodule with its own go.mod to prevent dependency contamination.

Problem

cosmos-sdk pulls in a massive transitive dependency tree:

• cometbft (celestia's fork: celestiaorg/celestia-core)
• iavl, cosmos-db, cosmos-proto
• gRPC, protobuf, gogoproto
• celestia-app's own forks of cosmos-sdk

Importing it into the core module would:

• Bloat build times and binary size for read-only deployments that don't need tx submission
• Create version pinning headaches against celestia's forked dependencies
• Make upgrades painful — a celestia-app bump could break unrelated apex code
• Bleed transitive deps into packages that have no business depending on them

Design

apex/
├── go.mod                      # core module — zero cosmos-sdk
├── cmd/apex/main.go
├── pkg/
│   ├── store/                  # SQLite — clean
│   ├── sync/                   # backfill, streaming — clean
│   ├── fetch/                  # DataFetcher, CelestiaNodeFetcher — clean
│   └── api/                    # JSON-RPC, gRPC server — clean
└── submit/
    ├── go.mod                  # separate Go module, imports cosmos-sdk here
    ├── go.sum
    ├── signer.go               # key loading, tx signing (SIGN_MODE_DIRECT)
    ├── msg.go                  # MsgPayForBlobs construction
    ├── gas.go                  # deterministic gas estimation
    ├── broadcast.go            # BroadcastTxSync + confirmation polling
    └── submit.go               # public API: Submit(blobs) -> TxResult

Boundary interface

The core module defines a submission interface with no cosmos-sdk types:

// In pkg/submit/iface.go (core module, no cosmos-sdk imports)
type BlobSubmitter interface {
    Submit(ctx context.Context, blobs []RawBlob, opts SubmitOpts) (*TxResult, error)
}

type RawBlob struct {
    Namespace []byte
    Data      []byte
}

type TxResult struct {
    TxHash   string
    Height   int64
    GasUsed  int64
    Code     uint32
    Error    string
}

The submit/ submodule implements this interface, converting RawBlob to cosmos-sdk types internally.

Build integration

• cmd/apex/main.go imports submit/ only when submission is configured
• Read-only deployments compile without the submodule (build tags or conditional import)
• CI tests the core module and submit module independently

Related issues

• #4 — Custom tx submission client (parent)
• #8 — Nonce management (lives in submit/)
• #9 — Keyring and signing (lives in submit/)
• #17 — Gas estimation (lives in submit/)
• #18 — Rate limiting / circuit breaker (can live in core, no cosmos-sdk needed)
• #19 — Tx confirmation lifecycle (lives in submit/)
• #5 — Multi-account support (lives in submit/)