The spec for migrating to the tez wrapper as well as its implementation keep the burden of delegation on the Checker side: vault owners can set the delegate for their own vaults, but burrow owners can only set the delegate for their collateral via Checker.
This design is not very modular; ideally delegation should happen entirely on the TezWrapper side (should also lower the gas costs, not having to go through checker) but that can't happen easily: (a) the burrow contracts only listen to checker, (b) only checker knows the burrow addresses, and (c) the burrow contracts are the only contracts that can set the delegate for their vaults.
I am thinking that exposing the burrow address for a user via an offline view could address (b), though I am not sure yet about the best way to circumvent (a) and (c). Either way, the ideal design would have Checker deal solely with FA2 tokens (accepting no tez and having no delegation-related entrypoints).
The spec for migrating to the tez wrapper as well as its implementation keep the burden of delegation on the Checker side: vault owners can set the delegate for their own vaults, but burrow owners can only set the delegate for their collateral via Checker.
This design is not very modular; ideally delegation should happen entirely on the TezWrapper side (should also lower the gas costs, not having to go through checker) but that can't happen easily: (a) the burrow contracts only listen to checker, (b) only checker knows the burrow addresses, and (c) the burrow contracts are the only contracts that can set the delegate for their vaults.
I am thinking that exposing the burrow address for a user via an offline view could address (b), though I am not sure yet about the best way to circumvent (a) and (c). Either way, the ideal design would have Checker deal solely with FA2 tokens (accepting no tez and having no delegation-related entrypoints).