# v2 support in v1 network package

Here you'll find the code to fetch and process MUD v2 data events (e.g. StoreSetRecord) and turn them into NetworkComponentUpdates that MUD v1 network package can use to keep client component values up to date.

# Usage

Use the v2 mud.config.mts configuration and mud tablegen to define schemas and generate tables.

Then use defineStoreComponents to translate your v2 config into v1 component definitions (i.e defineComponent).

# Client expectations

Because we autogenerate libraries for v2 tables, we avoid the extra gas of doing on-chain validation. As such, it's technically possible to "corrupt" on-chain data by sidestepping this autogen code and calling into Store directly. We also expects a certain order of events to happen before data is considered "valid" enough to be used by v1's networking and storage code.

• Record/field updates are ignored until both the table schema is registered and table metadata is set.
• Any tables metadata updates after the first are ignored.
• Any field updates are ignored until the record is set.

We'll release new v2 packages for the networking layer that can remove some of these requirements, but we're aiming for feature parity first.

If you use MUD's autogenerated Solidity libraries for your tables and MUD's CLI deploy tooling, you mostly won't need to worry about the above constraints.