I understand how to create multisig accounts as specified in the below documentation but am not sure how this works in practice. Suppose I have a partner, we both create a new keypair, and we both need to sign a transaction. The point is that I don't know his keypair and he doesnt know mine.
So how do you setup a process where we both sign a transaction from different computers neither knows the other's keypair info?
https://spl.solana.com/token
For a multisig allowing for transaction signatures from unconnected computers, you'll want to check out the Serum multisig example program: https://github.com/project-serum/multisig
As you've noticed, the native multisig functionality in the SPL token program is limited in this domain.
a bit late to this thread but wanted to share our latest solana multisig product here, in case you might find it useful. as Jon C mentioned, serum multisig and SPL token program are both great options and have been well adopted within the ecosystem. SPL token is more suited to DAO governance use case.
Snowflake Safe is gearing towards teams and secure individuals with a little more focus on the UX side.
DAPP : https://safe.snowflake.so
SDK : https://github.com/snowflake-so/snowflake-safe-sdk
Related
I have been using the spl-token whitelist based approach via the the CLI with Candy Machine V2 up to this point. Sending WL users a token that is registered as the WL token in the Candy Machine config. This route has been ok but I would like to switch to a wallet based approach where wallet addresses are detected automatically without the need to send out tokens. I have been looking online for some documentation / notes on how this can be done but haven't been able to find much (might just be looking for the wrong thing). Is this possible to set up with Candy Machine V2? If possible, does anyone know of some good resources I can check out that could help me get this done? I would need the ability to set up multiple whitelists.
Any help is appreciated!
You can do wallet based whitelisting with candy machine v2 together with gumdrop.
You would have to use claim-integration candy and distribution-method wallets. This will allow the given wallet to claim the wl token and since you are using claim integration candy will directly build the mint transaction, too. Therefore the user will only have to confirm one tx and would only see the wl token if the second transaction fails.
This is closest to what you can get to wallet based whitelisting with cm v2.
Keep in mind though that by default you have to give every user a personal claim link which contains a merkle proof that allows them to claim. Either use a discord bot where they can pull their claim link or modify the frontend to include the proofs and automatically fill it there.
Its not possible to set up a Wallet-based whitelist using the deployed CandyMachineV2 Program. The only way of having this feature is grabbing the CMv2 program and update it to allow Wallet Whitelist instead of SPL-Token whitelist, then deploy your new CMv2 and use that new program ID in ur mint page and ur CLI to create and update the CandyMachine
I need to know which instuctions list is used for a transaction in order to use it in my application.
For example:
There is an unknown NFT marketplace, I can buy NFT through the "Buy" button in the browser.
I want to buy these nft programmatically, not through the browser.
To do this, I need to know all the instructions and transactions.
And in general, can I buy NFTs if the marketplace does not use CandyMachine, MagicEden, etc.?
Each marketplace/platform has a different way of managing transactions.
If you are interested in how transactions are put together and want to start building an understanding of the ecosystem, you have two options:
pick an open source repo (on Metaplex on you have auction house / storefront / fixed price listing / candy machine at least ). Some of these will have template UIs as well that you can customise to suit your needs. They come with several examples of transactions so that you can learn to build them from ground up.
Pick a proprietary framework (like Magic Eden), and interact with them via their API. You will not be building the transactions yourself in this case. In the case of Magic Eden, they build the transaction instructions serverside and serve them over their instructions API. You will not know (nor would you necessarily need to know) how the transactions are put together, as they've handled the abstractions for you.
Some examples of different NFT frameworks in the solana space:
Metaplex Auction Manager (open source) + Storefront UI. Useful for learning about how transactions are created, but probably unwise to start building a long-term solution on top this. Also Storefront UI is in places quite complex but as long as you just focus on the transactions and how they are generated, it's a useful pedagogical tool.
Metaplex Auction House (open source) is intended as a replacement for Auction Manager framework. Like the Auction Manager, Auction House is open source and there are multiple examples of how to use it in metaplex repos.
Metaplex Fixed Price (open source) is another listing framework with its own set of contracts. Again repos are available on metaplex github.
Magic Eden (proprietary) expose their transactions via an API, which gives you serialized transaction. You can use the transactions generated by their API in your application, but because ME is not open source, you will not be able to generate the transactions from scratch.
The above are just examples. However, the one thing they all share is that they use Metaplex standard for expressing their mint metadata. The way ownership is expressed via TokenAccounts is also standard across all, which means that as long as you hold NFts in your wallet, you will be able to list them in any of the above.
In addition to the above, Metaplex discord is also a useful source of information with a friendly community, but please check the growing SO knowledge base first.
I am a little confused about the workflow of NFT's on the Solana blockchain. I come from Ethereum and everything there is very clear. There is a smart contract that is executed on the blockchain which requires a specific amount of Ether to accept and you send the transaction out to the mempool to be picked up by a miner.
On Solana from what I've gathered is, the NFT creator creates a token using SPL that gives them an ID. Then someone else can create an account under one of their wallets to accept that specific type of token that was created. Then that person can use that account to mint the NFT using the ID we got earlier. Is that all correct?
If someone could please clear up the some of the things below it would be greatly appreciated.
Where does Candy Machine come into play here?
What's the difference between the Mint Authority and the Update Authority?
Does a collection need to run the spl create-token command for every single token?
The Candy Machine by Metaplex (https://github.com/metaplex-foundation/metaplex) is the standard smart contract (actually known as programs in Solana) being used at the moment for minting NFTs in the Solana ecosystem.
It abstracts away from all the details you have described so people can simply clone and deploy the repo more or less rather than write your own contracts as in Eth.
An NFT in Solana is an SPL token with a metadata struct set to the Metaplex standard (i.e. a URI on-chain pointing to more metadata off-chain). This is the current agreed-upon standard for NFTs on Solana.
You are also right in saying Solana SPL tokens require an account to be created to "receive" NFTs or mint them as well. A new account will be created for each NFT. This is handled by the Candy Machine as well as the SPL token program built into Solana itself, so normally you don't have to deal with this unless writing your own contracts possibly. Check Solana docs / Anchor framework docs for more info on programming on Solana.
I am using the Google Client Library for Java SDK in my Android app to interface with Google Drive.
Do Google act as a Data Controller or Data Processor by using this SDK? I need to know if I need to store any data to show the user has consented to my app interfacing with Google Drive in line with GDPR.
I know I need to ask permission for personalised or non-personalised ads but the Google Drive SDK and GDPR stuff is driving me crazy.
Thanks
Disclaimer I am not a legal type person this is my opinion from the guidelines that we have been given. You should also seek independent legal advice relating to your status and obligations under the GDPR, as only a lawyer can provide you with legal advice specifcally tailored to your situation.
For refrence I am going to quote from the following documents which as of my writing are the only thing Google has released with regard to GDPR that i am aware of ath this time
Google Cloud & the General Data Protection Regulation
GOOGLE CLOUD & THE GDPR WHITEPAPER
Google Cloud & the General Data Protection Regulation (GDPR)
G Suite1
and Google Cloud Platform customers will typically act as
the data controller for any personal data they provide to Google in
connection with their use of Google’s services. The data controller
determines the purposes and means of processing personal data,
while the data processor processes data on behalf of the data
controller. Google is a data processor and processes personal data
on behalf of the data controller when the controller is using G Suite
or Google Cloud Platform.
Data controllers are responsible for implementing appropriate
technical and organisational measures to ensure and demonstrate
that any data processing is performed in compliance with the GDPR.
Controllers’ obligations relate to principles such as lawfulness,
fairness and transparency, purpose limitation, data minimisation,
and accuracy, as well as fulfilling data subjects’ rights with respect
to their data.
If you are a data controller, you may find guidance related to your
responsibilities under GDPR by regularly checking the website of
your national or lead data protection authority under the GDPR (as
applicable)2, as well as by reviewing publications by data privacy
associations such as the International Association of Privacy
Professionals (IAPP).
You should also seek independent legal advice relating to your status
and obligations under the GDPR, as only a lawyer can provide you with
legal advice specifcally tailored to your situation. Please bear in mind
that nothing on this website is intended to provide you with, or should
be used as a substitute for legal advice.
Gsuite is Googles sweet of tools that being Drive, Calendar ... they are the data controller for the data behind the Google tools.
Controller vs. Processor
(7) ‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;
(8) ‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;
IMO
If you are accessing a users data on Google Drive and changing it or doing anything with it then yes you are going to need to tell them what you are using their data for and log their consent. If you are saving their data anywhere then you are also going to have to give them the ability to delete that data.
There are some things you cant do for example if they want to delete all their files on drive thats not your responsibility that's Googles. You are only responsible for the data thats on your system and what you have done with it.
Using googles client library IMO doesn't have much to do with GDPR its what you are doing with the data that they return that matters. I did contact google a few months ago hoping to get some official guidelines with regard to GDPR and the client libraries. I have not heard anything as of yet.
I understand how NFC is supposed to work on a high level, and a bit about the protocols used. Now, I need to understand, with your help, if there are any standards related to mobile payments.
From a trusted service manager perpective, I believe there are no standards at all and that both the machine on the point of sale and the app on the mobile device would have to be custom made correct?
If no such standards exist yet, can I assume it can be as "simple" as:
On contact the machine creates a checkout receipt and sends it to the device (this would have to be done with customized hardware)
The device receives the receipt and uses the UICC to authenticate itself with the bank/TSM
The bank, upon validation, signs the receipt which is forwarded to the machine by the device
Am I getting this right? If there are any technical bits I'm missing, please refer them so I can research.
Thanks
sure there are standards - see EMV (Europay, Mastercard, Visa). It is necessary for world wide interoperability of the payments systems, which uses the chip (aka secure element), no matter they are contact or contactless (i.e. NFC).
EMV specifies used hardware, protocols, file structures and used commands, data authentication, PIN ciphering, key management. It is pretty complicated.
I think you can start here: http://en.wikipedia.org/wiki/EMV
Regards,
STeN
www.mautilus.com
As said before, EMVCo standards will cover some of your need, but so will also GlobalPlatform underlying technology, as well as some further refinements of AEPM.
I'll also add once you obtain the information you need from the payment card, you have to send it to a payment gateway which then transfers the information to the payment network (Visa, MasterCard, etc.) where the data will then be routed to the issuer of the card for authorization. The response is then sent all the way back through the chain to the initiator of the transaction. Triangle has a free API that captures the card information for you. You can then use the captured information and route it to your gateway.
Disclaimer: I'm the co-founder of Triangle.