[venugopalanvip]

This is the library clear-signing-erc7730-registry installs since ethereum/clear-signing-erc7730-registry#3008, so the descriptors below are ones its CI is carrying today.

The bug

An enum key is the field value it matches — the v2 schema is explicit:

Enumeration keys are the field values and enumeration values are the displayable strings

A bool holds 0 or 1 in calldata, so true and false are the keys a descriptor writes for a bool field. JSON has no boolean object key, so they arrive as text.

convert_enums ran int(ordinal) on them. int("true") raises, and nothing catches it until the top of the conversion, where the handler discards the entire descriptor — every format, every deployment — and returns an empty list:

🟠 warning: Error processing v2 ERC-7730 file None, skipping it
🔴 error: Failed processing descriptor: invalid literal for int() with base 10: 'true'

One bool enum is enough. The descriptor still passes the registry's own CI, because neither reference test runner goes through this converter — the failure only appears when device descriptors are generated.

What it costs on registry master today

descriptor	enum	before	after
registry/lido/calldata-WithdrawalQueueERC721.json	{"true": "Allow all", "false": "Revoke all"}	0	11
registry/ekubo/calldata-MEVCaptureRouter.json	{"false": "Token 0", "true": "Token 1"}	0	168
registry/flyingtulip/calldata-PftNft.json	{"True": "Grant all", "False": "Deny all"}	0	10

I found them by converting all 280 calldata descriptors in the registry and looking for ones that produced nothing.

The Lido entry landed on registry master on 2026-09-21 (#2989); I raised this problem on that PR before it merged and offered to rename the keys to "0"/"1", and the maintainers took it as written — which I think is right, since the schema says keys are field values and true/false are a bool field's values. The casing differs between the three because nothing constrains it.

It is also about to get more common: registry #2912 proposes a bool enum for the DAI permit allowed flag.

The fix

Boolean literals map to the value the bool holds, case-insensitively and ignoring surrounding space:

BOOLEAN_ORDINALS = {"true": 1, "false": 0}

This matches how the constraint encoder in the same package already treats a bool value:

if isinstance(value, bool):
    return bytes([1 if value else 0])

A key that is neither decimal nor boolean still raises. Silently mapping it to a number would build an enum entry the device can never match, which is worse than the loud failure.

Tests

tests/convert/calldata/v1/test_enum_ordinal.py: decimal keys including a negative, the six boolean spellings plus a padded one, and five keys that must still raise.

Also raised upstream as LedgerHQ/python-erc7730#345, where it has not been reviewed. Sending it here too since this is the copy the registry actually runs.

One thing I did not change

convert_enums takes no OutputAdder, so a bad key can only raise, and the handler that catches it cannot attribute the failure to an enum — the message never names the descriptor, the enum id, or the key. Threading out through would let a single unusable entry be reported and skipped rather than costing the whole file. Wider than this fix needs; happy to follow up.