[proto-codec / amino-converter] Update from verana-frontend

[antoniobenavidesvallejo]

Delete

ts-proto/src/helpers/aminoConverters.ts

Create

ts-proto/src/amino-converter/

copy from /verana-labs/verana-frontend: /verana-frontend/app/msg/amino-converter

rename:

aminoConvertersCS.ts -> cs.ts
aminoConvertersDID.ts -> dd.ts
aminoConvertersPerm.ts -> perm.ts
aminoConvertersTD.ts -> td.ts
aminoConvertersTR.ts -> tr.ts

In ts-proto/src/helpers copy from /verana-labs/verana-frontend: verana-frontend/app/msg/util/aminoHelpers.ts

Update imports to test.

Compare

• ts-proto/src/codec/verana/cs/v1/tx.ts with /verana-frontend/proto-codecs/codec/verana/cs/v1/tx.ts
• ts-proto/src/codec/verana/dd/v1/tx.ts with /verana-frontend/proto-codecs/codec/verana/dd/v1/tx.ts
• ts-proto/src/codec/verana/perm/v1/tx.ts with /verana-frontend/proto-codecs/codec/verana/perm/v1/tx.ts
• ts-proto/src/codec/verana/td/v1/tx.ts with /verana-frontend/proto-codecs/codec/verana/td/v1/tx.ts
• ts-proto/src/codec/verana/tr/v1/tx.ts with /verana-frontend/proto-codecs/codec/verana/tr/v1/tx.ts

Write the differences found in the comments of this issue.

Update the test imports and run them. If there are errors or not, put them in the comments of the issue.

[AirKyzzZ]

tx.ts Comparison: ts-proto vs frontend (proto-codecs)

Compared the five tx.ts files as requested in the issue:

• ts-proto/src/codec/verana/{module}/v1/tx.ts (ts-proto, generated with protoc unknown)
• verana-frontend/proto-codecs/codec/verana/{module}/v1/tx.ts (frontend, generated with protoc v5.29.3)

---

Common differences (all 5 modules)

These appear in every module:

#	Category	ts-proto	frontend	Affected lines (ts-proto → frontend)
1	protoc version comment	protoc unknown	protoc v5.29.3	L4 → L4
2	Long import	import Long = require("long")	import Long from "long"	varies (see per-module)
3	protobufjs import	import * as _m0 from "protobufjs/minimal"	import _m0 from "protobufjs/minimal"	L8 → L8-9
4	params field optionality	params: Params | undefined	params?: Params | undefined	varies
5	DeepPartial Long clause	not present	adds T extends Long ? string | number | Long	end of file
6	longToNumber() helper	present	removed	end of file
7	_m0.util.Long setup block	missing in some	present	end of file

---

Module: cs (Credential Schema)

File sizes: ts-proto 1008 lines → frontend 998 lines

uint64 fields changed from number to Long:

Field	Interface	ts-proto line	frontend line
trId	MsgCreateCredentialSchema	L35	L35
id	MsgCreateCredentialSchemaResponse	L49	L49
id	MsgUpdateCredentialSchema	L53	L53
id	MsgArchiveCredentialSchema	L72	L72

Optional fields changed (field: → field?:):

Field	ts-proto lines	frontend lines
issuerGrantorValidationValidityPeriod	L37	L37
verifierGrantorValidationValidityPeriod	L38	L38
issuerValidationValidityPeriod	L39	L39
verifierValidationValidityPeriod	L40	L40
holderValidationValidityPeriod	L41	L41
(same set in MsgUpdateCredentialSchema)	L57-L61	L57-L61

Encode/decode/JSON changes follow the number → Long pattern throughout:

• createBase*(): 0 → Long.UZERO (ts-proto L201 → frontend L201, L437 → L437, L500 → L500, L788 → L788)
• encode: !== 0 → !.equals(Long.UZERO)
• decode: longToNumber(reader.uint64() as Long) → reader.uint64() as Long
• fromJSON: globalThis.Number() → Long.fromValue()
• toJSON: Math.round() → .toString()
• fromPartial: ?? 0 → Long.fromValue() : Long.UZERO

