royalty-registry-solidity VS splicenft

https://opensea.io/collection/1989-sisters. As part of that project, I contributed to the open source Manifold royalty registry to patch an migration issue with OpenSea contracts that allowed for them to receive payments through Coinbase NFT: https://github.com/manifoldxyz/royalty-registry-solidity/pul....

Spending most of my time now back in Ruby/Rails, Docker, AWS and overseeing a small team of iOS developers and QA engineers based in eastern Europe (Ukraine as it happens). Also serving as our de facto product manager and designer and have handled all UI/UX/Iconography design in Figma. Extensive work with Plaid, multi-docker container deployments (AWS ECS/Fargate), subscription payments, etc. Fast learner and take pride in my craft.

Feel free to contact me. I'm happy to send work samples. Need to touch up my resume/portfolio/website but am posting here in the meantime. Thanks!

email: p dot osetinsky at gmail dot com

To solve this issue, a consortium of major NFT marketplaces around manifold.xyz agreed to deploy an industry-wide registry contract that collection builders can use to signal royalty splits independently from their token contracts. The Royalty Registry’s open source code base reveals that it supports many of the most important marketplace interfaces.

The tradeoffs of that approach might be neglectable for many use cases: PaymentSplitter deployments are comparatively gas-intensive and it’s impossible to replace payees or shares once a splitter has been initialized. A sample implementation of how to effectively replace splitter participants and instantiate gas-efficient subcontracts can be found in the generative art project Splice.