0xe1b3…0f6e

All memos sent from and to 0xe1b3…0f6e.

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2025-02-25·#21,922,074·0xa7032259…b8cb62

sendMessage(address,bytes,uint32)sendMessage(address,bytes,uint32) UIP-018: Raise the Stake Limit on Base and Optimism # Abstract - Chains: 0P and BASE - maxStake $1M - max borrow $101k - global debt limit 1M - half-decay point: $50k

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2024-12-06·#21,341,273·0x9f650c2f…d9ea70

UIP-017: Drip UNION to Base ## Abstract In order to support Union on Base, UNION token will need to be distributed to participants. The L1 treasury will drip UNION token to the Base comptroller. An intermediary contract (BaseConnector) is added to connect L1 treasury to the Union Base comptroller. ## Motivation Protocol participants will need to be able to claim UNION on the Base Network. Therefore, the Union protocol comptroller on the Base network needs to have UNION continuously dripped over. ## Specification - Set half decay point of the Base Comptroller to 100,000. - Add BaseConnector contract to be a new dripping target of the Treasury, and set the dripping rate to be 1 UNION per block in a total amount of 2,628,000 UNION tokens, which will last for one year at the current Ethereum block minting rate (12 seconds per block) ## Rationale Adding a treasury on L2 was considered, but there was no identifiable upside for going this route. Adding a comptroller provided the same benefits with lower effort. ## Backwards Compatibility No issues with backwards compatibility for this proposal ## Test Cases Tests and simulations can be found here: [Link to PR](https://github.com/unioncredit/union-v1-proposals/pull/26) ## Implementation On Mainnet - Call [Treasury](https://etherscan.io/address/0x6DBDe0E7e563E34A53B1130D6B779ec8eD34B4B9).addSchedule('uint256',uint256,address,uint256) with the following parameters: - drip start block: the block when the proposal is created - drip rate: 1 UNION per block - target address: [BaseConnector](https://etherscan.io/address/0x307ED81138cA91637E432DbaBaC6E3A42699032a) - total amount: 2,628,000 On Base: - Call [OpOwner](https://basescan.org/address/0x20473Af81162B3E79F0333A2d8D64C88a71B88e8).execute() to call [Comptroller](https://basescan.org/address/0x37C092D275E48e3c9001059D9B7d55802CbDbE04).setHalfDecayPoint("100000") to set the half decay point to 100,000.

0x1007a390…03dfsent to0xe1b3f07a…0f6e2024-12-02·#21,316,453·0xe6b946b7…37f0e2

I’ve long advocated for increasing emissions to protocol users, so I’m glad to see this proposal. Hopefully, it will drive the creation of more quality credit within the system, alongside broader distribution and enhanced liquidity of UNION across markets.

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2024-12-01·#21,305,174·0xc3b9528a…6f1f3a

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2024-07-04·#20,230,600·0x242c4002…d5fade

UIP-016: Update Half Decay Point and Max Stake Parameters # Abstract - Set half decay point of the Mainnet Comptroller to 10,000. - Set half decay point of the Arbitrum Comptroller to 1,000. - Set half decay point of the Optimism Comptroller to 100,000. - Raise the max stake on Optimism to 50,000 DAI. # Specification - Set the half decay point of the Ethereum Mainnet Comptroller to 10,000 - Set the half decay point of the Arbitrum Comptroller to 1,000 - Set the half decay point of the Optimism Comptroller to 100,000 - Raise the max stake on Optimism to 50,000 DAI. # Test Cases Tests and simulations can be found here: [PR](https://github.com/unioncredit/UIPs/pull/25) # Implementation For Mainnet: - Call [Comptroller](https://etherscan.io/address/0x216dE4089dCdD7B95BC34BdCe809669C788a9A5d).setHalfDecayPoint("10000") to set the half decay point to 10,000. For Arbitrum: - Call [Comptroller](https://arbiscan.io/address/0x641DD6258cb3E948121B10ee51594Dc2A8549fe1).setHalfDecayPoint("1000") to set the half decay point to 1,000. For Optimism: - Call [OpOwner](https://optimistic.etherscan.io/address/0x946A2C918F3D928B918C01D813644f27Bcd29D96).execute() to call [Comptroller](https://optimistic.etherscan.io/address/0x06a31efa04453C5F9C0A711Cdb96075308C9d6E3).setHalfDecayPoint("100000") to set the half decay point to 100,000. - Call [OpOwner](https://optimistic.etherscan.io/address/0x946A2C918F3D928B918C01D813644f27Bcd29D96).execute() to call [UserManager](https://optimistic.etherscan.io/address/0x8E195D65b9932185Fcc76dB5144534e0f3597628).setMaxStakeAmount("50000000000000000000000") to set max stake to 50,000 DAI.

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2024-06-26·#20,173,404·0x0799b895…0c74fc