Imports: L8-L10 changed (Long import moved to default, _m0 to default import, Long = require removed from L10)

---

Module: dd (DID Document)

File sizes: ts-proto 766 lines → frontend 772 lines

Minimal differences — no uint64 field type changes.

Only the common differences apply:

• Import style: ts-proto L8 → frontend L8-9
• params optionality: ts-proto L22 → frontend L23
• DeepPartial Long clause: ts-proto L755 → frontend L756
• _m0.util.Long setup block: not present in ts-proto, added at frontend L765-L768

---

Module: perm (Permissions) — most differences

File sizes: ts-proto 2430 lines → frontend 2354 lines (76 lines fewer)

Structural removals (fields that exist in ts-proto but NOT in frontend):

Field(s) removed	Interface	ts-proto lines
validationFees, issuanceFees, verificationFees (OptionalUInt64)	MsgStartPermissionVP	L39-L48
issuanceFeeDiscount, verificationFeeDiscount	MsgSetPermissionVPToValidated	L83-L90

Also: OptionalUInt64 import removed from ts-proto L11 (types import).

uint64 fields changed from number to Long:

Field	Interface	ts-proto line	frontend line
validatorPermId	MsgStartPermissionVP	L38	L38
permissionId	MsgStartPermissionVPResponse	L57	L47
id	MsgRenewPermissionVP	L63	L53
id	MsgSetPermissionVPToValidated	L74	L64
validationFees	MsgSetPermissionVPToValidated	L76	L67
issuanceFees	MsgSetPermissionVPToValidated	L77	L68
verificationFees	MsgSetPermissionVPToValidated	L78	L69
id	MsgCancelPermissionVPLastRequest	L97	L80
schemaId	MsgCreateRootPermission	L105	L88
validationFees	MsgCreateRootPermission	L111	L94
issuanceFees	MsgCreateRootPermission	L112	L95
verificationFees	MsgCreateRootPermission	L113	L96
id	MsgCreateRootPermissionResponse	L117	L100
id	MsgExtendPermission	L122	L105
id	MsgRevokePermission	L133	L116
issuerPermId	MsgCreateOrUpdatePermissionSession	L143	L126
verifierPermId	MsgCreateOrUpdatePermissionSession	L144	L127
agentPermId	MsgCreateOrUpdatePermissionSession	L145	L128
walletAgentPermId	MsgCreateOrUpdatePermissionSession	L146	L129
id	MsgSlashPermissionTrustDeposit	L155	L138
amount	MsgSlashPermissionTrustDeposit	L156	L139
id	MsgRepayPermissionSlashedTrustDeposit	L164	L147
schemaId	MsgCreatePermission	L172	L155
verificationFees	MsgCreatePermission	L178	L161
validationFees	MsgCreatePermission	L179	L162
id	MsgCreatePermissionResponse	L183	L166

Optional fields changed (field: → field?:):

Field	Interface	ts-proto line	frontend line
effectiveUntil	MsgSetPermissionVPToValidated	L75	L65
effectiveFrom	MsgCreateRootPermission	L109	L92
effectiveUntil	MsgCreateRootPermission	L110	L93
effectiveUntil	MsgExtendPermission	L123	L106
effectiveFrom	MsgCreatePermission	L176	L159
effectiveUntil	MsgCreatePermission	L177	L160

Timestamp helpers changed:

• toTimestamp(): ts-proto L2392 uses number seconds → frontend L2322 uses numberToLong() wrapping
• fromTimestamp(): ts-proto L2397 (t.seconds || 0) → frontend L2327 (t.seconds.toNumber() || 0)
• longToNumber() replaced by numberToLong(): ts-proto L2403-L2410 → frontend L2333-L2335

---

Module: td (Trust Deposit)

File sizes: ts-proto 828 lines → frontend 671 lines (157 lines fewer)

Structural removal:

Removed	ts-proto lines
MsgSlashTrustDeposit interface + full codec (encode/decode/JSON/partial)	L55-L72 (interface), L469-L597 (codec)
MsgSlashTrustDepositResponse interface + full codec	L74-L75 (interface), L599-L655 (codec)
SlashTrustDeposit RPC method	L750 (service interface), L763 (bind), L785-L789 (method)

