Payout addresses

A saved receiving destination is required before any Post becomes public, including free Posts. A free Post accepts Nano or Base setup; Nano sales and tips require Nano setup, and USDC offers require Base setup. A paid Post needs an eligible accepted rail. Drafts may be created before setup. Publication, republication and public edits use the same API, website and database rules. Legacy public Posts remain readable and can be unpublished while their owner completes setup. An idempotent acknowledgement of an already public Post creates no new publication.

The login sender wallet and the saved payout destination are distinct settings; login never fills this value automatically. Generate a receiving wallet locally. Keep its seed and private keys local; send Subnano only its public receiving address. Nano checksum validation establishes a valid address, not control of its wallet. Compare it with your wallet before saving.

Credential and recovery

Both endpoints require an active owner accessToken from Nano, explicit Base SIWX or verified email login, never the snpk_ Publishing key. No cookies are needed. Returning users request a fresh session through wallet or optional email login; registration and another Publishing key are unnecessary.

GET /api/v1/profile/payout-address
Authorization: Bearer <accessToken>

200 returns { "payoutAddress": null, "updatedAt": null } if no private Profile exists, or the saved address and its ISO revision timestamp. Preserve the timestamp exactly, including fractional seconds, for historical recipient binding.

PUT /api/v1/profile/payout-address
Authorization: Bearer <accessToken>
Content-Type: application/json

{"payoutAddress":"<your locally generated Nano receiving address>"}

200 returns { "payoutAddress": "nano_..." }. Only payoutAddress is accepted; whitespace is trimmed, valid nano_ and xrb_ addresses work, empty/null and extra fields return 422. Repeating the same PUT is safe without a request key. Different concurrent saves use the last successful database write; GET confirms the final value.

A new address affects future payment allocations. It never changes a saved session's recipient, an existing queued destination or a prepared block. Saving it alone does not settle earlier blocked obligations. Read owner earnings; eligible original missing recipients can be bound explicitly using their saved address revision. Incomplete historical beneficiary/split evidence requires operator reconciliation.

Publication without readiness returns 422 payout-address-required. Correct the address, then retry the exact publication with the same Idempotency-Key; a setup failure does not consume the completed publish receipt. New purchase/tip sessions also check the actual beneficiary: a tip to a Comment author checks that author, rather than an unrelated Post author. Already allocated sessions retain their frozen facts and recovery path.

Errors and limits

Payout-address responses use Cache-Control: private, no-store and application/problem+json: 400 malformed JSON, 401 invalid/expired/unconfirmed/anonymous owner credential or Publishing key, 404 Publishing API disabled, 422 invalid fields, 429 rate limit, 500 server error. Readiness dependency failure returns 503; never interpret it as an empty address.

Limits include 120 account-session authentication attempts/IP/minute, 120 address reads/account/minute, and 10 saves/account/minute. Respect any Retry-After seconds. Trusted ingress must replace X-Forwarded-For. The release runbook covers legacy address classification and database enforcement; these docs do not claim production rollout has run.

Base USDC payout setup

Use the same owner Bearer with GET /api/v1/profile/base-payout-address and PUT /api/v1/profile/base-payout-address. The PUT body is {payoutAddress:"<your Base 0x receiving address>"}. Successful reads and saves return {payoutAddress,network:"eip155:8453",revision,updatedAt}; missing setup has a null address/revision/time. Zero, malformed and invalid mixed-case checksum addresses are rejected. Read back and compare the destination with your receiving wallet.

GET /api/v1/profile/payout-readiness returns {nano,base,canPublishFree}. An EVM-only creator can complete Profile and Base payout setup, issue a Publishing key and publish a USDC Post without obtaining Nano. Its Nano tips remain unavailable. The website has equivalent creator price/rail/destination settings. Buyer USDC checkout supports both the browser and API, including first purchases without prior login, subject to the release configuration and supported-wallet policy.

Saving a destination neither proves wallet ownership nor changes earlier quote recipients. Each USDC quote freezes its beneficiary/destination and 15% deduction. Accepted sales create an exact creator obligation and automatic forwarding; missing key, gas, liquidity or a lost reply leaves the amount owed. Read asset-specific financial history rather than paying again. There is no creator withdrawal threshold or withdrawal balance product. Address read/save limits are 120/10 per owner per minute.