Skip to content
Capxul V2

Chapter 13: Open Questions

This is the canonical list of unresolved items across the entire V2 architecture. Items resolved in later design sessions are marked accordingly.

On-Chain Infrastructure

Section titled “On-Chain Infrastructure”

1. Zodiac Roles gas cost. What is the gas cost of role configuration changes (adding a role, updating a spending limit) on Base? Affects whether frequent limit adjustments are practical.

  • Status: Open

2. LlamaPay event compatibility. Confirm that LlamaPay’s native event signatures and parameters provide everything the indexer needs (stream ID, sender, recipient, amount, token). If not, determine what supplementary indexing is required.

  • Status: Open

3. CapxulRouter approval pattern. The router needs an ERC-20 approval from the smart account before it can execute transferFrom. Confirm this works cleanly with Openfort’s execute flow and that the approval can be batched with the initial session key grant in a single UserOp.

  • Status: Open

4. Batch execution limits. Openfort V1 limits executeBatch to 9 calls. For an employee with complex routing (3+ destinations), confirm that a claim + multi-destination route fits within this limit, or determine if multiple UserOps are needed.

  • Status: Open

Smart Account Infrastructure

Section titled “Smart Account Infrastructure”

5. Server-side pre-generation API. Exact Openfort endpoints and parameters for creating a player + computing an account address from an email without user interaction. Confirm bulk creation (20+ accounts).

  • Status: Open (POC Scenario 2)

6. Guardian configuration timing. Can Capxul be set as a guardian during server-side account creation, or does the user need to sign in first?

  • Status: Open (POC Scenario 7)

7. Email change for pre-generated wallets. Confirm the correct pattern: create new player/wallet, orphan old, update stream target.

  • Status: Open (POC Scenario 6)

8. ERC-7579 roadmap. Is 7579 compliance planned for Openfort accounts? Timeline?

  • Status: Open. Not a blocker. Openfort V1’s built-in features cover all current needs. Accounts are upgradeable via proxy if 7579 support is added later.

9. Self-hosted Shield + Better Auth. Has self-hosted Shield been validated with the Better Auth plugin specifically?

  • Status: Open

Fiat Ramps

Section titled “Fiat Ramps”

10. Session key scope for provider deposit addresses. In Path A, the session key can send USDC to any address. HoneyCoin generates a new provider deposit address per transaction. The backend must validate each address before signing. Confirm the backend can reliably determine that an address is a legitimate HoneyCoin address (via the API response) and is not spoofed.

  • Status: Partially resolved. Doc 6 defines Path A (offchain enforcement) and Path B (CapxulRouter) as the enforcement models. The reliability of provider address validation is an implementation concern, not an architecture question.

11. HoneyCoin virtual account details. Are virtual accounts persistent? Per-currency or multi-currency? Can sub-accounts be created for attribution?

  • Status: Open (pending HoneyCoin call)

12. Refund flow details. When a crypto send to a provider deposit address fails or the provider refunds, how exactly does the refund arrive? Same address? Different token? Timeline?

  • Status: Open

13. Session key validator contract. The provider deposit address whitelist mechanism needs detailed design.

  • Status: Resolved. Doc 6 defines the CapxulRouter (Path B) as the on-chain enforcement mechanism for destination whitelisting. Path A uses offchain enforcement in Convex. No separate “validator contract” is needed.

14. Auto-routing tax implications. Automatic crypto-to-fiat conversion on every pay cycle may have different tax treatment than manual withdrawals in some jurisdictions.

  • Status: Open (compliance/legal question, not technical)

15. Multi-provider quoting. When a second provider is added, should the facade automatically quote all providers and present the best? Or route by country?

  • Status: Open (deferred until second provider is added)

Identity Verification

Section titled “Identity Verification”

16. Shufti Pro eIDV coverage. Does the database lookup endpoint support NG, GH, KE, UG? Which databases per country?

  • Status: Open (pending Shufti Pro call)

17. Shufti Pro integration specifics. Latency per verification type? Pricing model? Webhook retry policy? White-labeling options? Data retention and deletion?

  • Status: Open (pending Shufti Pro call)

18. HoneyCoin KYC acceptance. Does HoneyCoin accept external KYC from Shufti Pro, or does it require its own verification?

  • Status: Open (pending HoneyCoin call). Architecture handles both outcomes: single verification (Capxul KYC sufficient) or dual verification (Capxul KYC + HoneyCoin-specific step).

19. Jurisdictional thresholds. Exact limits for tiered KYC in the context of crypto-to-fiat payroll disbursements (not general mobile money). Whether Capxul bears direct KYC obligations under each country’s AML framework.

  • Status: Open (pending legal counsel)

20. Uganda data quality. Shufti Pro’s database match rates may be lower in Uganda due to less mature digital ID infrastructure. What is the fallback?

  • Status: Open (pending Shufti Pro call)

Cross-Chain Bridging

Section titled “Cross-Chain Bridging”

21. Bridge session key compatibility. Confirm that bridge provider contracts (deBridge, Hyperbridge) can be called via the smart account’s execute() function through a session key. Some bridge contracts may require msg.sender to be an EOA.

  • Status: Open

22. Inbound bridging architecture. How does a Safe on Base control or delegate authority over a receiving point on Tron or Solana? Three options evaluated (custom non-EVM contract, Capxul-managed wallet, ephemeral deposit addresses), decision deferred.

  • Status: Open. Requires: research into cross-chain messaging (Option A), compliance evaluation of custodial wallets (Option B), provider deposit address capabilities (Option C).

23. Multi-asset treasury metrics. When a Safe holds USDT from inbound bridging alongside USDC, how do treasury balance, burn rate, and runway calculations work?

  • Status: Open (Financial Document Layer dependency)

24. Travel Rule compliance. For cross-chain transfers above certain thresholds, Travel Rule obligations may require transmitting sender and receiver information. Does deBridge or Hyperbridge support Travel Rule data?

  • Status: Open (legal/compliance question)

25. Safe module for bridge transactions. Org-initiated bridge payments need to go through the Safe’s approval flow.

  • Status: Resolved. The Payment Module handles bridge sends via the paymentType enum and the “bridge_backend” Zodiac role.

26. Hyperbridge Solana/Tron timeline. Monitor for 2026 chain expansion announcements.

  • Status: Open (monitoring)

Event Indexing

Section titled “Event Indexing”

27. Gas token tracking. Native ETH balance tracking for gas budgeting requires trace-level or block-level scanning, not ERC20 events. Define when needed and implementation approach.

  • Status: Open

28. Claim contract architecture. The exact contract handling employee claims is not finalized. The indexer accommodates any contract emitting a claim event.

  • Status: Open (depends on on-chain contract design)

29. Event schema versioning. If module contracts are upgraded and event signatures change, the indexer needs to handle both old and new formats during the transition.

  • Status: Open (plan before first contract upgrade)

General

Section titled “General”

30. Convex pricing at scale. At 2,000 MAU with frequent balance queries, what are the Convex costs?

  • Status: Open

31. Paymaster funding. Who funds the paymaster that sponsors gas? Capxul’s treasury? Per-org budgets?

  • Status: Open (business model question)

32. Regulatory classification. In Nigeria and Ghana, are there specific requirements around custodial/non-custodial wallet classification that affect the recovery guardian model?

  • Status: Open (legal question)