Domain Management

Check whether a domain is available for registration and return a live price quote. When to use: - The user named a specific domain ("can I get example.com?", "is foo.io taken?"). - Pre-flight before `register-domain` to avoid wasted payment attempts on taken or premium domains. - The user is comparing several candidate names. When NOT to use: - The user already owns the domain through Daski — use `get-domain-info` for its current state. - The user wants pricing for multiple domains in bulk — call this skill once per domain. Inputs: - `domain` — fully qualified domain name (e.g. `example.com`). Returns: A2A task; on `state: 'completed'` the artifact is `{ domain, available, currency, price, premium, expiresAt? }`. - `available: true` means the domain is registerable now. - `available: false` means currently registered. `expiresAt` is included when public WHOIS exposes it. - `premium: true` means a premium domain without a fixed retail price — `register-domain` rejects these. Next step: - If `available: true` and `premium: false`: proceed to `daski_buy_service` with `skillId: 'register-domain'`. - If `available: false`: try a different name or wait for the existing registration to lapse. - If `premium: true`: surface this to the user; premium acquisition is out of scope.

Delete a DNS record from a Daski-registered domain controlled by the signing payer wallet. Idempotent: deleting a missing record completes with a no-op artifact. Access: paid orders and owner-only asset operations are routed through the Daski gateway. The gateway obtains a short-lived wallet signature bound to the exact provider, action, asset, and request; the provider rejects direct anonymous access. When to use: - The user wants to remove a DNS record. - After `list-dns-records` returned a `recordId` the user wants to remove. When NOT to use: - The user wants to modify a record — use `set-dns-record`, which upserts on `(name, type)` and is one call faster than delete-then-create. - The user wants to remove ALL records — call this skill in a loop over `list-dns-records` results. Inputs: - `domain` — fully qualified domain name that you own through this provider. - `recordId` — registrar-assigned identifier from `list-dns-records`. Returns: A2A task; on `state: 'completed'` the artifact is `{ domain, recordId, deleted: true }`. If the record didn't exist, `deleted: false` plus `note: 'record not found, no-op'`; `state` is still `completed`. Next step: - `list-dns-records` to verify. - Done.

Read the current state of a Daski-registered domain you own. Combines on-chain ownership data with off-chain registrar state in a single artifact. Access: paid orders and owner-only asset operations are routed through the Daski gateway. The gateway obtains a short-lived wallet signature bound to the exact provider, action, asset, and request; the provider rejects direct anonymous access. When to use: - The user asks "what's the status of example.com?" or "when does example.com expire?" - Pre-flight before `renew-domain` (to confirm current expiry) or `transfer-domain-out` (to confirm ownership and lock status). - Auditing: confirming that an expected on-chain owner matches the wallet you're using. When NOT to use: - The domain isn't registered through Daski — public WHOIS is your tool, not this one. - You need PII for WHOIS verification — that data is NOT echoed back here (see PRIVACY below). Read the public WHOIS directly if you need it. Inputs: - `domain` — fully qualified domain name that you own through this provider. PRIVACY: this skill deliberately does NOT return the registrant's name, email, phone, or address. Those values are on the PUBLIC WHOIS database; they are buyer-submitted PII and Daski does not echo them back through agent surfaces. Only the registrant `country` and a `provenance` token are returned. Returns: A2A task; on `state: 'completed'` the artifact is `{ domain, ownerAgentId, ownerWallet, assetState, renewalEligible, registrant: { country, registeredVia }, provenance, expiresAt, createdAt, nameservers[], registrarLockStatus, transferAuthCodeAvailable, managedAt }`. - `assetState` is one of `active | transferred_out`. `transferred_out` is terminal; further ownership-gated calls will fail. - `registrarLockStatus` is registrar-side; `'unlocked'` means the domain can be transferred out. - `renewalEligible: true` means the asset is still actively managed here and a `renew-domain` call is accepted. Next step: - Done, in most cases. - `renew-domain` if expiry is near. - `set-dns-record` / `list-dns-records` for DNS work. - `transfer-domain-out` if leaving Daski.

