Draft templates/cross chain dca

[mmyslblocky]

Cross-Chain DCA Template

This PR adds a cross-chain DCA (Dollar-Cost Averaging) template as a new packages/cross-chain-dca package, demonstrating Hedera as a cross-chain orchestration layer for automated DeFi workflows.

Architecture

Hedera (DcaOrchestrator)
  └─ Schedule Service precompile (0x16b / HIP-1215) — self-reschedule, no off-chain keepers
  └─ AxelarMessageSender → callContract("ethereum-sepolia", ...)
        └─ Axelar relayer network
              └─ Sepolia (DcaExecutor)
                    └─ Uniswap v3 exactInputSingle

• Hedera acts as the control plane. DcaOrchestrator stores DCA plans and uses the Hedera Schedule Service (HIP-1215) to trigger recurring executions entirely on-chain with no off-chain keepers required.
• Axelar GMP serves as the cross-chain messaging layer (callContract only — no token bridging).
• Sepolia acts as the execution plane. DcaExecutor receives GMP messages and swaps USDC for the target token via Uniswap v3.

What's Included

Smart Contracts (packages/cross-chain-dca/)

• DcaOrchestrator.sol — Hedera-side plan manager with self-rescheduling via the Schedule Service precompile.
• AxelarMessageSender.sol — IBridgeSender implementation for Axelar GMP; bridge abstraction makes it swappable.
• DcaExecutor.sol — Sepolia-side executor that receives GMP messages and executes Uniswap v3 swaps.
• AxelarMessageReceiver.sol — Axelar IAxelarExecutable bridge between GMP and DcaExecutor.
• Full mock suites and Hardhat unit tests for both Hedera and Sepolia components.

Scripts

• deploy-all.sh — Single-command full deployment (Hedera → Sepolia → deployedContracts.ts generation).
• Per-side deployment, wiring, funding, balance-check, verification, and withdrawal scripts.
• Plan management scripts:
  • Create plan
  • Cancel plan
  • Inspect latest plan

Notable Design Decisions

Self-Rescheduling

No off-chain keeper is required. The orchestrator schedules its next execution during every execution cycle using the Hedera Schedule Service precompile.

Instruction-Only Bridging

The executor is pre-funded with USDC on Sepolia. Token bridging is intentionally out of scope for this template and documented as a future enhancement.

Bridge Abstraction

DcaOrchestrator depends on the IBridgeSender interface rather than Axelar directly. Supporting a different bridge provider only requires implementing a new IBridgeSender contract.

Additional Information

• I have read the contributing docs (if this is my first contribution).
• This is not a duplicate of any existing pull request.

[wiz-665387e357]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	4  1
Software Management Findings	-
Total	4  1

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[web3buidlerz]

Good detail in packages/cross-chain-dca/README.md, but template branches should treat the project-root README.md as canonical. Right now it still reads like the base scaffold from main (blank / payments-scheduler / hedera-demo), with cross-chain-dca added as a row in the table.

For draft-templates/cross-chain-dca, I'd suggest making the root README fully template-specific: what this template does, prerequisites, setup, deploy, test, and frontend — and link to packages/cross-chain-dca/README.md only for lower-level/package details. We can disregard the inherited main README content rather than trying to maintain both audiences in one file.

Also let's add to the prerequisites a way for users to get sepolia eth into their wallet as it can be cumbersome. Personally I used: https://sepolia-faucet.pk910.de/
Not sure it's actually the best option.

[web3buidlerz]

Template structure doesn't match scaffold-hbar / create-scaffold-hbar conventions

Introducing packages/cross-chain-dca as a separate workspace breaks how our templates are consumed. Template branches are expected to follow the standard layout:

packages/hardhat   OR   packages/foundry
packages/nextjs

with packages/nextjs + at least one Solidity framework package (hardhat or foundry) as the baseline. Other built-in templates (blank, payments-scheduler, hedera-demo) follow this — e.g. payments-scheduler puts contracts in packages/foundry and the app in packages/nextjs.

As-is, this PR adds packages/cross-chain-dca alongside the default packages/hardhat / packages/foundry, which won't wire up correctly when someone runs npx create-scaffold-hbar@latest --template cross-chain-dca. The CLI resolves a template branch and expects contracts, deploy scripts, and tests to live under the chosen framework package — not a bespoke top-level package.

Suggestion: fold the contract work into packages/hardhat , keep packages/nextjs for the /dca UI, and remove or empty the unused framework package.

[web3buidlerz]

Missing template.json — required for create-scaffold-hbar integration

This branch doesn't include a template.json, which other shippable templates in this repo do (e.g. payments-scheduler). That file isn't boilerplate — it's how the CLI understands and presents a template when someone runs:

npx create-scaffold-hbar@latest --template cross-chain-dca

Specifically, template.json tells create-scaffold-hbar:

• What this template is — name, description, and how it appears in the interactive picker
• Which capabilities it supports — e.g. nextjs-app frontend, hardhat or foundry as the Solidity framework
• Sensible defaults — so the CLI pre-selects the right options for this template
• Post-scaffold guidance — the outro.steps block (compile, deploy, start frontend, etc.) that users see after project creation

