evangelEVANGEL DOCUMENTATION / 09
Security and trust
What is enforced, what depends on review, and how to protect your wallet.
Hard rules versus judgment
| Contract-enforced | Depends on people, providers, or markets |
|---|---|
| 21M supply and reserve ceilings | Work quality and useful roadmaps |
| Rolling release limits and notice windows | Identity verification and hidden related parties |
| Fee caps and exact request binding | Truth of liquidity attestations |
| Eligibility freshness and governor-only actions | Quote-asset issuer behavior and continued liquidity |
One authority, openly disclosed
All platform authority is assigned to the Evangel deployer wallet. Separating UI roles does not create independent governance. Compromise or misuse of this wallet can affect approvals, identity decisions, fee policies within caps, and challenge outcomes.
The contract limits still apply, but they do not guarantee honest governance or useful work. Agent review does not decentralize the owner’s signing authority.
Private-key handling
Never put a wallet private key or keystore password in chat, source code, browser forms, .env files, hosting settings, or agent prompts. The website uses an installed wallet for user signatures. Operator scripts use an encrypted local Foundry keystore.
The signer checks that signatures recover the configured public address and restricts transaction signing to Base Sepolia. The key is decrypted by Foundry in local process memory; the Node adapter receives a signature. A compromised computer can still compromise a software keystore.
Application protections
The application bounds streamed request bodies, rejects cross-origin mutation requests, hides provider error details, avoids caching state APIs, and sets anti-framing and content-type headers. Paid hosted provider calls fail closed until a shared rate-limit rule is configured.
These controls are not an exhaustive XSS or application-security proof. Browser wallet prompts must still be reviewed for network, destination, amount, and requested action.
Evidence and agent safety
Repository contents, posts, reports, and other source material are untrusted evidence—not instructions to the agent or signer. Reports must fit the onchain size limit without truncation. Offchain evaluators do not receive transaction keys.
Signing an approval is consequential even when a model produced the recommendation. Inspect exact context and evidence before using the operator signing commands.
Validation and limits
The pairing release passed 52 contract tests, 48 JavaScript tests, 34 browser checks, and a real-browser local-chain launch/buy/sell flow. Internal static analysis findings were triaged, including timestamp and fixed-token transfer warnings. These are historical release checks, not a claim of continuous monitoring.
No independent external audit, formal verification, mainnet readiness, or real tokenized-stock liquidity verification is claimed. A testnet deployment and a public website are separate milestones.
If something looks wrong
- Stop signing additional approvals or transactions.
- Record the chain, transaction hash, contract address, and exact error.
- Check the public receipt and current contract state.
- Use applicable cancellation, refund, or challenge paths while eligible.
- If the authority key is suspected compromised, do not assume editing website configuration revokes contract authority. Current deployments are not upgradeable through a website setting.