Preview the live USD + USDC price for a paid skill before committing to purchase. Useful for budget calculation, multi-year math, and dry-run quotes. When to use: - The user asks "how much would 5 years of example.com cost?" — call with `skillId: 'register-domain'`, `serviceArgs: { domain: 'example.com', term: 5 }`. - The agent is presenting cost options to a user before triggering `daski_buy_service`. - You want to detect premium / unsupported TLDs without attempting a purchase. When NOT to use: - You are about to call `daski_buy_service` anyway — its first-call response already includes the live price in `quoteNotes`. Calling this beforehand is redundant unless the user explicitly asked for a quote. - The skill is free (`paymentRequired: false`) — those don't have a price to quote. Inputs: - `skillId` — the paid skill to price (currently `register-domain` or `renew-domain`). - `serviceArgs` — the same shape you'd send to the actual skill. For `register-domain` you only need `domain` and optionally `term`; the registrant fields don't affect price. Returns: A2A task; on `state: 'completed'` the artifact is `{ amount, amountUsd, currency: 'USDC', validUntil, errors? }`. - `amount` is in atomic USDC units (multiply by 10⁶). - `amountUsd` is a human-readable string (e.g. `"4.99"`). - `validUntil` is a unix timestamp; quotes are typically good for 60 seconds. - `errors[]` is populated for invalid `serviceArgs` (e.g. unsupported TLD, term out of range). No `amount` is returned in that case. Next step: pass the same `serviceArgs` to `daski_buy_service` to actually purchase. Note that prices may shift slightly between quote and settle; the `daski_buy_service` response is authoritative.

List all DNS records on a Daski-registered domain controlled by the signing payer wallet. Access: paid orders and owner-only asset operations are routed through the Daski gateway. The gateway obtains a short-lived wallet signature bound to the exact provider, action, asset, and request; the provider rejects direct anonymous access. When to use: - Before `delete-dns-record` — to look up the `recordId` to delete. - Auditing or troubleshooting: viewing the current DNS state. - After `set-dns-record` — to confirm a record was created with the expected `recordId`. When NOT to use: - You only need to know the nameservers — that's in `get-domain-info`. - The domain is not registered through Daski — this skill requires on-chain ownership. Inputs: - `domain` — fully qualified domain name that you own through this provider. Returns: A2A task; on `state: 'completed'` the artifact is `{ domain, records[] }`. Each record is `{ recordId, type, name, content, ttl, priority? }`. - `recordId` is the registrar-assigned identifier; pass it to `delete-dns-record`. - `priority` is only present for `MX` and `SRV` records. - The list includes nameserver (`NS`) records. Next step: - `delete-dns-record` with a specific `recordId` to remove an entry. - `set-dns-record` to add or update entries. - Done.

Register a new domain. On success the payer wallet controls the managed domain asset and a wholesale registrar handles ICANN compliance. Access: paid orders and owner-only asset operations are routed through the Daski gateway. The gateway obtains a short-lived wallet signature bound to the exact provider, action, asset, and request; the provider rejects direct anonymous access. When to use: - The user wants a new domain and `check-availability` returned `available: true`. - The user wants to register for multiple years up front (1–10 year term). When NOT to use: - The user already owns the domain at another registrar — transfer-in is outside this service's supported operations. - The user is renewing an existing Daski-registered domain — use `renew-domain` instead. - The domain is premium — premium domains without fixed retail prices are rejected. `check-availability` flags these. Inputs: - `domain` — fully qualified domain name (e.g. `example.com`). - `term` (optional) — 1 to 10 years, default 1. - `whoisPrivacy` (optional) — boolean; request registrar WHOIS privacy. - WHOIS registrant fields (REQUIRED BY ICANN, posted to the PUBLIC WHOIS database): - `registrantName` - `registrantEmail` — monitored inbox; see EMAIL VERIFICATION below. - `registrantAddress`, `registrantCity`, `registrantPostalCode` - `registrantState` — the state/province code exactly as the registrar expects it: the part AFTER the country prefix of the ISO-3166-2 code (`CO` for Colorado, `ON` for Ontario, `BY` for Bavaria — never `US-CO`). If the country genuinely has no subdivision, re-use the city name — never send an empty string, and never invent a region your Operator did not give you; ask instead. - `registrantCountry` — ISO-3166 alpha-2 (e.g. `US`, not `USA`). Any country is accepted; there is no registrant-nationality restriction. - `registrantPhone` — E.164 with no separators (e.g. `+15555550100`, not `+1.555.555.0100`). - `registrantOrganization` (optional) — the organization's LEGAL NAME when the registrant of record is a company; it becomes the public WHOIS Organization. `registrantName` then stays the natural-person contact. NEVER concatenate person + company into `registrantName`. COLLECT FIRST: gather ALL registrant fields from your Operator in ONE message before starting the purchase — they are ICANN-mandated and you will be blocked without them. Ask whether the registrant of record is a person or an organization (that decides whether `registrantOrganization` is needed). Do not invent values (states/provinces included); ask. If a field is genuinely not applicable (e.g. no subdivision exists), ask how to fill it — for the state field the registry convention is to re-use the city name, never a blank. Ask about WHOIS privacy in the same message (see below). WHOIS PRIVACY: pass `whoisPrivacy: true` to request registrar WHOIS privacy (free where the TLD supports it). The `registration_details` artifact reports the outcome: `whoisPrivacy: "enabled" | "unavailable" | "not_requested"` — "unavailable" means the TLD doesn't support privacy and the registrant data is on public WHOIS as-is; relay that to your Operator. EMAIL VERIFICATION: the registry sends a verification link to `registrantEmail`. It MUST be confirmed within 15 days or the domain is suspended until verified — `registration_details.verificationDeadlineDays` carries that deadline. Nothing here observes or receipts the send, so no arrival window is available: do NOT tell your Operator when the email will land. Renewal notices land at the same inbox at 30/15/7/1 days before expiry. Role accounts (`postmaster@`, `noreply@`, etc.) usually fail verification. Supported TLDs: `.com`, `.net`, `.org`, `.io`, `.ai`, `.xyz`, plus most ICANN gTLDs. Pricing: variable USDC, varies by TLD and term. Use `get-pricing` for a preview, or read `quoteNotes` on the `daski_buy_service` response. Returns: A2A task; median fulfillment under 60 seconds. On `state: 'completed'` the artifact is `{ domain, orderId, expiresAt, registrar, nameservers[] }`. Default nameservers are the registrar's resolvers — change them with `set-dns-record` using `recordType: 'NS'`. Next step: - Confirm the verification email within 15 days. - `set-dns-record` to publish DNS records through a wallet-authorized asset action. - `get-domain-info` to verify on-chain state.

Extend the registration of a Daski-registered domain you own. Adds 1–10 years to the existing expiry; the on-chain asset's `expires_at` is updated atomically with the registrar response. Access: paid orders and owner-only asset operations are routed through the Daski gateway. The gateway obtains a short-lived wallet signature bound to the exact provider, action, asset, and request; the provider rejects direct anonymous access. When to use: - A registrant-verification renewal reminder arrived (typically at 30/15/7/1 days before expiry). - The user wants to lock in multiple years up front. - A renewal failure or near-expiry warning surfaced in `get-domain-info`. When NOT to use: - The domain is not yet registered — use `register-domain`. - The user wants to switch registrars — use `transfer-domain-out`. - The current expiry is more than 90 days out and the user has no specific reason to renew now (renewing very early doesn't reset anything, just stacks years). Inputs: - `domain` — fully qualified domain name controlled by the payer wallet through this provider. - `term` (optional) — 1 to 10 years, default 1. Registrant info carries over from the original registration — no need to re-supply WHOIS fields. WHOIS contact changes are outside the renew-domain operation. Pricing: variable USDC, varies by TLD and term. Same backend as `register-domain`. Use `get-pricing` for a preview. Returns: A2A task; on `state: 'completed'` the artifact is `{ domain, term, newExpiresAt, registrar }`. The on-chain `expires_at` is updated in the same registrar callback. Next step: - `get-domain-info` to confirm the new `expires_at`. - Done. The domain stays in the `active` asset-lifecycle state.

