Scenario
My Smart contract (SM-A) can be used only if you own a specific NFT created and managed by another contract (SM-B).
If so, it stores additional information inside a mapping property :
msg.sender address
account name
and other properties to cover the SM-A business requirements.
Constraints
I'm the owner of SM-A.
I'm NOT the owner of SM-B and I don't have chance to change anything about it.
Questions
Is there a way for having information if and when the msg.sender sells his NFT from SM-B in order to remove his data from my mapping property stored in SM-A?
If so, how it works the cost of the delete transaction operation?
Will my contract pay for it?
Related
I have to develop an NFT minting contract with a whitelist system where we can set a variable amount of mint allowance per address.
It would be easy to achieve by setting manually in the contract with something like:
mapping(address => uint) allowancePerAddress
But as it's on Ethereum this solution would not be very cost efficient as we would need to store a couple hundreds of entries manually.
Is there another way, through signature for example to achieve this so it would be cost efficient for both the project and the minter ?
Signatures serve for checking the integrity of a message and also validate the emitter of the message, so Im not sure how would you accomplish using signatures, mainly because you'll need to set a value for each address, and keep track of them in the contract.
What you can do is create a constant that would be the default allowance, and when someone mints their first token you can update their allowance value during that transaction.
Yet, if what you want is to set up a custom value for each address, and you have a high amount of them, you can either do it on deploy, on the constructor or create a function that receives an array of Struct {address, allowance}, and set every address on a loop.
I am planning to issue erc20 token on ethereum and I want to use it as a payment for dapps on polygon.
How may I estublish the interaction between the contracts? A potential answer to that question might be bridging. But I tried to look for every platform to understand, how can I use my coin tokens after bridging, but failed to find any definite answer.
so my question is, if two contracts are on the same chain-
IERC20 token = IERC20(some_address);
We use the above line to call our coin token from our dapp. Since, our coin token is on different ethereum chain, after bridging, how do we call it feom a contract that will be deployed on polygon?
Will the above line of code work? Will I get a new address on polygon for my token contract?
(Recently I have seen a technique, but couldn't understand the underlying mechanism. So, there is a website called Coinvise, they let you deploy your coin airdrop contract on polygon and let you set the nft address (to know if user holds that particular nft) as eligibility condition that is deployed on ethereum. They do it on chain using something called 'sub-graph'. I do not know what this is but I'd like to know if it helps in my case.)
I am new to blockchain, please help
Most NFT code are more or like similar, so every time I want to create a new type/genre for an NFT I would have to upload a new Contract? Can't I just create just one contract with a property like edition/series/season/etc.. to manage every foreseen type is that possible or will it interfere with markets/rules or something.? Any Ideas how to manage a thing like that?
Thanks
You can handle this with the ERC1155 multi token standard, it is one contract that can manage both fungible and non fungible tokens in one single deploy
If you are using the ERC-721 standard, what is the prefer method determining which tokens the address owns in a DAPP.
Currently I'm request all the Transfer Events for an address and basically sorting them into transfer in and transfer out, and then using that to determine which tokens the user owns.
Is there a simpler way I missed.
Transfer events may be emitted also by contracts that are not ERC-721 tokens, or some noname tokens that you might not be interested in.
The actual token ownership is stored in the tokens contracts (and not the DAPP contract).
So your current approach is pretty much as straightforward as it can get, if you want to automatically keep track of all tokens that the address currently owns (and some false positives as well).
Note: This is also similar to the approach of Etherscan, which listens to all Transfer event logs and if the sender contract is listed in their database of tokens, they use the event log data to update balances of the sender and recipient.
If you're willing/able to create and maintain a list of tokens that you want to follow, I'd recommend a simpler approach:
Define the list of followed token contract addresses (e.g. ECF or RARI)
For each of these token contracts, call balanceOf(<your_dapp_address>) that returns amount of tokens that the <your_dapp_address> currently owns.
In a DAML contract, what does the signatory keyword do? For example, in the Iou contract, what does the line signatory issuer, owner actually mean?
Does it mean both owner and issuer should be same?
One of the compelling features of DAML as a modeling language is that it is designed to help solve problems involving authorization and delegation. To achieve this DAML has a first class type Party that represents independent ledger participants, and every contract on the ledger must be authorized by one or more parties before it can be created.
The signatory expression in a template defines who must authorize the creation of a contract instance of this template. It does so in terms of the data contained within the proposed contract instance — this means that any party who can see a transaction that attempts to create a contract also has enough data to verify the creation was properly authorized.
In the case of the Iou contract:
template Iou
with
issuer : Party
owner : Party
currency : Text
amount : Decimal
observers : [Party]
where
signatory issuer, owner
...
A party wishing to create an Iou must fill in the record: issuer, owner, currency, etc. Then they must pass that record to the create function within a transaction submitted to the ledger. That call to create must be authorized by issuer and owner, but does not require authorization by observers as they are not listed as a signatory.
Note that it is legal for issuer and owner to be the same party. In fact, this would be the only way for the create to be legally submitted directly to the ledger as individual ledger interactions can only be authorized by a single party. Larger authorization sets must occur as a part of a larger transaction using delegated authority from other contracts already on the ledger.
For more on this, and especially on how to do authority delegation, see the DAML documentation: https://docs.daml.com/concepts/ledger-model/ledger-structure.html
For a worked example, see: https://docs.daml.com/daml/patterns/initaccept.html and the other examples in the Patterns section of the DAML docs.