Adding Walley to the wallet directory

[kevmuko]

Type of submission

• New wallet application

Summary

Adds Walley (https://walley.cc), a self-custodial browser wallet for CIP-0056 tokens on Canton MainNet, operated by K2F Labs. Signing keys are derived in the browser from a WebAuthn passkey PRF secret and never leave the device.

Ten features are claimed with evidence: CC support, CC pre-approvals, CIP-0056 transfers and allocations, CIP-0103 dApp API, memo tags, DA Registry pre-approvals, UTXO merge delegation, clear signing, and integrated swaps. Key recovery is claimed as a self_attested_only feature. Twelve more are explicitly marked not supported with a reason rather than left blank, so readers can see the gaps.

Checklist

• wallets/walley.yaml added (self-attestation)
• A heading added to proofs/walley/walley-self-attestation.md for every feature claimed as supported: true
• python scripts/generate_table.py was run and the regenerated WALLET_DIRECTORY.md is included in this PR
• Confirmed membership in #ext-temp-party-scaling and set slack_party_scaling_channel_joined: true
• Reasons filled in under each feature marked not supported

Additional context

Evidence basis. The self-attestation cites publicly reachable sources: the product documentation at https://docs.walley.cc, the unauthenticated REST API at api.walley.cc and its Swagger UI at https://api.walley.cc/swagger-ui/, and the published dApp SDK on npm. Anyone can re-run these checks:

• https://api.walley.cc/v1/tokens returns 79 live instruments, 78 of them non-CC CIP-0056 tokens
• https://api.walley.cc/v1/tradecraft/pools, /v1/oneswap/pools, and /v1/silvana/config return the three live swap venues
• https://www.npmjs.com/package/@k2flabs/walley-dapp-sdk is the CIP-0103 provider adapter

Joel Lovera at Digital Asset is familiar with Walley's feature support and can attest to the claims in this submission.

Transaction update IDs are not published in this submission. Happy to supply them for any feature a reviewer or third-party verifier wants pinned to specific on-ledger evidence.

A gap in the feature registry. Walley has a production Ethereum to Canton bridge for USDCx, running against the live xReserve contract on Ethereum mainnet with Circle's attestation API, with deposit, withdraw, per-user caps, and an activity timeline in the wallet. _feature_registry.yaml has no feature id for bridging, so there is nowhere to claim it. The nearest boolean is tokenization, which we have deliberately left unset because Walley drives the mint and redeem flow but is not the issuer, and claiming it would misrepresent the relationship.

Flagging it in case the Foundation wants to add a bridging id, since Walley is unlikely to be the only wallet in this position. Happy to open a separate PR proposing one if that would be useful.

[davidrichards-da]

I still need to resolve the conflicts

[davidrichards-da]

All resolved