Proxy Ownership Register
A proxy ownership register allowing trustless proof of ownership between ethereum addresses, with delegated asset delivery
status: Draft
type: Standards Track
category: ERC
Proxy Ownership Register
A proxy ownership register allowing trustless proof of ownership between ethereum addresses, with delegated asset delivery
status: Draft
type: Standards Track
category: ERC
@omnus do you mind removing the EIP text from you post and just linking to the EIP PR? Thanks
That’s a good idea @matt. Done!
Interesting idea! Seems vaguely similar to Non-Fungible Token with usage rights by @kkimos and EIP-4907 by @LanceSnow (et. al). I’d love to see all of these “separate transfer permission from usage permission” EIPs collaborate, though not strictly required.
Thanks for spinning up this EIP.
A few questions about some design decisions:
Hi @cxkoda,
Thank you very much for reading the EIP and taking the time to comment, I really appreciate it.
On your questions:
Early on I considered creating a 1:n structure, but in the end opted for 1:1 for a few reasons:
It certainly could, and I think that’s a great idea! My main reason was that I wanted there to be no reliance on any off-chain component at all. Collecting a sig and then combining into another transaction would mean that the register isn’t maintained entirely on-chain.
Making it entirely on-chain has enabled me to deploy EPS as a ‘headless protocol’, in that there is no front-end off chain code required to add or maintain the register, and wallets never need to connect directly to a UI (not even something like etherscan). Instead the protocol exposes an API through ERC20 txns.
I mean to write up the headless protocol as an EIP at some point, I think it’s pretty neat :).
Yes that’s true, I could have left the rights for both the cold and hot wallet and relied on the consumer to decide whether it accepted one or the other. But I felt that was somewhat obviating the responsibility to maintain the atomic nature of the rights associated with the NFT. I strongly feel that’s the protocol’s responsibility. The NFT creator envisaged one set of rights when tokenId 3,321 was minted (for example), and any primitive that builds composability on top of that should respect that constraint (imo). So in this regard when those rights and benefits ‘bubble up’ from the cold wallet to a hot wallet they can no longer be ascribed to the cold.
To follow on from that, it also has the benefit of making integration easier (and I like things that are simple ). The consumer doesn’t need to worry about ‘double spend’ of rights, as the protocol won’t allow it. It also allows the very simple ‘find and replace’ integration where instead of querying a contract for a holder’s balance you can query EPS (which is backwards compatible).
Thank you again for the feedback, it means a lot.