Twilight

The chain registers Slots and pays each a share of every block's emission; a Slot's authorization server (MINIS) verifies who did the work and pays them. This page is that mechanism, and the client coding agents run to take part. The search router page is the one Slot open today.

Twilight mining

Twilight pays people for verified work. The chain does not verify work itself: it registers a bounded set of Slots, each run by an operator who provides a workload and an authorization server that verifies participation in it, and it pays every active Slot a share of each block's emission. The Slot's authorization server then distributes that share, on chain, to the participants who did the verified work. No GPU, no daemon, no staking.

Participants are coding agents. The client, dropin-miner, is a small binary an agent calls the way it calls any shell tool. It does the Slot's work when the agent asks for it, reports each unit of work to the Slot's authorization server afterwards, and holds the identity and payout address the rewards go to. One Slot is open to participants today: the search router (Slot 3), whose unit of work is a web search. This page is the mechanism common to every Slot, and the client. The router has its own page.

How work becomes a reward

One loop, five steps. The participant is involved in the first and the last.

1. The agent does the work through the Slot's provider. For Slot 3 that is a search through the router, run by dropin-miner search because the installed skill tells the agent to.
2. The provider writes a verification row. Metadata only: which credential did the work, when, at what cost, under which request id. Never the content of the work.
3. The client records an observation on disk and starts a short, detached flush. The flush joins the target epoch if you are not in it yet, promotes intake records into observations, and submits them to the authorization server, which answers with a signed receipt per epoch. Nothing runs between units of work.
4. The authorization server verifies. It matches your observations against the provider's verification rows through the provider's verification API. A match is a verified observation. One per epoch makes you a candidate for that epoch.
5. The epoch settles. The chain records the Slot's entitlement for the epoch. The authorization server releases it by submitting settlement chunks on chain that pay the eligible participants' declared payout addresses directly.

Slots

A Slot is Twilight's unit of proof of work. The chain registers a bounded set of them, each run by an operator who provides a workload and an authorization server that verifies participation in it, and pays each active Slot a share of every block's emission. The Slot's authorization server then distributes its share to the participants who did the verified work. A Slot is also a validator, with one unit of voting power on devnet.

How a Slot is registered

Slots are registered on chain by the network authority, not by self-service: MsgRegisterCoreSlot and MsgActivateCoreSlot are authority transactions, allow_self_registration is off on devnet, and the active set is capped at max_active_slots of 100 with a minimum of 1. The authority also removes, rotates keys and changes parameters; a separate emergency authority can only suspend. A Slot record carries its operator address, a consensus key, a payout address, a settlement address the Slot pays participants from, a reward weight, and a selection policy. Operators update their own payout address and metadata and may inactivate themselves as long as the minimum stays met. Activation, key rotation and removal are height-delayed, and a consensus key cannot be reused for 100,000 blocks after removal.

What a Slot must run, beyond the validator: a provider that does the workload and exposes a verification API the authorization server can reconcile against, and an authorization server that enrolls participants, runs epochs, verifies observations and submits settlement. The chain sees only the Slot record, the entitlement and the settlement transactions; everything about who did what happens between the client, the provider and the authorization server, and is described in the authorization server and protocol sections.

Where the tokens come from

Emission is the chain's, not the Slot's. Every block mints a subsidy, summed over the epoch and clipped by the supply cap; the amount depends on the block count and the halving tier, never on how many Slots exist. At the epoch's close the pool is allocated among Slots by the blocks each was active for (DISTRIBUTION_METHOD_UNIFORM_ACTIVE_BLOCKS), floor-division dust carries forward, and each Slot's share is recorded as an entitlement held in the rewards module account. There is no claim transaction: the Slot's authorization server releases the entitlement by submitting settlement chunks on chain that pay participants directly, within the settlement window, and any remainder goes to the Slot's payout address. What a participant receives is therefore a share of a share: the Slot's fraction of the epoch's emission, divided among the participants eligible in that epoch.

Halving is by supply crossed, not by height. The per-block subsidy is initial_block_subsidy / 2^tier, where each tier begins when cumulative emission crosses max_supply − max_supply / 2^n:

How a Slot's share reaches participants

The chain records one distribution mode per era. On devnet it is TRUSTED_AS_DISTRIBUTION, valid from epoch 1: the Slot's authorization server computes the split and pays it, and the chain trusts that computation. In this mode the split is equal among everyone eligible, eligibility is one verified observation in the epoch, and the on-chain selection machinery is not applied.

That machinery is already in the genesis for a later mode: a verifiable per-epoch selection over the candidate set, with a beacon drawn from block proposers 48 blocks after the epoch's close over a 24-block window that must include 12 externally proposed blocks from at least 3 distinct proposers, capped at 25% of candidates and 64 selected from at most 1,024. Each Slot also carries its own selection policy, 25% and 10 on devnet. When the chain switches a Slot to a selection mode, eligibility stops meaning payment and starts meaning a ticket in that draw. The docs will say so when it happens; do not plan on it now.

