generate: --owner and --legal-name are swapped, and legalName is rejected by the v2 schema

Start at the generate and lint entry points, then compare their behavior with specs/erc7730-v1.schema.json and specs/erc7730-v2.schema.json. Reproduce the documented commands and verify that --owner maps correctly, v2 output does not emit legalName, and local validation agrees with the raw v2 schema.

erc7730 generate writes the --owner value into metadata.info.legalName, which is a v1-only field that the v2 schema rejects. erc7730 lint accepts the result, so the problem only surfaces later in the registry's CI.

Version: erc7730 1.0.10, Python 3.12.13.

1. The two flags are swapped

Help text:

--owner       <str>  The display name of the owner or target of the contract
--legal-name  <str>  The full legal name of the owner

Actual behaviour, using rETH (0xae78736Cd615f374D3085123A210448E74Fc6393) on chain 1:

--owner only — the value disappears entirely:

erc7730 generate --chain-id 1 --address 0xae78736Cd615f374D3085123A210448E74Fc6393 \
  --owner "Rocket Pool"

"metadata": {}

--legal-name only — lands in metadata.owner:

erc7730 generate --chain-id 1 --address 0xae78736Cd615f374D3085123A210448E74Fc6393 \
  --legal-name "Rocket Pool Ltd"

"metadata": { "owner": "Rocket Pool Ltd" }

Both, plus --url — the mapping is visibly inverted:

erc7730 generate --chain-id 1 --address 0xae78736Cd615f374D3085123A210448E74Fc6393 \
  --owner "Rocket Pool" --legal-name "Rocket Pool Ltd" --url "https://rocketpool.net"

"metadata": {
  "owner": "Rocket Pool Ltd",
  "info": {
    "legalName": "Rocket Pool",
    "url": "https://rocketpool.net"
  }
}

--owner → info.legalName, --legal-name → owner. In the first case info is omitted because no --url was given, so the --owner value is silently dropped with no warning.

2. legalName is not a valid v2 field

In the registry's spec files:

Schema	Occurrences of legalName
specs/erc7730-v1.schema.json	2
specs/erc7730-v2.schema.json	0

metadata.info in v2 permits only deploymentDate and url, with additionalProperties: false.

3. lint and the schema disagree

Validating the generated file above:

erc7730 lint calldata-Test.json
  -> no issue found, checked 1 descriptor files, no errors found

jsonschema.validate(descriptor, specs/erc7730-v2.schema.json)
  -> INVALID at $.metadata.info
     Additional properties are not allowed ('legalName' was unexpected)

lint validates against the pydantic models, while the registry's validate JSON schemas CI job validates against the raw schema, so a descriptor can pass locally and fail in CI.

Impact

The documented onboarding flow is generate → edit → lint → open a PR. Following it produces a descriptor that passes every local check and then fails CI with an error pointing at a field the contributor never typed. It also means --owner, the flag a first-time contributor is most likely to reach for, is the one that silently does nothing.

Hit while preparing ethereum/clear-signing-erc7730-registry#2962.

Suggestions

• Map --owner to metadata.owner and drop or relocate --legal-name to match the v2 schema
• Stop emitting metadata.info.legalName for v2 output
• Consider having lint also validate against the published JSON schema, so local results match CI