API and SDK Changes for Protocol Upgrades

The Compound documentation is the starting point for current Compound III Comet and legacy Compound II cToken integration behavior. Use it to confirm high-level method flows, market concepts, collateral handling, reward claiming, and expected contract interaction patterns. For upgrade work, do not rely on prose alone: map each documented function to the deployed ABI for the target chain and market, then test transaction construction against a fork or staging environment. Pay special attention to differences between cToken patterns such as mint, redeem, and borrow, and Comet patterns such as supply, withdraw, supplyTo, and collateral-specific accounting.

The Comet repository is the canonical engineering reference for Compound III contract interfaces, deployment configuration, tests, and implementation changes. Integrators should review interfaces, storage assumptions, events, extension contracts, and deployment artifacts before accepting an SDK or wrapper change as safe. For API compatibility reviews, compare the repository ABI and tests against your production call surface: transaction builders, liquidation bots, indexers, reward claimers, and position engines. When a governance proposal upgrades a Comet implementation or deploys a new market, use the repository to understand whether the change is a new deployment, implementation replacement, configuration update, or peripheral tooling change.

Many wallets, custodians, dashboards, and DeFi aggregators still support legacy Compound II markets, so cToken and Comptroller interfaces must remain part of compatibility testing. The Compound Protocol repository provides source contracts for cTokens, the Comptroller, interest rate models, price oracle adapters, and governance-controlled admin paths. Use it to verify legacy ABI behavior when SDK updates attempt to abstract both Compound II and Compound III behind one client surface. Regression tests should cover exchange-rate accounting, borrow index accrual, allowance flows, liquidation calls, and error-code handling because cToken integrations often fail through silent accounting drift rather than obvious transaction reverts.

API and SDK changes often follow governance execution rather than a conventional software release. The Compound governance portal is the operational source for proposal status, payload timing, executable actions, and affected contracts. Before changing production integration logic, teams should inspect the proposal actions, target addresses, function signatures, calldata, and execution status. This is especially important for Comet market deployments, parameter changes that alter risk calculations, oracle updates, pause controls, and contract implementation upgrades. Treat proposed changes as pending until execution is confirmed on-chain, and schedule SDK releases around timelock execution rather than forum discussion or draft documentation.

The Compound forum provides proposal rationale, implementation discussion, audit notes, parameter reasoning, and integration warnings that may not appear in formal API documentation. Use it to identify upcoming changes before they reach an on-chain governance vote, especially new market deployments, Comet upgrades, oracle changes, reward distribution updates, and deprecation plans for legacy tooling. Forum posts are not authoritative execution records, so teams should cross-check any described behavior against the final proposal payload and deployed contracts. For integration planning, maintain a watchlist of forum threads that mention ABI changes, SDK changes, subgraph migrations, or market-specific deployment differences.

The Compound JavaScript SDK repository is useful for teams that inherited legacy Compound client code or depend on SDK-level transaction construction. Review package history, exported helpers, ABI assumptions, supported networks, and maintenance status before adopting it for new protocol-upgrade work. For production systems, avoid treating SDK behavior as canonical: pin versions, diff generated calldata, compare embedded ABIs against deployed contracts, and add integration tests for every market you support. If an upgrade introduces a new Comet deployment or changes a peripheral contract, confirm whether the SDK has been updated or whether your application needs direct contract bindings instead.