🧑‍💻 Intermediate Issue

Welcome! This is an Intermediate Issue touching core SDK architecture.

🏁 When this issue is complete, you will have:

✅ Researched across multiple files and modules
✅ Owned implementation decisions
✅ Written thorough, meaningful tests
✅ Delivered a clean, review-ready pull request

🐞 Problem Description

Currently the the NodeCreateTransaction and NodeUpdateTransaction class in the SDK uses the PublicKey type for admin_key field. hese field should support any valid Key which include Public/Private Key

💡 Expected Solution

Update the NodeCreateTransaction and NodeUpdateTransaction class to accept the generic Key class for admin_key field

🔍 Background Research

• Review hiero_sdk_python/crypto/key.py to understand the base Key class.
• Reference hiero_sdk_python/account/account_create_transaction.py or account_update_transaction.py, which already use the Key class for the key field.

🛠️ Implementation Notes

• Locate the admin_key field in the NodeCreateTransaction and NodeUpdateTransaction class.

• Change the type from the PublicKey to the Key.

admin_key: Key | None = None

• Update the setter method for admin_key in both class

def set_admin_key(self, admin_key: Key | None):
        self._require_not_frozen()
        self.admin_key = admin_key
        return self

• Update the _build_proto_body() method to parse the Key

def _build_proto_body(self):
           # Rest of the code
            admin_key=self.admin_key.to_proto_key() if self.admin_key is not None else None,
           # Rest of the code

• Create a unit test for testing this changes using the public and private key
• Validate the changes

Note:
The above code snippet are just for example

🔬 Technical Domains

• Intermediate to Advanced Programming (Object oriented design, inheritance, complex type systems)
• File Specific Knowledge (request → serialization → execution → response mapping)
• Backward Compatibility (preserving method signatures, defaults, and return types)
• Protobuf Alignment (reading .proto files, _to_proto() / _from_proto() correctness)
• Testing (unit, integration, mocking, test coverage for edge cases and failure modes)

🧠 Intermediate Contributors — Prerequisites & Expectations

🏁 Concrete Prerequisites

• Advanced Programming Language: Higher level intermediate or advanced programming language.
• Expertise: Strong understanding of files related to this issue (research before claiming!).
• Proven History: Successfully completed ≥ 5 beginner issues in this repo.

If this feels like too big a step, that is completely fine — try a Beginner Issue first or a different Intermediate Issue. You can always come back when you are ready.

⚠️ AI Usage Policy

• Using AI to generate code for Intermediate issues is strictly discouraged
• Using AI as the main source of research is strictly discouraged, refer to language and library documentation, protobuf definitions and other SDKs.

⏱️ Timeline & Workflow

• Typical time: ~2 weeks / ~25 hours.
• 🔴 Completing an intermediate issue in 1–3 days is a red flag.

🧪 Testing Requirements

How you test depends on the type of change.

Source code changes (e.g. in src/):

• Write unit tests covering happy path, edge cases, and error handling
• Run tests locally: uv run pytest tests/unit/<specific_file>_test.py -v
• Verify naming, types, and field ordering match protobuf definitions
• Check consistency with similar classes already in the SDK — use the same patterns
• Integration tests will run automatically when you push

GitHub Actions / workflow changes (e.g. in .github/): Guide

• Test by merging to your fork's main and simulating the scenario
• Create test issues or PRs as evidence and link them in your PR
• Include screenshots of workflow runs where applicable

Example script changes (e.g. in examples/):

• Run the example script and confirm output matches expected behavior
• Compare your example with similar existing examples for consistency
• You will need a Hedera Portal account for testnet credentials

🛡️ Quality & Review Standards

Intermediate PRs must be "working, maintainable, and aligned with SDK architecture."

1. Working: The implementation must solve the problem and meet the acceptance criteria.
2. Maintainable: Code should be clear and concise enough for others to understand and debug without your assistance.
3. SDK Alignment: The solution should fit well with existing SDK patterns and abstractions.
4. Backward Compatibility: Public API signatures must be preserved.
5. Comprehensive Testing: Must include unit and integration tests covering all new logic paths, edge cases, and failure modes. AI generated tests based on AI generated code is grounds for immediate rejection.

⚠️ Breaking changes

• Before changing any function signature, return type, or public API — stop and check
• If a breaking change is unavoidable: get explicit maintainer approval before implementing
• All existing tests should pass as-is.

🤖 AI notes

• AI often has outdated real-world knowledge: it will not be able to identify current packages.
• AI has gaps or incorrect understanding of repo-specific patterns, logic, and protobuf schemes.

✅ PR Quality Checklist

Before opening your PR, confirm:

• I have spent the majority of my time researching the problem and solution space extensively, including reviewing relevant code, documentation, and external resources.
• My implementation works but is also of high quality - including maintainability, readability, and architectural fit.
• I have checked for breaking changes - no public APIs regress.
• The system design fits with current Hiero SDK architectural approaches.
• Every line of code is personally understood and explainable.

Before requesting a review, confirm:

• I have reviewed the diff line by line.
• My implementation fully addresses the problem described above.
• I did not modify files unrelated to this issue
• Clean git history — no rebase artifacts, merge commits, or unrelated files
• My commits are signed: git commit -S -s -m "chore: description" — Signing guide
• I have verified naming, types, and field ordering against pinned Protobufs.
• I have applied appropriate linting, code quality, and formatting tools used in this repo.
• I have included appropriate tests and all CI checks pass.
• Double and triple check — intermediate PRs are time-consuming to review

📋 Workflow quick reference

You know the workflow — here are the links if you need them:

📚 Resources & Support

🆘 Stuck?

Project references:

• Project structure
• CONTRIBUTING.md
• Browse closed intermediate PRs — see how others did it
• Pylance guide

Protobuf references:

• Hedera Protobufs — source of truth for field names, types, and ordering
• Protobuf language guide

Python references:

• Python official docs
• Data model (dunder methods)
• Type hints
• unittest.mock — for mocking in tests

Community:

• Community Calls
• Discord