# Onchain Coordination: Identity, Consent, Credentials, and Programs By [Orchestra](https://paragraph.com/@orchestra) · 2025-07-10 --- > _Orchestra isn’t just a ledger. It’s a social computer — one that understands identity, intent, and trust as first-class primitives._ * * * The Problem: Wallets Are Not People, and Signatures Are Not Coordination ------------------------------------------------------------------------ For the past decade, onchain interaction has been modeled as signing a transaction with a private key. But signing isn’t coordination. It’s just cryptographic agreement. When protocols rely only on wallet signatures, they lose the nuance of: * **Who is signing** (person? organization? delegated actor?) * **What the signature represents** (intent? approval? endorsement?) * **How agreement should unfold** (multi-party? threshold-based? reversible?) In the real world, coordination is layered: * You trust people, not public keys. * You grant roles, not raw access. * You approve things with context, not click-throughs. * You want workflows that reflect human and institutional behavior. Most chains force these behaviors offchain — in Telegram groups, Notion docs, legal contracts. Orchestra brings them onchain, natively, legibly, and composably. * * * Orchestra’s Approach: Modeling Human Coordination as Onchain Logic ------------------------------------------------------------------ At the heart of Orchestra is a simple principle: > **Coordination is data.** And so Orchestra models coordination not as contract code, but as structured data and events that: * Describe **who** is involved * Express **what** is being proposed or consented to * Show **why** something is valid (via credentials, relationships, rules) * Allow others — machines or people — to subscribe, verify, and respond Let’s break this down. * * * Identity: More Than a Wallet ---------------------------- Orchestra identities are: * **Named** (optional) * **Delegable** (others can act on your behalf) * **Recoverable** (you can set trusted recovery agents) * **Linked** (to assets, credentials, claims) * **Auditable** (via history logs and relationships) Each identity can hold: * Credentials (e.g. “KYC verified”, “licensed custodian”) * Reputation scores (derived from participation and trust) * Delegations (for automation or human fallback) This means “Alice” isn’t just `0xabc...` — she might be: * The creator of asset X * A voting member in a collective * A verified medical provider * A trusted actor in a reputation graph * * * Consent: Intent, Approval, Execution ------------------------------------ Orchestra supports a formalized **intent model**, where multi-party actions follow this lifecycle: 1. **Declare Intent** A user proposes an action (e.g., transfer ownership of an asset, update credentials). 2. **Gather Approvals** Other parties — identities or collectives — approve or reject it. 3. **Execute When Ready** Once quorum is met, the action can be executed onchain. This models real-world agreements: * Asset transfers that require custodian sign-off * Legal documents requiring board approval * Programmatic conditions like “after 3 of 5 consents, execute within 72h” * * * Credentials: Structured Trust ----------------------------- Any identity in Orchestra can **issue** or **receive** credentials. These are JSON documents with: * A type (e.g. `AccreditedInvestor`, `Verifier`, `InspectedFacility`) * A subject (identity or asset) * Optional schema validation * A validity window Credentials are: * **Revocable** * **Queryable** * **Attachable to rules or access conditions** This enables systems where, for example: * Only credentialed identities can mint regulated assets * A DAO only accepts proposals from members with a “Delegate” credential * Transfer rules require a “KYC Level 2” credential from a trusted issuer * * * Collectives: Shared Authority, Threshold Logic ---------------------------------------------- Orchestra lets identities form **named collectives**: * With explicit membership * With quorum and role rules * With metadata and lifecycle hooks Collectives can: * Hold assets * Approve intents * Vote on proposals * Act as credential issuers or program owners And since collectives can hold credentials and have reputation, they become composable governance actors — useful in both DAO and enterprise settings. * * * Programs: Composable Workflows ------------------------------ Orchestra’s `CREATE_PROGRAM` feature lets users define **multi-transaction workflows**: * A series of transactions * Executed sequentially or conditionally * Bound to identities, assets, or collectives This enables: * Custom onboarding flows (“register identity → issue credential → link asset”) * Automated compliance (“submit report → approve → issue status update”) * Recovery sequences (“delegate → revoke → transfer ownership”) And because programs emit events at each step, external systems (like analytics dashboards, regulators, or bots) can stay in sync. * * * Real-World Use Cases -------------------- Here’s how these pieces combine in the real world: ### 🏛️ A Local Government Registers Land Titles * Land office is a credentialed identity * Each title is a tokenized asset * Ownership requires a verified identity + land surveyor credential * Transfers emit events and update public registries * Disputes trigger a multi-party consent intent with attached proofs ### 🧪 A Supply Chain Verifies Product Authenticity * Each product is an Orchestra asset * Manufacturers, transporters, and retailers hold credentials * Chain of custody is enforced via rules and recorded in the asset history * Consumers can verify authenticity via webhooks and indexed events ### 🛡️ A DAO Governs a Regulated RWA Fund * Members hold credentials and participate in a collective * Fund assets are Orchestra-native tokens with lifecycle rules * Proposals require multi-party approval + credential checks * Reputation scores influence proposal weight or submission limits * * * Why It Matters -------------- Onchain coordination isn’t just about being decentralized. It’s about being **legible, secure, and programmable** in ways that mirror real institutional behavior. Orchestra brings this to the base layer: * You don’t need to write a smart contract to model consent. * You don’t need a multisig to manage shared ownership. * You don’t need offchain spreadsheets to track roles or rules. Everything — identity, approval, roles, and program logic — is modeled natively. * * * What’s Next ----------- In upcoming updates, Orchestra will: * Support **attestation export** for trust portability * Introduce **zk-compatible credential proofs** * Expand its **reputation graph** for more fine-grained automation * Enable **cross-chain trust verification** via anchored claims and proofs We’re building a system where institutions, collectives, and autonomous agents can coordinate with the same precision and trust they expect from legal infrastructure — but programmable, composable, and onchain. ### 👋 Want to Follow Orchestra? Follow us on Mirror and stay tuned for updates. --- *Originally published on [Orchestra](https://paragraph.com/@orchestra/onchain-coordination-identity-consent-credentials-and-programs)*