Custodial and smart-contract casinos: who controls deposited funds?

Short answer

Follow the signing authority, not the marketing label

Custody asks who can authorise movement of an asset. If a casino gives a deposit address, receives the transfer and credits numbers in a user account, control has usually moved to the operator or its payment processor. The balance is a contractual claim recorded in a private ledger. The player cannot broadcast a withdrawal from that address; the player asks the operator to do it.

A smart contract changes the possible control structure. Assets can sit at a public contract address and move according to code. Yet the relevant question is still authority. An owner, upgrade administrator, emergency pauser, multisig group or oracle may influence execution. A web interface can also point a wallet toward a different address from the one previously reviewed.

Self-custody means the user controls the signing key or account recovery rules. Ethereum.org explains that a wallet is a tool for interacting with an account; it does not hold the funds like a physical wallet. Whoever controls the relevant private key or smart-account authorisation controls transaction signing.

These models are not a simple safe/unsafe ranking. Custody can make account recovery and support easier but creates counterparty and withdrawal risk. Self-custody removes some operator control but transfers key, signature and approval risk to the user. Smart contracts can make rules inspectable while introducing code and governance risk.

Vocabulary

Wallet, address, key, ledger and contract are different objects

An address is a public destination used to identify an account or contract on a blockchain. It is not proof of ownership. Anyone can copy an address; only the valid signing authority can normally initiate transactions from an externally owned account.

A private key authorises transactions for a conventional account. A recovery phrase may derive several keys and therefore requires equivalent protection. A wallet application helps create, store or use those credentials. The application interface should not be confused with the blockchain account itself.

An internal casino ledger is a private database of customer balances and events. A blockchain explorer cannot normally show how one omnibus wallet is allocated between users. The operator can move on-chain assets while separately updating ledger liabilities.

A smart contract is a program running on Ethereum. Ethereum.org notes that contracts are accounts controlled by code and can hold assets. But contract code can refer to other contracts and can expose privileged functions, so the main address alone may not describe the whole system.

“Non-custodial” should therefore be a testable claim: can the user move the asset without an operator approving a withdrawal, and can another party change or block that ability? If the answer is unclear, describe the model as unverified rather than adopting the label.

Hosted account model

A deposit normally becomes operator-controlled after confirmation

In a common casino flow, the cashier generates an address or memo for one account and one network. The player signs a blockchain transaction from an external wallet. After the required confirmations, the casino credits an internal balance. The original asset may remain at that address, be swept to an omnibus wallet or pass through a processor.

Once sent, the player does not possess the receiving private key. A password, two-factor code and account login authenticate a request to the casino; they do not sign from the receiving blockchain address. The operator controls whether and when an outward transaction is broadcast.

This model creates a claim against the operator. The claim is governed by account terms, identity checks, bonus rules, transaction monitoring, withdrawal limits and solvency. A visible blockchain deposit proves value reached an address. It does not prove that the site keeps one-to-one reserves or segregates each customer's coins.

Processors can add another custody layer. A payment service may generate the address, convert assets or forward settlement to the casino. Identify the contracting casino company and any named processor; do not assume the brand alone holds the keys.

Off-chain accounting

The displayed casino balance is usually not an on-chain wallet balance

An internal balance can change instantly after a wager because no blockchain transaction is needed for each game round. The casino records stakes, wins, bonuses and adjustments in its own database. This speed is a clue to the model, not evidence of dishonesty.

The number displayed can also be denominated differently from the deposited asset. A site might show a fiat-equivalent value while holding cryptocurrency, or convert at deposit. Terms should explain when exchange rates are fixed, who bears conversion movement and which asset is returned.

A block explorer cannot reconcile the internal ledger without additional proof. One wallet can contain funds attributable to many customers plus operator capital. A published address balance is not complete proof of reserves unless liabilities, ownership and methodology are also verified.

Account restrictions can affect the ledger even when on-chain funds exist. A site may freeze a balance during KYC, source-of-funds review, bonus investigation or territorial check. Those powers belong in the operator review, while custody explains why the operator can exercise them.

From request to transaction

A withdrawal approval is separate from blockchain settlement

A custodial withdrawal begins as an account instruction. The operator checks balance, eligibility, wagering conditions, identity, address format, network and internal risk rules. Only after approval does the operator or processor sign and broadcast an on-chain transfer.

