gno-ibc AGENTS.md

AGENTS.md

.gno Files Are NOT Go

• .gno looks like Go but runs in a deterministic VM.
• No goroutines, channels, unsafe, net, os.
• Realms (r/) are stateful (on-chain state).
• Packages (p/) are stateless libraries.
• Import paths: gno.land/p/... or gno.land/r/... — never github.com/....
• Module config: gnomod.toml (not go.mod).
• cross(cur) operator for cross-realm calls (the legacy bare cross / cross1 keyword is gone).
• realm type for realm-aware functions. Functions that act on their own realm's state declare cur realm as the first parameter.

---

Build & Test

Gno tests	Go tests
make test for the first-party suite; gno test ./path/... for focused runs	go test ./...
Test files: _test.gno	Test files: _test.go

---

Light Client Proof Verification

• Any core-hosted code path that verifies membership or non-membership proofs must reject inactive clients before proof verification.
• For Union core paths (gno.land/r/onbloc/ibc/union/core and versioned implementation realms such as gno.land/r/onbloc/ibc/union/core/v1), keep the existing core-level lightClient.Status() == lightclient.Active checks before every VerifyMembership or VerifyNonMembership call. Treat gno.land/r/aib/ibc/core as the vendored gno-realms reference path, not the active onbloc Union core path.
• The lightclient.Interface adapter methods do not by themselves guarantee active-status gating. Existing object adapters such as cometbls and state_lens/ics23_mpt rely on the core caller to enforce active status before calling VerifyMembership or VerifyNonMembership; state_lens reports its status from the underlying L1 client.
• Adapter implementations should still enforce status checks they own when they are not guaranteed by the caller or when they verify through another light client directly. Use lightclient.Active for internal status checks; use types.StatusActive only for converted public status values.
• New proof-verification paths must include tests showing that frozen or expired clients cannot be used for membership or non-membership proof verification, either at the core caller boundary or inside the adapter when the adapter owns that guard.