Add `updateToken` endpoint to tck module

[manishdait]

Add the updateToken endpoint to the tck module, Following the TokenUpdate Specification

Chnages To Made

• Add the update_token method to the handler/token.py
• Create the dataclass representing params/response for token update transaction
• Test the endpoint against hiero-sdk-tck

[github-actions]

Thanks for your submission.

This issue is awaiting approval from @hiero-ledger/hiero-sdk-python-triage and @hiero-ledger/hiero-sdk-python-committers and @hiero-ledger/hiero-sdk-python-maintainers.

[github-actions]

Approved by @hiero-ledger/hiero-sdk-python-triage and @hiero-ledger/hiero-sdk-python-committers and @hiero-ledger/hiero-sdk-python-maintainers.

[github-actions]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

• Add updateToken by replicating the established 3-layer TCK pattern (param → handler → response) used by createToken/deleteToken, requiring no routing/server changes since handlers self-register.
• Model UpdateTokenParams on the reference TCK field set (mutable token fields only) and reuse the exact create_token conversion helpers (get_key_from_string, Timestamp, Duration, AccountId/TokenId.from_string, to_int).
• Return a status-only UpdateTokenResponse and execute via the standard build → apply common params → execute → receipt skeleton.
• Validate compliance by running the external hiero-sdk-tck suite against the running server rather than adding new internal unit tests.

Design Choices

Design Choice 1: Should the `keyVerificationMode` field be included in `UpdateTokenParams`?

Options Considered:

1. Include keyVerificationMode as an optional param mapped to the TokenKeyValidation enum.
2. Omit keyVerificationMode to stay aligned with the established TCK param surface.

Chosen Option: 2

Rationale: Match the reference TCK specification param set (which omits it) to remain compliant with the external suite; it can be added later if the spec requires it.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Add updateToken Endpoint

This phase introduces the complete updateToken capability across the three TCK layers (param → handler → response). All three pieces are grouped together because they form one cohesive, independently reviewable feature, and the handler cannot compile without its param/response counterparts. The goal is to mirror the existing createToken conventions for mutable token fields and the deleteToken/updateAccount execution skeleton, so the new endpoint automatically registers with the dispatch registry and becomes reachable via JSON-RPC with no server/protocol changes.

Task 1: Define the UpdateToken request param dataclass

Introduce the request-side model that parses incoming JSON-RPC params for token updates.

• Add UpdateTokenParams to tck/param/token.py, extending BaseTransactionParams (which already provides sessionId and commonTransactionParams).
• Declare all fields as optional (str | None = None), mirroring the reference TCK param surface: tokenId, name, symbol, treasuryAccountId, adminKey, kycKey, freezeKey, wipeKey, supplyKey, feeScheduleKey, pauseKey, metadataKey, memo, expirationTime, autoRenewAccountId, autoRenewPeriod, metadata.
• Implement parse_json_params(cls, params) following the CreateTokenParams convention: read each field via params.get(...), keep key/expiry/auto-renew fields as raw strings (conversion deferred to the handler), and terminate with sessionId=parse_session_id(params) and commonTransactionParams=parse_common_transaction_params(params).

Task 2: Define the UpdateToken response dataclass

Introduce the result-side model returned to the caller.

• Add UpdateTokenResponse to tck/response/token.py as a subclass of StatusOnlyResponse (from tck/response/base.py), matching DeleteTokenResponse/FreezeTokenResponse/PauseTokenResponse, since updateToken only returns a transaction status.

Task 3: Implement the update_token handler and transaction builder

Add the business logic that builds, signs, executes, and reports the result of a token update.

• In tck/handlers/token.py, add TokenUpdateTransaction to the SDK imports and add UpdateTokenParams/UpdateTokenResponse to the existing tck.param.token/tck.response.token import groups.
• Add a private _build_update_token_transaction(params) -> TokenUpdateTransaction builder that instantiates the transaction with .set_grpc_deadline(DEFAULT_GRPC_TIMEOUT) and conditionally applies each setter only when the corresponding field is not None, reusing the create_token conversion conventions:
  • tokenId → TokenId.from_string(...) via set_token_id.
  • treasuryAccountId/autoRenewAccountId → AccountId.from_string(...).
  • all key fields (adminKey, kycKey, freezeKey, wipeKey, supplyKey, feeScheduleKey, pauseKey, metadataKey) → get_key_from_string(...).
  • expirationTime → Timestamp(seconds=to_int(...), nanos=0).
  • autoRenewPeriod → Duration(seconds=to_int(...)).
  • name, symbol, memo, metadata → set directly.
