Skip to content
This repository has been archived by the owner on Mar 28, 2023. It is now read-only.

Expose collateralization functions and Keep address #590

Merged
merged 4 commits into from
Apr 22, 2020

Conversation

NicholasDotSol
Copy link
Contributor

These functions return per-deposit collateralization details. Exposing these can be useful for monitoring and managing liquidation easily.
The Keep address can be useful in order to easily obtain useful info about the keep.

Nicholas Evans added 2 commits April 21, 2020 13:01
These functions return per-deposit collateralization details.
Exposing these can be useful for monitoring and managing
liquidation easily.
Allow for anyone to check the address of the keep
associated with the Deposit.
This can be useful to obtail operating info
about the keep. Status, events, members etc.
Copy link
Member

@mhluongo mhluongo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice ergonomic improvement. Waiting for one more 👍 for merge

Shadowfiend and others added 2 commits April 22, 2020 13:09
These functions are now implemented in parent.
No need to overload.
@Shadowfiend Shadowfiend merged commit 5ddacba into master Apr 22, 2020
@Shadowfiend Shadowfiend deleted the expose-liq-assist branch April 22, 2020 17:24
/// @notice Get the current collateralization level for this Deposit.
/// @dev This value represents the percentage of the backing BTC value the signers
/// currently must hold as bond.
/// @return The severe collateralization level for this deposit.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NicholasDotSol potential copypasta re: "severe"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also is there a reason why getCollateralizationPercentage is uint256? Seems like we could return uint16 here too, just curious.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NicholasDotSol potential copypasta re: "severe"?

yeah good catch, severe -> current

Also is there a reason why getCollateralizationPercentage is uint256? Seems like we could return uint16 here too, just curious.

There is no reason to move this to a smaller uint size. It makes sense for other collateralization values that take up storage since we can take advantage of bit-packing. But Since this value is calculated in memory, converting from and to uint types will just take additional gas

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah good catch, severe -> current

also note that this is repeated below too.

There is no reason to move this to a smaller uint size. It makes sense for other collateralization values that take up storage since we can take advantage of bit-packing. But Since this value is calculated in memory, converting from and to uint types will just take additional gas

Alright, fair enough. Didn't know that there were gas costs for casting to lower types, thought everything was the same word-size in memory.

@NicholasDotSol NicholasDotSol mentioned this pull request Apr 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants