memoscan

0x3070…ec29

All memos sent from and to 0x3070…ec29.
0x3070f20f…ec29sent to0xd101f2b2…5447·#25,221,524·0x17d56bcb…9b95ed
# Claim tBTC from Bridge Fees (Routine Execution) ## tl;dr Claim ~1.61776434 tBTC (161,776,434 sats) from accumulated tBTC Bridge fees and transfer it to the Threshold Committee treasury multisig. ## Background Threshold DAO accrues protocol fees from tBTC Bridge activity as a Bank balance credited to the Governor timelock. Depending on active DAO-approved fee parameters, Bridge fees can relate to mint/deposit and redemption flows. Periodic claims convert the timelock's Bank balance into tBTC via TBTCVault and transfer it to the Threshold Committee treasury multisig for DAO-directed treasury operations. This proposal follows the same operational pattern as the latest executed routine fee claim, Claim tBTC from Bridge Redemption Fees (Routine Execution), which executed at block `24580626` and claimed `190,688,808` sats (~1.90688808 tBTC). This execution uses the current accrued fee amount. ## Proposal Execute the standard 3-step fee claim: 1. Increase the timelock's Bank balance allowance for TBTCVault 2. Mint the corresponding tBTC from TBTCVault 3. Transfer the minted tBTC to the Threshold Committee treasury multisig ## Parameters * Amount: `161,776,434` sats (~1.61776434 tBTC) * Recipient: `0x71E47a4429d35827E0312Aa13162197C23287546` * Balance source: `Bank.balanceOf(Governor timelock)` checked at Ethereum block `25210546` ## Notes * No new permissions or contracts. * Same execution pattern as TIP-107; this is a maintenance sweep of accumulated tBTC Bridge fees. * Given fee claim is a recurring process the Committee plans to execute every few months (more often as substantial fees accrue faster), we will queue the proposal same day as this Forum post, and voting will begin after ~13,000 blocks (approximately 2 days)
0x3070f20f…ec29sent to0xd101f2b2…5447·#24,491,599·0x5999ad1f…80899d
# Claim tBTC from Bridge Redemption Fees (Routine Execution) ## tl;dr Claim ~1.9 tBTC (190,688,808 sats) from Bridge Fees and transfer it to the Threshold Committee treasury multisig. ## Background Threshold DAO accrues tBTC redemption fees as a Bank balance credited to the Governor Bravo timelock. This proposal is a routine follow-on execution consistent with TIP-107 (same flow, new amount), intended to periodically sweep accrued fees into the Threshold Committee treasury multisig for DAO-directed use. ## Proposal Execute the standard 3-step claim flow: 1. Increase Bank balance allowance for TBTCVault 2. Mint tBTC from the TBTCVault for the accrued fee amount 3. Transfer the minted tBTC to the Threshold Committee treasury multisig ## Parameters * Amount: `190,688,808` sats (~1.90688808 tBTC) * Recipient: `0x71E47a4429d35827E0312Aa13162197C23287546` ## Notes * No new permissions or contracts. * Same execution pattern as TIP-107; this is a maintenance sweep of accrued protocol fees.
0x3070f20f…ec29sent to0xd101f2b2…5447·#24,048,982·0x75eca10f…8302ef
# TIP-108: Reduce Governor Bravo Voting Period from 9 Days to 7 Days ## tl;dr Reduce the Threshold Governor Bravo **Voting Period** from **9 days** to **7 days** by updating the `votingPeriod` from **66,461 blocks → 50,000 blocks**. ## Background Threshold DAO governance uses Governor Bravo, which defines voting delay, voting period, quorum, and execution rules. The current voting period is **9 days**, as confirmed on-chain via `votingPeriod() = 66461` blocks. A 9-day voting duration slows governance execution and extends proposal cycles unnecessarily. Moving to a **7-day period** improves DAO responsiveness while maintaining a widely recognized minimum timeframe for decentralized participation. ## Proposal This proposal updates the Governor Bravo voting period as follows: * **Old value:** 66,461 blocks (~9 days) * **New value:** **50,000 blocks** (~7 days) This change: * Reduces the total governance cycle by two days * Maintains broad accessibility for voters * Aligns Threshold more closely with standard DAO governance timing * Requires no new contracts or permissions ## Transaction The Governor Bravo contract will execute a single administrative call: 1. **Update Voting Period** * Contract: Governor Bravo (`0xd101f2b25bcbf992bdf55db67c104fe7646f5447`) * Method: `setVotingPeriod(uint256 newVotingPeriod)` * New value: `50000` ## Notes * This proposal modifies **only** the voting period; all other governance parameters remain unchanged. * The 7-day duration preserves decentralization while enabling more agile DAO decision-making.
0x3070f20f…ec29sent to0xd101f2b2…5447·#23,991,919·0x94979ffc…8d446a
# TIP-072v3: Reduce Redemption Default Delay to 15 Minutes and Introduce Waived Amount parameter ## tl;dr Reduce the **default redemption delay** from **2 hours → 15 minutes** by updating `_defaultDelay` from **7200 → 900 seconds**, and set a **5 BTC waived amount limit** so redemptions can finalize faster and offer a better user experience. ## Background The redemption delay exists to provide a buffer for monitoring and validation before a BTC redemption is finalized. As operational processes have matured, a shorter delay improves efficiency and user experience without reducing safety. A small waived amount threshold allows low-value redemptions to clear immediately while keeping the veto mechanism focused on larger, higher-impact flows. ## Proposal Update the Redemptions Guardian parameters as follows: * Update `_defaultDelay` to **900 seconds (15 minutes)**. * Update `_waivedAmountLimit` to **5 BTC (500,000,000 sats)**. All other Redemptions Guardian parameters remain unchanged from their current values: * `watchtowerLifetime = 93,312,000` * `vetoPenaltyFeeDivisor = 20` * `vetoFreezePeriod = 2,592,000` * `levelOneDelay = 28,800` * `levelTwoDelay = 86,400` ## Notes * No contract upgrades are required. * Only `_defaultDelay` and `_waivedAmountLimit` are modified; all other parameters are unchanged. * The 5 BTC waived threshold is intended to keep small, routine redemptions frictionless while preserving controls for larger transactions.
0x3070f20f…ec29sent to0xcb162218…f85c·#22,552,938·0xbe1d72ee…6dcb8e
I agree with the need for delegate compensation however the cost of implementing this might be a little high. Can the price of SC implementation be justified ? I find it hard to ... despite this It will somewhat be hopefully money well spent !
0x3070f20f…ec29sent to0xcd33bcd2…04b4·#13,686,193·0xabd5fb20…c1c9a6
forevermore"What has been and what to be Are but of a page each part Which the world to read is free. Yet who knows them off by heart? All that was and is to come Prospers in the present too, But its narrow modicum You imagine and construe." M.Eminescu