Good morning Luke, Considering the proposal as a whole, I think, it's a little imperfect. The main problem, is that the end goal is activation, but what the opcode rewards is signalling. Consider a miner who signals only if the number of non-signalling blocks in this retargeting time > 5% of 2016. Such a miner would still effectively block a softfork activation, while still has a chance (albeit reduced) of winning the transaction fees of the block-signalling-opcode, in proportion to the number of miners not signaling for a softfork or using a similar algorithm. What we should reward should be activation. How about an opcode which requires this stack (stack top at right) 1. If the given is in state FAILED, then it checks if the given matches the given . 2. If the given is in state LOCKED_IN or ACTIVE, it checks if the given matches the block's coinbase transaction signature. This creates an output which is refundable to the owner, if the softfork fails to activate, but which may be claimed by miners, if the softfork activates. I don't know enough yet about Bitcoin's codebase to know if the above spec is actually workable. But basically, I think we should create an assurance contract for activation of a softfork. -- Also, this invites an inverse logic: 1. If the given is in state LOCKED_IN or ACTIVE, then it checks if the given matches the given . 2. If the given is in state FAILED, it checks if the given matches the block's coinbase transaction signature. I think, your proposal allows an economic actor to pay fees if the miner is explicitly not signaling. This is supposed to allow a vote against a particular softfork. Thus, it should also be possible to allow to vote against a softfork. But in any case, I think, it's better to pay on activation or failure to activate, rather than mere signalling, as signalling is not the goal. Activation, or rejection of activation, is the goal. Regards, ZmnSCPxj