metamaskproxy-contractsSecuritysolidity
I was looking at the recent FE badger DAO exploit and this Twitter thread in it https://twitter.com/CryptoCatVC/status/1466380960648380419?s=20
One piece of advice the author gives before signing a metamask transaction is to inspect the etherscan address of the contract and see if it is a proxy contract.
What exactly is a proxy contract?
How does one check if a contract is a proxy contract?
What are the risks involved with interacting with a proxy contract?
But the question here is, technically, what exactly are we signing away when we approve a collection contract for listing and trading on OpenSea? Approving "All of your NFT" sounds like anything that we own from a specific collection can just be taken out of our wallet without asking us for a MetaMask signature, even though we came to it only to list a NFT for sale.
This is exactly it. You're allowing an address (Usually a smart contract, but nothing prevents you from approving a user, which could then transfer your NFTs out of your wallet as it if was theirs) to spend all your tokens from a specific collection.
Please provide a list of what ApproveForAll() actually encompasses in terms of potential events, versus the specific event (e.g. list the NFT for sale) we might have come to use it for.
Well if you're interacting with a smart contract that isnt malicious, and is well designed, the answer is : nothing. Let me explain. While you are actually giving permission to that contract to do literally anything with your tokens, it cannot do anything it hasnt been programmed to do.
Let's take this very simple example contract :
contract TransferNFT {
function makeTransfer(address collection, address to, uint tokenId) public {
IERC721(collection).transferFrom(msg.sender, to, tokenId);
}
}
While, by calling setApprovalForAll(myContractAddress) on an NFT contract (let's say, BAYC), you're allowing my contract to transfer all of your BAYC tokens, to any address, the only situation where it would actually be able to transfer your tokens would be when you're calling makeTransfer(), only from the wallet that holds the tokens, only to the address you specified as input, and only the token you specified. (in the case of OS, it's a bit more complex obviously, they ask you for approval when you list your token so they can transfer it later when the sale is fulfilled, but it's the exact same idea)
In other words, it is perfectly safe. So safe that most dApps asks you to set approval for all of your tokens from a collection eventhough you're trying to list/transfer only one of them instead of asking you for only the one token you want to move, just to avoid asking you again for approval if you want to move more of these tokens with that smart contract in the future.
Now, if you're setting approval to a malicious address, well you just allowed them to transfer all of your tokens on your behalf, so that's what they're usually gonna do. And as soon as they do that, your tokens are gone and you'll never see them again.
And is there any situation where the prompt would instead read "Give permission to access all of your funds"?
Nop, that can't happen. 1 setApprovalForAll transaction = approving all of the tokens from ONE collection, to ONE address only.
ERC20 has a similar mechanism, btw. That's why you have to make an approval transaction when you're swapping tokens on a DEX for the first time, for example.
In a smart contract security audit, or "smart contract audit" for short, usually a third party reads through the code written by the project smart contract developers and they look out for security vulnerabilities. This is somewhat different from the traditional IT security audits and penetration testing because a good smart contract auditor must possess a great deal of domain-specific knowledge not just about coding, but finance and cryptocurrency ecosystem as well.
Because the industry is new, there are not yet best practices for auditors or what the client or the investors should expect. The industry is developing so fast, so setting any technical standards today might be outdated tomorrow.
The quality of auditors and audits varies greatly. For the sake of this answer being neutral, I do not want to name any auditors or services. You can find these easily if you want to check if any auditor is legit and worth of their asking price.
Usually an audit happens "before deployment" e.g. before smart contracts go live and touch real money.
Smart contract auditor is hired by any protocol or other smart contract developer: token issuer, DeFi protocol, NFT project.
The project hires the auditor. Depending on the bull/bear market cycle and the brand value of the auditor, the auditing cost can be anything between $500/day to $10,000 day.
Note that audits are rarely "independent". There are some exceptions, like audits done by venture capital funds that look to invest in a project. But those are not usually called "smart contract audits". More about this below.
In high-quality audits, the person who performs the actual audit is named in the audit report. In low-quality audits this often is not the case, because the person do not want any personal responsibility for the shoddy quality of work.
For the audit itself, the auditor checks the smart contracts with free linting and static analysis tools and also reads the code through to find any bugs in the logic.
The smart contract audit is not a guarantee of a security. In a proper audit, the purpose of the auditor is to give guidance and verbal feedback to developers how to make it more secure.
A smart contract audit should not be used as a marketing material. If any project does this, it is usually a red flag about the motives of the project.
Unlike in traditional finance and accounting audits, on public blockchains any investor or a third party can assess the risk themselves. Any smart contract source code is public, so any auditor does not need privileged access to see if there could be vulnerabilities. For a true public protocol, any flow of money is 100% transparent. Thus, any investor is able to assess the risk themselves or ask someone to do it on their behalf.
For high-quality projects, so-called bug bounty programs or audit contents are run where white hack hackers are rewarded high sums of money for finding bugs in already deployed smart contracts.
Auditors rarely take any liability for the quality of work ("skin in the game"). There are some exceptions like the Sherlock protocol where auditors are only fully paid if there is no exploit over the course of the full life cycle of a project.
Centralised exchanges, like Binance, KuCoin, Gate.io and others ask for an audit for any ERC-20 token they list. This is mostly to ensure the free-form ERC-20 contracts do not have functions to remove tokens from exchange reserves (i.e. not backdoored). Some other exchanges like Coinbase perform their own audits.
Note that like in accounting audits, from the investor perspective, there is usually a conflict of interest between the auditor and their client, the project. Auditors do not work for investors. This is especially true when a smart contract audit report is publicly used as marketing material, The auditor is getting paid by the client, not the external users of the protocol or smart contracts. Thus, any audit, especially one from low-quality auditors, can be seen as biased. Audits never directly says if a project is a scam, because the auditor would not be paid in this case.
An audit does not fix any bad development process or low-quality software engineers.
Here is a good presentation by Corey Petty what a smart contract project should have in order before asking for an audit.
The Ultimate 100+ Point Checklist Before Sending Your Smart Contract for Audit
What do smart contract auditors look for while doing a smart contract audit
Disclaimer: I did some of the early audits for Ethereum smart contracts back in 2016-2017.
Best Answer
A proxy contract is a contract which delegates calls to another contract. To interact with the actual contract you have to go through the proxy, and the proxy knows which contract to delegate the call to (the target).
A proxy pattern is used when you want upgradability for your contracts. This way the proxy contract stays immutable, but you can deploy a new contract behind the proxy contract - simply change the target address inside the proxy contract.
Therefore it's a bit dangerous to use a proxy contract, since there are no guarantees that the underlying (target) contract hasn't been changed to a malicious one. There is no strict definition on how to detect a proxy contract, but basically it's anything that delegates the functionality to another contract. You have to analyze the source code to be able to decide.