Hi @ryanio for the discussion. However I do think you some important consideration on the design of ERC6672. As one of the authors I would like to elaborate more on the benefits of extending existing standards with small blocks of functionality rather than rebuilding a bundle of complete logic into a pack.
As a standard to be adopted by the community, we believe it should be simple yet extensible, rather than complex but specific. Complex mechanisms may build on top and we should make it generally re-usable to most business logic if possible.
First of all, ERC6672 intend to solve only the redemption tracking part, and we have received many feedbacks to polish the interface for it to be adoptable towards many businesses including distributors and suppliers. As simple it may seem, it is able to support complex logic, and we believe it should be supported with future implementations or standards.
Secondly, the redemption part of 7498 is extremely similar to 6672, with 6672 able to support more complex business structures with the operator management (which also can be freely implemented) As for the cancel part it is highly demanded from all sorts of providers, suppliers and creators for their “real world operation and business models”. The redemption record is still immutable, only that the aggregated final status is modified.
Thirdly, We should try to reuse interfaces so that we can build in consensus, rather than having a different standard for each problem. Linking it with dynamic trait is a great plus and I believe we can discuss the implementing to make it work. However for interfaces (like the cancel mentioned), we should still think more generally, and if unwanted in certain scenarios, simply deactivate it during implementation. For example, many builders of Soul Bound Tokens still uses 721 and follows Opensea’s metadata standard. They simply block the transfer part which they no longer needed.
To sum up, I believe it is beneficial to extend 7498 from 6672, so that the existing and growing mass network of real life scenarios, IOTs, hardwares and brands can be connected to the novel mechanisms that you and us are building.
Final touches, we also feel it quite good to have on chain campaign specifications. However we proposed 6672 to focus on the redemption handling because there are existing privilege specifying standards that we think is quite general and extensible. Have you looked at any of those and what’s your thoughts on the major differences ?