PBT Locking

[illestrater]

Hello! Firstly, thank you for bringing this to life and tackling real-world solutions with tokenization.

While contemplating the current functionality, I've thought about the social behavior around a physical backed token. Currently, any individual within proximity of the physical token would be able to sign a transfer to their wallet. Now, I think this is a really cool mechanism.

For example, this mimics the fun of public signing of a physical artifact with a marker, that can then be showcased at another event - introducing the feeling of proving that "I was here".

I think one drawback this has is if the intended use is secure provenance through supply chain. And perhaps, the owner of a token does not want to unknowingly allow other people to claim provenance, thus having to introduce physical security over the item.

I believe this can be solved by introducing a locking/unlocking mechanism for transfers, in which the intended receiver of the item can choose whether they would like to enable signed transfers of the item.

I've written three contracts PBTLocket.sol, PBTLocketMock.sol, and PBTSimpleTest.sol (transferTokenWithChip as virtual) as an example working draft of this proposed functionality. Would love the team's input on the proposal and hope the functionality may be added as an option for the community!

[theCuratorCM]

Fantastic observation—methinks this is a must to implement.

[jahvi]

@illestrater Great PR, I like the unlockForReceiver implementation so owners can only unlock for specific receiver addresses only.

I wonder if it's worth having the tokens as "locked" by default and having them unlock manually? That way it'd prevent the token from being vulnerable initially.