Implement the transaction module: builder, fee estimation, and fee bump

[N-thnI]

Description

Deliver a complete transaction-construction module with tests.

Problem Statement

Transaction building is duplicated in vero-relayer-service/src/services/stellar.js and vero-guardian-dashboard/src/lib/stellar-interact.ts, each with its own defaults for fee, timeout, and network passphrase — divergent defaults are how a transaction succeeds in one service and fails in another for non-obvious reasons. Fee handling also needs bounds: the relayer shipped without them until vero-relayer-service#134, and an unbounded fee read from a network spike is a real fund-loss risk.

Proposed Changes

• Add src/transaction/builder.ts — accept a NetworkConfig so passphrase and endpoint can never mismatch; provide a manageData helper using the DataKey names from src/types
• Add src/transaction/fees.ts — estimateFee(rpc, opts) clamped to a required [minFee, maxFee], throwing a VeroError when the bounds are inverted rather than producing nonsense
• Add buildFeeBump() reusing the original sequence — a fee bump must not consume a new one
• Add src/__tests__/transaction.test.ts asserting on decoded XDR, not string equality
• Export from src/index.ts

Technical Implementation Scaffolding

• Target Repository: vero-sdk
• Target Path: src/transaction/
• Branch Naming: feat/issue--transaction-module
• Authority Context: Security-sensitive — constructs what users and services sign

Acceptance Criteria

• manageData entry names match DataKey exactly
• Fee clamps at both bounds; inverted bounds throw
• A fee bump does not consume an additional sequence number
• Tests cover all of the above
• npm test, npm run typecheck, npm run lint, and npm run build all pass

Definition of Done

• Reviewed by lead maintainer
• Pull request merged via verified status check

---

This issue is self-contained. Everything it needs already exists on main; it does not wait on any other issue. Deliver the module and its tests in one PR.

[Oshone87]

I have experience working with JavaScript/TypeScript, backend services, APIs, and writing tests around application logic. I’m interested in this issue because centralizing transaction construction and fee handling into a reusable SDK module is important for keeping transaction behavior consistent across services. I can implement the transaction builder around the existing NetworkConfig and DataKey types, add bounded fee estimation and fee-bump construction while preserving the original sequence number, and write tests that validate the resulting XDR rather than relying on string comparisons. I’ll also verify the implementation with the project’s typecheck, lint, test, and build commands.

[amankoli09]

Can i work on this issue PR merge within 1hr

[grantfox-oss]

🦊 GrantFox — @amankoli09 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #45)
2. Your PR will be reviewed by the Vero-protocol maintainers

Good luck! Track your progress on GrantFox.