Union Safety ModuleThis safety module protects Union users against significant hacks, bugs, or malfeasance.https://assets.coingecko.com/coins/images/30556/standard/Mark.png{"protectionCapAmountUsd":"","shortfallDistributionMethod":"Prorata"}

0x8d07d225…a265sent to0xe1b3f07a…0f6e2024-06-24·#20,164,456·0xaf9f8bb3…18f7d5

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2024-06-20·#20,131,355·0xd0e2efce…240c9c

UIP-015: Union Safety Module # Abstract Deploy the Cozy Safety Module for UNION. # Specification - Deploying the Union Safety Module requires 3 steps 1. Deploying the governance-controlled trigger contract 1. Deploying the Safety Module 1. Update the Safety Module metadata - Deploy the Union Rewards Manager requires 2 steps 1. Deploying the rewards dripping model 1. Deploying the rewards manager # Test Cases Tests and simulations can be found [here](https://github.com/unioncredit/UIPs/pull/24) # Implementation - Deploy the governance-controlled trigger contract by calling CozyRouter.deployOwnableTrigger(address,(string,string,string,string),bytes32) - Deploy the Safety Module by calling CozyRouter.deploySafetyModule(address,address,((uint256,address)[],(address,address,bool)[],(uint64,uint64,uint64)),bytes32) - Update the Safety Module metadata by calling CozyRouter.updateSafetyModuleMetadata(address,address,(string,string,string,string)) - Deploy the Drip Model for the Rewards Manager by calling CozyRouter.deployDripModelConstant(address,uint256,bytes32) - Deploy the Rewards Manager by calling CozyRouter.deployRewardsManager(address,address,(address,uint16)[],(address,address)[],bytes32)

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2024-06-11·#20,069,716·0x70c13157…a7ca5c

deploySafetyModule(address,address,((uint256,address)[],(address,address,bool)[],(uint64,uint64,uint64)),bytes32) UIP-015: Union Safety Module # Abstract # Specification - Deploying the Union Safety Module requires 3 transactions to the CozyRouter contract (0xC58F8634E085243CC661b1623B3bC3224D80B439) 1. Deploying the governance-controlled trigger contract 1. Deploying the Safety Module 1. Update the Safety Module metadata # Test Cases Tests and simulations can be found [here](https://github.com/unioncredit/UIPs/pull/24) # Implementation - Deploying the governance-controlled trigger contract by calling CozyRouter.deployOwnableTrigger(address,(string,string,string,string),bytes32) - Deploying the Safety Module by calling CozyRouter.deploySafetyModule(address,address,((uint256,address)[],(address,address,bool)[],(uint64,uint64,uint64)),bytes32) - Update the Safety Module metadata by calling CozyRouter.updateSafetyModuleMetadata(address,address,(string,string,string,string))

0x66cd62c6…65f9sent to0xe1b3f07a…0f6e2024-04-27·#19,745,099·0x2763dfe0…28ec83

It might be premature for a recognized delegate program. My vote has no weight, but I am abstaining anyway because I feel my interest in becoming a recognized delegate could be considered a conflict of interest

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2024-04-26·#19,737,132·0x50910bb8…187f4e

