| name | dexdo-register-account |
|---|---|
| description | Register a deployed-and-funded PrivateNote with the DEX.DO backend to get an API credential (apiKey + apiSecret) for the REST API. This is the bridge between onboarding (deploy/deposit a note on-chain) and using the API (signed reads in dexdo-market-data, REST orders in dexdo-trading). It is a deliberate security step — registering delegates the note's private key to the backend. Load when the user wants to "register my note / account", "get API keys", "connect my note to the API", or before any signed REST call when no creds.json exists yet. |
Turns a deployed PrivateNote into a usable API account: POST /api/v1/accounts
returns an apiKey + apiSecret, stored as <tt>.creds.json (mode 0600). Those
creds are what dexdo-market-data (signed reads) and dexdo-trading (REST
orders) sign requests with.
Where it sits in the flow:
dexdo-deploy-multisig → dexdo-deposit (note deployed + funded on-chain)
│ produces notes/<tt>.account.json
▼
dexdo-register-account ← THIS skill (POST /accounts → creds.json)
│
┌───────┴────────┐
▼ ▼
dexdo-market-data dexdo-trading → dexdo-total-withdraw
(signed reads) (REST orders)
Registration is its own step on purpose — it is a security decision, not a silent side-effect of depositing.
Registering hands the note's private key to the backend (the body includes
pnSeckeyHex); the backend custodies it (sealed under its KEK) and signs your trades
on your behalf. So:
- Only register notes you're willing to let the backend trade with.
- The hosted dev backend (
https://dodex-dev.ackinacki.org) is Shellnet testing only, with no security guarantees for delegated keys, and won't exist on Mainnet. - It is one-shot per note: a second registration of the same note returns
-2015(the original credential stays; no new one is minted). Losing anapiSecretcan't be undone by re-registering.
Confirm with the user before registering — this is a deliberate, consequential action.
- The note must be deployed and funded on-chain (the endpoint reads its on-chain
owner key before minting creds; an undeployed note →
-2013). Rundexdo-deposit-shellnetfirst if it isn't. - You need the note's
<tt>.account.json(from onboarding) — it is the exact POST body:pnAddress,pnPubkeyHex,pnSeckeyHex,pnDihHex.
Public endpoint (no auth — possession of the note's keys in the body is the capability). Driven by the shared client:
DEXDO="python3 $PWD/.claude/skills/dexdo-common/dexdo_client.py" # from repo root
export WORKSPACE="${WORKSPACE:-$HOME/dexdo-workspace}"
$DEXDO register \
--account-file "$WORKSPACE/notes/<tt>.account.json" \
--save-creds "$WORKSPACE/notes/<tt>.creds.json"
# add --base-url https://your-host to target a backend other than the dev defaultOn success it prints {accountId, pnAddress, apiKey, apiSecret, permissions} and
writes <tt>.creds.json mode 0600 (it holds the apiSecret, which the backend
returns only once). That file is exactly what the read/trading skills consume via
--creds / $DEXDO_CREDS.
$DEXDO account --creds "$WORKSPACE/notes/<tt>.creds.json" # signed read should return balancesA 200 with balances confirms the credential works end-to-end (auth + signing).
-2015already registered — the note has a credential already; don't retry, reuse the existingcreds.json. (Not a failure to fix.)-2013note not deployed on-chain — finishdexdo-deposit-shellnetfirst.-2016submitted key does not own the note — wrongaccount.jsonfor this note.-1130malformed field (bad hex / pubkey≠seckey-derived).-1500transient backend read — retry.
- In: register one deployed note → store its API credential (0600). With confirmation.
- Out: deploying / funding the note (→
dexdo-deposit-shellnet); using the creds to read or trade (→dexdo-market-data/dexdo-trading). Registration is public and unsigned, so it needs no existing credential.