This is a placeholder for a potential follow-on project to the Bootleg project, where the linear array and rigid single-owner structure are modified so that each franchisor can retain some number of sale/transfer/append rights after they do a sale/transfer/append to the next Franchisor. This would result in a new vector in the array with each new Owner/Franchisor.
As we researched artist rights, we realized that what we were calling “owners” were more correctly referred to as royalty holders, or Franchisors. [Link to the royalty reference page.] And this gave us our ultimate insight. We weren’t creating a bunch of buyers and sellers – we were creating little clubs of people who shared the rights to future cash flows from the fees provided by new members of the club.
Our reference implementation, the Bootleg application in this kit, restricts the “club” to a single thread. Only one person at a time gets the right to add someone new to the Franchisor club, and they must transfer that right to the new member. But this is an artificial restriction. You could permit every new member to add some number of other members, who in turn can add their own, and so on. This would lead to an exponential expansion in the size of the club – and the cashflows back to the original members. But in our “bootleg” example, making the videos scarce is more important than having a large “club.” It was also easier to construct the minimally viable reference implementation of the token.
This needs to go into the site in such a way that it extends the paragraph just above but is clearly in the “mods and call-for-repo-contribution” section:
6.4.1: The bootleg reference implementation is linear. Each new member of the Franchisor array is designated (by the way an ERC721 works) as the Owner, and only the Owner can add a new member to the array and transfer Ownership to someone else. So for any Print, only one person can sell the Print at a time. But there are ways to make this exponential. In order to create a n^n revenue model, where each Owner can continue to be an Owner, with rights to add some number of new Owners without transferring this right to the single new Owner, you’d have to modify some key attributes of the base ERC721 to allow multiple Owners as vectors in the Franchisors array. Then each new Franchisor could, in turn, create a new line of Franchisors (of some determined or indeterminate length, depending on what you are trying to achieve), each of which in turn could create their own new line of Franchisors, and so on and so on… You get the idea. This is a very different economic pattern than what we did for the reference implementation here, and it would suit a very different set of uses, but the bootleg token SRNTF structure would support this more advanced Franchisor array. Just as soon as you jump into the repo and help create these extensions! :)
This is a placeholder for a potential follow-on project to the Bootleg project, where the linear array and rigid single-owner structure are modified so that each franchisor can retain some number of sale/transfer/append rights after they do a sale/transfer/append to the next Franchisor. This would result in a new vector in the array with each new Owner/Franchisor.
As we researched artist rights, we realized that what we were calling “owners” were more correctly referred to as royalty holders, or Franchisors. [Link to the royalty reference page.] And this gave us our ultimate insight. We weren’t creating a bunch of buyers and sellers – we were creating little clubs of people who shared the rights to future cash flows from the fees provided by new members of the club.
Our reference implementation, the Bootleg application in this kit, restricts the “club” to a single thread. Only one person at a time gets the right to add someone new to the Franchisor club, and they must transfer that right to the new member. But this is an artificial restriction. You could permit every new member to add some number of other members, who in turn can add their own, and so on. This would lead to an exponential expansion in the size of the club – and the cashflows back to the original members. But in our “bootleg” example, making the videos scarce is more important than having a large “club.” It was also easier to construct the minimally viable reference implementation of the token.
This needs to go into the site in such a way that it extends the paragraph just above but is clearly in the “mods and call-for-repo-contribution” section:
6.4.1: The bootleg reference implementation is linear. Each new member of the Franchisor array is designated (by the way an ERC721 works) as the Owner, and only the Owner can add a new member to the array and transfer Ownership to someone else. So for any Print, only one person can sell the Print at a time. But there are ways to make this exponential. In order to create a n^n revenue model, where each Owner can continue to be an Owner, with rights to add some number of new Owners without transferring this right to the single new Owner, you’d have to modify some key attributes of the base ERC721 to allow multiple Owners as vectors in the Franchisors array. Then each new Franchisor could, in turn, create a new line of Franchisors (of some determined or indeterminate length, depending on what you are trying to achieve), each of which in turn could create their own new line of Franchisors, and so on and so on… You get the idea. This is a very different economic pattern than what we did for the reference implementation here, and it would suit a very different set of uses, but the bootleg token SRNTF structure would support this more advanced Franchisor array. Just as soon as you jump into the repo and help create these extensions! :)