WenLuckPays

At first glance, WenLuckPays looks like a simple lottery. Buy a ticket, win a prize. But underneath the minimal UI is a genuinely novel piece of financial infrastructure - one that required solving a set of problems that have no off-the-shelf answers.

The Core Innovation: Prize money that works while It waits. Every traditional lottery sits on idle capital. Ticket proceeds sit in a contract doing nothing until the draw. WenLuckPays changes that fundamental assumption: every dollar from every ticket is converted into USYC - Circle's yield-bearing stablecoin backed by US Treasury bills - the moment it arrives on Arc Testnet. The prize pool grows in real time, automatically, without any manual intervention. The winner receives not just the sum of the tickets, but the original capital plus all yield accumulated since each ticket was purchased.

This is what makes the model compelling for large-scale deployments. A corporate lottery running over 30 days with a $1 million ticket pool earning 4.5% APY generates ~$3,700 in additional prize money just from the wait. At $10 million, that's $37,000 extra for the winner — from money that would otherwise have done nothing.

The vision is for WenLuckPays to power:

1. Corporate lotteries - employee incentive programs, customer reward campaigns, or promotional jackpots where companies want the prize pool to visibly grow during the campaign window
2. Consumer app integrations — embedded lotteries inside fintech apps, gaming platforms, or social products, where USYC yield makes the prize pool self-augmenting without any additional budget
3. Standalone high-stakes lotteries — large participant pools where yield accumulation is substantial enough to meaningfully increase the payout, making the lottery more attractive without increasing ticket prices

Arc Testnet serves as the universal treasury layer: a single chain where USDC from any source chain arrives, converts to USYC, earns yield, and can be redeemed to pay out winners on any destination EVM chain and Solana. The backend wallet acts as the entitled yield agent — pre-whitelisted by Circle for USYC minting - and the ArcTreasury contract on Arc testnet provides the on-chain accounting.

What looks simple to the user - buy a ticket, claim a prize - required solving a multi-layered cross-chain coordination problem:

1. USDC → USYC Conversion Requires On-Chain Entitlement Circle's USYC Teller is not open to arbitrary callers. Only pre-whitelisted (entitled) addresses can mint USYC. The ArcTreasury contract cannot be whitelisted on testnet, so the system uses a carefully choreographed round-trip: ticket USDC arrives at the treasury, the treasury releases it to the entitled backend wallet, the backend wallet mints USYC via the Teller, and those shares are held by the backend wallet on behalf of the lottery pool. This required understanding Circle's ERC-4626 Teller interface, the difference between deposit() and withdraw(), and the exact entitlement model — none of which is in a simple tutorial.

2. USYC → USDC Redemption on Prize Claim When a winner claims, the backend redeems ALL USYC shares via Teller.redeem() on Arc, recovering the original USDC plus all accrued yield. That USDC is then deposited into Arc's Circle Gateway Wallet and bridged via a signed BurnIntent to the winner's chosen destination chain. This Arc → destination bridge required constructing an EIP-712 BurnIntent from Arc (domain 26) — a flow Circle supports but does not document with working examples.

3. Six-Chain Prize Delivery Including Solana Circle's Gateway forwarder service supports EVM chains but not Solana. For Solana winners, the backend manually builds and submits a gatewayMint instruction to the GatewayMinter program on Solana Devnet — including deriving the correct Program Derived Addresses (PDAs), building Borsh-encoded instruction data with the Circle attestation, and computing the Transfer Spec Hash (TSH) from the raw attestation bytes at a precise byte offset. This required reverse-engineering the program's on-chain instruction format with no public specification.

4. Arc Testnet can be unpredictable Arc Testnet transactions can take 30–120 seconds to confirm. Every step — withdraw, approve, mint, redeem, deposit — requires waiting for on-chain confirmation before the next step can proceed (since nonces are sequential). With up to five chained transactions on Arc per operation, the backend must hold an HTTP connection open for up to 5 minutes while orchestrating the cross-chain flow. Standard serverless timeouts (60s) and default viem receipt timeouts (60s) both had to be extended.

5. Nonce Management Across Async Flows mon-critical bookkeeping transactions (like recording a deposit in ArcTreasury that is a smart contract on Arc) cannot run concurrently with critical USYC minting transactions — they share the same backend wallet nonce space. Sending a fire-and-forget bookkeeping transaction before the USYC minting sequence causes both to attempt the same nonce, resulting in silent rejection. The solution: always complete the critical USYC path first, then submit bookkeeping as a non-blocking tail transaction.

6. Randomness for winner selection within the sold ticket range: Pyth Entropy (Base Sepolia)

The result is a system that, from the user's perspective, is a clean and minimal lottery app — but is in fact a live demonstration of real yield generation, multi-chain USDC bridging, on-chain USYC minting and burning, and Solana program interaction, all wired together in a single coherent flow.