Security
This is a new tool asking you to connect a wallet, which is a thing worth being suspicious of. Here is how it works and what it has not been through.
Do you ever see my private key?
No. Signing happens inside your wallet; this app receives the finished signature and never the key that made it. There is no field anywhere here that asks for a seed phrase, and no code path that could accept one.
What am I signing when I sign in?
One personal message, containing a random challenge this server issued and the network it was issued for. It is not a transaction: no gas is spent, no object moves, and nothing on chain changes.
What it produces is a session cookie that lasts a week. The cookie is httpOnly, so page scripts cannot read it, and its only power is to see and change what that wallet could already see and change. Anything that touches the chain still goes back to your wallet for a real signature.
What happens before a write is signed?
It is simulated against current state first, and the result is shown: the gas it would cost, the objects it would create, change or delete, and the balance changes it would make. A call that would fail says so before you are asked to sign it, with the reason the chain gave.
Read functions never leave that stage — they are only ever simulated, so they cost nothing and change nothing.
Where does my Move source go?
Into the workspace it belongs to, in a Postgres database, readable by the members of that workspace and nobody else. It is not published anywhere by being written here.
Compiling sends it to a separate service that runs the Sui toolchain in its own container with no outbound network. That service writes the files, builds them, and deletes the directory afterwards. It logs how long a build took, how many diagnostics it produced and their codes — never the source itself.
Who can see my workspace?
Its members. Every table is behind row level security in the database, so a request for somebody else’s workspace is refused where the data lives rather than by the screen that asks for it.
On-chain data is a different matter: package addresses, councils and proposals are public by nature, and anybody with a fullnode can read them whether or not they use this.
What it has not been through
- It has not been audited. No third party has reviewed this code. Use small amounts on testnet before anything else, and read what a transaction will do in the preview before signing it — that preview is there for exactly this reason.
- The source is not public yet. You cannot check any of the above by reading the code today, which means this page is currently a claim rather than something you can verify. That is a real limitation and it is the next thing worth fixing.
- It is one person’s project. There is no company behind this, no support rota, and no uptime commitment. If the compile service is down, building stops working until it is back.
- A council registration is a bookmark, not a guarantee. Watching a council here does not make it legitimate — the contract decides who may approve what, exactly as it would for somebody using the CLI. Check the council id against the package you actually trust.
- Analytics. Page views only, through Vercel Analytics: no cookie and no visitor identifier. The path is part of a page view, so workspace and package ids in a URL do leave with it.
Found something wrong?
Say so before saying it publicly, and give it a few days. There is no bounty to offer — only that it will be taken seriously and fixed.