“Pending” can therefore refer to internal review before a transaction exists. Once a transaction ID is supplied, the blockchain stage can be checked independently for sender, recipient, asset, amount, fees and confirmations. Do not call an internal reference number a transaction hash.

Limits may apply per transaction, day, week or account tier. Network fees can be fixed by the operator or based on current chain costs. The game maximum win is a different cap: it describes game settlement, not how quickly the account balance can leave the platform.

A withdrawal to the wrong network or incompatible contract can be irreversible. Confirm the exact asset and chain, use a fresh trusted address, and compare the first and last characters on the signing device. This is operational safety, not encouragement to deposit or gamble.

User-controlled authority

Self-custody moves responsibility to keys and recovery rules

With a conventional self-custody account, the user controls the private key and signs transactions locally. A wallet provider can supply software without being able to move the assets. Ethereum.org's wallet directory explicitly tracks self-custody as a feature, showing why “wallet” alone is not enough.

Smart-account wallets can use programmable authorisation such as multisignature or social recovery. In that case, custody is determined by the account's validation logic and recovery roles rather than one private key. Read who can replace signers, delay recovery or freeze actions.

Self-custody does not mean risk-free. Lost credentials, malicious signatures, compromised devices and wrong-address transfers can cause irreversible loss. Support cannot reset a blockchain private key in the way a casino can reset a login password.

A casino interaction can begin in self-custody and end in custody. Connecting a wallet proves control of an address; sending assets into an operator wallet still transfers control. Likewise, signing a token approval can give a contract spending authority without transferring immediately. Follow the complete action, not just the login method.

Code-mediated funds

A smart contract can enforce rules, but the whole dependency chain matters

A contract can receive stakes, calculate or verify conditions and release payouts according to deployed code. Public bytecode and verified source can make those rules more inspectable than an operator's private ledger. Transactions and balances are also visible at the address.

Visibility is not the same as comprehension. Reviewers need the exact chain, contract address, verified source, compiler information and linked libraries. A copied contract name or interface can point to a malicious deployment with different code.

Contracts cannot fetch off-chain events by themselves. Ethereum.org explains that oracles bring external information on-chain. A casino relying on prices, sports results or off-chain randomness therefore depends on the oracle design and its failure controls.

The contract can also call other contracts. Tokens, routers, randomness coordinators, vaults and bridges expand the trust surface. A claim that “the game is on-chain” should map where value is held and which component decides each transition.

Privileged functions

Owner, pauser and role accounts can change practical control

Ethereum.org's security guidance recommends explicit access controls for sensitive functions. An Ownable pattern assigns privileged actions to one owner address; role-based control can divide minting, upgrades and pausing between accounts.

For custody review, list what each role can do. Can it pause withdrawals, move reserve assets, change the oracle, alter fees, add supported tokens, blacklist addresses or rescue funds? A contract can be publicly callable while those critical choices remain centralised.

Emergency pause may reduce damage during an exploit, but it also means users depend on the pauser to restore access. Rescue functions may recover accidentally sent tokens yet also provide a movement route. Describe capability and safeguards instead of assuming every admin function is malicious or benign.

Check current role holders on-chain. Documentation may say that a multisig controls the system while the deployed role still points to a single externally owned account. Ownership can also be transferred after an audit or article date.

Mutable execution

A proxy can keep the same address while changing the logic

Ethereum contracts are immutable at their deployed addresses, but Ethereum.org documents upgrade patterns that route calls through a proxy to replaceable logic. The user can keep interacting with one proxy address while an administrator changes the implementation contract.

Upgradeability can fix bugs, yet it expands trust. The upgrade authority may introduce new withdrawal, fee or access behaviour after a user reviewed the original source. A verified proxy without a verified current implementation is incomplete evidence.

Identify the proxy standard, implementation address, upgrade administrator and any delay. Compare recent upgrade events and confirm that the interface displays the same chain and address. An implementation shown in an old audit may no longer be active.

“Renounced ownership” is not enough if another role, beacon or proxy administrator retains control. Trace every privileged path. Where this is beyond the available evidence, state that the contract is upgradeable and admin control remains unverified.

Shared administration

Multisig and timelocks reduce some single-key risk, not all risk

