Technical Architecture
System design for engineers, protocol designers, and auditors.
This section describes DOER DAPP as a protocol system, not simply a wallet product. It explains how authority, automation, validation, and risk analysis are handled across both on-chain and off-chain components.
This document assumes familiarity with:
wallet-based account models
on-chain permission systems
smart contract execution
off-chain orchestration systems
1. Design Objective Revisited
The primary objective of DOER DAPP is to enable safe programmable wallet behavior through bounded authority and deterministic enforcement.
Most automation systems fail because authority is either:
too granular (requiring constant user approval), or
too coarse (granting long-lived permissions that cannot be safely constrained).
DOER DAPP introduces a third model: policy-driven intent execution.
Automation is allowed, but only within strict user-defined boundaries.
Key architectural invariants:
Authority cannot silently expand
Execution cannot occur outside declared intent
Revocation is immediate and irreversible
Off-chain logic cannot override on-chain enforcement
Every automated action must pass policy validation
These guarantees are enforced by the DoerPolicy system.
2. Authority Model
DOER DAPP separates authority into multiple layers to prevent privilege escalation and authority collapse.
2.1 Authority Layers
Ownership Authority
Retained entirely by the user. Ownership authority governs asset control and key management. This authority is never delegated to DOER DAPP.
Intent Authority
Defines what outcomes are acceptable. An intent describes a goal and a constraint set that determines when execution is allowed. Intent authority is passive until paired with execution authority.
Execution Authority
Granted through mandates. Execution authority allows a designated executor to attempt transaction proposals under strict limits. Execution authority is always subordinate to intent authority.
Policy Authority
Policies enforce operational constraints on execution. Examples include:
gas limits
execution frequency
contract allowlists
spending ceilings
Policy checks occur during every execution attempt.
No system component ever holds both ownership authority and execution authority simultaneously.
2.2 Authority Invariants
The following invariants are enforced at the protocol level:
Execution authority must reference a valid intent
Mandates cannot outlive their declared expiry
Revoked mandates cannot be resurrected
Execution cannot mutate intent state
Automation cannot bypass policy constraints
Off-chain components possess zero authority
Any violation of these rules results in deterministic execution failure.
3. Intent Model (Formal Perspective)
An intent is a declarative object that defines permissible state transitions. It describes:
a target outcome
a constraint system
temporal validity rules
3.1 Intent as a Constraint System
Conceptually, an intent defines the predicate: Execute(action) ⇒ Constraints(action) == true
Constraints may include:
program allowlists
asset allowlists
amount ceilings
time windows
state predicates
Only actions satisfying the full constraint set are valid.
3.2 Immutability and Auditability
Once registered:
Intent constraints cannot be modified
Every execution can be traced back to the originating intent
Observers can independently verify authorization
This provides deterministic auditability for automation systems.
4. Mandate Model (Execution Rights)
Mandates are the only mechanism through which execution authority is granted. They bind:
an intent
an executor identity
a scope of execution
4.1 Mandatory Mandate Properties
Each mandate includes enforced limits.
Executor Scope
Single executor or bounded executor set.
Temporal Scope
Start time and hard expiration.
Usage Limits
Maximum executions and optional rate limits.
Value Limits
Per-execution spending caps and aggregate ceilings.
All limits are enforced on-chain.
4.2 Mandate Lifecycle
Mandates follow a strict lifecycle: Created Active Expired or Revoked Terminal Terminal mandates cannot be reactivated.
5. Execution Model
Execution in DOER DAPP is proposal-based, not imperative. Executors do not perform actions directly. They propose transactions that must pass protocol validation.
5.1 Execution Proposal
An executor submits a proposal referencing:
intent
mandate
proposed transaction
The proposal asserts: “This transaction satisfies all constraints.”
5.2 Deterministic Validation
Before execution occurs:
intent constraints are evaluated
mandate validity is verified
policy limits are enforced
usage counters are updated
Validation is deterministic and executed entirely on-chain. If any check fails, execution aborts atomically.
6. On-Chain vs Off-Chain Responsibilities
6.1 On-Chain (Authoritative Layer)
The protocol layer enforces:
authority validation
policy enforcement
mandate lifecycle
execution settlement
revocation guarantees
task reward settlement
reputation updates
This layer is the final arbiter of execution validity.
6.2 Off-Chain (Executor Network)
Off-chain services perform orchestration tasks. They may:
monitor intents and policies
detect trigger conditions
schedule executions
submit execution proposals
They cannot:
bypass validation
expand permissions
alter policies
execute transactions directly
Executors are treated as untrusted infrastructure.
7. Transaction Risk Intelligence Layer
DOER DAPP introduces a transaction risk analysis system to improve user visibility before signing transactions. Before approval, the wallet evaluates:
token approval amounts
contract verification status
contract deployment age
program reputation
interaction type
A risk score is generated using heuristic evaluation. Example model:
if unlimitedApproval: +3
if contractUnknown: +4
if contractNew: +2
Risk levels:
0–2 → Low
3–5 → Medium
6+ → High
Users receive a clear preview before signing. Example:
Spending Limit: Unlimited
Contract Risk Level: Medium
This improves transparency and reduces accidental approvals.
8. On-Chain Work & Task System
DOER DAPP expands beyond automation by introducing a task and reward protocol. Projects and DAOs can post tasks directly on-chain. Users can complete tasks and receive rewards from escrow.
Core Accounts
TaskAccount
Represents an on-chain job or bounty. Fields include:
creator
reward token
reward amount
deadline
task metadata
WorkerSubmission
Represents proof of task completion. Fields include:
worker
task reference
proof URI
verification status
RewardVault
Escrow holding reward tokens until work verification.
Reputation System
A lightweight on-chain reputation record tracks work history. WorkerReputation includes:
tasks_completed
tasks_failed
total_earned
Over time, this creates a verifiable on-chain work profile.
9. Failure Modes and Guarantees
Executor Misbehavior
If an executor submits an invalid proposal: Execution fails. No state change occurs.
Off-Chain Compromise
Even if off-chain systems fail or behave maliciously: Policies remain enforced. Users retain revocation authority.
User Error
DOER DAPP enforces constraints exactly as defined. It does not infer user intent or protect against unclear rule definitions.
10. Integration Patterns
Wallet Integrations
Wallets can visualize: active intents, policy limits, risk analysis, execution history. Wallets do not require execution logic.
Automation Tool Integrations
External tools may propose execution. They must respect policy constraints. They never receive permanent permissions.
DAO Integrations
DAOs can: delegate spending authority, enforce operational budgets, enable time-bounded execution authority. This enables safer treasury automation.
11. Security Assumptions
The system assumes the following adversarial conditions: • executors may be malicious • off-chain systems may fail • users may misunderstand permissions
Therefore the protocol enforces:
minimized authority
explicit constraints
deterministic validation
absolute revocation guarantees
12. What DOER DAPP Deliberately Does Not Solve
Certain risks remain outside the protocol scope. These include:
market volatility
vulnerabilities in external smart contracts
poor user judgment
fully autonomous financial agents
The protocol enforces authority boundaries, not economic correctness.
13. Mental Model for Builders
Think of DOER DAPP as:
a permission firewall
a rule engine for execution authority
a policy layer for wallet behavior
Your system proposes actions. DOER DAPP decides whether they are allowed.
14. Evaluation Checklist for Builders
Before integrating with DOER DAPP:
What authority does your system require?
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 for your architecture.
Architectural Summary
DOER DAPP is designed to make authority explicit, limited, and enforceable. For developers and protocol designers, this enables powerful automation systems without introducing hidden permission risk. The constraint is intentional. Safety is part of the architecture.