Support access and address disputes

Two things in this page are about Ziklag acting on your account rather than you acting on it. Both are rare. Both are things you should be able to check rather than take on trust, which is why they are documented here with the controls named.

When a Ziklag engineer opens a support session

To investigate an issue, a support engineer can open a time-boxed session that shows them your account as you see it. Every session:

• is announced. The account owner receives an email when it starts, naming the engineer and the reason they gave. There is no version of this that happens quietly.
• appears in your own audit log, alongside everything else that happens on your account. Look for support_session_started in Settings → Audit.
• expires. Thirty minutes by default, two hours at the very most. An extension requires a fresh reason and produces a second entry in your log.
• is read-only by default. Write access is a separate grant inside Ziklag, issued per incident, and it expires on its own.

What a support session cannot do

These are refused by the platform, not hidden in an internal screen — the refusal happens in the same service that would have carried out the action, so there is nothing for an engineer to click past:

Blocked	Why
Read your extended public keys beyond the masked xpub6CUG…f5d5 preview	The full key reveals your entire transaction graph
Send a transaction or broadcast one	Moving your funds is never a support action
Trigger a consolidation	Same — it moves real balances
Schedule a destructive wipe	Irreversible, and owner-only
Approve an identity rotation	A security decision that belongs to you
Rotate your API key	It would lock your integration out
Register or revoke an Edge credential	Those live on your hardware
Archive an address	Archiving stops monitoring, which risks unseen funds
Change your capacity band	Billing goes through a path that emails you

A support engineer who needs one of these will ask you to do it. That is the intended answer, not a workaround.

Cancelling a scheduled wipe is deliberately not blocked. If an engineer finds a wipe scheduled by mistake, they can stop it immediately — waiting for you to wake up is the worse failure.

Address conflicts

Addresses in ChainOS are unique per account, not globally. Two accounts deriving from the same mnemonic — or one customer running two accounts — will legitimately hold the same address, so this is not, by itself, an error.

It becomes one when the two accounts are not the same customer. If an import or an address registration collides with an address another account already holds, you will see:

{
  "error": {
    "code": "CONFLICT",
    "message": "This address is already registered on the platform. Contact support with reference IMP-CONFLICT-imb_01J9K2L3M."
  }
}

You will not be told who the other party is, and they will not be told about you. An address book is the most commercially sensitive asset a payments business has, and a dispute-resolution process that hands one over is not one worth having. Both sides see only the reference.

Proving control

Ziklag asks both parties the same question: sign a nonce with the key that controls the address. Whoever holds the key can; whoever does not, cannot. Nobody has to be believed.

You will receive an email with a nonce that looks like this:

chainos-proof-ESC-01J9R2S3T-1755600000-8f14e45fceea167a

Run this on the machine holding your mnemonic:

chainos-edge prove-control \
  --address=0x3fC91A3afd70395Cd496C647d5a6CC9D4B2b7FAD \
  --nonce=chainos-proof-ESC-01J9R2S3T-1755600000-8f14e45fceea167a

It prints a signature. Paste it into Settings → Proof of control in the portal, or POST it:

POST /v1/settings/proof-of-control
{ "nonce": "chainos-proof-…", "signature": "0x967e08…" }

Four properties of that command are worth knowing, because they are what make it safe to run:

• Your key never leaves the machine. What you send is a signature over a string Ziklag chose. A signature over a fixed string is useful for nothing else.
• It searches for the address. You name an address and the Edge finds the key behind it — the gas tank, the treasury wallet, then the first thousand deposit addresses. You cannot accidentally sign with the wrong key, because a key that does not produce that address is not used.
• It refuses to sign anything that is not a ChainOS nonce. "Sign this message to verify your identity", where the message is a transaction, is the oldest attack in this space. This command will not sign arbitrary text.
• It needs no network access. Read the mnemonic, sign, print. You can run it on an air-gapped machine and carry the signature out by hand.

The response to a submission is always the same, whatever you send. That is deliberate: an API that confirmed a nonce was valid would let somebody discover that an address is under dispute without being party to it. Support tells you the outcome.

Which chains this works on

Today: Ethereum, BNB Smart Chain, Polygon, Avalanche, Base and TRON — the chains with a signed-message convention ChainOS can verify (EIP-191 personal_sign).

Bitcoin, Solana, Stellar and XRP each have their own convention and none is verified automatically yet. On those chains prove-control refuses rather than producing a signature nobody can check, and the dispute is settled by an engineer on other evidence. A receipt for a conversation that never happened is worse than no receipt.

What happens then

Outcome	Meaning
You proved control and the other party did not	The address is awarded to you
Neither proved control	An engineer decides on the remaining evidence — key sources, derivation paths, registration history
Both proved control	One customer is operating two accounts. Both keep it; nothing is taken away
Your nonce expired unanswered	The claim is not granted. Ask support for a new one

A nonce is single-use and carries the reference of the dispute it belongs to, so a signature obtained for one cannot be submitted as the answer to another.

Changes Ziklag makes to your account

Anything Ziklag changes about your account — your capacity band, your capability tier, a temporary capacity grant, a suspension — emails your account owners and is written to your own audit log. If you find a change you were not told about, that is a bug worth reporting.

Suspension

If your account is suspended, the API is closed and returns:

{ "error": { "code": "ACCOUNT_SUSPENDED", "message": "This account is suspended: …" } }

Monitoring does not stop. Your Edge stays enrolled, deposits to your existing addresses are still detected and credited, and your balances are unchanged. A commercial dispute must never make your money invisible — the same principle that keeps a superseded xpub monitored.

You can still sign in, read the reason, see your balances and settle up. /v1/auth, /v1/billing, /v1/organizations and the whole Edge plane stay open throughout.

Temporary capacity

A grant adds to your band's limit rather than replacing it, and it expires — the email tells you when. If you need the capacity permanently, move up a band before then. Going over a limit stops new addresses being issued; it does not stop monitoring the ones you already have.