Launch a DAO from TypeScript

Use @daoships/sdk@0.1.0-alpha.4 to construct and verify a launch. The SDK supports direct DAO launches against an existing vault, combined launches with an existing vault, and combined launches that create a new vault. The CLI supplies executable versions of these workflows, including encrypted signing and local recovery.

npm install @daoships/sdk@0.1.0-alpha.4 quais@1.0.0-alpha.53

The following example prepares an existing-vault launch. It does not broadcast. Supply the Orchard launcher from the contract reference, the intended vault and the public deployment account. That account must be a Cyprus-1 Quai account.

Build and simulate a plan

import { ZeroAddress } from 'quais';
import {
  DaoShipsProvider, discoverDeployment, mineDAOShipSalts,
  buildDAOShipLaunchPlan, prepareDAOShipLaunch, stringify,
} from '@daoships/sdk';
 
export async function planExistingVaultLaunch(
  launcher: string, vault: string, sender: string,
) {
  const provider = new DaoShipsProvider(
    'https://orchard.rpc.quai.network/cyprus1', 15000,
    { usePathing: false },
  );
  try {
    const deployment = (await discoverDeployment(provider, {
      chainId: 15000, launcher,
    })).contracts;
    const salts = await mineDAOShipSalts({
      factory: deployment.daoShipLauncher,
      sender: deployment.daoShipAndVaultLauncher,
      singletons: {
        daoShip: deployment.daoShipSingleton,
        shares: deployment.sharesSingleton,
        loot: deployment.lootSingleton,
      },
      maxAttempts: 100_000,
    });
    const plan = buildDAOShipLaunchPlan({
      chainId: 15000, from: sender, deployment,
      route: 'existing-vault', existingVault: vault,
      parameters: {
        shareTokenName: 'Crew Shares', shareTokenSymbol: 'CREW',
        lootTokenName: 'Crew Loot', lootTokenSymbol: 'LOOT',
        sharesSalt: salts.shares.salt, lootSalt: salts.loot.salt,
        daoShipSalt: salts.daoShip.salt,
        initialization: {
          multisendLibrary: deployment.multisendCallOnly,
          governanceConfig: {
            votingPeriod: 86_400, gracePeriod: 86_400,
            proposalOffering: 0n, quorumPercent: 2_000n,
            sponsorThreshold: 10n ** 18n, minRetentionPercent: 0n,
            defaultExpiryWindow: 604_800,
          },
          navigators: [], navigatorPermissions: [],
          initMembers: [sender], initShareAmounts: [100n * 10n ** 18n],
          initLootAmounts: [0n], guildTokens: [ZeroAddress],
          pauseSharesOnLaunch: false, pauseLootOnLaunch: false,
        },
      },
    });
    const prepared = await prepareDAOShipLaunch(plan, provider);
    return { plan, prepared, serializedPlan: stringify(plan) };
  } finally {
    provider.destroy();
  }
}

The configuration is illustrative; choose voting, grace, threshold and treasury policies for your DAO. Percentages are basis points (2000 means 20%). Token allocations use exact base units. The typed configuration includes all seven governance fields and the complete launcher initialization layout.

The plan records expected addresses and ordered steps. Preflight checks the network, launcher references, predicted addresses and current deployment prerequisites at a fixed block. Discovery verifies a consistent graph of deployed contracts; it does not authenticate who selected the launcher.

Complete vault setup and verify

For an existing vault, the DAO module must be enabled and MultiSend delegatecall permission established through authorized vault owner execution. Follow the plan's vault steps and verify the final execution receipt with verifyDeploymentWorkflowStep. A transaction proposal or owner approval alone is not completed setup.

For a new-vault plan, supply owners, threshold and verified QuaiVault proxy creation bytecode. mineDAOShipSalts first mines the DAO/token addresses, then the vault using the predicted DAO as its initial module. buildDAOShipLaunchPlan uses route new-vault, vaultSalt and vaultProxyBytecode. Obtain that bytecode from the verified vault build for the selected factory; the navigator bytecode bundle does not supply vault infrastructure.

For a direct plan, use the direct launcher and mine salts with the account that calls that launcher as sender. Combined routes use the combined launcher as the factory's sender. The SDK validates these route-dependent predictions; do not reuse salts mined with a different sender.

Execute with durable checkpoints

advanceDeploymentWorkflow advances one step at a time using an atomic DeploymentWorkflowStore and caller-supplied executors. Executors obtain the correct signer or vault/DAO authorization and persist transaction hashes before waiting. reconcileDeploymentWorkflowStep handles a mined transaction whose acknowledgement was lost.

The SDK never supplies a private key, keystore or approval policy. Use the SDK transaction and recovery boundary, or use the CLI's launch plan, launch execute, workflow prepare and workflow verify commands. Review the plan before a send and preserve its operation IDs across restarts.

Add navigators and metadata

buildNavigatorDeploymentPlan covers all eight built-in navigators. Native CREATE needs a nonce and a Cyprus-1 address prepared by a Quai-aware executor; the CLI implements this. Activation is separate: DAO roles, Budget's vault module permission, and Signal's governance endorsement have different requirements. Creating a contract does not activate it.

Use buildDaoProfileUpdate and encodePosterPost for DAO metadata. Carry forward fields that should remain unchanged, and post through the correct authorized route. A raw metadata post from an arbitrary signer cannot establish DAO authority. Proposal actions should use encodeProposal and buildGovernanceAction, with commitment and outcome checks during processing.

SDK deployment workflow reference · CLI deployment examples · Coverage and testing