• Add the public @rpc_method("updateToken") def update_token(params: UpdateTokenParams) -> UpdateTokenResponse handler that gets the client via get_client(params.sessionId), builds the transaction, applies commonTransactionParams.apply_common_params(...) when present, executes with wait_for_receipt=False, fetches the receipt with validate_status=True, and returns UpdateTokenResponse(status=ResponseCode(receipt.status).name) — matching the delete_token skeleton exactly.
• No changes are required to tck/handlers/__init__.py, tck/server.py, or tck/protocol.py; the decorator auto-registers the method.

🤖 Prompt for AI agents

Implement the `updateToken` JSON-RPC endpoint in the TCK module by adding three
cohesive pieces across the param/handler/response layers, mirroring the existing
`createToken`/`deleteToken` conventions so the endpoint auto-registers with no
server/protocol changes.

1. In `tck/param/token.py`:
- Add an `UpdateTokenParams` dataclass extending `BaseTransactionParams` (which
already provides `sessionId` and `commonTransactionParams`).
- Declare all fields as optional (`str | None = None`): `tokenId`, `name`,
`symbol`, `treasuryAccountId`, `adminKey`, `kycKey`, `freezeKey`, `wipeKey`,
`supplyKey`, `feeScheduleKey`, `pauseKey`, `metadataKey`, `memo`,
`expirationTime`, `autoRenewAccountId`, `autoRenewPeriod`, `metadata`.
- Implement `parse_json_params(cls, params)` following the `CreateTokenParams`
convention: read each field via `params.get(...)`, keep key/expiry/auto-renew
fields as raw strings (deferring conversion to the handler), and end with
`sessionId=parse_session_id(params)` and
`commonTransactionParams=parse_common_transaction_params(params)`.

2. In `tck/response/token.py`:
- Add `UpdateTokenResponse` as a subclass of `StatusOnlyResponse` (from
`tck/response/base.py`), matching the pattern used by
`DeleteTokenResponse`/`FreezeTokenResponse`/`PauseTokenResponse`, since
`updateToken` only returns a transaction status.

3. In `tck/handlers/token.py`:
- Add `TokenUpdateTransaction` to the SDK imports, and add
`UpdateTokenParams`/`UpdateTokenResponse` to the existing
`tck.param.token`/`tck.response.token` import groups.
- Add a private `_build_update_token_transaction(params) ->
TokenUpdateTransaction` builder that instantiates the transaction with
`.set_grpc_deadline(DEFAULT_GRPC_TIMEOUT)` and conditionally applies each setter
only when the corresponding field is not `None`, reusing the `create_token`
conversion conventions:
     - `tokenId` → `TokenId.from_string(...)` via `set_token_id`.
     - `treasuryAccountId`/`autoRenewAccountId` → `AccountId.from_string(...)`.
- key fields (`adminKey`, `kycKey`, `freezeKey`, `wipeKey`, `supplyKey`,
`feeScheduleKey`, `pauseKey`, `metadataKey`) → `get_key_from_string(...)`.
     - `expirationTime` → `Timestamp(seconds=to_int(...), nanos=0)`.
     - `autoRenewPeriod` → `Duration(seconds=to_int(...))`.
     - `name`, `symbol`, `memo`, `metadata` → set directly.
- Add the public handler `@rpc_method("updateToken") def update_token(params:
UpdateTokenParams) -> UpdateTokenResponse` that gets the client via
`get_client(params.sessionId)`, builds the transaction using the builder,
applies `commonTransactionParams.apply_common_params(...)` when present,
executes with `wait_for_receipt=False`, fetches the receipt with
`validate_status=True`, and returns
`UpdateTokenResponse(status=ResponseCode(receipt.status).name)` — matching the
`delete_token` skeleton exactly.
- Do not modify `tck/handlers/__init__.py`, `tck/server.py`, or
`tck/protocol.py`; the `@rpc_method` decorator auto-registers the new method.

Omit `keyVerificationMode` from `UpdateTokenParams` per the assumption
resolution, to remain aligned with the reference TCK param surface.

No new internal unit tests are required; verification is performed by running
the TCK server (`python -m tck`, default `localhost:8544`) and pointing the
external `hiero-sdk-tck` `TokenUpdateTransaction` spec suite at it.

Research

