> For the complete documentation index, see [llms.txt](https://hinkal-team.gitbook.io/hinkal/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hinkal-team.gitbook.io/hinkal/technical-description/risks.md).

# Risks

**For Users:**

1. **Caution**: If a malicious user gains access to the private owner key, they may be able to perform malicious actions, including removing legitimate relayers, adding malicious relayers to the protocol, and disallowing the further use of any token within the protocol.
2. Like with any smart contract, there is a risk that a token contract blacklists Hinkal from using their token. In this case, users will not be able to deposit that token to Hinkal anymore. Furthermore, the token amounts already inside Hinkal would end up locked up inside protocol.
3. **Caution**: Please do not send direct transactions to Hinkal. All funds should be sent via transact methods. Any funds that are sent directly will be permanently lost.
4. **Caution**: Please always be careful to send trusted coins to Hinkal. Use of malicious coins with Hinkal may cause problems including users not being able to withdraw their balance of malicious funds.
5. **Note**: Sometimes in case an access token is blacklisted, your transactions may be reverted. This is a normal part of the process and reverted transactions can be safely posted again, once the access token is whitelisted, without any problem resulting from it.
6. **Caution**: An adversarial user that is participating in the Hinkal Protocol may attach UTXOs in the `encryptedOutputs` field of the transaction that are not the ones that supposedly should be (amount/owner fields may be changed). It could trick another user into thinking that he has sent him some tokens. Once a sender sends tokens, always check a transaction in Statistics tab of the application to verify correct amount and token was sent.
7. **Caution**: When calling transact(), do not send native tokens through msg.value unless erc20TokenAddresses contains address(0). If no native-token slot is included, the value is not accounted for and may become permanently locked in the Hinkal contract.
8. **Note**: During transact(), external actions execute before the transaction’s nullifiers are recorded, so reentrancy protection currently depends on the nonReentrant modifier.
9. **Note**: The circuit uses a zero value to mark unused Merkle path levels, enabling proofs over variable-depth paths. Since all real path values are Poseidon hash outputs, the probability of one being exactly zero is negligible. This is a known and accepted part of the design, and no practical attack can result from it.
10. **Note**: Emporium Contract is designed to be stateless and must never hold tokens, native currency, persistent allowances, roles, or other authority. Do not transfer assets to Emporium or grant it permissions, because its execution flow may perform caller-supplied operations and any value or authority associated with its address could be exposed.

**For Relayers:**

1. Relayers are Ethereum addresses that post transactions to Hinkal on the user’s behalf for some incentive. Please note that Relayers cannot be Smart Contracts. The address used for relaying Hinkal transactions should be used exclusively for that purpose.