intents/miner is a machine attached to one coin on pump.fun. it belongs to nobody who can steer it. the only thing that reaches it is trading. every trade pays a creator fee, every fee becomes an intent to cross to a shielded chain, every crossing that lands is proven by a share, and every share buys the coin. the site you are reading is the machine's window. it is a readout. there is nothing to press.
the intake is the wallet that created the coin. pump.fun pays a creator fee on every trade of the coin, and for this coin those fees land in that wallet. the engine reads every credit to the intake as a trade and splits it: seven eighths to the vein, one eighth to the buffer. the vein part leaves as an intent. the buffer part stays and pays rewards. the intake never holds more than the fees that have not yet left.
a solana transaction signature is 64 bytes. the engine decodes the signature of each trade and reads byte 63, the last one. if it is even the trade routes to zcash. if it is odd the trade routes to monero. the byte is as good as a coin flip, nobody chooses it, and over any long run it sends half the fees each way. the byte and the route are shown on every trade on the tape.
an intent is one trade's request to cross: the trade signature, the chain, the vein amount, and a hash of those three. the engine opens it on near intents with the vein amount as input and the destination asset as output, delivered only to the machine's own address on that chain. when the vein amount is half a sol or more the intent fragments into up to eight pieces of a quarter sol each, and each piece crosses on its own and can be proven on its own.
a fill is an intent that landed. on zcash it lands as an orchard note in the machine's unified address, and the engine records the note commitment and the anchor it was inserted under. on monero it lands as an output to the machine's primary address, and the engine records the one time key, the transaction hash and the global output index, then waits for ten confirmations. every fill keeps the near transaction and the destination transaction so both halves of the crossing can be checked.
a share is the proof that a fill is shielded. the solver builds 136 bytes: the trade signature, the intent hash, the commitment or output key, and a nonce. it hashes them with blake3 and reads the 32 byte result as a number. if the number is below the chain's target, the share is ready. the program on solana recomputes the hash with its blake3 syscall, checks the merkle path to a mirrored anchor for zcash or the ten confirmations for monero, creates an account named by the commitment or the output index so the proof can never be made twice, appends the share hash to the tree, and pays the reward. a share references the share before it, so accepted shares form one chain across both sides.
not every share weighs the same. a zcash fill by the direct route is grade 1. a monero fill by the direct route is grade 2. a fill that went two hop through near is grade 3, because it settled twice. a fragment whose parent intent was superseded by a newer quote before it settled is an uncle and carries half its grade's weight. weight multiplies the reward.
each chain has its own target. a target is a 256 bit number and a share's hash must be below it. both start at two to the 236, a difficulty of two to the twenty. after every seventeen accepted shares on a chain, that chain retargets: it divides the intents emitted to it over that span by the shares it accepted, takes a quarter of the distance of that ratio from one, and moves the target by that much, loosening by at most 32 percent and tightening by at most 16 percent. a chain that is behind gets easier. a chain that is flooding gets harder. the two controllers never read each other.
each accepted share is paid from the buffer with a buy of the coin on the curve. the size is the buffer times the share's weight divided by two to the power of four plus the rung. the rung starts at zero and climbs by one the first time cumulative buy volume on the curve crosses 100, 300, 1,000, 3,000, 10,000 and 30,000 sol. it never falls. at higher rungs each share takes a smaller slice, so the buffer lasts through high volume. the reward buy is a trade like any other: it pays a fee, routes by its own byte, and emits an intent.
idle: no coin configured or no trade yet. bilateral: both chains have accepted a share within the last 34 intents. unilateral orchard: only zcash has. unilateral monero: only monero has. stalled: neither has. pending is not a mode; it is the state of a share waiting on an anchor or on confirmations, and pending shares are listed but not counted.
the program keeps the last 32 orchard anchors. a relay feeds it each new anchor as zcash blocks land. a zcash share proves against one of those 32. if the relay falls behind, new zcash shares wait as pending and the monero side keeps mining, which is why the targets are separate. if an anchor ages out of the mirror before its share is submitted, the share is orphaned and the fill stays in the vein unproven and unpaid.
the machine never spends a note or an output. it has no instruction for it and no key for it. the machine never sells the coin. nothing runs on a clock: there are no epochs, snapshots, timers or scheduled runs anywhere, and every number on this site is a count of events or a sum over events. the vein only grows.
the miner drawn at the top of every page is placed character by character from the machine's state. the wheel turns once per share. the left fan spins while zcash is proving, the right while monero is. the mode bar and the rung bar fill from the state. the conveyor carries one dot per intent. the bit drops one row per share. the vein row at the bottom widens from the center with the dollar value of everything shielded, olive for the zcash side and amber for the monero side.
the program's id and state account are linked on the home page. the zcash full viewing key and the monero view key are published there. a view only wallet on either chain will list the machine's notes or outputs, and the shares page lists the same commitments and indexes with the solana transaction that accepted each one. the tree root after every share is on the shares page so the sequence can be replayed by anyone with the list.