Why was claimable removed?

I found myself writing a SafeOwnable contract (with two steps to transfer ownership and a bool parameter for renouncing ownership). I was considering opening a PR to include it in OpenZeppelin contracts and that’s when I stumbled on the fact there was once a claimable contract. Why was it removed? Would a SafeOwnable contract be something worth a PR, or has such a thing been decided against already at this point?

2 Likes

I’m gonna drop this [repo comparison] here, just in case:

Also, I realized SafeOwnable is a miserable name. Implication being that Ownable is… less than safe, which obviously isn’t the case. Instead, I’ll refer to this more cautious implementation of Ownable as OwnableCautious.

1 Like

Hi @CallMeGwei

Claimable removal is discussed in: https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1488

https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1488#issuecomment-440396469
The main reason behind Claimable no longer being a thing is that we’re in the process of deprecating Ownable : we think having a single account with superpowers is too powerful, and doesn’t fit some scenarios where some granularity regarding permissions is required (see #366).

If you haven’t already, I suggest having a look at Role Based Access Control:
https://docs.openzeppelin.com/contracts/2.x/access-control#role-based-access-control

Can you share some details on your requirements for SafeOwnable?

1 Like

In many cases, full blown permissions can be overkill. Ownable is great, imho. It lets the contract designer worry about access controls and fine-grained controls if they want to. And it doesn’t get in anybody’s way otherwise.

The only thing I didn’t like about it was that - (despite wording in the tests about avoiding a locked state) - it was too easy to fat-finger an address and end up stranded.

My other quibble was that … and this may be silly … but pressing the ‘renounceOwnership’ button anywhere an auto-generated UI was involved (think: remix) was just way too easy. Not necessarily a big deal for production, but adding a single bool to confirm doesn’t really bloat anything and ensures accidents like those won’t happen.

1 Like

P.S.

I do value the renounceOwnership feature. It’s dead-simple for others to verify that the contract has been “let go”. I know upgradable contracts are sort of in vogue, but the ones closest to my (philosophical) heart are the ones without owners or proxies.

I will definitely check out the RBAC stuff, as that is bound to be handy for more complicated scenarios. I do, however, shed a tear at the thought of a deprecated Ownable.

1 Like

Hi @CallMeGwei

Roles have the two stage transfer process, where first you add and then you renounce.
https://docs.openzeppelin.com/contracts/2.x/api/access#MinterRole

I can see an argument for having a parameter for renounce functions. I was manually minting some tokens on a testnet using an autogenerated GUI and pressed return and renounceMinter() was the first function. Though rather than a bool, I would probably prefer the address to renounce (thinking of when you delete a repository in GitHub).

Can you give an example of where you would want to use Ownable rather than using a Role?

Off the top of my head? Someplace I only ever want there to be one active owner at a time. In the minter example you linked to, for instance, during that time between add and renounce there are effectively two accounts with minter permission. Glancing over the other contracts, it seems that’s normal. With OwnableCautious (or the original Ownable) there is only ever one owner at a time.

The roles documentation is sparse, but pretty easy to follow. The library needs another smart contract to do something with it… so you could easily add an addAndRenounce function to achieve the same end… but Roles.sol isn’t exactly a “grab and go” solution for ownership (certainly not until there’s --at least–an OwnerRole.sol!

Even then, it’ll still be one file more than Ownable for a common use case.

1 Like

Oh, and I do like the idea of making the user input their address for renunciation. The bool idea was just because I didn’t want to have to copy/paste in remix to renounce. :wink:

1 Like

Hi @CallMeGwei
What functionality do you need to own? Can you give an example use case.

e.g. MinterRole has permission to mint, PauserRole has permission to pause.

I suggest checking out OpenZeppelin SDK I really like it. (I am biased :smile:).

One other point, is you can edit your posts, to add more information, rather than making lots of small posts.

Very interesting comments @CallMeGwei! Some of us in the team are having a chat this week about the security practices around Roles and Ownable. I’ll make sure to bring this up.

1 Like

I’m working through the upgradeable proxy libraries right now - (I am implementing an upgradeable “entity” contract where I don’t want a “transparent” proxy… which is the sdk default as I understand it). There is our beloved Ownable front and center in the proxy contracts. I’m replacing it with OwnableCautious as opposed to Roles.

I’d be interested to hear the cliffnotes from the meeting, @frangio . :slight_smile:

1 Like

Referring to your original post (at the top of this page):

I have posted that as an issue about 9 months ago.

See https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1488.

2 Likes