Native programs and product protocols

Native programs give applications account management, token operations, trading and coordination primitives within Singularity's shared transaction execution. Their value is composition: an application can pass declared account capabilities between supported execution environments without first moving its assets to a separate chain.

Choose a primitive by the state transition you need, then check its authority and deployment requirements. A registered native program is executable runtime functionality; a helper module or a background-service constructor establishes a different, narrower capability. The native registry and executor dispatch establish the first boundary.

Choose the application building block

The protocol primitives and asset/identity model own the shared foundations. This chapter concentrates on the application-specific mechanisms.

Constant-product swaps: reserves, custody and slippage

The AMM stores a 120-byte pool header containing two reserves, aggregate LP supply, pool authority and the two mint keys. Its implemented instruction enum contains CreatePool, Deposit, SwapAForB and SwapBForA. It does not expose a liquidity-withdrawal instruction in that enum, despite the broader introductory comment.

Each instruction takes the same six accounts in this order:

pool, user, vault_a, vault_b, user_token_a, user_token_b

The user must sign. The pool and four token accounts must be writable. Vault token owners must match the pool key; user token owners must match the user; mints, token-program ownership, initialized state and canonical account layout are checked. Amounts are SPL token base units, not the accounts' SING balances. Swaps use a 997/1000 input multiplier, corresponding to a 0.3% fee, and reject output below min_out. Pool format and instruction contract.

For example, a wallet building an A-to-B swap supplies its A and B token accounts, both vaults and the pool. It specifies an integer input and a minimum acceptable B output. A successful execution changes the token balances and pool reserves together through the outer changeset. A wrong mint, missing signature, insufficient token balance or slippage failure rejects the operation.

Two consequences matter before using this as a financial product:

• The pool account is created with an ordinary keypair, and the pool key is the vaults' token authority. A holder of that private key can authorize token transfers outside the AMM. The source explicitly identifies replacing that authority with a PDA as unfinished custody work.
• Direct donations to a vault are surplus outside recorded reserves. Ignoring that surplus prevents a one-unit donation from making every subsequent swap fail. Aggregate LP supply alone is not a complete user-owned LP token and redemption system.

These are concrete integration boundaries, not evidence of a deployed trustless exchange. The AMM tests cover funded swaps, mint/owner checks, alias rejection, slippage, pool initialization and donation behavior. They were inspected for this documentation, not executed.

Liquid staking: an explicit pool accounting model

The liquid-staking program maintains a pool, per-user UserStAccount balances, delayed-withdrawal tickets, proposals and vote records. Its exchange rate is the integer ratio of backing lamports to pool-token supply; an empty supply starts at 1:1. The user balance is a program-specific account, so an stSING label does not by itself establish compatibility with ordinary SPL-token wallets.

The source sets a minimum deposit of 100,000,000 lamports, a default reward fee of 500 basis points, a maximum fee of 1,000 basis points and a one-epoch delayed-withdrawal cooldown. These describe this implementation, not a return promise or a deployed pool's policy. Pool state and constants.

Reward settlement is especially important. UpdateEpoch { rewards_earned } takes the pool, its manager and a funding source. The manager must sign; a positive reward also requires the funding source's signature and sufficient lamports. The funding account is debited exactly what the pool receives. The program cannot independently establish that the caller-supplied amount was earned by validators. This is a manager-backed pool update, not permissionless creation of new SING or automatic linkage to validator reward distribution. Reward update.

An integration must arrange the funding, update cadence, withdrawal liquidity and governance account lifecycle. Consensus staking and validator activation have a separate validator lifecycle.

Workflows and collateral composition

The workflow router encodes up to 16 legs in declared order. A leg may splice return bytes from a strictly earlier leg into its calldata. This backward-reference rule makes the list an acyclic dataflow graph without a separate scheduling algorithm. Opcode 1 adds per-leg account references with signer and writable flags; references cannot create authority absent from the enclosing instruction.

Successful legs share a transaction journal, so later legs can read earlier staged writes. A failed leg or final write-claim conflict aborts the transaction's state changes. The concrete targets are EVM, WASM, BPF, Move and native SVM; Bombil's place in the architecture does not add a Bombil discriminator to this interface. Router format, limits and semantics.

The RWA collateral program provides a specific composition example: initialize a vault with an EVM DEX address, then post collateral and update a user's position using the EVM result. The executor implements separate signed initialization and post-collateral paths. This demonstrates a local cross-VM accounting flow; the name “RWA” does not establish off-chain asset custody, legal redemption or a valuation oracle. Collateral dispatcher. Use cross-VM composition for the transaction and failure model.

Agents and tools: durable records versus external work

Agent records identify authorities and delegated permissions. A2A records describe agents, tasks, messages, artifacts and escrow transitions. MCP records tools, resources, prompts, invocation logs and spending mandates. These programs are currently dispatched by the native executor; older “wiring instructions” in module comments are not an accurate statement that dispatch is still absent.

An ordinary MCP InvokeTool checks access, funds a new log account and records the input hash with success: false and empty output/result hashes. It increments the invocation count. That transition does not perform an HTTP request or prove that an external service completed the work. A separate result or mandate operation has its own authority and schema. The production wrapper calls the signed instruction handler and applies writable/alias checks. Invocation creation, signed dispatch.

Trigger accounts likewise represent pending work. The repository contains scan_and_process_triggers, but the inspected runtime has no production call site for that scanner. A comment saying it runs after a block is insufficient to establish automatic execution. An agent integration must identify the actual worker, its credentials, retries and result authorization. Scanner helper.

Market context and strategy helpers

Optional oracle configuration connects a Hermes fetcher to block production. BlockOracleData carries feed records in deterministic order and hashes its serialized snapshot into block evidence. Configuring the optional section enables the feed path, with default stale-feed exclusion after 300 seconds. This supplies a shared price snapshot; applications still need a freshness and confidence policy. It is separate from HILSA's explicit foreign-state verification classes. Oracle configuration, snapshot encoding, node wiring.

The funding-carry module supplies deterministic strategy and reconciliation logic, not a running trading service. Mesh and MEV modules similarly require examination of production call sites: service constructors and dry-run bundle code are not evidence of activated cross-chain infrastructure. Start an application with the smallest executable path whose state, authority and external dependencies you can account for, then use the compatibility reference to check its release and environment.