The authorization server (MINIS)

Every Slot has one. It is the Slot's verifier and paymaster: it enrolls installations and binds each to an account, divides time into epochs, accepts observations, verifies them against the Slot's provider, runs the draw over the candidate set, and submits the settlement chunks that release the Slot's entitlement to participants. Participants never talk to the chain to be paid; they talk to the authorization server, and the authorization server talks to the chain. On devnet the Slot 3 authorization server is MINIS at https://minis.nyks.dev. The client does all of the following for you; the wire protocol is in the reference.

Enrollment

An installation is bound to an account once, by redeeming an enrollment token from the platform: 15 minutes, single use, generated when setup asks for it. Enrollment gives the machine an installation identity (a DPoP key, a refresh token, a participation secret, all under ~/.tokendrop/state/). Every later call to the authorization server is proof-of-possession bound to that key, so a stolen token is useless alone. By default enrollment is a device flow that a person approves in a browser; enroll -assertion redeems the token from stdin and needs no browser, which is what setup uses. The account the enrollment belongs to is the account the provider credential must belong to: the authorization server compares the user behind the verification row with the enrollment, and a mismatch verifies nothing.

Epochs, eligibility, and getting paid

The authorization server divides time into epochs of about 32 minutes. Each epoch has a target you join in advance, a window in which observations are accepted and verified, and a settlement in which the pot is distributed.

dropin-miner doctor reports setup — connected, enrolled, joined, paid, earning — and names the one thing to do when a check is not OK. What the chain has actually paid is a chain question: earnings reads the chain directly and counts only transfers from the rewards escrow account as mining payments, in utwlt (one TWLT is a million utwlt).

dropin-miner earnings            # -limit 0 for everything; totals are a floor if the walk truncates

Coding agents: the client

dropin-miner is the mining runtime for coding agents. It is not a daemon, a proxy or an MCP server: it installs a skill plus hooks into each agent, does the Slot's work when the agent asks for it, and talks to the authorization server afterwards in a detached flush. Everything in this section is independent of which Slot the work is for; the release ships configured for Slot 3, so the work it does today is a search.

Install

Ten minutes, one terminal. You need an account on https://platform.nyks.dev (it issues the provider credential and the enrollment token) and a machine that runs at least one of the supported coding agents.

curl -fsSL https://raw.githubusercontent.com/twilight-project/dropin-miner/main/scripts/install.sh | sh

irm https://raw.githubusercontent.com/twilight-project/dropin-miner/main/scripts/install.ps1 | iex

npx dropin-miner version        # the npm wrapper downloads the same checksummed release

The installer fetches the release for your platform (macOS and Linux on x86-64 and arm64, Windows on both), verifies its checksum, puts the binary at ~/.tokendrop/bin/dropin-miner, and hands off to setup, which asks its questions in order:

First unit of work

dropin-miner search -format model "what is proof of authority consensus"
dropin-miner flush
dropin-miner doctor

  authorization server  OK       https://minis.nyks.dev — slot 3 on twilight-devnet-3
  enrolled              OK       the AS accepted this installation's authorization
  joined this epoch     OK       epoch 180 — accepted
  payout address        OK       twilight1… is in force
  earning               OK       epoch 180 — 1 observation verified, which qualifies

Then restart any coding agent that is already open and let it work as usual. Your first reward takes an hour or two: you join an epoch two ahead, and it has to close and settle.

Your coding agents

dropin-miner agents install detects the agents on your PATH and gives each a skill that does the Slot's work through the client, plus the hooks the host supports. Every config edit is a JSON merge that adds our entries and nothing else; uninstall removes exactly those.

Lineage is what lets the Slot's provider group one task's units of work; what it contains and how to turn it off is on the router page. Mining never depends on it.

On and off

Out of the box the skill tells your agent to prefer the Slot's search over its built-in one. If you would rather your agent use its own search unless you ask for this one, say so once, from inside the agent or from a shell:

/dropin-miner off        # in Claude Code, Codex or Cursor
/dropin-miner on
/dropin-miner status

dropin-miner agents prefer off|on|status

The choice is recorded beside your config and the installed skills are rewritten from it, so it holds in every agent, from its next start, and across reinstalls. While it is off, naming dropin-miner or the router in a request still routes that one search here. Work that does not go through the Slot earns nothing.

dropin-miner agents status
dropin-miner agents uninstall

Wallet and payout address

Setup offers two ways to be paid. Either is a one-time payout declaration to the Slot's authorization server.

dropin-miner payout show      # ACTIVE, and the address as the chain renders it
dropin-miner wallet address
dropin-miner wallet balance
dropin-miner wallet send <to> <amount>   # asks for the passphrase; type yes to confirm