UIP-014: Recognized Delegate Program # Abstract We propose implementing a recognized delegate program to distribute UNION tokens to active delegates and those who delegate. # Specification - Invoke the Treasury.grantToken() function to send 900,000 Union tokens to the [multisig wallet](https://etherscan.io/address/0xB869146C2d215B359E875aab583dA3F54440f278). # Test Cases Tests and simulations can be found here: [PR](https://github.com/unioncredit/UIPs/pull/23) # Implementation Call Treasury.grantToken() to send 900,000 Union tokens to the [multisig wallet](https://etherscan.io/address/0xB869146C2d215B359E875aab583dA3F54440f278).

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2024-02-21·#19,275,771·0x85e1ec37…657b12

setHalfDecayPoint(uint256) UIP-013: Update Half Decay Point and Max Stake Parameters # Abstract - Set half decay point of the Mainnet Comptroller to 25,000. - Set half decay point of the Arbitrum Comptroller to 25,000. - Raise the max stake on Optimism to 25,000 DAI. # Motivation Now that v2 is insured it doesn't make sense to continue to over incentivize TVL on v1. # Specification - Set the half decay point of the Arbitrum Comptroller to 25,000 - Set the half decay point of the Ethereum Mainnet Comptroller to 25,000 - Raise the max stake on Optimism to 25,000 DAI. # Test Cases Tests and simulations can be found here: [PR](https://github.com/unioncredit/UIPs/pull/22) # Implementation For Mainnet: - Call [Comptroller](https://etherscan.io/address/0x216dE4089dCdD7B95BC34BdCe809669C788a9A5d).setHalfDecayPoint("25000") to set the half decay point to 25,000. For Arbitrum - Call [Comptroller](https://arbiscan.io/address/0x641DD6258cb3E948121B10ee51594Dc2A8549fe1).setHalfDecayPoint("25000") to set the half decay point to 25,000. For Optimism - Call [OpOwner](https://optimistic.etherscan.io/address/0x946A2C918F3D928B918C01D813644f27Bcd29D96).execute() to call [UserManager](https://optimistic.etherscan.io/address/0x8E195D65b9932185Fcc76dB5144534e0f3597628).setMaxStakeAmount("25000000000000000000000") to set max stake to 25,000 DAI.

0x7a0c61ed…2be4sent to0xe1b3f07a…0f6e2024-01-22·#19,060,384·0x0b7eb2d4…687720

UIP-012 Update Arbitrum Dripping Schedule # Abstract Update Arbitrum dripping schedule to send another 1,296,000 UNION tokens to Arbitrum. # Motivation This proposal aims to resolve the issue identified in UIP-008, which was intended to update the Union dripping schedule for Arbitrum. The problem with UIP-008 was that it proposed dripping a total of 1,296,000 UNION to Arbitrum. However, while updating Arbitrum's existing dripping schedule, UIP-008 mistakenly set the total dripping amount to 1,296,000 without accounting for the amount previously dripped. This error caused the Arbitrum dripping to stop, as the previous dripped amount was already greater than the newly proposed amount. To rectify this, we propose changing the total dripping amount to the sum of the previously dripped amount (2,400,000) and the newly proposed amount (1,296,000), bringing the total to 3,696,000. # Specification - Invoke the Treasury.editSchedule() function to modify the dripping schedule for Arbitrum. Set dripStart to the block number at which UIP-008 was executed. The dripRate should be set to 1 UNION per block. Specify the target as the ArbConnector (address: 0x307ED81138cA91637E432DbaBaC6E3A42699032a). Set the total dripping amount to be 3,696,000 UNION. # Test Cases Tests and simulations can be found here: PR # Implementation Call Treasury.editSchedule() to update the dripping schedule for the Arbitrum.

0x1b1e924a…4011sent to0xe1b3f07a…0f6e2023-11-30·#18,685,110·0x221bc32e…a2be6c

ACTIVOS EN LA ACTIVIDAD

0x7a0c61ed…2be4sent to0xe1b3f07a…0f6e2023-06-14·#17,475,656·0x0f0a471b…bed98c

