Skip to content

Conversation

@Adityarya11
Copy link
Contributor

@Adityarya11 Adityarya11 commented Nov 5, 2025

Description:

This PR updates TokenCreateTransaction to accept PublicKey objects for all key fields, in addition to the existing PrivateKey. This is a crucial feature to enable non-custodial transaction building.

With this change, an application (like an agent) can construct a transaction using a user's PublicKey, serialize it, and then return the bytes to the user for them to sign with their PrivateKey.

This implementation follows the exact pattern already established in TopicCreateTransaction.py, as suggested by the maintainer.


Changes:

  • Created a Key = Union[PrivateKey, PublicKey] type alias.
  • Updated the TokenKeys dataclass to use the new Key type.
  • Updated all set_*_key methods to accept the Key type.
  • Updated the _to_proto_key helper to correctly handle both PrivateKey (by getting its public key) and PublicKey (by using it directly).

Related issue(s):

Fixes #735
also fixes
#104


Checklist

  • Documented (Updated CHANGELOG.md)
  • Tested (This is a direct import fix)

Copy link
Contributor

@exploreriii exploreriii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to unit and integration test the new functionality you've added - not just the existing functionality

For example
test if you can pass a public key and this will generate the token and convert to proto correctly
No tests for edge cases
I think we can expect ed2559 keys to have a problem with this method

@Adityarya11 Adityarya11 force-pushed the feat/token-create-public-key#729 branch 2 times, most recently from 65ab0d7 to 3af0f20 Compare November 6, 2025 11:10
@exploreriii
Copy link
Contributor

missing edge cases please

@Adityarya11 Adityarya11 force-pushed the feat/token-create-public-key#729 branch from 3af0f20 to a7f0fa4 Compare November 6, 2025 14:42
@exploreriii
Copy link
Contributor

@skurzyp-arianelabs requesting your opinion please

@skurzyp-arianelabs
Copy link

@exploreriii @Adityarya11 The implementation looks good to me, but I would recommend adding some testcases for ECDSA keys to make sure this implementation works fine for them too.
The full coverage would be using:

  • ED25519 PrivateKey - present
  • ED25519 PublicKey - present
  • ECDSA PrivateKey
  • ECDSA PublicKey

for setting the keys for the token.

Also, just to unify across the codebase I would recommend aligning the TopicCreateTransaction which currently accepts just the PublicKey. See: https://github.com/hiero-ledger/hiero-sdk-python/blob/main/src/hiero_sdk_python/consensus/topic_create_transaction.py Should i create an issue or can you handle it @exploreriii?

@exploreriii
Copy link
Contributor

Thanks for your ideas. I'm working at the moment maybe @nadineloepfe or @manishdait are available, else i can create it likely in a few hours.

@exploreriii
Copy link
Contributor

@manishdait created the issue, thank you so much

@exploreriii
Copy link
Contributor

Hi @Adityarya11 I'll be releasing a new python sdk release soon -
if this PR is not done in time that's no problem, but note you will need to change your changelog entry and put it under a new unreleased section.
it may be easier to start fresh.
Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support passing PublicKey instead of PrivateKey for TokenKeys object in token creation

3 participants