SCBridgeAccount

This project is a proof-of-concept 4337 compatible account / smart contract wallet that emulates and extends the functionality of a Lightning Network payment channel.

Owners of a SCBridgeWallet (state-channel-bridge-wallet) enlist the help of an intermediary so that payments between the owner and compatible addresses can be made via routed HTLCs - a peer to peer off chain protocol. The owner can also use their SCBridgeWallet to drive normal operations on the EVM chain (or L2) where it is deployed - eg, to craft and execute arbitrary 4337 UserOperations.

For off-chain routed payments, compatible addresses need not reside on the same chain. For example, an SCBridgeWallet deployed on Ethereum can send or receive off-chain payment to compatible wallets deployed on Scroll, Mantle, Polygon, Filecoin, Optimism, etc etc. In principle, it can even send and receive payments to and from the Lightning Network or to compatible wallets in other blockchain ecosystems, but integrating this is a stretch goal for the hackathon.

NOTE:

The off-chain capabilities of this PoC have been artificially scoped to HTLC based payments so that it can be built within the time span of the hackathon while respecting the "from scratch" rules. With this limitation, a name like PCBridgeWallet (payment-channel-bridge-wallet) might have been more appropriate.

A production grade SCBridgeWallet would be capable of more: opening and closing payment and application channels between owners of compatible wallets, including across the boundaries of different EVM compatible environments, and likely extending to other Turing complete blockchain runtime environments. (Sorry Lightning Network users - you're not invited to this part of the protocol.)

The project has three main components:

• a 4337 compatible wallet StateChannelWallet in Solidity
• a set of StateChannelWallet clients, written in typescipt, with ethers.js as the headlining web3 dependency
• a UI written in react, again depending on ethers for chain watching functionality

The project has seen a continually shifting set of targeted backends for our wallet contract & 4337 infrastructure contracts (EntryPoint + dependencies). As the wallet client has achieved more milestones, the tarted backends have moved along a path approximately like

• manually injected fake chain data
• a single local hard hat instance
• multiple local hard hat instances (to prove out cross-chain payments)
• a growing list of EVM testnet environments, including several partner L2s

We currently have wallets deployed on (as far as I can count - there may be more)

Goerli - https://goerli.etherscan.io/address/0x82c203cBb79054eD4E9186A32fE5E3A86ddBBF7c Sepolia - https://sepolia.etherscan.io/address/0x0928bE32ab7d8Ad079514C6777a61787ddDF7c51 Mantle Testnet - 0xDA1BbeDF1bB2966BFD2821A9f87Dd1D86bdf8656 Filecoin Calibration Testnet - https://explorer.glif.io/address/0x91FB524Ae92C1c038CE61462299F7142E2fD0e8c/?network=calibration zkEVM Testnet - https://testnet-zkevm.polygonscan.com/address/0xAC5f6d0130Ad82e0677b5ACF788926F5DDA76ca5 Scroll Testnet - https://sepolia.scrollscan.com/address/0x705DBe0E96E172e95d56eB689dE3Fc43E29b8236

A particularly hacky shortcut we took (to limit scope and focus on development of core ideas) was to rely on in-browser BroadcastChannels as a messaging layer between wallet clients. This way we can open multiple demonstration wallets on a single machine and have them exchange messages over a very low-friction "local network" that requires none of the usual overhead for network messaging (serialization, cors, etc).