Explore ERC-20 approve/transferFrom pattern with Splice Token Standard

[salindne]

Context

Our EVM RPC facade (pkg/ethrpc/eth_api.go) currently only supports transfer -- there is no allowance/delegation mechanism. The ERC-20 standard defines approve(spender, amount) and transferFrom(owner, spender, amount), which is the foundation for DApp composability (DEX approvals, token spending caps, third-party payments).

With the CIP-56 contract rewrite to natively implement the Splice Token Standard (canton-erc20#27), we should design the approve/transferFrom pattern properly against the Splice interfaces rather than bolting it onto the old custom model.

Goal

Design and implement approve/transferFrom using the Splice Token Standard primitives, ensuring compatibility with Canton ecosystem wallets and the broader Canton Coin Standard.

Design Exploration

Splice Standard Primitives Available

• TransferPreApproval -- pre-authorizes a transfer that a third party can execute. Conceptually similar to ERC-20 approve. The owner creates a pre-approval, and the approved party can later trigger the transfer without further owner interaction.
• TransferFactory -- the standard transfer entry point. approve/transferFrom would need to integrate with this flow.
• AllocationV1 interfaces -- for atomic settlement / DvP workflows. Could be relevant for more complex approval patterns.

Key Design Questions

• How does TransferPreApproval map to approve(spender, amount)? Is it 1:1 or are there structural differences (e.g., per-transfer vs cumulative allowance)?
• How do allowances work with the UTXO model? An ERC-20 allowance is against a balance, but Canton holdings are individual contracts. Does the spender need to specify which holding contracts to spend from?
• Should transferFrom go through the TransferFactory or exercise a choice directly on the TransferPreApproval?
• How do wallets (Loop Wallet, MetaMask) surface and manage allowances?
• What does the middleware API look like? (eth_call for allowance(), eth_sendTransaction for approve() / transferFrom())

Implementation Scope

DAML (canton-erc20):

• Design allowance/pre-approval contract using TransferPreApproval from Splice standard
• Integrate with the redesigned CIP56TransferFactory
• Handle UTXO selection for transferFrom (which holdings to spend)

Middleware (canton-middleware):

• Add approve support to EVM RPC facade (eth_sendTransaction with approve ABI)
• Add transferFrom support to EVM RPC facade
• Add allowance query to EVM RPC facade (eth_call)
• Track allowances in API database for fast lookups
• Reconcile on-chain TransferPreApproval contracts with DB state

Timeline Decision Needed

This needs to be scoped to either CIP-0086 Phase 1 (before April 18) or Phase 2:

• Phase 1 (April 18 deadline): Would require prioritizing this alongside Issues Migrate to External Parties (AllocateExternalParty) #109, Adapt middleware for Splice Token Standard (CIP-56 contract rewrite) #110, and Non-custodial signing: Prepare/Execute API MetaMask Snap #111. Tight but possible if the Splice TransferPreApproval maps cleanly to our needs.
• Phase 2: Lower pressure, allows the contract rewrite (Adapt middleware for Splice Token Standard (CIP-56 contract rewrite) #110, canton-erc20#27) to land first, then build approve/transferFrom on top of the stable Splice-native foundation.

Decision: TBD -- needs team discussion on Phase 1 deliverable scope.

Related Issues

• Depends on: canton-erc20#27 (Splice Token Standard rewrite)
• Depends on: Adapt middleware for Splice Token Standard (CIP-56 contract rewrite) #110 (Middleware Splice adaptation)
• Related: Migrate to External Parties (AllocateExternalParty) #109 (External parties -- approve/transferFrom needs InteractiveSubmission for non-custodial approvals)
• Related: Non-custodial signing: Prepare/Execute API MetaMask Snap #111 (Non-custodial signing -- spender needs to sign transferFrom)

[salindne]

We decided against this for this project