Draft
Conversation
ubuntu-latest is now 24.04 (glibc 2.39), which produced v29 binaries that fail to run on Ubuntu 22.04 / Debian 12 hosts. Pinning to 22.04 (glibc 2.35) restores compatibility with the validator fleet. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…61) Bumps [github.com/hashicorp/go-getter](https://github.com/hashicorp/go-getter) from 1.7.9 to 1.8.6. - [Release notes](https://github.com/hashicorp/go-getter/releases) - [Commits](hashicorp/go-getter@v1.7.9...v1.8.6) --- updated-dependencies: - dependency-name: github.com/hashicorp/go-getter dependency-version: 1.8.6 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…59) Bumps [go.opentelemetry.io/otel/sdk](https://github.com/open-telemetry/opentelemetry-go) from 1.40.0 to 1.43.0. - [Release notes](https://github.com/open-telemetry/opentelemetry-go/releases) - [Changelog](https://github.com/open-telemetry/opentelemetry-go/blob/main/CHANGELOG.md) - [Commits](open-telemetry/opentelemetry-go@v1.40.0...v1.43.0) --- updated-dependencies: - dependency-name: go.opentelemetry.io/otel/sdk dependency-version: 1.43.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
trevormil
force-pushed
the
feat/sdk-v0.54-upgrade
branch
from
9ca0623 to
a291052
Compare
…am (#72) Bumps [github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream](https://github.com/aws/aws-sdk-go-v2) from 1.7.7 to 1.7.8. - [Release notes](https://github.com/aws/aws-sdk-go-v2/releases) - [Commits](aws/aws-sdk-go-v2@service/m2/v1.7.7...service/m2/v1.7.8) --- updated-dependencies: - dependency-name: github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream dependency-version: 1.7.8 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [github.com/aws/aws-sdk-go-v2/service/s3](https://github.com/aws/aws-sdk-go-v2) from 1.97.1 to 1.97.3. - [Release notes](https://github.com/aws/aws-sdk-go-v2/releases) - [Commits](aws/aws-sdk-go-v2@service/s3/v1.97.1...service/s3/v1.97.3) --- updated-dependencies: - dependency-name: github.com/aws/aws-sdk-go-v2/service/s3 dependency-version: 1.97.3 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Previously ValidateAltTimeChecks only bounded OfflineHours (0-23) and OfflineDays (0-6). The v29-added fields — OfflineMonths, OfflineDaysOfMonth, OfflineWeeksOfYear, and TimezoneOffsetMinutes — had no bounds at all. Since TimezoneOffsetMinutes is an sdkmath.Uint settable by any user via MsgSetIncomingApproval, a caller could set it to a value that later caused the consumer (approval_criteria/ alt_time_checks.go) to either panic in sdkmath.Uint.Uint64() (for values exceeding uint64) or silently wrap through int64 overflow in time.Duration multiplication (for values in [2^63, 2^64-1]). Bounds chosen: - OfflineMonths: [1, 12] - OfflineDaysOfMonth: [1, 31] - OfflineWeeksOfYear: [1, 53] (ISO 8601 weeks can reach 53 in long years) - TimezoneOffsetMinutes: [0, 840] where 840 = 14*60, the widest real-world UTC offset (UTC+14:00, Kiribati). Also: - validateTimeRanges now checks start/end against uint64 range before calling .Uint64() (which panics on overflow) and enforces the min bound it was already accepting as a parameter. - Defense-in-depth added to alt_time_checks.go consumer: reject the same out-of-range values with an error rather than panicking or wrapping, in case a checker is ever constructed outside the validate-basic path (e.g. from migrated state). Follows the throw-not-bandaid principle: the producer (validate_basic) rejects bad input up front instead of the consumer silently tolerating nonsense local times. Implements backlog #0255. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…n filter (#75) SendNativeTokensFromAddressWithPoolApprovals set OnlyCheckPrioritizedIncomingApprovals=true but only ever prioritizes an outgoing approval, so every non-prioritized incoming approval (including the synthetic "all-incoming" appended for recipients with AutoApproveAllIncomingTransfers=true) was dropped by FilterApprovalsWithPrioritizedHandling before the auto-scannable check could run. This broke swap-and-action-hooks flows where the IBC-derived intermediate address is freshly flagged for auto-approve, producing errors like: incoming approvals not satisfied ... auto-scan failed (checked 0 potentially matching approval). Approvals not checked (require prioritization): ["all-incoming"] Switch to OnlyCheckPrioritizedOutgoingApprovals=true, which matches the ApprovalLevel of the one-time approval we're actually trying to gate the pool on. Also rewrite the "require prioritization" branch in buildPotentialErrorsString to diff unfilteredApprovals against the post-filter list. The previous code labeled every unfiltered approval as "require prioritization" whenever approvalIdxsChecked was empty, even when the real cause was an address/time mismatch — which is how this bug looked when it surfaced in production. Regression test reproduces the original failure against the pre-fix code. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…oval conditions, criteria, tracking, and dynamic stores This commit introduces several new proto files for version 29 of the tokenization module, including: - `address_lists.proto`: Defines AddressList and AddressListInput messages for managing lists of addresses. - `approval_conditions.proto`: Introduces various conditions for approvals, such as MustOwnTokens and DynamicStoreChallenge. - `approval_criteria.proto`: Specifies criteria for approving transfers, including Merkle challenges and predetermined balances. - `approval_tracking.proto`: Implements tracking for approval amounts and transfer limits. - `dynamic_stores.proto`: Defines DynamicStore and DynamicStoreValue for flexible on-chain data storage. These additions enhance the functionality and flexibility of the tokenization module, enabling more complex approval and transfer scenarios.
…date version references This commit updates the application to version 30, introducing a new upgrade handler for the tokenization module. The changes include: - Updated the Makefile to set VERSION to v30. - Replaced references to the previous upgrade version (v29) in the upgrades.go file with v30. - Added a new file for the v30 upgrade logic, which includes a custom upgrade handler for migrating tokenization data. - Updated the tokenization module to reflect the new consensus version of 30. These changes enhance the upgrade process and ensure compatibility with the latest features in the tokenization module.
…instructions This commit refactors the command structure of the BitBadges CLI by consolidating multiple forwarder commands (`sdk`, `api`, `builder`) into a single `cli` command. This change simplifies the command usage, allowing all top-level subcommands to be accessed through `bitbadgeschaind cli <subcommand> [args...]`. Additionally, the installation instructions have been updated to reflect the new package name `bitbadges`, replacing previous references to `bitbadgesjs-sdk`. This includes updates in the `.gitignore`, `install.sh`, and documentation files to ensure consistency across the project. Changes include: - Removal of the old `sdk`, `api`, and `builder` command files. - Introduction of a new generic `cli` command. - Updates to installation messages and documentation to use the new package name. - Removal of deprecated modules related to `maps` and `anchor` as part of the v30 upgrade. This refactor enhances usability and prepares the codebase for future expansions of the CLI functionality.
…me (#74) (#76) The x/badges module was renamed to x/tokenization in v23, but the migration that re-derives collection addresses with the new module name — and moves the corresponding bank balances — was never wired into any upgrade handler. Every existing mainnet collection still stores a mintEscrowAddress / cosmosCoinBackedPath.address / cosmosCoinWrapperPath.address derived from module="badges", while today's msg handlers and every downstream consumer derives with module="tokenization". The daily indexer consistency check surfaced this as a 16-field-per-collection drift across all 11 active collections on mainnet. This adds migrateCollectionAddressesFromBadgesToTokenization and hooks it into the existing MigrateCollections loop so v30 will: 1. For each collection, compute the legacy (badges) and new (tokenization) forms of mintEscrowAddress + cosmosCoinBackedPath.address + every cosmosCoinWrapperPath.address. 2. Move any bank balances from the old address to the new one via bankKeeper.SendCoins. No-op when balances are zero (common for fresh wrapper/backed paths that never held funds). 3. Flip the reserved-protocol-address flag from the old address to the new one so downstream lookups don't treat stale module addresses as reserved. 4. Overwrite the stored address on the collection so future queries return the tokenization-derived value. All steps are skipped when old == new, so re-running the migration (or running it on a chain that was created post-rename) is a no-op. Derivation helpers are direct ports of the ones in msg_server_universal_update_collection.go with a pluggable module name. Pairs with bitbadges-indexer#100 which mirrors chain-augmented fields in the handler + has a one-shot v29-patch migration to re-sync DB state from chain; after v30 runs, that migration will pick up the new addresses. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Regenerates docs/static/openapi.yml via `ignite generate openapi --enable-proto-vendor --clear-cache`. The scaffolding commit 0b360ad had shrunk the spec from ~515KB to 14KB by running ignite without the proto-vendor flag, which dropped every non-cosmos-evm service. Now back to full coverage: all cosmos SDK modules, ibc, gamm, managersplitter, poolmanager, sendmanager, tokenization (v27/v28/v29), and ibcratelimit. proto/buf.lock and proto/buf.yaml updated by the same regen to add the cosmos/evm buf dep and bump googleapis + wellknowntypes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ths (#77) Add cross-referenced comments at the three sites an audit agent would inspect when flagging the shared CosmosCoinBackedPath escrow address: - generatePathAddress: explain that backed-path derivation is intentionally not scoped by collection ID, and what makes that tolerable today. - ValidateTransferWithInvariants: note that the from=Mint block on backed collections is load-bearing for drain safety, not just UX. - HandleSpecialAddressBacking: walk through why the naive-looking SendCoins(escrow -> initiator) line is net-zero under current invariants, plus the caveats that would flip it back to live. No functional change. This addresses a backlog security audit finding (cross-collection backed-path drain via shared denom) that was re-flagged despite being blocked by the existing from=Mint invariant in v30. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…#79) The CreateCollection msg server builds a MsgUniversalUpdateCollection and dispatches to it, but omitted UpdateValidTokenIds: true. The universal handler gates ValidTokenIds ingestion on that flag, so every new collection created via MsgCreateCollection landed with empty validTokenIds on chain — bricking tokens 1..N since no IDs were valid. The bug went unnoticed because no existing test exercises the MsgCreateCollection path directly; all integration helpers route through UniversalUpdateCollection. Added a regression test that FAILS pre-fix (asserts expected validTokenIds == on-chain state). Real-world symptom: collection 83 on testnet has validTokenIds=[] while the submitted MsgCreateCollection payload explicitly set validTokenIds=[{start:1,end:1}]. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After bun/npm install of the SDK CLI, detect whether the binary
landed in a directory that isn't on the user's PATH and print the
exact `export PATH=...` line they need (resolved per-package-manager:
`bun pm bin -g` for bun, `npm config get prefix`/bin for npm).
The previous hint was generic ("Check your global bin directory")
which left users — particularly those on bun's default ~/.bun/bin
or an unconfigured npm global prefix — to guess.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the raw.githubusercontent.com URL in install.sh's header comments and in the GitHub Release body template with the new Cloudflare-Worker-fronted short URL. Source-of-truth is unchanged — install.bitbadges.io proxies the same master install.sh — but new copy-paste surfaces use the cleaner form. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
… 0 (#83) The first ever MsgCreateDynamicStore on a chain reads the counter (0), overrides to 1, but does not persist that override. IncrementNextDynamicStoreId then bumps the stored 0 to 1, so the second create reads 1 and reuses it, silently overwriting the first store's createdBy/uri/defaultValue/globalEnabled. This actually fired on bitbadges-1 mainnet: a dynamic store created on 2026-02-28 was clobbered on 2026-04-26 when a different account submitted a fresh MsgCreateDynamicStore. Both got store_id = 1. Persist the override (SetNextDynamicStoreId(1)) so the increment lands at 2. Adds a regression test that creates three stores from a zeroed counter and asserts they receive ids 1, 2, 3. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes #0355 (autopilot backlog, install side). `bb` is the friendly entry point for the unified CLI. The shim points at bitbadgeschaind which already wraps tx/query/keys (chain-native) and `cli ...` (forwarded to Node SDK CLI). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Part of #0355 / #0360. The Node SDK CLI ships auth login/logout/ status via this forwarder once the SDK release lands. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
chain: agent-UX push — JSON Schema generator, bb alias, forwarder doc
The auth subcommand was removed from the SDK CLI when SIWBB was deprecated as a site-only flow. Remove the dangling reference here. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
chain(cli): drop auth from forwarder doc (SIWBB removed)
Bridges the BitBadges CLI auth flow (`bitbadges-cli auth verify
--signature ...`) with keys held in the chain binary's keyring,
without exposing the raw private key. Pure offline operation: no
network, no chain state, no tx broadcast.
Output is a JSON envelope `{ format, address, pubKey, signature,
message, algo }` that posts directly to the indexer's
`/api/v0/auth/verify` endpoint.
v1 supports cosmos `secp256k1` keys only — the indexer's
`CosmosDriver.verifySignature` accepts these unchanged via
`@keplr-wallet/cosmos verifyADR36Amino`. `eth_secp256k1` keys are
rejected with a clear error pointing at a future `--format eip191`
follow-up.
Verified end-to-end against mainnet `/api/v0/auth/{getChallenge,verify,
status,logout}` flow — fresh local key signs the Blockin challenge,
indexer verifies the ADR-36 signature, mints a Full Access session
cookie. Golden-vector test locks the canonical-JSON byte encoding
against output that round-tripped successfully through Keplr's verifier.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Protocol fee is now taken out of the coin transfer amount rather than added on top. A 1 USDC payment with a 0.1% fee now debits the payer exactly 1 USDC; the recipient receives 0.999 USDC and the community pool receives 0.001 USDC. Previously the payer was charged 1.001 USDC. - Fee is deducted inline in ExecuteCoinTransfers before the royalty/recipient split so the payer sends exactly the quoted amount. - Royalty and protocol fee are both taken off gross; royalty + fee > gross is rejected instead of underflowing the recipient. - Post-hoc CalculateAndDistributeProtocolFees is gone; entries land in coinTransfers via the same sendProtocolFee helper so event payloads keep their IsProtocolFee=true rows. Behavior change: the fee now follows the payment source — if an approval uses OverrideFromWithApproverAddress, the approver pays the fee along with the coins (previously initiatedBy paid the fee regardless). This is consistent with "inclusive" semantics. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
) * chain(cli): scrub forwarder help text for flat CLI redesign (#0376) The forwarder logic itself is path-agnostic — it just exec's whatever subcommand the user passes through to the Node bitbadges-cli. The embedded help text and docstring examples still listed the old sdk/builder umbrellas; updates to match the new flat surface. Lists the new groups (Build & Ship / Indexer / Local State / Discovery / Address & lookup) and updates the example snippets: bitbadgeschaind cli sdk review tx.json → cli check tx.json bitbadgeschaind cli builder templates → cli build bitbadgeschaind cli builder create-with-burner → cli deploy --burner Companion to bitbadgesjs#199. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chain: scrub stale `bitbadgeschaind cli sdk docs` reference in help_links (#0376) Embedded help string at help_links.go:98 referenced the pre-refactor `bitbadgeschaind cli sdk docs messages` path. Updates to the new flat-surface `bitbadgeschaind cli docs messages` after bitbadgesjs#199. Caught in third-pass cross-repo audit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…o-v10 Rebased the feat/sdk-v0.54-upgrade branch onto current master (feat/v30 having landed) and folded in: - All v0.54 chain code from prior 3 commits on the branch (see backup tag v0.54-pre-rebase-backup): SDK v0.54.2, cometbft v0.39.1, ibc-go v11, log/v2, store/v2, IBC v11 middleware adjustments, x/group + x/crisis removal, v30 upgrade handler. - cosmos/evm v0.6.0 → v0.7.0-beta.0 (released 2026-04-27) - All required v0.7 replace directives: cosmos-sdk pseudo-version, cometbft pseudo-version, x/group → enterprise/group, geth fork to v1.17.2-cosmos-0, keyring + gin security replaces, btree → cosmos/btree - precisebank imports moved to contrib path (chain stays 9-decimal) - ibc-go/v10 → v11 in 4 remaining test files - Dependabot PR #84 bumps absorbed via go mod tidy: bufbuild/buf 1.69, ibc-apps PFM v10.6, geth 1.17, golang.org/x bumps, indirect updates. Local shim added at vendor-shims/cosmossdk-x-upgrade — copy of cosmossdk.io/x/upgrade@v0.2.0 with types/storeloader.go removed (uses incompatible store v1 types; we never call it from this path). BLOCKER: cosmos/ibc-apps/middleware/packet-forward-middleware/v10 still imports github.com/cosmos/ibc-go/v10, whose 02-client/types/store.go uses cosmossdk.io/store v1 KVStore — incompatible with our store/v2 baseapp. Build fails with type mismatches. Needs architectural decision before this branch can compile. See ticket #0118 for options. Pending mechanical fixes (will apply once PFM unblocks): - 3 precompiles: add Name() method (geth 1.17 PrecompiledContract iface) - 3 precompiles: cmn.LoadABI → abi.JSON(bytes.NewReader(f)) + f []byte - x/tokenization/module: add SetICS4Wrapper + SetUnderlyingApplication
trevormil
force-pushed
the
feat/sdk-v0.54-upgrade
branch
from
5f72bc3 to
1e79792
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Status: STUCK — waiting on two upstreams
Tracking ticket:
backlog/0118Resume when:
cosmos/evmships a non-betav0.7.0(currentlyv0.7.0-beta.0)cosmos/ibc-appsshipspacket-forward-middleware/v11on ibc-go v11 + cosmos-sdk v0.54 (latest isv10.6.0, no v11 work in flight)What's done on this branch (committed at
1e797922)Rebased onto current
master(feat/v30 has landed). All chain-side migration code is applied:x/group → enterprise/group, geth fork, keyring, gin security, btree forkprecisebankimports moved togithub.com/cosmos/evm/contrib/x/precisebank(chain stays 9-decimal — virtual fee collection NOT enabled per migration guide)x/group+x/crisisremoved (imports, keeper, depinject, genesis, endBlockers, module config)Deleted: ["anchor", "maps", "group", "crisis"]SetICS4Wrapper/SetUnderlyingApplicationadded to ibc-hooks IBCMiddleware, customHooksWrapper, and MockIBCModuleNewUncachedContext(false, header)→NewNextBlockContext(header)cosmos-sdk/contrib/x/circuitgo mod tidyvendor-shims/cosmossdk-x-upgrade/: copy ofcosmossdk.io/x/upgrade@v0.2.0withtypes/storeloader.goremoved (it uses store v1 types incompatible with v0.54 baseapp; we never call it via that import path)Blocker
PFM v10 → ibc-go/v10 →
cosmossdk.io/store v1. Non-test sourceibc-go/v10/modules/core/02-client/types/store.gousescosmossdk.io/store/types.KVStorewhoseCacheWrap()return type is incompatible with our SDK v0.54 baseapp'scosmos-sdk/store/v2/types.CacheWrap. Noreplacedirective can fix this — it's in non-test code requiring an actual API match.PFM has no v11 release.
mainis still on cosmos-sdk v0.53.4 + ibc-go v10.6.0. Only open v0.54-related PR (cosmos/ibc-apps#280) is on SDK v0.50, doesn't address this.Pending mechanical fixes once unblocked (~30 min)
x/tokenization/precompile,x/sendmanager/precompile,x/gamm/precompile):func (Precompile) Name() string(geth 1.17vm.PrecompiledContractinterface change)cmn.LoadABI(f, "abi.json")withabi.JSON(bytes.NewReader(f)), changef embed.FS→f []byte(cosmos/evm v0.7 removedcmn.LoadABI)x/tokenization/module/module.go: addSetICS4Wrapper+SetUnderlyingApplicationmethods to*IBCModule(IBC v11 middleware interface)make testto 100% greenBackup
Tag
v0.54-pre-rebase-backup(sha5f72bc30) preserves the prior 3-commit-on-feat/v30 layout in case anything goes sideways with the new single-commit rebase.