[web3buidlerz]

Frontend UX issues on /dca

Tested the Cross-Chain DCA page end-to-end after deploy. The contracts and scheduling path appear to work on-chain, but a few frontend gaps make the page hard to demo and verify.

1. No navigation to /dca
The page works when visited directly (/dca), but the Header has no link to it — only Home, Debug Contracts, and Block Explorer. After yarn next:start, users won't discover the main template feature without knowing the URL.

2. Active Plans stays empty
Plans can be created successfully (confirmed on HashScan), but the Active Plans table does not display them. The UI should reflect on-chain state after creation, including plans created via CLI/scripts — not only plans created in the same browser session.

3. Execution Log does not surface executions
Despite successful scheduled executions visible on HashScan, the log remains stuck on "Listening for new executions…" and never shows ExecutionTriggered or SwapExecuted events. This likely needs fixes around event subscription, chain targeting, and/or fetching historical events on page load — not only listening for live events after the page opens.

4. HashScan link in success toast points to mainnet
After creating a plan, the explorer link in the success toast opens HashScan mainnet instead of testnet. For this template it should use https://hashscan.io/testnet/....

[web3buidlerz]

Overall the code looks good to me, just some small tweaks to improve UX/DX

[web3buidlerz]

Schedule failure is silent

payments-scheduler reverts on scheduleCall failure; here you only emit ScheduleAttempted. A plan can be created with no future executions if scheduling fails (capacity, expiry, etc.).

Options:

• Revert on initial schedule failure in createPlan
• Pause plan + expose reschedule(planId)
• Pre-check hasScheduleCapacity before scheduling

[web3buidlerz]

Swap output custody

Swap proceeds (recipient: address(this)) accumulate in the executor. Only the contract owner (deployer) can withdrawToken — not the Hedera plan creator. Fine for a demo, but please call this out prominently in README/frontend so users don't expect user-owned DCA positions on Sepolia.

[web3buidlerz]

Overall — nice work 👍

We ran through the template on testnet and the important stuff works: Hedera orchestration, scheduling, and cross-chain execution all behave as described. That's a solid foundation — clearly a lot of thought went into the architecture and scripts.

The feedback above is really about two buckets:

1. Small UI fixes on the /dca page so the demo is easy to discover and verify
2. Template structure so npx create-scaffold-hbar@latest --template cross-chain-dca works the same way as our other templates

Neither changes the underlying design — just gets this ready for the scaffold-hbar ecosystem. Looking forward to the next iteration.

[mmyslblocky]

Thank you for your comments during the code review. They helped me better understand the code structure and conventions used in this repository. I have addressed all the points and followed all the recommendations you provided. I hope the updated code now meets the standards and requirements of your repository.

[jaycoolh]

Thank you for your comments during the code review. They helped me better understand the code structure and conventions used in this repository. I have addressed all the points and followed all the recommendations you provided. I hope the updated code now meets the standards and requirements of your repository.

Thanks @mmyslblocky I will bump this with @web3buidlerz

[web3buidlerz]

I am sorry I was on holiday and missed your changes. I am going over them and will do a test for this branch. Will be back with a confirmation asap. Thanks for your contribution!

[web3buidlerz]

Great stuff, managed to get through it all. Overall everything is great now, app is functional, structure and readmes are helpful and project structure consistent with already existing templates. I identified a couple of possible issues that we might want to check before we merge:

1. deployAll.ts script:

Step 9/10 failed with HTTP 503 from Sourcify:

"Service Unavailable - API v1 Brownout"
"API v1 is temporarily unavailable during a scheduled brownout period.
Please migrate to API v2."
Brownout window: 2026-06-23 → 2026-06-24
This appears to be a Sourcify infrastructure issue, not a misconfiguration on our side. Hardhat's verify:sourcify task still hits the v1 endpoint (check-all-by-addresses), which is currently in brownout.

Because deployAll.ts treats step 9 as a hard failure, step 10 (Sepolia/Etherscan verification) never ran, even though the functional deployment (steps 1–8) was already complete.

2. Connection to hashpack seems flaky sometimes. Using a clean instance of an incognito browser it works, but using my an existing browser instance sometimes it hangs when trying to connect. I think we should double check that.

Other then that everything is great!

[mmyslblocky]

Ok, thank you very much for the review :) . I will look into these two last issues tomorrow and resolve it and get back to you then

[mmyslblocky]

@web3buidlerz ok, I resolved the last two points you mentioned

1. I am using v2 endpoints now, but if it would fail, only warning is printed and step 10 commences
2. I think it was due to the fact I put the sepolia chain in the targetNetworks in scaffod.config, and the chain ID from sepolia was later used in wallet connect. I managed to move it out from config there and it should be fine now

[web3buidlerz]

@mmyslblocky great stuff, looks good, I think we can proceed and merge this one.

[mmyslblocky]

@web3buidlerz Thanks! Great to hear that :)