Check it yourself
How you will confirm the pool's admin powers, tell shields, private transfers and withdrawals apart, and re-check every proof, using only the public chain.
You should not have to take this site’s word for anything. Once the pool is deployed, every check below reads Elysium directly, needs no wallet, and sends no transaction.
Nothing is deployed yet. This page describes the checks that ship with the first testnet release. Addresses will appear on Network and contracts.
One script for every check
A single read-only script will check the admin powers, list every pool transaction with its kind, and send each proof back to the deployed verifier. It needs Node.js 20 or newer and Elysium’s public RPC; you can point it at your own RPC instead. The script is short: read it before you run it.
Admin powers
The pool’s source will be verified on the Elysium explorer, so the code you read there is the code on chain. The admin can call only two functions:
| Function | What it does |
|---|---|
setToken(token, supported) |
Turns deposits of a token on or off |
setAdmin(admin) |
Hands the admin role to another address |
How to confirm the rest:
| Claim | How to check |
|---|---|
| The admin is the published multisig | Call admin() on the pool and compare it with Network and contracts |
| It can’t block withdrawals | transact checks token support only when extAmount is positive (a deposit) |
| It can’t move funds | No admin function transfers tokens. Tokens leave the pool only inside transact, to the recipient and relayer fixed by a valid proof |
| It can’t change the verifier | verifier is immutable: set once at deploy, with no setter |
| It can’t upgrade the pool | The pool is not a proxy, and its code has no DELEGATECALL or SELFDESTRUCT |
What each pool transaction looks like
Every pool action is one call to transact. Its extAmount and the token movements in its receipt tell you which kind it is.
| Kind | extAmount |
Token movements | Pool events |
|---|---|---|---|
| Shield | Positive: the deposit | The deposit, from the sender’s wallet into the pool | 2 NewCommitment, 2 NewNullifier |
| Private transfer | 0 | None, or only the relayer fee from the pool to the relayer | 2 NewCommitment, 2 NewNullifier |
| Withdrawal | Negative: the amount out | The amount, from the pool to the recipient, plus the relayer fee if relayed | 2 NewCommitment, 2 NewNullifier |
In a private transfer, nothing on chain names the sender, the recipient or the amount. The new notes are encrypted, and the spent notes appear only as nullifiers, which can’t be traced back to the notes they spend. The one exception is who submits it: through a relayer, the sender on chain is the relayer; from your own wallet, it is your wallet.
Re-check a proof
A pool transaction can only succeed if the verifier accepts its proof. You can also ask the verifier again at any time:
- Decode the transaction’s input as
transact(_args, _extData)using the pool’s verified ABI. - Call
verifyProof(_args, _extData.token)on the pool. It returnstrue. - Change any public input, for example add 1 to
publicAmount, and call it again. It returnsfalse.