We’ve recently deployed the Lazy Summer Protocol to Sonic.
As part of Sonic’s onboarding we needed to connect it up to LayerZero’s backbone to enable cross-chain messaging.
A crucial whitelisting of Sonic’s Timelock contract with Base’s SummerToken contract was missed. Without this whitelisting we’re unable to bridge SUMR to Sonic to fulfil rewards.
The fix for this is here: Lazy Summer DAO (Official) | SIP5.3: Whitelist Sonic Timelock with Base SummerToken
Essentially, we cannot execute this proposal → Lazy Summer DAO (Official) | SIP3.2: Cross-chain Reward Setup Proposal for LazyVault_LowerRisk_USDCe Fleet on Sonic
Given, this is of highest priority, I’m going to publish the proposal on-chain shortly to limit any further delays. The standard on-chain voting delay and voting period are still in effect. But, I’m keen to minimise the hold up.
Thank you for your patience.
3 Likes
Thanks for the quick response to this issue.
Just from a security point of view: Will the regular checks of smart contracts still apply before execution?
1 Like
Absolutely.
In this case, there’s no new contract code so that simplifies things.
It’s a whitelist of only of one address:
Note: the account being whitelisted in the trace is 0x4c32A28AD95deaBc06bF7C83AdEbCF6fe6721ED9
Which is the SummerTimelockController on Sonic → SummerTimelockController | Address 0x4c32a28ad95deabc06bf7c83adebcf6fe6721ed9 | SonicScan Block Explorer
The reason we have to whitelist a Sonic address on Base is because in LayerZero’s send method we have transfer restrictions applied there as well.
The relevant contract code is below.
And in github: lazy-summer-protocol/packages/gov-contracts/src/contracts/SummerToken.sol at 0f3353093223704060cccd187fd0e0403f69d59f · OasisDEX/lazy-summer-protocol · GitHub
// Convert bytes32 to address using uint256 cast
address to = address(uint160(uint256(_sendParam.to)));
// Allow transfers if:
// 1. Transfers are enabled globally, or
// 2. The target address is whitelisted, or
// 3. The sender is sending to themselves
if (
!transfersEnabled && !whitelistedAddresses[to] && to != msg.sender
) {
revert TransferNotAllowed();
}
2 Likes
Amazing! Thank you for the detailed response.