Summary
External report (gist) correctly notes that nibi-stargate in NibiruChain/nibiru-wasm ignores _info.sender in execute and forwards MsgMint / MsgChangeAdmin (and related paths) with sender = contract_addr.
That behavior is expected for this example contract. It is not a production protocol vulnerability. Implementation here is documentation and developer-safety hygiene in the example repo, not adding authorization logic to nibi-stargate.
Code lives in nibiru-wasm; tracked from this repo for visibility.
Severity / triage
- Priority: p3 — dev tooling / example contract hygiene
- Not protocol-critical: Nibiru does not deploy or operate
nibi-stargate for production infrastructure
Contract taxonomy
From contracts/README.md:
| Group |
Contracts |
Role |
Core (core-*) |
core-cw3-flex-msig, core-cw3-fixed-msig, core-token-vesting, core-token-vesting-v2 |
Production-style contracts (e.g. Treasury / Hot Wallet multisigs on mainnet) |
| Example |
nibi-stargate |
Runnable Stargate / tokenfactory docs and workshops |
| Utility |
lockup, incentives |
Reference building blocks (separate issue) |
Compiled .wasm files under nibiru-wasm/artifacts/ are normal build output. They do not imply mainnet deployment or protocol operation by Nibiru.
Discord context (support ticket #833-daniel526, 2026-07-10)
Team response on the gist report:
nibi-stargate is in the repo as a toy meant to show people how to construct protobuf-based messages using our Rust SDK. It's not a smart contract intended for any production use. That's why it doesn't manage things like permissions or anything for minting. It simply does whatever's passed in blindly. We've used it in educational workshops as a runnable form of documentation.
Follow-up taxonomy:
nibi-stargate, lockup, and incentives are not deployed or used by the team for protocol operations. The team uses the core-* contracts where Wasm is part of production infrastructure.
Affected code
Recommended approach
Keep nibi-stargate simple and permissionless on purpose so it stays a clear protobuf/Stargate teaching example. Do not add auth in this ticket. If a guarded production wrapper is ever needed, that should be a separate core-* or new example contract.
Acceptance criteria
Out of scope
- Adding authorization logic to
nibi-stargate
lockup / incentives eligibility bug (tracked separately)
- Mainnet deployment audit unless reporter supplies specific contract addresses
Summary
External report (gist) correctly notes that
nibi-stargatein NibiruChain/nibiru-wasm ignores_info.senderinexecuteand forwardsMsgMint/MsgChangeAdmin(and related paths) withsender = contract_addr.That behavior is expected for this example contract. It is not a production protocol vulnerability. Implementation here is documentation and developer-safety hygiene in the example repo, not adding authorization logic to
nibi-stargate.Code lives in
nibiru-wasm; tracked from this repo for visibility.Severity / triage
nibi-stargatefor production infrastructureContract taxonomy
From contracts/README.md:
core-*)core-cw3-flex-msig,core-cw3-fixed-msig,core-token-vesting,core-token-vesting-v2nibi-stargatelockup,incentivesCompiled
.wasmfiles undernibiru-wasm/artifacts/are normal build output. They do not imply mainnet deployment or protocol operation by Nibiru.Discord context (support ticket
#833-daniel526, 2026-07-10)Team response on the gist report:
Follow-up taxonomy:
Affected code
_info: MessageInfounused; privileged Stargate messages usesender: contract_addrRecommended approach
Keep
nibi-stargatesimple and permissionless on purpose so it stays a clear protobuf/Stargate teaching example. Do not add auth in this ticket. If a guarded production wrapper is ever needed, that should be a separatecore-*or new example contract.Acceptance criteria
nibi-stargate/README.mdbefore deploy instructionscontracts/README.mdtaxonomy from the example READMEexecutedocumenting that_infois intentionally unchecked for teachingcontracts/README.mdOut of scope
nibi-stargatelockup/incentiveseligibility bug (tracked separately)