Technical Architecture
System design for engineers, protocol designers, and auditors.
This section describes DOER DAPP as a system, not a product. It is written for those who need to understand how authority, execution, and failure are handled within DOER DAPP.
This document assumes familiarity with: Wallet-based account models, On-chain permissioning, Smart contract execution, and Off-chain orchestration.
1. Design Objective Revisited
The primary design objective of DOER DAPP is to enable conditional execution under user-defined authority constraints, without relying on persistent trust assumptions.
Most automation systems fail because authority is either too granular (forcing constant user involvement) or too coarse (granting long-lived, opaque permissions).
DOER DAPP introduces a third model: explicit, bounded, revocable authority.
Authority cannot silently expand
Execution cannot occur outside declared intent
Revocation is final and immediate
Off-chain logic can never override on-chain enforcement
These are not UX decisions. They are architectural invariants.
2. Authority Model
DOER DAPP separates authority into distinct layers to prevent authority collapse.
2.1 Authority Layers
Ownership Authority
Retained entirely by the user. Governs asset ownership and ultimate control. Never delegated to DOER DAPP.
Intent Authority
Defines what outcomes are acceptable. Passive until bound to execution authority. Immutable once registered (except revocation).
Execution Authority
Granted via mandates. Explicit, scoped, and temporary. Always subordinate to intent authority.
No component ever holds both ownership and execution authority.
2.2 Authority Invariants
Execution authority must reference a valid intent
Mandates cannot outlive their declared expiry
Revoked mandates cannot be resurrected
Execution cannot mutate intent state
Off-chain components have zero authority
Any violation of these invariants results in execution failure.
3. Intent Model (Formal Perspective)
An intent is a declarative object that encodes permissible state transitions. It defines a target outcome space, a constraint set over that space, and temporal validity rules.
3.1 Intent as a Constraint System
Conceptually, an intent defines a predicate: Execute(action) ⇒ Constraints(action) == true
Constraints may include:
Program allowlists
Asset allowlists
Amount ceilings
State predicates
Time windows
3.2 Immutability and Auditability
Once registered: An intent’s constraints cannot be modified. Any execution can be traced back to its intent. Observers can independently verify authorization.
4. Mandate Model (Execution Rights)
Mandates are the only mechanism by which execution authority is granted. They bind: An intent, An executor identity, and A scope of execution.
4.1 Mandatory Mandate Properties
Executor Scope
Single executor or bounded set.
Temporal Scope
Start time, Hard expiry.
Usage Limits
Max executions, Optional rate limits.
Value Limits
Per-execution caps, Aggregate caps.
All fields are enforced on-chain.
4.2 Mandate Lifecycle
Mandates move through a strict lifecycle: Created → Active → Expired or Revoked → Terminal (irreversible). There is no “paused” state.
5. Execution Model
Execution in DOER DAPP is proposal-based, not imperative.
5.1 Execution Proposal
An executor submits a proposed action with references to intent and mandate. This proposal asserts: “This action satisfies all declared constraints.”
5.2 Deterministic Validation
Before execution: Intent constraints are evaluated, Mandate validity is checked, Usage/Value limits are enforced. Validation is deterministic, stateless beyond counters, and fully on-chain. Failure at any step aborts execution atomically.
6. On-Chain vs Off-Chain
6.1 On-Chain (Authoritative)
Responsible for: Authority enforcement, Constraint validation, Mandate lifecycle, Revocation, Execution settlement.
6.2 Off-Chain (Advisory Only)
Can: Monitor, Propose, Interpret, Schedule. Cannot: Bypass validation, Extend authority, Modify constraints, Execute directly. Off-chain components are treated as untrusted.
7. Failure Modes and Guarantees
Executor Misbehavior
If invalid proposal or limits exceeded: Execution fails, No state change.
Off-Chain Compromise
Constraints still apply. Users retain revocation power. No additional authority gained.
User Error
DOER DAPP enforces constraints exactly. It does not infer intent. It does not protect against unclear user decisions.
8. Integration Patterns
Wallet Integrations
Visualize intents, surface expiries, enable revocation. No execution logic needed.
Tool Integrations
Propose executions and respect constraints. Tools never receive permanent permissions.
DAO Integrations
Delegate operational authority, enforce budgets, ensure time-bounded execution.
9. Security Assumptions
DOER DAPP assumes: Executors may be malicious, Off-chain logic may fail, Users may misunderstand permissions. Therefore: Authority is minimized, Rules are explicit, Enforcement is deterministic, Revocation is absolute.
10. What DOER DAPP Deliberately Does Not Solve
Market risk
Contract-level exploits in allowed programs
Poor user judgment
Fully autonomous agents
These are outside the system’s scope.
11. Mental Model for Builders
Think of DOER DAPP as: A permission firewall, A rule engine for execution authority, A guardrail not a driver. Your system proposes actions. DOER DAPP decides whether they are allowed.
12. Evaluation Checklist for Builders
What authority do I actually need?
Can that authority be bounded?
Can users revoke it safely?
Can failures be handled gracefully?
If the answer is no, DOER DAPP may not be appropriate.
Closing Statement
DOER DAPP is designed to make authority explicit, limited, and enforceable. For developers, this means building systems that can be powerful without being dangerous. That constraint is intentional.