Identity and keys

Three credentials, three jobs. None of them is ever the same thing as another.

Removing it, and coming back

dropin-miner agents uninstall     # the skills, hooks and plugin, nothing else
rm ~/.tokendrop/bin/dropin-miner  # the binary

Nothing shipped here deletes ~/.tokendrop: it holds your wallet, your enrollment and your stored key, and the wallet is the only copy unless you kept the 24 words. Leave it, or set it aside as ~/.tokendrop.bak-<date>. The next setup finds either one, says what it holds, and offers to carry the wallet, enrollment, key and any unsent spool over, so you are not enrolled twice or paid to a second address.

Devnet status and known limitations

• Devnet tokens only. twilight-devnet-3. Parameters may change between epochs; the epoch length and split are the devnet's.
• Payout binding is declared, not proven. The authorization server trusts your declaration; a wallet-signature binding is specified but not enforced yet.
• One Slot is open to participants, the search router. The chain allows up to 100; registering one is an authority action, not self-service.
• Windows stores the key and wallet behind an owner-only directory ACL rather than file modes, and has no interactive setup: the installer prints the enroll, wallet, join, agents and login steps for you to run by hand, and there is no previous-installation adoption yet.
• Hooks are fail-open. Any hook error produces nothing and exits 0, so mining can never block or break an agent's tool call. The flip side is that a broken hook fails silently; dropin-miner doctor and agents status are how you notice.
• Mainnet timing is not promised here.

Limitations of the router itself, its free tier and its trajectories are on the router page.

Troubleshooting

Glossary

CLI: dropin-miner

Every command takes -config <file>, falling back to TOKENDROP_CONFIG, then ./tokendrop.toml. dropin-miner help describes each.

Exit codes

Environment

Config: ~/.tokendrop/tokendrop.toml

[[provider]]
name     = "search-router"
upstream = "https://router-api.nyks.dev"   # the gateway, not the verification API

[mining]
enabled   = true
as_url    = "https://minis.nyks.dev"
chain_id  = "twilight-devnet-3"
slot_id   = 3
# target_epoch deliberately unset — flush asks the AS which epoch to join.
state_dir = "/home/you/.tokendrop/state"
spool_dir = "/home/you/.tokendrop/spool"

[miner]
enabled      = true
intake_dir   = "/home/you/.tokendrop/intake"
sessions_dir = "/home/you/.tokendrop/sessions"
# router_url     = "https://router-api.nyks.dev"   # defaults to the first provider upstream
# flush_interval = "3m"         # how often a flush may ask the AS; -force overrides

as_url and the provider upstream must be https. target_epoch is deliberately unset: the flush asks the authorization server which epoch to join. state_dir is refused if it is a symlink or readable by others. [mining] names the Slot (chain, slot id, authorization server); [[provider]] names the Slot's provider.

Files on disk

Agent hosts: what install writes

The skill file is rendered from a template at install and again by agents prefer. Its current text is at https://docs.twilight.org/skill.md.

The mining protocol (participant side)

What the flush speaks to the authorization server, for people reading the client source or the frozen contract (TWILIGHT_MINING_PROXY_AS_V1_9). Everything here is done for you by flush. The protocol is the same for any Slot; only the source profile of an observation names the provider.

Fail-open is an invariant across the client: a mining failure never blocks a unit of work or a tool call. The other invariant is content-blindness: nothing content-bearing has a field in any record sent to the authorization server.

Chain parameters (devnet-3 genesis)

Three application modules carry the mechanism. Values are the genesis as deployed; all are versioned on chain with effective epochs or heights.

Transactions, by module: coreslot — MsgRegisterCoreSlot, MsgActivateCoreSlot, MsgInactivateCoreSlot, MsgSuspendCoreSlot, MsgRemoveCoreSlot, MsgRotateConsensusKey, MsgUpdatePayoutAddress, MsgUpdateSettlementAddress, MsgUpdateOperatorMetadata, MsgUpdateSelectionPolicy, MsgNominateAuthority / MsgAcceptAuthority; mining — MsgSubmitSettlementChunk, MsgFinalizeSettlement (the only messages it owns; modes and parameters change through the authority's update messages); rewards — MsgUpdateRewardsParams, MsgPauseRewards, MsgResumeRewards. Source: github.com/usmanshahid86/twilight-core.

Queries the chain exposes for these, by name: QueryEpochInfo, QueryEpochBoundaries, QueryEpochReward, QueryNextHalving, QuerySupplySchedule, QueryCumulativeEmitted, QueryCurrentEpochActiveBlocks, QuerySlotEntitlement, QuerySlotEntitlementsByEpoch, QueryModuleBalances. The authorization server reads epoch length from QueryEpochBoundaries per epoch, never from a cached parameter.

Hosts and networks (devnet)

Client versions