Arkeo needed substantial modernization around an outdated Cosmos SDK foundation. I took responsibility for a complete application rewrite: defining the new structure, guiding the team through implementation, and working directly on the SDK integration and application code.
Arkeo provides blockchain data infrastructure. The rewrite connected the SDK migration with changes to state access, commands, signing, tests, and releases. Subsequent work addressed reward calculations and specific sources of protocol inconsistency.
Rebuild around the updated SDK
My Cosmos SDK migration moved the application to SDK 0.50.8 and IBC-Go 8.3.1. It also reworked application and keeper organization, updated the root command, adjusted message signing, and brought tests and build tooling along with the change.
Keepers are the components through which Cosmos modules access and manage state. Separating Arkeo’s keeper wiring from the main application structure made that boundary more explicit in the migration.
The work extended to protobuf generation, Docker builds, binary releases, and CI. These are part of delivering an upgrade: the application code and the path used to build and run it need to move together.
Remove assumptions that differ between nodes
One later change addressed nondeterministic iteration and local-time-dependent defaults.
The patch sorted keys before traversing configuration and claim-related data, and replaced a default derived from time.Now() with a fixed timestamp. These are small implementation details with a larger architectural concern behind them: independent nodes need a consistent basis for processing the same chain state.
The useful question at this boundary is whether a value comes from agreed application data or from the particular process executing the code. Local machine state can be convenient in ordinary application code; in replicated state transitions, that convenience needs much closer scrutiny.
Include the network in what gets signed
Another merged change added the chain ID to signing and verification flows to address signatures being replayed across networks.
The change crossed several boundaries: CLI signing, sentinel authentication, contract-income claim handling, and tests. Updating only one side would leave producers and consumers disagreeing about the message being authenticated.
The intended network had to become part of the signed message and the verification context throughout the flow. That requirement connected an individual security fix to changes across several components.
What shipped
The merged work includes the SDK migration and release changes, updated validator payout calculations, deterministic-processing fixes, and network-specific signing changes.
The rewrite established an updated application foundation. The follow-up work addressed specific rules that the application still had to enforce: consistent execution, reward calculations, and signatures for the intended network. Those concerns connected the larger architectural work to changes in individual functions and tests.