Evaluate custom transaction submission client vs celestia-node client

[tac0turtle]

Summary

Decide whether to use celestia-node's existing blob submission client or build a custom transaction submission client in apex. Leaning toward a custom implementation.

Context

Apex is currently designed as a read-only indexer — Submit(...) returns "not supported" (see #2). However, if we add write-path support, we need a submission client. celestia-node provides one, but it may not be the best fit.

Why custom

• Tighter control: We know exactly what fields and encoding we need for our namespaces — no need to pull in celestia-node's full blob submission stack
• Fewer dependencies: Avoids importing celestia-node as a library (heavy dependency tree, version churn)
• Optimized for our use case: Can batch, retry, and manage nonces in ways specific to our workload (see Multi-account support for transaction submission #5 for multi-account support)
• Simpler error handling: Custom client can surface actionable errors for our specific failure modes rather than generic celestia-node errors

Questions to resolve

• What is the minimal transaction construction path? (MsgPayForBlobs, signing, broadcast)
• Can we use cosmos-sdk's tx client directly against a celestia-core RPC endpoint?
• Do we need fee estimation or can we use a fixed/configurable gas price?
• How does this interact with the Fiber path (Implement Fiber DA spec compatibility (FiberFetcher) #1) — does Fiber have its own submission mechanism?

Status

Optional — only needed if apex grows beyond read-only indexing into a full DA client.

References

• celestia-node nodebuilder/blob/blob.go — existing Submit impl
• celestia-app x/blob — MsgPayForBlobs transaction type