I read in the docs that on manifold.studio you can deploy a creator core. Where can I find this option?
I understand that deploying the core via the studio would be cheaper than deploying the core myself on ethereum
gm! Thanks for reaching out - What mechanics are you thinking to do? To deploy a Creator contract, this can be done through the Create menu in Manifold Studio.
I just want to deploy a core and apply a simple extension to it, which will allow a different contract to mint an nft using a custom call.
Basically changing mintExtension to mint, client requirements.
As I understand it deploying the core via ManifoldStudio is cheaper since it is uses the delegate proxy deployment?
So on the menu you showed it is basically either a ERC721Core or an ERC1155Core being deployed?
Is there the option to choose if it is an enumerable core or not?
I recall there being an option to mint to a testnet on manifold studio, dont see if thats available any more.
Hi there bob!
Perhaps I can shed some light. Manifold Creator Core is our name for our specific implementation of the ERC721 & ERC1155 standards. Like lyndon showed above, you can deploy a Creator Contract through studio, which will be 1 instance of the creator core, owned by you alone.
“Cheaper” is a relative term. What we mean by it is that our contract is split: the core, which is deployed one time by Manifold, contains a bulky library of functionality. The proxy, deployed by each creator, is your contract. It controls your tokens, and manifold can’t touch them. This arrangement is cheaper than preexisting contracts, which had every user deploy all the code every time.
To deploy on testnet, just go to the top-right corner of studio and switch to your workspace named “Testnet”:
I’m a little confused by the wording here, are you saying you’re a Solidity developer working for a client?
If so, maybe you could tell me a little more about what you’re trying to do with your extension? I doubt that you want to use mint over mintExtension. mint is designed to allow the creator to mint tokens manually; whereas mintExtension allows an extension contract to mint and control tokens on the contract, for example managing their tokenUri method.
If you want examples alongside our extension documentation, check out: GitHub - manifoldxyz/creator-core-extensions-solidity: A library of example Apps (Extensions) for use with Manifold Creator Core smart contracts.
Thanks for getting back to me.
Yes Im a solidity dev and our client has tasked us with making 2 contracts, an ERC721 and ERC1155, which will have a mint(address to). They will then hook these 2 contracts into one of their own, which will have some logic to allow users to mint the NFT’s, which is out of the scope. So the mint interface has to look like this so it works with their contracts.
Currently I’ve made two contracts extending the Creators of the ERC721 and 1155, which work fine. But if I can deploy a proxy (rather than the 23kb contracts I have) and make an extension which will have a mint function like
function mint(address to) adminRequired {
mintExtension(to);
}
I assume that would work as well and deployments would be cheaper. Just not sure how much cheaper and if its worth it. For ERC721 the core would have to have enumerable logic, is that possible to do from studio?
Ok, interesting!
It would only be possible to answer “how much cheaper” by writing your whole system of contracts and deploying to an EVM chain and then comparing the total gas used in both cases. That’s a case where I would use a testnet and then multiply gasUsed by current gas price to get a real price.
I’m not really sure what you mean by “enumerable logic”, can you clarify?
In addition to our example extensions, the creator core source code is also available here: GitHub - manifoldxyz/creator-core-solidity
What you’re describing sounds possible, but the only way to know for sure is to try and build it!
By enumerable logic I mean there are two distinct contracts in the repo:
ERC721Creator and ERC721CreatorEnumerable.
I would require the deployed proxy contract to be of the latter as I require incremental tokenId’s.