A multisignature account requires a threshold of approved signers. Ethereum.org gives examples such as three-of-five or four-of-seven. This can prevent one lost or compromised key from acting alone and distribute operational responsibility.

The threshold only matters with genuine signer independence. Five keys held by one company on one system do not offer the same resilience as independent signers using separate devices. Public addresses can reveal the threshold, but organisational independence may require documentation.

A timelock can delay a proposed upgrade or privileged action, allowing observers time to inspect and possibly exit. Check which actions are delayed, how long, and whether an emergency role can bypass the delay. A nominal timelock that excludes withdrawals or implementation changes gives limited protection.

Multisig and timelock do not prove solvency, fair games or good terms. They answer narrower control questions. Record them as safeguards around specific admin powers, not as a universal security score.

External dependencies

Oracle, randomness and frontend control can sit outside the visible vault

A contract needing data unavailable on-chain must rely on an oracle or signed message. Identify the provider, update conditions, stale-data handling and who can replace the source. A decentralised contract can still depend on one signer for a decisive input.

Randomness deserves separate evidence. A transaction hash, block timestamp or predictable block field may be manipulable in some designs. Look for the documented randomness source and how requests are matched to settlements. Do not confuse on-chain execution with automatically fair randomness.

Most users interact through a website rather than directly calling contract functions. Ethereum.org's security report highlights compromised interfaces as a major risk. A hijacked frontend can substitute an address, request a broader approval or present misleading transaction text while the original contract remains unchanged.

Bookmark independently verified addresses and compare them in the wallet confirmation. If the interface and published documentation disagree, stop. A hardware wallet helps only when the user can understand and verify what its screen asks to sign.

Delegated spending

Token approval can create ongoing authority beyond one wager

ERC-20 tokens commonly require an approval before a contract can transfer them. The approval can be limited to a specific amount or set very high. An unlimited approval may remain after the casino session ends.

Ethereum.org's security research notes that a later-compromised contract can exploit an existing approval. The risk remains even if the original approval was granted to a legitimate application. Upgradeable routers add another reason to review continuing allowances.

Before signing, compare spender address, token, network and amount. An approval is not the same as a transfer, and it should not be described as a completed deposit. After use, inspect active allowances and revoke those no longer needed through a trusted tool where appropriate.

Revocation itself is an on-chain transaction with a fee and cannot undo a transfer already made. A malicious permit signature can also create approval without an obvious conventional approval transaction. Never sign unreadable requests merely to “verify” or “unlock” an account.

Asset and network identity

Bridges and wrapped tokens add custody and contract layers

The same ticker can represent different contracts on different networks. A casino may accept native ETH, a bridged representation or an ERC-20 token. Record chain ID and contract address, not only the symbol.

A bridge can lock assets on one network and issue representations on another. Security then depends on bridge validators, message verification and the contracts on both sides. “Funds are on-chain” does not remove the bridge's custody or exploit risk.

Operators can also credit deposits after fewer confirmations than their processor ultimately requires, then delay withdrawals until settlement completes. Smart-contract applications may rely on a specific rollup or bridge finality assumption. These timing rules should be documented separately from game speed.

Never test compatibility with a material transfer. Public documentation, wallet simulation and a minimal reversible learning environment are safer evidence sources. This guide does not recommend moving assets to evaluate a casino.

Evidence hierarchy

Build a custody map from addresses, roles and terms

Start with the exact domain and contracting entity. Save current terms, custody language, withdrawal rules and named processors. Then identify the chain, deposit or contract address and the asset contract. A block explorer can show transactions and contract metadata but cannot interpret private operator liabilities.

For a contract model, save verified source, implementation address, admin roles, pause state, oracle addresses, upgrade events and audit links. For a custodial model, save the deposit transaction, credited amount, internal reference and later withdrawal transaction if one exists.

Use precise conclusions. “The user sent assets to an operator-controlled address and received an internal balance” is stronger than “centralised”. “The proxy admin can replace logic after a delay” is stronger than “trustless” or “unsafe”.

Evidence expires. Addresses, implementations, processors and terms can change. Date every check and preserve conflicts. A site redesign or rebrand should trigger a new contracting-entity and address review.

No deposit required

Compare two fictional flows without transferring value

