Token Extension Token Transfer Guard

[balmy-gazebo]

Instead of forcing the approve IX to be Called by all programs, we can leave it for Marketplaces to simplify royalties but instead just have the Execute function check CPI-ing programs for blacklist/whitelist that could be a global value in WNS (as this is how we'd ultimately have to do it with approve.

Benefits:

• Would simplify integration significantly
• Would require less accounts on transfer with hook

Cons:

• Would reduce future flexibility on enforcement

[kespinola]

I'm excited about this one and would like to see folks thoughts on building this as separate protocol from the current royalty distribution which blurs the lines between WNS and itself. If the protocol is decoupled from WNS then it can serve as a general token extension hook protocol.

WEN NGMI PROTOCOL Allows fungible and non fungible tokens to govern which protocols are allowed to facilitate the transfer of the asset based on an allow list.

Requirements

• Manage allow list lifecycle based on some authority wallet.
• Enforce in transfer hook that the program facility the transfer is in the allow list.

WEN community also hosts a management portal for teams to pick from community managed lists to add to their mint.

The simpler allow list style still allows mints to block protocols that don't respect royalties without directly being responsible for royalty distribution which complicates interacting with the protocol for marketplaces.

[balmy-gazebo]

Makes sense, I think doing a blacklist might be better than whitelist on this.

The other important thing is thinking about how to maintain the distribution component to just be a one call system for sending out royalties funds as is now. Even if we drop the approval piece

[kespinola]

Token Extensions Transfer Guards

Summary

This specification introduces a guard system for governing the transfer of Token Extension (TE) mints via TE token transfer hooks. Mint authorities can setup a guard to control the transfer flow of the asset.

Use cases

• Blocking collections from being sold on marketplaces that do not respect royalties.
• Prevent the transfer of an asset until conditions are met on the mint as described by its fields or the fields on its group.

Protocol

State

• Mint: Identifies which guard should be applied to a token extension."
  • A custom field added to the mint that specifies which guard account is required to govern transfer interactions with.
• Guard: Details how programs can manage transfers of a mint.
  • Simple: Features an allow and deny list of program addresses authorized or blocked from facilitating transfers, as determined by a designated authority.
    • authority - pubkey
    • allow - array of pubkeys
    • exclude - array of pubkeys
  • Advanced: A set of rules dictating the conditions under which transfers are permitted, inspired by Metaplex Token Auth. The details of a rule and its mechanics need to be further explored.
    • authority - pubkey
    • rules - array of Rule objects

Instructions

• [ ] create_guard: Establish a guard with specified information and assign an authority.
• set_guard_rules: Replace existing guard rules with new ones, adjusting the size of the account as necessary. Only the owner of the NFT can own it.
• delete_guard: Remove a guard account and send remaining rent to the authority.
• [X] initialize: Setup the transfer extension on the mint given a known guard.
• [X] execute: Verifies the transfer can be completed based on the conditions governing the asset.

dApp

A management and discovery portal for guards.

Managers:

• Manage the lifecycle of enforcement lists.

Mint Authorities:

• View and assign guards to mints.
• See metrics on guard invocations.

Visitors:

• Access descriptive details about guards, view their usage, see which guards are most popular, and engage with guards by upvoting or commenting.

Developers:

• Query protocol information through contextualized JSON RPC and receive webhook updates when guards are invoked.

Considerations

• Should a mint assigned to a group automatically determine which guard to apply based on the group mint? Goal is reduce complexity for governing and applying guards by setting group wide details on the group mint.

[luke-truitt]

How do you see this integrating with the execute instruction? Passing in the CPI GUARD account to Execute in WNS and then having it deserialize there? Or would the transfer hook be owned by the CPI GUARD program?

[luke-truitt]

I support this approach though and generally separating royalty distribution contract entirely into a convenience module. The current model results in a lot of wasted space for every CPI with the excess APPROVE call, which would be resolved by having the transfer guard be purely white/black list based (or more complex).

[kespinola]

@luke-truitt current thinking is this is a completely separate and stand-alone offering from WNS so it owns the hook execution and guard accounts.

WNS style mints can add guard to their WNS asset.

[luke-truitt]

Yes okay thats a good idea. Maybe should include some modifications to WNS alongside that. Remove the default Execute function thats added for Royalty Enforcement and make it a choice? Also should drove the Approve account.

[kespinola]

Brief standup notes:

• New program wen_transfer_guard under programs
• Can likely drop storying guard as extra field on mint since its address will be encoded in the token extensions extra account meta list.

Approach for releasing:

1. Create guard
2. Register wen_token_guard as token extension on dummy mint
3. Write hook that reads guard and does allow lookup
4. Build out more of the guard logic and settings

[kespinola]

Guard A guard will be be linked to a WNS asset. Whoever owns the asset has the rights to update the guard.

seed = ["token_extension_guard", "guard", {mint}]

checks for who can create or update guard:

• mint exists
• mint supply is 1
• toke account balance on mint is 1
• signer is the owner of the token account

A guard is considered immutable if the supply of token_account is burned or closed.

When updating a guard The update instruction should take the mint and token_account of the signer. The signer must have token_account with balance 1 and sign the instruction in order to modify the contents of the guard.

[balmy-gazebo]

Not sure this is the best approach as then if someone wanted to "avoid" royalties they would be able to just remove the hook for the asset they own no?

[balmy-gazebo]

Should probably be the asset metadata authority that has this control

[kespinola]

Rules can be evaluated based on the state of the mint, token being transferred, or programing cati.

Rule {
  object: CPI PROGRAM ID,
  object: PROGRAM,
  outcome: ALLOW | DENY
}

Rule {
}

Guard {
 rules: Vec<Rule>
}

[kespinola]

Not sure this is the best approach as then if someone wanted to "avoid" royalties they would be able to just remove the hook for the asset they own no?

Should probably be the asset metadata authority that has this control

@balmy-gazebo

The use of an asset to govern authority rights on the guard does not mean that entity has rights to remove the token extension or guard from the mint.

It does give rights to update the guard rule set. My thinking is that communities will maintain guards and mint authorities can choose to attach them to their asset. If the authority of the mint doesn't like some rule added to a guard they can copy it, modify, be the authority on the guard, and assign it to their mint.

With the community part of the guard system I wanted to have a means of displaying descriptive information on the guard like image, name, description, external url etc. I don't like having another 2 accounts associated to the guard but do think they are decoupled. Meaning the asset portion of the guard is solely for display and management of the guard. Once the guard is assigned to the mint for transfer enforcement it doesn't need to worry about the asset attached to the guard ie no extra accounts to pass or register for the TE other than the guard account.