Cosmos-SDK, IBC, and EVM blockchain engineering
CorpiXo builds Cosmos-SDK appchains and modules, EVM and Solidity contracts, and the infrastructure that connects them to other networks. Work spans a chain's own logic, the bridges that move assets across it, and the nodes that keep it running. Each of these is a different failure mode, and each gets its own tests rather than one shared assumption that if the module compiles, the bridge is safe. A chain that has never seen an adversarial state transition and a chain that has been fuzzed against one are not the same deliverable, even if the code looks identical at a glance.
What we build
Every item below ships with the tests that exercise it — a module without simulation tests, or a bridge without a relayer failure case covered, isn't considered delivered. Where a deliverable touches consensus-critical state, the test suite is written to fail loudly on an unexpected state transition, not to pass quietly on the transitions someone thought to check.
- A Cosmos-SDK module with keeper, msg server, and simulation tests
- An IBC-enabled chain configuration, including relayer setup between two chains
- EVM/Solidity contracts with an upgrade path (proxy pattern) and a test suite covering reentrancy and access-control paths
- A two-way bridge — lock-and-mint or burn-and-mint — with relayer design and replay protection
- Validator and full-node infrastructure: deployment, monitoring, and upgrade runbooks
- Gas-cost profiling for contract calls, run against a reproducible benchmark script
Stack
Cosmos-SDK v0.50 · IBC · CometBFT · Solidity · Foundry · Go
This is the version and toolchain baseline used across chain and module work, not a project-specific choice made to fit a single client's constraints. Where a project needs an older Cosmos-SDK version for compatibility with an existing chain, that constraint is handled in discovery, not discovered mid-build.
How this is usually scoped
Chain and module work is usually fixed-scope and phased: discovery fixes the module boundaries, state migrations, and any upgrade path before a line of production code is written — the same specification and phase plan described in How we work, with particular attention to what a failed migration would do to a chain already carrying state. Bridge and relayer work is often its own phase, isolated from feature work elsewhere in the chain, since bridge risk shouldn't block unrelated releases and a bridge issue shouldn't require redeploying unrelated modules to fix. Ongoing validator operations, or a maintenance workstream on a chain already live, is usually hourly, since the scope of that work is inherently open-ended rather than a fixed artifact with an acceptance criterion.
What you receive at handover
The point of handover is that the client can operate and upgrade the chain without CorpiXo on retainer — a runbook that only makes sense to the person who wrote it isn't a runbook. That standard applies equally to a chain's validator set and to a single Solidity contract: whoever inherits the system should be able to diagnose a failed upgrade at 2am from the documentation alone.
- Full repository, transferred to the client's own organization
- Module and contract documentation, including the invariants the test suite checks
- Deployment scripts and validator/node runbooks
- A test suite — unit, simulation, and, for contracts, invariant tests — runnable by the client without CorpiXo
Frequently asked questions
- Do you audit smart contracts you didn't build?
- No. CorpiXo verifies its own work during delivery — invariant tests, simulation tests, and gas-cost benchmarks committed alongside the code. We don't offer a standalone audit or sign-off on a third party's contracts, and we won't reframe that work as something else if asked.
- Can you take over a chain or contract another team started?
- Yes. Joining an existing Cosmos-SDK chain or Solidity codebase and owning a scoped workstream is one of the two entry points we work from, alongside greenfield builds. The first phase in that case is usually spent understanding what's already there well enough to write an honest phase plan against it, not assuming the existing code is sound.
- Which chains do you build for?
- Cosmos-SDK appchains and EVM-compatible chains. IBC connects the two ecosystems; a two-way bridge is how we connect them when a canonical IBC path isn't available or the target chain isn't IBC-enabled.
- What happens to replay protection if a relayer goes offline?
- Relayers are permissionless by design in most bridge architectures we build, so one relayer going offline slows relay of pending messages rather than stopping the bridge — anyone can run a replacement relayer without needing our involvement or the chain's. Replay protection lives at the light client and message-sequencing layer, not with any single relayer, so it holds regardless of which relayer submits the message.