Flow A shows a cashier address, asks the user to send USDC and promises an internal credit after confirmations. The account later exposes a withdrawal form. Without the receiving key, the user cannot move the deposited USDC directly. Classify the flow as custodial unless evidence shows an enforceable alternative.

Flow B asks a wallet to approve 100 USDC to a published contract, then calls a deposit function. The contract source is verified, but an admin can pause withdrawals and upgrade the implementation through a two-of-three multisig with no timelock. Classify the assets as contract-held with material admin dependency, not simply “non-custodial”.

Now inspect what is missing. Flow A needs operator identity, processor, reserve and withdrawal evidence. Flow B needs signer independence, current implementation, oracle and frontend evidence. Both need eligibility and game fairness checks.

This exercise can be done with screenshots, documentation and explorer data using zero-value addresses. Do not make a real deposit for research. A practical checklist should reduce uncertainty before exposure, not create exposure in order to answer it.

Scoped assurance

An audit is a dated review, not insurance or a permanent guarantee

Read the report, not the badge. Confirm auditor, date, repository commit or deployed address, scope, severity findings and whether fixes were retested. A logo on a website may refer to an older implementation or only one component.

Audits can miss vulnerabilities and usually do not evaluate operator solvency, signer integrity, economic incentives or every frontend. Later upgrades can make a report stale. A clean report should increase confidence in the reviewed scope, not erase all other risks.

Bug bounties, formal verification and monitoring can add evidence, but each has limits. Check whether emergency procedures protect users or merely allow administrators to pause. Examine how incidents are disclosed and how users can withdraw during recovery.

Never turn the absence of a public finding into proof that no problem exists. State what was reviewed, what remains privileged and what changed after the report date.

Recovery reality

Custodial support can reverse ledger entries; blockchain settlement usually cannot

An operator may correct an internal ledger mistake, cancel a pending withdrawal or restore account access. That central control can help with errors, but the same control can also freeze funds under terms. The quality of support and dispute routes therefore matters.

A confirmed blockchain transfer to the wrong address generally cannot be recalled. A contract may include rescue or refund logic, but only if the exact code and conditions allow it. Courts or operators can sometimes act against identifiable parties, yet the transaction record itself remains.

Preserve addresses, transaction hashes, timestamps, account statements, chat transcripts and terms. Never pay an unsolicited “recovery agent” who asks for a seed phrase or additional crypto. Legitimate support does not need a private key.

Custody classification helps set expectations: which party can technically move value, which party owes a contractual balance and what forum can hear a dispute. It does not guarantee the outcome.

Local boundary

On-chain access does not establish New Zealand permission

A contract can be technically callable from New Zealand while a related operator's terms restrict the account. Conversely, a custodial site can be reachable without clearly permitting a resident. IP access, NZD display and a wallet connection are not contractual evidence.

Identify the operator, current restricted-country clause and age requirements, then compare them with the site's dated New Zealand legal-status guide. The Department of Internal Affairs remains the primary national information source.

Smart-contract administration can be pseudonymous, leaving no practical customer-support or dispute respondent. That is a material risk, not a shortcut around local rules. A visible contract address is not a company identity.

If gambling is no longer recreational, use the contacts in the responsible gambling guide. Moving between wallets or protocols does not solve loss-chasing and can add irreversible transaction risk.

Before any exposure

Crypto casino custody checklist

1. Identify the exact operator, domain and contracting entity.
2. Classify the balance as internal ledger, self-custody or contract-held.
3. Record chain, asset contract and relevant addresses.
4. Determine who can sign or approve a withdrawal.
5. For contracts, verify source and current implementation.
6. List owner, pause, upgrade, oracle and rescue powers.
7. Check multisig threshold, signer independence and timelock.
8. Inspect token approval amount and spender address.
9. Map frontend, oracle, bridge and processor dependencies.
10. Read current fees, KYC, limits and dispute terms.
11. Treat audits as dated scoped evidence.
12. Verify New Zealand eligibility independently.
13. Do not deposit merely to complete research.
14. Never reveal a seed phrase or private key.

The conclusion should name the model and its remaining dependencies. “Contract-held under an upgradeable proxy with multisig administration” communicates more than “decentralised”. “Operator-controlled omnibus custody with internal balances” communicates more than “crypto account”.