Roadmap
Signed writes — what's coming and what it needs
Not implemented yet: Everything on this page is planned, not available today. Every
operation currently shipped on this node (see Overview) is a free Mirror Node
read.
Planned Write Operations
| Resource | Planned Operation |
|---|---|
account | create, transfer |
token | mint, associate, transfer |
topic | create, submit (publish a message) |
utility | sign message |
These will follow the exact same partial-class/service pattern as today's reads — same
resource/operation config shape, same per-network selection.
Why They're Not Here Yet: the SDK Gap
Signing a Hedera transaction requires an actual Hedera SDK — Mirror Node REST calls, which is all this node uses today, can only read. Two SDK options exist:
Hashgraph(community package by bugbytesinc) — net9-compatible, the intended dependency for the Services layer.Hiero(the newer successor SDK) — currently targets net10 only, so it can't be used until this project's target framework moves forward.
How Signing Will Work
The signing credential will be resolved from a vault CRYPTO_WALLET record via the
executor's credentials layer (the same ReadCredentialRawPrimaryAsync →
CryptoWalletRecord pattern already used by the Ethereum node), plus two additional
config fields supplied per write operation:
| Field (planned) | Description |
|---|---|
credentialId | Vault reference to the CRYPTO_WALLET record holding the private key. |
payerAccountId | The Hedera account ID that pays the transaction fee and signs it. |
keyAlgorithm | Key type used by the payer account — ED25519 or ECDSA_SECP256K1. |
Want this sooner? Track progress via the BizFirst.Ai team — the SDK spike and
wallet-credential wiring are the two blocking pieces of work before write operations can ship.