Frontend replaces SlashTrustDeposit RPC with a comment: // rpc SlashTrustDeposit(MsgSlashTrustDeposit) returns (MsgSlashTrustDepositResponse); at frontend L621.

uint64 fields changed from number to Long:

Field	Interface	ts-proto line	frontend line
claimedAmount	MsgReclaimTrustDepositYieldResponse	L40	L40
claimed	MsgReclaimTrustDeposit	L45	L45
burnedAmount	MsgReclaimTrustDepositResponse	L50	L50
claimedAmount	MsgReclaimTrustDepositResponse	L52	L52
amount	MsgRepaySlashedTrustDeposit	L79	L62

---

Module: tr (Trust Registry)

File sizes: ts-proto 1087 lines → frontend 1101 lines (14 lines more, due to commented-out code)

uint64 fields changed from number to Long:

Field	Interface	ts-proto line	frontend line
id	MsgAddGovernanceFrameworkDocument	L50	L50-L52
id	MsgIncreaseActiveGovernanceFrameworkVersion	L65	L67
id	MsgUpdateTrustRegistry	L75	L77
id	MsgArchiveTrustRegistry	L87	L89

Note: The frontend MsgAddGovernanceFrameworkDocument contains commented-out code showing the id field evolved through multiple types (string → number → Long). These comments appear at frontend lines L50-L52, L394-L399, L443-L447, L493-L495, L508-L514, L542-L544.

---

Summary

Module	uint64 number→Long fields	Structural removals	Optional field changes
cs	4 fields	None	10 fields
dd	0 fields	None	1 field (params)
perm	26 fields	OptionalUInt64 fee fields in MsgStartPermissionVP; issuanceFeeDiscount/verificationFeeDiscount in MsgSetPermissionVPToValidated	6 fields
td	5 fields	MsgSlashTrustDeposit + MsgSlashTrustDepositResponse + SlashTrustDeposit RPC entirely removed	0 fields
tr	4 fields	None	0 fields

[matlux]

Adding concrete code pointers before implementation starts, so we avoid repeating past Amino regressions.

Pitfalls to keep in view (with line refs)

1. MsgCreatePermission zero-fee omission is intentional and sign-byte sensitive.

• Omit-if-zero helper: ts-proto/src/helpers/aminoConverters.ts:49
• Where it is used for MsgCreatePermission: ts-proto/src/helpers/aminoConverters.ts:403, ts-proto/src/helpers/aminoConverters.ts:413, ts-proto/src/helpers/aminoConverters.ts:414
• If these become explicit "0" fields again, sign bytes can diverge.

2. Optional wrapper semantics for CS are also deliberate.

• { value: 0 } -> {} encode semantics: ts-proto/src/helpers/aminoConverters.ts:64
• {} decode back to wrapper zero: ts-proto/src/helpers/aminoConverters.ts:71
• Applied in CS converter: ts-proto/src/helpers/aminoConverters.ts:278, ts-proto/src/helpers/aminoConverters.ts:284

3. Amino type map should remain consistent with current signing setup.

• Current map used by tests/client helper: ts-proto/test/src/helpers/client.ts:127

4. The perm bench explicitly demonstrates the breaking condition.

• Client-style zero-field injection: ts-proto/test/scripts/benches/amino/perm/ts.ts:46, ts-proto/test/scripts/benches/amino/perm/ts.ts:49, ts-proto/test/scripts/benches/amino/perm/ts.ts:50
• “omit vs zeros” verification checks: ts-proto/test/scripts/benches/amino/perm/ts.ts:85, ts-proto/test/scripts/benches/amino/perm/ts.ts:171

Dependency note before #242 implementation

There were CI coverage gaps around exactly these bench/type-check paths.

• Rationale issue: Retro: why ts-proto CI coverage gaps had to be closed #244
• Implementation PR (pending merge): Close ts-proto CI coverage gaps and untrack runtime artifacts #243

The concrete additions are in tsClientTests.yml:

• ts-proto/test type-check gate: .github/workflows/tsClientTests.yml:81
• Amino parity bench gates (perm+cs, TS↔Go compare): .github/workflows/tsClientTests.yml:130

Recommendation: merge #243 first, then implement #242 under those gates.

[antoniobenavidesvallejo]

Good afternoon, the following clarifications:

1. All errors encountered while signing on Amino were corrected on the front end. Furthermore, to correct some problems, it was necessary to specify the lines of code that needed to be changed in the go statement of the chain. These lines were then replaced with wrappers, without commenting, and again on the front end, it was necessary to adjust the Amino converters and helpers to make it work with these changes.

2. The verana-types library that we want to publish consists of two parts: the first, the proto-codecs generated by protoc-gen-ts_proto, which allow signing both Direct and Amino; the second, the Amino converters and helpers that have been developed and adjusted in the verana-frontend project, which are what allow transactions to be made by signing on Amino.

3. The current verana-types library contains an older copy of the Amino converters and helpers developed in the verana-frontend project. It has everything in a single 1008-line file, while the frontend consists of 5 files organized in the same way that the transactions are defined in the chain (dd, cs, tr, td, and perm), plus one more file with the helpers used in these Amino converters. The frontend approach is a better development practice.

4. The proto-codecs generated by protoc-gen-ts_proto "should" remain unchanged in the verana-types library, a recommendation that the generator notes in the comments of the ts files. These are the files that actually do everything @matlux mentions in his comment. The Amino converters are used when signing transactions with Amino, which is why the problems with Amino signatures have been corrected in them, avoiding modifications to the proto-codecs.

5. The task for the created issue had two parts: first, updating the current Amino converters and helpers (those that are working), while maintaining the six frontend files and avoiding a single file with more than a thousand lines; second, comparing the differences between the tx.ts files of the proto-codecs generated for each package by protoc-gen-ts_proto. The importance of this review is that if the proto-codecs were the same, updating the Amino converters would allow us to have the verana-types library ready for publication and use in the frontend via npm.

6. @AirKyzzZ's findings indicate that the protocodecs are generated with different versions of the protocol and have differences in the types that, while functional for signing direct, prevent them from working with the frontend's Amino converters. It even seems as if an older version of the generator was used, because there is a Node/CommonJS import that was done previously; the preference in NextJS today is ESM. The biggest changes that would affect Amino Converters and, in general, the signing of frontend transactions are related to the handling of uint64: the proto-codec version generated with protoc v5.29.3 handles them as Long in a way that ensures protobufjs uses Long correctly; however, the proto-codecs from the library, generated with an undefined protoc version, do not use Long and could lead protobufjs to decode int64/uint64 as a number.

7. Therefore, to continue, we need @matlux, or whoever is responsible, to answer the following questions:

• What is the reason for using an older version of the proto-codec generator?

• Is it strictly necessary to use the older version, or can the proto-codecs be generated with protoc v5.29.3?

The answers determine whether updating the Amino Converters and helpers will allow us to publish a stable version of Verna Types that uses our Verna Frontend and any other frontend; or whether we need to make adjustments to the Amino Converters and other components of the signature so that they work with the current Proto-Codecs of the library, which, I reiterate, belong to an earlier version of Proto-Codec.

[antoniobenavidesvallejo]

Amino converters and helpers with the latest changes for transactions: permissions and credential schemas & proto-codecs generated with: protoc-gen-ts_proto v1.181.2 and protoc v5.29.3 (libprotoc 29.3)

###Delete

• /ts-proto/src/helpers/aminoConverters.ts
• /ts-proto/src/helpers

Create

/ts-proto/src/amino-converter/

copy full folder from /verana-labs/verana-frontend: /verana-frontend/app/msg/amino-converter

/amino-converter/

• cs.ts
• dd.ts
• perm.ts
• td.ts
• tr.ts

/amino-converter/util/

• helpers.ts

Replace

/ts-proto/src/codec with /verana-frontend/proto-codecs/codec

Update imports to test

Update the test imports and run them. If there are errors or not, put them in the comments of the issue.

Readme

Create a Readme file specifying which helper should be used for the types that require it. This will serve as instructions for creating new Amino converters.