Create or update a DNS record on a Daski-registered domain controlled by the signing payer wallet. Access: paid orders and owner-only asset operations are routed through the Daski gateway. The gateway obtains a short-lived wallet signature bound to the exact provider, action, asset, and request; the provider rejects direct anonymous access. When to use: - The user wants to point a domain at a host (`A`, `AAAA`, or `CNAME`). - The user wants to set up email (`MX`). - The user wants to change nameservers (`NS`) — e.g. moving DNS hosting elsewhere while keeping the domain registered through Daski. - The user wants to publish a verification token (`TXT`). - The user wants to advertise a service (`SRV`). When NOT to use: - The record already exists with the exact same content — this skill upserts on `(name, type)`; a no-op rewrite is wasteful but not destructive. - The user wants to remove a record — use `delete-dns-record`. - The user wants to transfer the domain away — use `transfer-domain-out`. Inputs: - `domain` — fully qualified domain name that you own through this provider. - `recordType` — one of `A`, `AAAA`, `CNAME`, `MX`, `TXT`, `NS`, `SRV`. - `name` — record name (e.g. `www`, `@`, `_acme-challenge`). Use `@` for the apex. - `content` — record value (e.g. `203.0.113.42` for `A`, `mail.example.com` for `MX`). - `ttl` (optional) — seconds, minimum 300 (registrar-enforced), default 3600. - `priority` (required for `MX` and `SRV`) — integer. Returns: A2A task; on `state: 'completed'` the artifact is `{ domain, recordId, type, name, content, ttl, priority? }`. `recordId` is the registrar-assigned identifier for the new or updated record. Next step: - `list-dns-records` to verify the change. - Done. The asset stays in the `active` lifecycle state.

**Terminal action.** Initiate transfer of a Daski-registered domain to a different registrar. After successful execution, the domain is no longer manageable through Daski and enters the terminal `transferred_out` state. The payer has 7 days to use the auth code at the destination registrar. Access: paid orders and owner-only asset operations are routed through the Daski gateway. The gateway obtains a short-lived wallet signature bound to the exact provider, action, asset, and request; the provider rejects direct anonymous access. When to use: - The user explicitly wants to move a domain off Daski. - The user has already chosen a destination registrar and is ready to paste the EPP auth code there. When NOT to use: - The user just wants to change nameservers — use `set-dns-record` with `recordType: 'NS'`. That keeps the domain managed through Daski. - The user wants to update WHOIS info — that operation is unsupported; do not initiate a transfer for it. - The user is unsure about the destination — initiate the transfer ONLY after the destination is locked in. The 7-day window starts now. Inputs: - `domain` — fully qualified domain name controlled by the signing payer wallet. The first wallet-authorized call stages the exact irreversible effect without contacting the registrar. After the reviewed delay, a fresh wallet authorization must confirm that exact staged execution; cancellation remains available until execution. Pricing: an operator-configured exit service fee (default: the platform minimum provider fee). Use `get-pricing` or `/quote` for the exact amount. Returns: A2A task; on `state: 'completed'` there are two artifacts: `transfer_auth_code` = `{ domain, authCode, expiresAt: <7 days from now> }` and `domain_transferred_out` = `{ domain, timestamp, previousAssetId, nextSteps }`. The on-chain asset enters the terminal `transferred_out` state in the same callback; further calls to ownership-gated skills (`set-dns-record`, `renew-domain`, `get-domain-info`) for this domain will fail. Next step: take the `authCode` to the destination registrar within 7 days. There is no Daski skill for completing the transfer on the destination side. If the transfer is never completed, the registrar lock is automatically restored after the auth-code window.