Function create_did 

pub fn create_did(
    ctx: &mut SpendContext,
    funding_coin: Coin,
    owner: Owner,
    recovery_list_hash: Option<Bytes32>,
    num_verifications_required: u64,
    metadata: HashedPtr,
) -> DidResult<DidSpend>

Mints a brand-new DID, fully settled and wallet-parseable, from a funding coin.

Spends funding_coin (owned by owner) to create the launcher, launches the eve DID with the given recovery configuration and metadata, then performs the owner-update (“settle”) spend that confirms the DID for wallets. Returns a DidSpend whose child is the fully-created, spendable Did.

The funding coin becomes the DID, in full

The singleton’s amount IS funding_coin.amount — the whole coin, because this crate builds spends and emits no change output (choosing where change goes is caller policy). Two consequences the caller owns:

• The amount MUST be ODD, or no singleton is created at all and the coin is spent for nothing. Refused here with crate::DidError::EvenSingletonAmount.
• Any excess is locked in the identity coin forever. Pass a coin pre-split to EXACTLY the amount the DID should carry — dig-account splits an exact 1-mojo coin off its source coin and calls in with that, which is the reference pattern.

Signature

Two AGG_SIG_ME signatures are required, both under whichever key/spend owner names (SPEC §3): one over the funding-coin spend (which creates the launcher) and one over the settle spend (which confirms the DID for wallets). Both are coin-bound AGG_SIG_ME, never AGG_SIG_UNSAFE.

Errors

• crate::DidError::UnsupportedOwner if owner is Owner::Custom — see below.
• crate::DidError::EvenSingletonAmount if funding_coin.amount is even — see above.
• Any chia-wallet-sdk driver failure (currying, spend construction) as crate::DidError::Driver.

Owner::Custom

Refused. A create is two spends of two different coins, and a pre-built inner spend is one fixed (puzzle, solution) pair emitting one fixed condition set, so it cannot serve both. Three independent reasons, each sufficient on its own:

1. Different coins, one condition set. The funding coin must emit the launcher’s create/announcement conditions; the DID coin must emit its own recreation. One spend cannot emit both.
2. Circular. The recreation condition needs did.info.inner_puzzle_hash(), which does not exist until create_eve_did has run inside this call. No caller can precompute it.
3. Actively wrong, not merely insufficient. With a custom owner the DID’s p2 puzzle IS the caller’s puzzle, so replaying that solution on the DID coin re-emits the FUNDING conditions — a second launcher CREATE_COIN from the DID coin, not a settle.

Additionally, any AGG_SIG_ME baked into a custom spend is coin-bound and therefore valid for at most one of the two coins.

A caller that genuinely needs a custom DID p2 puzzle wants a launch-conditions builder it can compose into its own parent spend (mirroring dig_merkle’s mint_datastore_launch_with_kind), not this end-to-end builder.