> 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/security-and-compliance/risks.md). # Risks Known risks - Items marked Caution can cause loss of funds; items marked Note describe accepted design behavior you should be aware of. #### For users **1. Owner key compromise** - Caution The protocol has an admin key that controls relayer and token allowlists; if it were stolen, the attacker could change who is allowed to operate the protocol. 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. Token contract blacklisting Hinkal** - Note Some tokens (USDC, USDT, and others) can block specific addresses, and Hinkal's contract is an address like any other. 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 inside the protocol. **3. Direct transfers to the contract** - Caution Hinkal only knows about funds that arrive through its own methods; a plain wallet-to-contract transfer creates no commitment, so nothing can ever claim it. 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. Malicious tokens** - Caution A token contract can behave arbitrarily on transfer - reverting, taxing, or blocking - and Hinkal cannot fix a token that refuses to move. 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 those funds. **5. Reverted transactions after access-token blacklisting** - Note Compliance screening can temporarily flag an access token; a revert in that case is the protocol working as intended, not a lost transaction. 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. Forged `encryptedOutputs`** - Caution The encrypted payload attached to a transaction is written by the sender and is not verified by the contract, so a dishonest sender can make it say whatever they want. An adversarial user participating in the Hinkal protocol may attach UTXOs in the `encryptedOutputs` field of the transaction that are not the ones that should be there (amount/owner fields may be changed). This could trick another user into thinking they have received tokens. When a sender sends tokens, always check the transaction in the Statistics tab of the application to verify the correct amount and token were sent. **7. Native tokens sent without a slot** - Caution `transact()` accounts for ETH only if the call explicitly declares it; value sent without that declaration is received but never credited. 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. Reentrancy ordering** - Note External calls happen before the spent notes are marked as spent, which is the pattern reentrancy guards exist for. During `transact()`, external actions execute before the transaction's nullifiers are recorded, so reentrancy protection currently depends on the `nonReentrant` modifier. **9. Zero as a Merkle path sentinel** - Note The circuit reuses the value zero to mean "no more levels," which would only be a problem if a real hash happened to equal zero. 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. Emporium contract** - Note Emporium executes operations supplied by whoever calls it, so anything it owns or is allowed to do is effectively available to any caller. The 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 **11. Relayer address requirements** A relayer is a plain wallet that fronts gas and submits transactions; mixing it with other activity or using a contract breaks assumptions the protocol makes about it. Relayers are Ethereum addresses that post transactions to Hinkal on the user's behalf for an incentive. Relayers cannot be smart contracts. The address used for relaying Hinkal transactions should be used exclusively for that purpose.