> For the complete documentation index, see [llms.txt](https://docs.bloxchain.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloxchain.app/developers/integration-surfaces.md). # Integration surfaces Three ways to work with a Bloxchain smart account, often combined on the same contract address. ## The three surfaces | Surface | What it is | Best for | Who runs it | Requires | | -------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------- | ---------------------------------------------------- | | **Bloxchain Platform** (bloxchain.app) | Browser workspace for operators. Non-custodial: your wallet signs, Bloxchain never holds a key. | Deploying and importing accounts, approvals, policy setup, history, no custom UI | Hosted by Particle CS. **Alpha · Testnet · Local-first.** | A browser and a wallet on Sepolia | | **SDK** (`@bloxchain/sdk`) | Open-source TypeScript library, part of the Protocol | Automation, services, CI/CD deploys, embedding governed flows in your own app | You: your infrastructure, your keys, your RPC | Node.js, `viem`, an RPC endpoint and a key or wallet | | **Bloxchain Protocol** (Solidity) | The on-chain contracts. Source of truth for every rule. | Custom deployments, extensions, audited baselines | You deploy and govern the bytecode | Solidity tooling and a deployment pipeline | All three enforce the same policy, because the policy lives in the account contract. A denial on chain cannot be bypassed by any client. They differ in how much you build, not in how the rules are enforced. ## Choosing | If you want to | Use | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Try Bloxchain in fifteen minutes | The Platform: [Quickstart](/get-started/quickstart.md) | | Operate a shared treasury with several approvers | The Platform, with the SDK for any automation | | Run scheduled or programmatic requests | The SDK: [Developer quickstart](/get-started/developer-quickstart.md) | | Deploy on a network the Platform does not list yet, or change contract behaviour | The Protocol contracts: [Deploy the Protocol](/developers/deployment.md) | | Let an AI agent act under governance | The SDK: [For AI agents](/developers/for-ai-agents.md) | ## The Platform as it is today * **Free on this device.** No sign-in. Connect a wallet, deploy or import accounts, operate them. The account list and custom networks stay in your browser (**This device**). Back them up from **Settings → Backup**. * **Sign in for extras.** Alerts (in-app bell, email), watched addresses, profile and privacy settings. Sign in if you have early access. Otherwise join the waitlist from the same dialog. The Free path needs no account. * **Organizations for shared workspaces.** A paid organization (Pro, Team, Enterprise) adds a shared account list (**Cloud**), member addresses, members and roles, billing. * **Sepolia today.** The Platform runs on Sepolia today. Ethereum mainnet is coming soon. See [Free, sign-in, and organizations](/introduction/free-sign-in-organizations.md) and the [Platform guide](/platform-guide/platform.md). ## The SDK The SDK wraps the account contract in typed classes (`SecureOwnable`, `RuntimeRBAC`, `GuardController`, `BaseStateMachine`) plus a meta-transaction signer. You bring your own viem clients and keys. There are no Bloxchain API keys. Setup: [SDK setup and authentication](/developers/sdk-setup.md). Patterns: [SDK core patterns](/developers/sdk-setup/sdk-core-patterns.md). The SDK is part of the Protocol, not a separate product. Both are released together from the [Bloxchain Protocol repository](https://github.com/PracticalParticle/Bloxchain-Protocol/tree/99beac2d6e6d7567c23b25cecaf6f4053f31c987) under the Mozilla Public License 2.0. The SDK does two different jobs, and it is worth keeping them apart when you design an integration. | Job | What it covers | Page | | ------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | | **Operate** | Read state, post requests, approve, sign and submit meta-transactions | [SDK core patterns](/developers/sdk-setup/sdk-core-patterns.md) | | **Configure** | Register actions, create roles, assign each step of an execution path, grant gates, manage allowlists, in signed batches | [Configure an account programmatically](/developers/sdk-setup/configure-programmatically.md) | Configuring from code is the part most integrations miss. It is what makes many accounts, repeatable environments and CI possible, because the same script produces the same policy on every account. ## The Protocol Clone the repository at the pinned commit, deploy the foundation libraries and an account template, then operate the result from either client. Official deployments are immutable clones; upgradeable proxies are possible with your own factory. See [Deploy the Protocol](/developers/deployment.md) and the [Protocol documentation](/protocol-reference/protocol.md). ## Hybrid patterns **Operate in the Platform, automate with the SDK.** People deploy, configure policy and approve in bloxchain.app. A service holds a **Broadcaster** key and submits signed approvals or one-signature requests with the SDK, paying gas. The service can only do what the Broadcaster role and the action's permissions allow. **Script the setup, operate in the Platform.** A script deploys an account and configures its actions, roles, permissions, gates and allowlists in a few signed batches. The team then works in bloxchain.app: **New request**, **Approvals**, **History**. The result is indistinguishable from an account configured by hand, because the policy lives in the contract. This is the usual pattern for a team that runs more than one account. See [Configure an account programmatically](/developers/sdk-setup/configure-programmatically.md) and [Ways to configure an account](/guides/ways-to-configure.md). **Deploy with the SDK, operate in the Platform.** Deploy an account from the Protocol or with `npm run create-wallet`, then open bloxchain.app → **Accounts → Import**, choose the network, paste the contract address and select **Import**. The account appears on this device and every rail page works against it. See [Import an account](/platform-guide/accounts/import.md). **Sign in one place, submit in another.** An approver signs in the Platform and exports a signed file (`.bloxmeta.json`). Your broadcaster service, or another Platform user, submits it before it expires. See [Signed files](/platform-guide/operate/signed-files.md). Policy changes always go through governed on-chain operations, whichever client you use. ## Version alignment Pin `@bloxchain/sdk`, `@bloxchain/contracts` and the deployed bytecode to the same Protocol release. See [Releases and compatibility](/resources/releases.md). ## Related * [How governed operations work](/introduction/how-it-works.md) * [Supported networks](/introduction/supported-networks.md) * [Production readiness](/developers/deployment/production-readiness.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bloxchain.app/developers/integration-surfaces.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.