test GFI

[DeathGun44]

🆕🐥 Newcomer Friendly

Welcome! This is a Good First Issue designed to be approachable to brand-new contributors.

🏁 When this issue is complete, you will have:

✅ Learned how to fork and navigate the codebase
✅ Learned our contribution workflow
✅ Implemented a real change to the SDK

🐞 Problem Description

💡 Solution

🛠️ Implementation Steps

🧠 Good First Issue Developers — Prerequisites & Expectations

Important

This issue does not require prior domain knowledge.

• No Hiero or Hedera experience needed
• No distributed ledger background required
• Beginner Programming is sufficient

Note

⏱️ Typical time to complete: ~1 Day / ~4 hours (including set-up)
🧩 Difficulty: Small, well-contained change
🎓 Best for: New contributors

🤖 AI Usage Policy

• Good First Issues are open for humans, AI bot-authored PRs will be rejected.
• Refer to our set-up and workflow guides, AI may make mistakes.

Warning

We expect pull requests to use our workflow and meet the quality standards outlined in this issue.

📋 Step-by-Step Setup Procedure

• Visual Studio (VS) Code: Guide

• GitHub Desktop: Guide

• Hedera Testnet Account with root .env file: Guide

• Create a GPG key linked to GitHub: Guide

• Fork Create an online and local copy of the repository: Guide

• Connect origin with upstream: Guide

• Install Packages and protobufs: Guide

• Windows users: see the Windows Setup Guide for platform-specific installation steps.

• Sync Main pull any recent upstream changes: Guide

You are set up! 🎉

📋 Step-by-step workflow guide

✅ Get ready

• Claim the issue: comment /assign: Guide. Pull requests created without being assigned will be automatically closed.

• Double check the Issue and AI plan: carefully re-read the issue description and any AI plan below

• Ask questions early: ask on Discord, and the @good_first_issue_support_team (setup and workflow help)

• Sync Main pull any recent upstream changes: Guide

• 💡 Tip: Before coding, you are free to leave a short comment describing what you plan to change. We'll confirm you're on the right track.

🛠️ Solve the Issue

• Create a branch from main: Guide

• Implement the solution: follow the implementation steps in the issue description.

• Commit with Conventional format and DCO, GPG signing: commit changes using: git commit -S -s -m "chore: your message", Guide

• Add a .CHANGELOG.md entry: under the appropriate [UNRELEASED] section and commit as git commit -S -s -m "chore: changelog entry" Guide

🚀 Create the pull request

• Push your commits: push your branch to your fork git push origin your-branch-name Guide

• Open a pull request: Guide

• Complete the PR description: briefly describe your changes, Guide

• Link the Issue: link the issue the PR solves in the PR description, Guide. Pull requests created without a linked issue will be automatically closed.

• Submit the pull request: click **Create pull request** and Ready to Review 🎉

✅ PR Quality Checklist

To be able to close this issue, the following criteria must be met:

Workflow:

• I have worked from a branch that is up to date with main
• I have not made changes outside the scope of this issue
• My commits are signed: git commit -S -s -m "chore: description" — Signing guide
• I added a CHANGELOG.md entry (if appropriate) under [Unreleased] — Changelog guide
• I linked the issue in my PR description using Fixes #issue_number to automatically close it when merged
• I have applied appropriate linting, code quality, and formatting tools used in this repo (if applicable).

Issue Requirement:

• The issue is solved: I've carefully read and implemented the issue requirements

---

🤔 What to expect after submitting a PR

Once you open a pull request, here's what happens next.

🤖 1. Automated checks
Automated checks will run and all must pass before merging.
Open any failed check at the bottom of the PR to see details. Ask for help if you don't understand a failure or how to fix it.

😎 2. Initial Team review
Once tests pass, a team member will check if your PR follows the workflow.

✅ 2. Team review
Once your tests pass and the workflow is followed, a team member will review the implementation.
You may be asked to make changes or your PR may be approved.
Approved PRs are usually merged within one day.

🔄 Merge conflicts (sometimes)
Conflicts can happen and are normal as the SDK updates. Resolve using this Guide

Tip

Follow the workflow and double check your work
This is the best way to ensure a fast review and merge process.

---

🧭 Getting help if you're stuck

🆘 Stuck?

Tip

• Comment on this issue and ask maintainers or tag @good_first_issue_support_team

Other Resources:

• New Starter Docs (Signing, Rebasing, Changelog, Merge Conflicts, Workflow, Setup)
• All Things Github Workflows
• Community Calls
• Discord

---