Bounty parameters

Every step below is written against these three names. Pick the bounty you are working on and read its column; the workbench fills them in automatically for whichever bounty and child you have selected.

	`0` — Proof of Personhood	`1` — Art & Social Experiments	`2` — Zero-Knowledge & Cryptography
`BOUNTY_ID`	`0`	`1`	`2`
`CURATOR_ACCOUNT`	`HfMgvo7Lfuymg9sxii2H747rXdts5be6UfLPp6kXS4cNE9u`	`HyfBoVzPkikGdDv5P9pNoMkHrQJ5LvktdXwiv9RntbrTHi4`	`DVYbCSWbNfNxA2DXK1TUJSUaBYZVyeVq6AEvmp98S2nn3LH`
`CURATOR_MULTISIG`	`FhDqdZBwWH16Auzttnc4hurJNVHNZYguMGPWxY2Bjzzxt6G`	`HNAgeYNFWJeNXBoe5Nf5KHLY5q2hp8X2UJNJjFGnrU8YYjw`	`D3LkMK27GeTV924MVcHJHDPwuHrk1jovzvAKKAoh3SJJHed`

Placeholders used below

The steps below carry these names wrapped in angle brackets. The workbench replaces each with the real value for whatever bounty and child you have selected; read this file directly on GitHub and they stay as written. Names are listed bare here so the table itself is not substituted.

Name	Source
`BOUNTY_ID`	the bounty you selected — `0`, `1` or `2`
`CURATOR_ACCOUNT`	from `multiAssetBounties.bounties(BOUNTY_ID)`
`CURATOR_MULTISIG`	from `proxy.proxies(CURATOR_ACCOUNT)`, the type-`7` Governance delegate
`PARENT_VALUE`	the parent bounty's allocated value, in planck, from `multiAssetBounties.bounties(BOUNTY_ID)`
`PARENT_VALUE_DOT`	the same value rendered in DOT
`CHILD_ID`	the child bounty you selected
`CHILD_VALUE`	its recorded value, in planck
`CHILD_VALUE_DOT`	the same value rendered in DOT
`CHILD_METADATA`	its metadata hash, from the child bounty record
`BENEFICIARY_SS58` / `BENEFICIARY_HEX`	read from chain once the child bounty is awarded; you supply it beforehand — see 4.1
`PREIMAGE_HASH`	you supply it — the hash of the metadata you write in Step 1
`PREIMAGE_LEN`	the byte length of that metadata, needed for the `preimageFor` query
`CURATOR_ACCOUNT_ID`	a structural marker inside a worked example, never filled
`BENEFICIARY_ACCOUNT_ID`	same, for the beneficiary — 4.6 stays structural so it cannot be reassembled

The two marked you supply it are never auto-filled, because nothing on chain can tell you what they should be. Everything else is read.

Curator accounts read from multiAssetBounties.bounties(BOUNTY_ID); multisigs read from proxy.proxies(CURATOR_ACCOUNT), taking the delegate with proxy type 7 (Governance). Both queried on Kusama Asset Hub, 23 Aug 2026. Bounty 0's entries match the values this document was originally written with, which is what validates the method for the other two.

Every curator account also carries a second delegate with proxy type 0 (Any): EFuprYL5sShF5qao4F9hVRrkbutFeoAgn4HHehq4Rkx3ahm. It is the same account across all three bounties and holds unrestricted authority over each curator account — worth knowing about, not something curators act through.

Where this document says a transaction can be submitted by a curator multisig signatory, it means any one of that bounty's signatories can initiate or submit it. The operation still needs the bounty's threshold in approvals before it executes.

Governance proxy

The curator multisig uses a Governance proxy to act on behalf of the parent curator/proxied account.

When this document says:

curator multisig via Governance proxy

it means the operation should be structured as:

curator multisig
  → proxy.proxy
      real: <CURATOR_ACCOUNT>
      force_proxy_type: Governance
      call: <nested call>

Signing tool

The steps below were written and tested in Nova Spektr — the desktop wallet, not Nova Wallet. They are different products from the same team: Nova Wallet is the mobile wallet, Nova Spektr is the desktop client with the multisig and proxy workflow.

In Nova Spektr the arbitrary-call surface is Custom operation → Build an operation — not the multisig transfer/staking flow, and not documented on the docs site at the time of writing. It offers Paste for raw call data and Build for a metadata-driven form with typed argument fields.

Nothing in this runbook depends on Nova Spektr specifically. Any client works if it can do all four of these:

Needs to	Why
Connect to Kusama Asset Hub and load current runtime metadata	the bounty pallet is not in any hardcoded call list; the client has to read it from the chain
Build an arbitrary pallet call, not just transfers and staking	every call here comes from `multiAssetBounties`
Wrap a call in `proxy.proxy` with an explicit `force_proxy_type`	`Governance` has to be set deliberately, not defaulted
Submit as `multisig.as_multi` and show the call hash and call data	co-signers verify the hash; the chain stores only the hash, so the last signatory must supply the call data

Polkadot.js Apps (Developer → Extrinsics) meets all four and is the fallback when a wallet cannot build the nested call. Other multisig clients exist — Mimir, Multix, Signet, Polkasafe — but none of them has been run against these steps. Treat them as untested rather than unsupported.

If signatories use different clients: an operation created outside Nova Spektr shows there as an “Unknown” operation, because it cannot decode what it did not build. It can still be signed and executed. Verify it by call hash in that case, not by the description on screen. Operations built through Custom operation do decode by name for everyone on Nova Spektr — Multi asset bounties: Award bounty and so on.

Child bounties

Child bounty value

Beneficiary

Runbook