Hey, was reading through the-beaconator and had a question about fund_bonus_wallet. The doc comment explains it intentionally skips the mainnet chain guard that fund_guest_wallet has, since "disbursing real mainnet USDC is the entire point," and says the real-money safety instead lives in the usdc_bonus_limit cap, the bearer-token auth, and "the caller's own kill-switch + atomic single-use claim." Looking at the route itself though, I don't see any idempotency or already-claimed check on the beaconator side, it validates the amount against the cap, acquires a pool wallet, and sends the USDC, keyed only on wallet_address from the request body with no record of whether that address already got its bonus.
So the single-use guarantee is entirely the calling service's responsibility. Given this route runs on Arbitrum One with real USDC and no per-address tracking of its own, is that single point of trust intentional (keep beaconator stateless, let the caller own claim state), or worth a defense-in-depth check here too, in case the caller ever retries a webhook or double-fires the same signup event? Mostly curious whether there's already a redundant check I'm missing.
The wallet locking setup is genuinely nice work otherwise, the Redis distributed lock plus heartbeat that flips a lock_lost flag before a second tx can fire on a stolen lock is exactly the kind of defense-in-depth I'd want for anything touching nonces under concurrency.
I think about similar "who actually owns the one-time guarantee" trust-boundary questions building settlement logic for a cross-chain vault on Chainlink CCIP (https://github.com/aegonmyy/meridian). Happy to compare notes if useful.
Hey, was reading through the-beaconator and had a question about
fund_bonus_wallet. The doc comment explains it intentionally skips the mainnet chain guard thatfund_guest_wallethas, since "disbursing real mainnet USDC is the entire point," and says the real-money safety instead lives in theusdc_bonus_limitcap, the bearer-token auth, and "the caller's own kill-switch + atomic single-use claim." Looking at the route itself though, I don't see any idempotency or already-claimed check on the beaconator side, it validates the amount against the cap, acquires a pool wallet, and sends the USDC, keyed only onwallet_addressfrom the request body with no record of whether that address already got its bonus.So the single-use guarantee is entirely the calling service's responsibility. Given this route runs on Arbitrum One with real USDC and no per-address tracking of its own, is that single point of trust intentional (keep beaconator stateless, let the caller own claim state), or worth a defense-in-depth check here too, in case the caller ever retries a webhook or double-fires the same signup event? Mostly curious whether there's already a redundant check I'm missing.
The wallet locking setup is genuinely nice work otherwise, the Redis distributed lock plus heartbeat that flips a lock_lost flag before a second tx can fire on a stolen lock is exactly the kind of defense-in-depth I'd want for anything touching nonces under concurrency.
I think about similar "who actually owns the one-time guarantee" trust-boundary questions building settlement logic for a cross-chain vault on Chainlink CCIP (https://github.com/aegonmyy/meridian). Happy to compare notes if useful.