Clarify gl.message.chain_id: finalized Bradbury deployment received 1, not 4221

[Leokings]

Summary

A finalized Intelligent Contract deployment on Bradbury received gl.message.chain_id == 1, while Bradbury's EVM RPC and the current network documentation report chain ID 4221.

This may be a Bradbury execution-context configuration defect or an undocumented distinction between the GenVM field and the EVM chain ID. The current documentation appears to describe them as the same network identifier.

Documentation

• gl.message.chain_id is described as the “Current chain ID”:
  

  genlayer-docs/pages/developers/intelligent-contracts/features/transaction-context.mdx

  Line 20 in 7208bbf

  | `chain_id` | `u256` | Current chain ID |

• Bradbury is documented with chain ID 4221:
  

  genlayer-docs/pages/developers/networks.mdx

  Lines 18 to 26 in 7208bbf

  	## Testnet Bradbury
  	Production-like testnet with real AI/LLM workloads.
  	| Setting | Value |
  	|:--|:--|
  	| **GenLayer RPC** | `https://rpc-bradbury.genlayer.com` |
  	| **GenLayer Chain RPC** | `https://rpc.testnet-chain.genlayer.com` |
  	| **Chain ID** | 4221 |

• Studio source supplies the configured simulator chain ID to GenVM message context:
  https://github.com/genlayerlabs/genlayer-studio/blob/c94072951e483510329670aa427fba3fa6944f45/backend/node/base.py#L1035-L1040
• Studio's eth_chainId returns that same configured value:
  https://github.com/genlayerlabs/genlayer-studio/blob/c94072951e483510329670aa427fba3fa6944f45/backend/protocol_rpc/endpoints.py#L2318-L2319

Reproduction

The contract stores the field during initialization:

self.deployment_chain_id = gl.message.chain_id

Source:
https://github.com/Leokings/digital-deliverable-verifier/blob/73b8ed3d729eb52deff691e04babe0841dc2b7d6/contracts/DigitalDeliverableVerifier.py#L759

Bradbury artifacts:

• contract: 0x91d6E838b93c9CCA32Ab964d096949210F60b1DF
• deployment tx: 0xffb61c378c31f7689905e536f6e9cbccd8ccda49b980a24e56f0fc207535d834
• evaluation tx: 0x7fa6613923f792bcf570b5741dc06ded9e37dac9a27f021398bc6df52b6ea320
• both transactions are FINALIZED
• eth_chainId through the Bradbury RPC: 4221
• stored deployment_chain_id returned by get_policy(): 1
• terminal decision records also contain chain_id: 1

Full public test record:
https://github.com/Leokings/digital-deliverable-verifier/blob/main/docs/BRADBURY_TEST_RECORD.md

Value 1 is also the direct-test VM's default, but it is not Bradbury's documented ID:
https://github.com/genlayerlabs/genlayer-testing-suite/blob/343e3a358f9e235a93b49c60721ce7676585ff07/gltest/direct/vm.py#L160-L165

Requested clarification

1. Should gl.message.chain_id equal eth_chainId on Bradbury?
2. If 1 is intentional, what domain does it identify, and can the documentation name that domain explicitly?
3. If it is unintentional, can the Bradbury execution context be configured to supply 4221?

This matters for contracts that include gl.message.chain_id in domain-separated commitments. It did not affect this verifier's authorization, evidence evaluation, scoring, or validator consensus, but integrations should not have to guess whether the embedded value is the EVM network ID.

[ygd58]

One data point that might help narrow this down, and one honest limitation.

The 1 coincidence isn't causally connected

I checked genlayer-testing-suite's direct-mode mock VM (gltest/direct/vm.py), which is where the issue notes 1 also appears as a default:

_chain_id: int = 1

This is an isolated Python dataclass field default in an entirely separate, offline unit-testing mock (gltest's in-memory VMContext, used for local pytest runs with no real network involved at all). It shares no code path with Bradbury's actual execution — genlayer-testing-suite never talks to Bradbury or to genlayer-node. So this is very likely coincidence (a common placeholder default two unrelated codebases both happened to pick), not evidence that Bradbury's message context is somehow drawing from — or sharing logic with — this test harness. Worth ruling out as a lead rather than a cause.

What I could and couldn't check

I traced chain_id through the shared GenVM runtime (genvm-executor's executor/src/wasi/genlayer_sdk.rs) and confirmed GenVM itself doesn't default or compute this value — it just forwards whatever message.chain_id the invoking process supplies (self.message.chain_id.clone()). For Studio, that's backend/node/base.py, already confirmed correct in the issue. For Bradbury, the equivalent caller is genlayer-node — I don't have access to that repo (not visible under genlayerlabs with the token I'm using, likely private), so I can't trace where Bradbury's 1 actually originates or confirm question 1/3 one way or the other.

This looks like it needs someone with genlayer-node access to answer definitively — flagging that explicitly rather than guessing at a docs clarification I can't back with source.