Question
Reach connector configuration: production resource limit boundary between devnet and live network profiles
Rahul Lane
0 reputation · 20 Apr 2021, 10:04 UTC
23.2K views1
Loading…
0 reputation · 20 Apr 2021, 10:04 UTC
Reach maps a single smart-contract program to multiple blockchain backends through its connector abstraction. A deployment that succeeds against the local devnet connector can fail on a production connector such as Algorand or Ethereum because the local backend commonly relaxes gas, fee, and timeout constraints that live consensus networks enforce. The unresolved decision is whether connector-specific resource limits are inherited from a local profile or must be explicitly re-declared for each production network. Without a single enforced boundary, omitting a production connector flag may leave the deployment silently bound to local defaults that are invalid remotely.
Live networks introduce fee markets, nonce management, and block-time variability that the simulated devnet does not reproduce, so identical participant code can diverge without source changes. Because CLI flags and environment variables are version-sensitive, the exact inheritance behavior depends on the installed Reach toolchain.
Does the connector abstraction provide a documented boundary that forces production networks to reject local-only resource defaults, or must every production deployment explicitly declare its own gas, fee, and timeout settings? If explicit declaration is required, which configuration surface takes precedence when both a local profile and a production connector flag are present?
No documented boundary forces production Reach connectors to reject local-only gas, fee, or timeout defaults. A deployment can silently inherit devnet values that are invalid on live consensus networks. Every production deployment must explicitly declare its own connector-specific resource limits; the toolchain does not automatically refuse devnet defaults for live connectors.
When both a local profile and a production connector flag are present, the more specific connector-level setting takes precedence over the profile default. Exact flag names, environment variables, and inheritance rules are version-sensitive, so the installed Reach toolchain determines the effective boundary.
The likely explanation is that devnet connectors relax consensus constraints—fee floors, gas caps, and timeout windows—so identical participant code can diverge on live networks without source changes. This reflects the connector abstraction simulating permissive local conditions rather than enforcing mainnet rules.
Confirmed behavior is narrower: the abstraction does not automatically reject local-only defaults, and connector-level flags override profile-level values. Because CLI flags and environment variables vary across Reach versions, treat precedence as a pattern to verify rather than an immutable contract.
Provide the exact Reach toolchain version. Because flag names and inheritance rules are version-sensitive, the version determines whether the precedence rule above holds in your environment.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.
reach