UIP-009: Change Optimism reward schedule # Abstract - Change Optimism drip schedule to 1 UNION for 12 months # Motivation We propose to continue a 1 UNION per block drip for the next 12 months to the users of Union on Optimism. # Specification - Call Treasury.editSchedule() to change the dripping schedule for Optimism. Set the dripStart to be the block number when executed, dripRate to be 1 ether, target to be OpConnector ([0xF5690129Bf7AD35358Eb2304f4F5B10E0a9B9d65](https://etherscan.io/address/0xF5690129Bf7AD35358Eb2304f4F5B10E0a9B9d65)), and amount to be 2628000 # Test Cases Tests and simulations can be found here: [PR](https://github.com/unioncredit/UIPs/pull/18) # Implementation For Mainnet: - Call [Treasury](https://etherscan.io/address/0x6DBDe0E7e563E34A53B1130D6B779ec8eD34B4B9).editSchedule() to update the dripping schedule for the Optimism.

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2023-06-13·#17,469,887·0x16895750…dce1c8

UIP-008: Change Arbitrum dripping schedule and update half decay point of the Comptroller # Abstract - Drip of 1 UNION for 6 months to the Comptroller on Arbitrum. - Set half decay point of the Arbitrum Comptroller to 250,000. # Motivation As there is not yet a v2 deployment on Arbitrum, we propose to continue a 1 UNION per block drip for the next 6 months to the users of Union on Arbitrum. At the end of the 6 months we can revisit the question, as it seems likely there will either be an Arbitrum v2 deployment or everyone will have migrated to Union v2 on Optimism. We also propose lowering the half-decay point to 250k. Now that v2 is insured it doesn't make sense to continue to over incentivize TVL on v1. # Specification - Call Treasury.editSchedule() to change the dripping schedule for Arbitrum. Set the dripStart to be the block number when executed, dripRate to be 1 ether, target to be ArbConnector (0x307ED81138cA91637E432DbaBaC6E3A42699032a), and amount to be 1,296,000 - Set the half decay point of the Arbitrum Comptroller to 250,000 # Test Cases Tests and simulations can be found here: [PR](https://github.com/unioncredit/UIPs/pull/17) # Implementation For Mainnet: - Call [Treasury](https://etherscan.io/address/0x6DBDe0E7e563E34A53B1130D6B779ec8eD34B4B9).editSchedule() to update the dripping schedule for the Arbitrum. For Arbitrum - Call [Comptroller](https://arbiscan.io/address/0x641DD6258cb3E948121B10ee51594Dc2A8549fe1).setHalfDecayPoint("250000") to set the half decay point to 250,000.

0x0c387030…e763sent to0xe1b3f07a…0f6e2023-03-06·#16,767,755·0xd5d304f6…ee195b

It is very good that we are adapting to the recent changes at micro and macro level

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2023-03-03·#16,745,649·0x40b28b82…8602ed

setInterestRate(uint256) UIP-007: Adapt to PoS blocktime # Abstract - Change the interest rate per block from 41668836919 to 38051750380 - Change overdue period blocks from 197250 to 216000 # Motivation Now that PoS has passed and enough time passed to get an accurate Blocks per year. It's necessary to adjust. # Specification - To calculate the new interest rate per block, we use the PoS block time of approximately 12 seconds, and the targeted 10% interest rate per annum, which is 1e17. Therefore, the calculation would be 1e17 / 2,628,000, which results in 38051750380 - To calculate the number of new overdue blocks, we use the PoS block time of approximately 12 seconds and a 30-day overdue period. Therefore, the calculation would be (3600 * 24 * 30) / 12, which results in 216,000 # Test Cases Tests and simulations can be found here: [PR](https://github.com/unioncredit/UIPs/pull/15) # Implementation For Mainnet: - Call [FixedInterestRateModel](https://etherscan.io/address/0xfDd998ce04AB8f48B473cE4C9af1C2F8F8E264Eb).setInterestRate("38051750380") to update the interest rate per block - Call [UToken](https://etherscan.io/address/0x954F20DF58347b71bbC10c94827bE9EbC8706887).setOverdueBlocks("216000") to change the loan overdue period For Arbitrum - Call [FixedInterestRateModel](https://arbiscan.io/address/0x051e2514E3fE8da88CaA2951442a21042BCe99Ea).setInterestRate("38051750380") to update the interest rate per block - Call [UToken](https://arbiscan.io/address/0x954F20DF58347b71bbC10c94827bE9EbC8706887).setOverdueBlocks("216000") to change the loan overdue period

