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
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.modto prevent dependency contamination.Problem
cosmos-sdk pulls in a massive transitive dependency tree:
celestiaorg/celestia-core)Importing it into the core module would:
Design
Boundary interface
The core module defines a submission interface with no cosmos-sdk types:
The
submit/submodule implements this interface, convertingRawBlobto cosmos-sdk types internally.Build integration
cmd/apex/main.goimportssubmit/only when submission is configuredRelated issues