The Chainlink VRF documentation section is a bit meager as of today, I was wondering whether there is any merit for smart contract developers to allow for Chainlink VRF consumer contracts configuration parameters to change in the future, such as the LINK fee (due to the VRF oracle).
P.S. I was asked by the Chainlink team to turn this doubt into a stackoverflow thread
parameters like VRFCoordinator contract and public key of the VRF node won't change often, if at all with the current version of VRF.
Take note though that in an upcoming improved version, there will be more flexibility, which will include dynamic VRF costs based on gas in the response etc
Related
I know that VRFCoordinatorV2Interface is an interface and we put the respective chain coordinator address in it. what does it signifies and how to visualise it.
OR
What will be the outcome when we put an address in a interface.
The Chainlink VRF Coordinator is a contract that is deployed to a blockchain that will check the randomness of each random number returned from a random node.
By putting "its address in an interface" you can programmatically interact with it from your smart contract. In other words, the function of your smart contract can call some other function from the VRF Coordinator function, like for example createSubscription().
I have developed smart contract running on Cronos Chain.
But while testing in bsc test net, Possible to generate random using chainlink oracle.
But to test on cronos chain, I didn't find VRF coordinator address.
I found chain link token address in Cronos chain. But others like VRF coordinator address, hash, fee, I couldn't find.
Please reply if you have experience with this.
I want to know if there's a concept similar to Meta-transactions in Substrate.
"A meta transaction is a regular Ethereum transaction which contains another transaction, the actual transaction. The actual transaction is signed by a user and then sent to an operator or something similar, no gas and blockchain interaction required. The operator takes this signed transaction and submits it to the blockchain paying for the fees himself." 2
You can learn further about meta-transactions in Ethereum from these articles:
Ethereum Meta-Transactions 101
How to implement generalized Meta-transactions?
I want to implement a substrate pallet where I can airdrop certain amount of tokens native to the substrate blockchain and let users with 0 balance claim according to their interaction with some other protocols built on other blockchains.
I researched some feeless mechanisms in Substrate and built a feeless pallet inspired from tutorials by Shawn tabrizi so that my pallet could send balance to users for a certain transaction. But I don't see how I can best implement this mechanism without risking a sybil attack on the blockchain. In ethereum, due to the concept of meta-transactions, it's pretty easy to onboard new users to a certain protocol. What's a possible equivalent case in Substrate for onboarding non-substrate users to a new substrate blockchain?
How would one go about building an escrow and multisig contract on NEAR?
E.g. in comparison to building the contract in Solidity; what would be needed, are there any examples?
I can't compare this for solidity. But on NEAR multisig contract can be implemented either using multiple AccessKeys or using multiple predecessors.
The following steps are needed:
Propose an action e.g. transfer X to Y to the contract by calling propose() on the contract. This should return a proposal_id
Aggregate approvals for the proposal_id using approve() or reject() calls.
Once necessary amount of approvals are collected. A caller can call issue and pass the proposal_id, it will issue the action and close the proposal.
Seems there are two questions here, for escrow and multisig. Evgeny has taken on the multisig part.
We do have a simple example of escrow on NEAR written in Rust.
This example has no frontend but provides the lower-level CLI commands needed to show an escrow in use.
https://examples.nearprotocol.com/rust-fungible-token
There is an example of multisig contract now here written in Rust - https://github.com/near/core-contracts/tree/master/multisig
The main benefit and why it becomes way simpler, is that NEAR Accounts already maintain set of keys per account. Contract just needs to manage the requests and execute them when enough confirmation have been received.
I've looked at this question, which didn't have a suitable answer (basically recommends tokenisation). I'm intrigued as to why the fields for delivery address are mandatory as I'm assuming this isn't validated against. The billing address makes sense as this will be the address linked to the card and therefore worth validating. However, the delivery address presumably provides very little.
I can see that it's provided in the response from SagePay in relation to PayPal payments, presumably to check whether this has been altered when getting to PayPal, but as PayPal payments are optional, then if this is the only reason surely it too should be optional?
The reason I ask is that when providing a service rather than a tangible physical product, what should go in this? I'm assuming in most cases this would simply be the same as the billing address, but in the scenario that a 3rd party pays for the service, should the delivery address now be the address of the person receiving the service?
Fraud screening. Sage Pay send all of that stuff to a third party, which then provides a fraud score.
Some of the criteria for that fraud score are based around delivery (known dodgy addresses, business rather than residential, delivery address doesn't match billing etc).
You can just submit billing addresses - you may have to tune your approach towards fraud scores accordingly.