unknown sendersent to0xe1b3f07a…0f6e2022-07-19·#15,170,767·0xf966cee4…6fe241

# UIP-006: Dropping the Effective Number from 3 to 1 # Abstract Right now, the number of vouches required to become a Union member is 3. This requirement is called the “effective number.” This proposal will change the effective number from 3 to 1. It's important for protocol health for the global average number of edges per node to be >1. With this proposal we plan to drop the hard requirement to 1 and monitor where the actual averages end up. # Motivation The goal of changing the effective number is to facilitate user interaction with the protocol. Dropping the effective number affects two aspects of user interaction: onboarding and follow-through. - Streamline onboarding: Dropping the effective number to 1 allows for current members to onboard their community members quickly, and promotes local network growth. - Increase membership follow-through: A current issue with the effective number being 3 is that if someone is missing one or two of the vouches required to become a member, they are less likely to follow through on membership completion. This problem also gates people from vouching for others. Reducing the amount of vouches required to become a member will result in a higher rate of membership completion. # Specification Change the 'effectiveNumber' in [SumOfTrust](https://github.com/unioncredit/union-v1-contracts/blob/master/contracts/user/SumOfTrust.sol) from '3' to '1'. # Backwards Compatibility Existing Union members with 3 or more vouches should still work as previously. # Test Cases Tests and simulations can be found here: [Link to PR](https://github.com/unioncredit/UIPs/pull/12) # Implementation Set the 'effectiveNumber' of [SumOfTrust](https://github.com/unioncredit/union-v1-contracts/blob/master/contracts/user/SumOfTrust.sol) to '1' by calling 'SumOfTrust.setEffectiveNumber(1)' Link to PR: https://github.com/unioncredit/UIPs/pull/12 # Security Considerations One of the implications is that if only one member is vouching for you, and someone else is borrowing against that person’s vouch, your total amount of available credit could go down to 0. The possibility of a member’s available credit being dependent on only one credit provider should encourage the user to onboard more members as underwriters, and incentivize users to not rely on a sole credit provider.

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2022-07-19·#15,170,767·0xf966cee4…6fe241

UIP-006: Dropping the Effective Number from 3 to 1 # Abstract Right now, the number of vouches required to become a Union member is 3. This requirement is called the “effective number.” This proposal will change the effective number from 3 to 1. It's important for protocol health for the global average number of edges per node to be >1. With this proposal we plan to drop the hard requirement to 1 and monitor where the actual averages end up. # Motivation The goal of changing the effective number is to facilitate user interaction with the protocol. Dropping the effective number affects two aspects of user interaction: onboarding and follow-through. - Streamline onboarding: Dropping the effective number to 1 allows for current members to onboard their community members quickly, and promotes local network growth. - Increase membership follow-through: A current issue with the effective number being 3 is that if someone is missing one or two of the vouches required to become a member, they are less likely to follow through on membership completion. This problem also gates people from vouching for others. Reducing the amount of vouches required to become a member will result in a higher rate of membership completion. # Specification Change the 'effectiveNumber' in [SumOfTrust](https://github.com/unioncredit/union-v1-contracts/blob/master/contracts/user/SumOfTrust.sol) from '3' to '1'. # Backwards Compatibility Existing Union members with 3 or more vouches should still work as previously. # Test Cases Tests and simulations can be found here: [Link to PR](https://github.com/unioncredit/UIPs/pull/12) # Implementation Set the 'effectiveNumber' of [SumOfTrust](https://github.com/unioncredit/union-v1-contracts/blob/master/contracts/user/SumOfTrust.sol) to '1' by calling 'SumOfTrust.setEffectiveNumber(1)' Link to PR: https://github.com/unioncredit/UIPs/pull/12 # Security Considerations One of the implications is that if only one member is vouching for you, and someone else is borrowing against that person’s vouch, your total amount of available credit could go down to 0. The possibility of a member’s available credit being dependent on only one credit provider should encourage the user to onboard more members as underwriters, and incentivize users to not rely on a sole credit provider.

