fix(dapp): replace the mocked VaultFactory with real contract deployment

[0xDeon]

Context

apps/dapp/frontend/lib/stellar/vault-factory.ts generates fake vault IDs, contract addresses and transaction hashes with Math.random(), and CreateVaultWizard.tsx:97 calls it. Vault creation in the product is entirely fictional — it returns a plausible-looking contract address that does not exist.

Acceptance criteria

• Vault creation builds, signs and submits a real transaction against the deployed factory.
• The returned contract address is read from the transaction result, never generated.
• Failure surfaces a real error; no fake success path remains.
• lib/stellar/vault-factory.ts mock implementation is deleted, not left behind a flag.
• E2E test creates a vault on testnet and reads it back.

Notes

Hard blocker: a user cannot actually create a vault today.

---

Testnet launch backlog — E3 DApp real transactions.

[Aonlike]

@Aonlike has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would like to work on this issue. I am a FullStack Developer. I have experience in frontend technologies such as HTML, CSS, JavaScript, React, Next.js, Tailwind CSS, and backend technologies including Node.js, Express.js, Python, Django, PHP, and Laravel.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Aonlike to this issue.

[Lurdings]

@Lurdings has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I’m interested in contributing to this task and can deliver a clean solution within the timeline.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Lurdings to this issue.

[Clinton6801]

@Clinton6801 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello boss I'd love to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Clinton6801 to this issue.

[drips-wave]

Congratulations, @Clinton6801! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Clinton6801: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[0xDeon]

Partial progress landed in #1165 (network resolution is now shared with the signer, so a network switch no longer signs against the wrong passphrase). Deliberately leaving this open — the core of the issue is not done.

Two blockers found while integrating PR #1161:

1. The call signature is wrong. On-chain it is create_vault(env, caller: Address, salt: BytesN<32>, underlying_asset: Address, init_args: Vec<Val>) -> Address. The client calls it with (name, owner).
2. No factory is deployed. NEXT_PUBLIC_VAULT_FACTORY_CONTRACT_ID is set nowhere, and packages/contracts/scripts/deployed-testnet.env lists only the vault, vault token and treasury — there is no vault_factory entry.

So the deployment path targets an undeployed contract with arguments it would reject. The wizard also still drops allocations, lock period, vault type and auto-rebalance before the call while reporting "Vault created successfully!".

Deploying the factory to testnet is the prerequisite; the client call should be written against the real signature once an address exists.

[drips-wave]

This issue has been marked as completed by a Drips Wave moderator for @Clinton6801 as part of the Stellar Wave Program's 8th Wave 🥳

Moderator's reason: [Auto-assessed] Although PR #1161 was closed without being merged directly, maintainer @0xDeon explicitly stated in comment on PR #1161: 'Merged into dev via #1165, which integrated all four of these branches and repaired the blocking defects found in review... Thanks for the work — the direction was right on all four.'

😎 @Clinton6801: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.

ℹ️ Note: This issue was marked complete via moderation. Points were issued even though the GitHub issue remains open.

[0xDeon]

Fixed on dev. Checking each acceptance criterion against the current code:

• lib/stellar/vault-factory.ts contains no Math.random(). It builds a transaction with TransactionBuilder, simulates it, assembles it, has the wallet sign it, and submits via server.sendTransaction.
• The contract address is decoded from the transaction's return value with Address.fromScVal(returnValue), and the code throws when there is no return value rather than inventing one.
• Failures surface as real errors at every stage — simulation error, submit ERROR status, on-chain FAILED, and confirmation timeout all throw with the transaction hash.
• No mock implementation is left behind a flag.
• apps/dapp/frontend/e2e/vault-creation.spec.ts covers the flow, and .github/workflows/e2e-testnet-nightly.yml runs it against testnet.

Closing as complete.