The TCK module (tck/) exposes a Flask JSON-RPC 2.0 server (tck/server.py) that dispatches methods through a global registry (tck/handlers/registry.py). Every method follows a strict 3-layer pattern: a request dataclass in tck/param/, business logic in tck/handlers/ decorated with @rpc_method, and a result dataclass in tck/response/. Handlers auto-register at import time via tck/handlers/__init__.py, so no manual routing changes are needed. Token operations live in tck/param/token.py, tck/handlers/token.py, and tck/response/token.py. The underlying SDK already provides TokenUpdateTransaction (src/hiero_sdk_python/tokens/token_update_transaction.py) with all necessary setters. Shared utilities (get_key_from_string, to_int, AccountId/TokenId/Timestamp/Duration construction, DEFAULT_GRPC_TIMEOUT) are reused across handlers.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Implement the `updateToken` JSON-RPC endpoint in the TCK module by adding three
cohesive pieces across the param/handler/response layers, mirroring the existing
`createToken`/`deleteToken` conventions so the endpoint auto-registers with no
server/protocol changes.

1. In `tck/param/token.py`:
- Add an `UpdateTokenParams` dataclass extending `BaseTransactionParams` (which
already provides `sessionId` and `commonTransactionParams`).
- Declare all fields as optional (`str | None = None`): `tokenId`, `name`,
`symbol`, `treasuryAccountId`, `adminKey`, `kycKey`, `freezeKey`, `wipeKey`,
`supplyKey`, `feeScheduleKey`, `pauseKey`, `metadataKey`, `memo`,
`expirationTime`, `autoRenewAccountId`, `autoRenewPeriod`, `metadata`.
- Implement `parse_json_params(cls, params)` following the `CreateTokenParams`
convention: read each field via `params.get(...)`, keep key/expiry/auto-renew
fields as raw strings (deferring conversion to the handler), and end with
`sessionId=parse_session_id(params)` and
`commonTransactionParams=parse_common_transaction_params(params)`.

2. In `tck/response/token.py`:
- Add `UpdateTokenResponse` as a subclass of `StatusOnlyResponse` (from
`tck/response/base.py`), matching the pattern used by
`DeleteTokenResponse`/`FreezeTokenResponse`/`PauseTokenResponse`, since
`updateToken` only returns a transaction status.

3. In `tck/handlers/token.py`:
- Add `TokenUpdateTransaction` to the SDK imports, and add
`UpdateTokenParams`/`UpdateTokenResponse` to the existing
`tck.param.token`/`tck.response.token` import groups.
- Add a private `_build_update_token_transaction(params) ->
TokenUpdateTransaction` builder that instantiates the transaction with
`.set_grpc_deadline(DEFAULT_GRPC_TIMEOUT)` and conditionally applies each setter
only when the corresponding field is not `None`, reusing the `create_token`
conversion conventions:
     - `tokenId` → `TokenId.from_string(...)` via `set_token_id`.
     - `treasuryAccountId`/`autoRenewAccountId` → `AccountId.from_string(...)`.
- key fields (`adminKey`, `kycKey`, `freezeKey`, `wipeKey`, `supplyKey`,
`feeScheduleKey`, `pauseKey`, `metadataKey`) → `get_key_from_string(...)`.
     - `expirationTime` → `Timestamp(seconds=to_int(...), nanos=0)`.
     - `autoRenewPeriod` → `Duration(seconds=to_int(...))`.
     - `name`, `symbol`, `memo`, `metadata` → set directly.
- Add the public handler `@rpc_method("updateToken") def update_token(params:
UpdateTokenParams) -> UpdateTokenResponse` that gets the client via
`get_client(params.sessionId)`, builds the transaction using the builder,
applies `commonTransactionParams.apply_common_params(...)` when present,
executes with `wait_for_receipt=False`, fetches the receipt with
`validate_status=True`, and returns
`UpdateTokenResponse(status=ResponseCode(receipt.status).name)` — matching the
`delete_token` skeleton exactly.
- Do not modify `tck/handlers/__init__.py`, `tck/server.py`, or
`tck/protocol.py`; the `@rpc_method` decorator auto-registers the new method.

Omit `keyVerificationMode` from `UpdateTokenParams` per the assumption
resolution, to remain aligned with the reference TCK param surface.

No new internal unit tests are required; verification is performed by running
the TCK server (`python -m tck`, default `localhost:8544`) and pointing the
external `hiero-sdk-tck` `TokenUpdateTransaction` spec suite at it.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Hi @aceppaluni 👋

This issue has been assigned but no pull request has been created yet.
Are you still planning on working on it?
If you are, please create a draft PR linked to this issue or comment /working to let us know.
If you’re no longer able to work on this issue, you can comment /unassign to release it.

From the Python SDK Team

[aceppaluni]

/working