unknown sendersent to0xe1b3f07a…0f6e2022-07-01·#15,057,378·0xb56562cf…31cd4c

UIP-005: Add Aave V3 Support on Arbitrum ## Intro This is a change to the protocol, and therefore will go through the UIP process. ## Motivation Currently, all unlent DAI in Union on Arbitrum is stored in a puretoken DAI adapter. Now that aave V3 has been deployed to Arbitrum, an adapter can be written to support depositing a portion of deposited DAI in aave V3 to earn interest. ## Proposal / Solution Create an AssetManager Adapter that works with Aave V3 to deposit a portion of unlent DAI to Aave V3 on Arbitrum to earn interest and rewards. ### Main functions: - deposit() - deposit DAI in AssetManager to Aave to earn interest. - withdraw() - withdraw DAI from Aave and move to AssetManager. - claimRewards() - get the rewarded Aave token. ### Parameters - Set AaveV3Adapter floor to 10,000 DAI - Set AaveV3Adapter ceiling to 50,000 DAI ## Defining Success Be able to deposit to / withdraw from Aave, and be able to claim rewards token from Aave on Arbitrum. ## Backwards Compatibility No issues with backward compatibility for this proposal. ## Test Cases Tests and simulations can be found here: [Link to PR](https://github.com/unioncredit/union-v1-contracts/pull/106) ## Implementation ### Before creating the proposal: - Create and deploy AaveV3Adapter on Arbitrum - Set AaveV3Adapter floor to 10,000 DAI - Set AaveV3Adapter ceiling to 50,000 DAI - Set AaveV3Adapter mapTokenToAToken ### In the proposal: - Call AssetManager.addAdapter() to add AaveV3Adapter.

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2022-07-01·#15,057,378·0xb56562cf…31cd4c

createRetryableTicket(address,uint256,uint256,address,address,uint256,uint256,bytes) UIP-005: Add Aave V3 Support on Arbitrum ## Intro This is a change to the protocol, and therefore will go through the UIP process. ## Motivation Currently, all unlent DAI in Union on Arbitrum is stored in a puretoken DAI adapter. Now that aave V3 has been deployed to Arbitrum, an adapter can be written to support depositing a portion of deposited DAI in aave V3 to earn interest. ## Proposal / Solution Create an AssetManager Adapter that works with Aave V3 to deposit a portion of unlent DAI to Aave V3 on Arbitrum to earn interest and rewards. ### Main functions: - deposit() - deposit DAI in AssetManager to Aave to earn interest. - withdraw() - withdraw DAI from Aave and move to AssetManager. - claimRewards() - get the rewarded Aave token. ### Parameters - Set AaveV3Adapter floor to 10,000 DAI - Set AaveV3Adapter ceiling to 50,000 DAI ## Defining Success Be able to deposit to / withdraw from Aave, and be able to claim rewards token from Aave on Arbitrum. ## Backwards Compatibility No issues with backward compatibility for this proposal. ## Test Cases Tests and simulations can be found here: [Link to PR](https://github.com/unioncredit/union-v1-contracts/pull/106) ## Implementation ### Before creating the proposal: - Create and deploy AaveV3Adapter on Arbitrum - Set AaveV3Adapter floor to 10,000 DAI - Set AaveV3Adapter ceiling to 50,000 DAI - Set AaveV3Adapter mapTokenToAToken ### In the proposal: - Call AssetManager.addAdapter() to add AaveV3Adapter.

unknown sendersent to0xe1b3f07a…0f6e2022-03-31·#14,492,806·0x65231c22…b2d3d8

UIP-004: Drip UNION to Arbitrum comptroller ## Abstract In order to support Union on Arbitrum, UNION token will need to be distributed to participants. The L1 treasury will drip UNION token to the Arbitrum comptroller. An intermediary contract (ArbConnector) is added to connect L1 treasury to the Union Arbitrum comptroller. ## Motivation Protocol participants will need to be able to claim UNION on the Arbitrum One Network. Therefore, the Union protocol comptroller on the Arbitrum network needs to have UNION continuously dripped over. ## Specification Add ArbConnector contract to be a new dripping target of the Treasury, and set the dripping rate to be 1 UNION per block in a total amount of 2.4M UNION tokens, which will last for 1 year at the current Ethereum block minting rate (13.14 seconds per block) ## Rationale Adding a treasury on L2 was considered, but there was no identifiable upside for going this route. Adding a comptroller provided the same benefits with lower effort. ## Backwards Compatibility No issues with backwards compatibility for this proposal ## Test Cases Tests and simulations can be found here: [Link to PR](https://github.com/unioncredit/union-v1-proposals/pull/9) ## Implementation Call the function 'addSchedule(uint256,uint256,address,uint256)' of the Treasury contract ([0x6DBDe0E7e563E34A53B1130D6B779ec8eD34B4B9](https://etherscan.io/address/0x6DBDe0E7e563E34A53B1130D6B779ec8eD34B4B9#code)) with the following parameters: - drip start block: the block when the proposal is created - drip rate: 1 UNION per block - target address: arbConnector ([0x307ED81138cA91637E432DbaBaC6E3A42699032a](https://etherscan.io/address/0x307ED81138cA91637E432DbaBaC6E3A42699032a)) - total amount: 2.4M UNION - PR link: https://github.com/unioncredit/union-v1-proposals/pull/9 ## Security Considerations - ArbConnector contract should work correctly to bridge any wrapped UNION on its balance to the Arbitrum comptroller. - Any wrapped UNION in ArbConnector cannot be sent to any addresses other than the Arbitrum bridge. - Wrapped UNION in ArbConnector can be withdrawn by the owner in case of emergency (by calling 'claimTokens(address recipient)')

0xcbd1c32a…beebsent to0xe1b3f07a…0f6e2022-03-31·#14,492,806·0x65231c22…b2d3d8

0x497c20fe…3779sent to0xe1b3f07a…0f6e2022-03-08·#14,345,191·0xc1c7047a…077392

UIP-003: Transfer treasury's ownership to Timelock # Simple Summary In short, as part of progressive decentralization, this proposal transfers ownership of the treasury from Admin key to DAO governance. In order to execute https://unioncredit.slite.com/app/docs/LKtqwvcEiQDocE, the treasury's ownership must belong to Timelock. This proposal executes the transfer of ownership. # Motivation Increasing decentralization is the primary motivation. In addition, to execute UIP 0004, setting up a UNION drip from Mainnet to Arbitrum One, treasury ownership must be transferred to Timelock from Admin key. # Specification - Prerequisites: Set the 'newAdmin' property of the Treasury contract to be the Timelock's address (0xBBD3321f377742c4b3fe458b270c2F271d3294D8). - Call the function 'acceptAdmin()' of the Treasury contract to set its 'admin' property. # Test Cases Simulation on mainnet here: https://github.com/unioncredit/union-v1-proposals/blob/uip/003-treasury-admin-transfer/proposals/003_TreasuryAdminTransfer/testProposal.js # Implementation - Call the function 'acceptAdmin()' of the Treasury contract # Security Considerations Make sure the new admin is Timelock's address. UIP 0003 and UIP 0004 could have been completed together, but as this change pertains to the treasury, and abundance of caution is beneficial to limit risk. Therefore, the changes were split up into individual proposals and will be handled one at a time.

unknown sendersent to0xe1b3f07a…0f6e2022-03-08·#14,345,191·0xd4f3710b…fd4222

0x497c20fe…3779sent to0xe1b3f07a…0f6e2022-03-08·#14,345,191·0xd4f3710b…fd4222