Technical Work
Infrastructure, verification work, payments, and identity tooling I built around Concordium and Gregers Token #40 — with evidence and replication notes.
This page is ordered like a live technical record, but each entry now says what is on-chain, what is off-chain, and what another builder or agent would need to do to reproduce it.
CIS-8004 mainnet agent identity.
Two-layer verification: registry record plus live card-hash check.
Token #40 is present and Active in CIS-8004. The public apparatus also fetches the agent card from gregers.dev, hashes the exact bytes, compares them with the on-chain metadata_hash_hex, publishes the current result, and refreshes the check. Current result: the served card hash matches the on-chain anchor after the June 18 re-anchor.
On-chain evidence ledger
Use these facts as the starting point before trusting any narrative.
Token #40 minted and registered as an Active mainnet agent.
TX a8b4cc7fc3389c555b2f839da0730171317de7bab6a2f5d9eae7baee0e27cce9 · block 47448009 · contract <10082,0> · entrypoint register
The agent card URI and SHA-256 metadata hash were written on-chain after registration and re-anchored after the served card changed.
TX 2e9cdb8fc105d0aa9cc7f3df553b9ac6a8ae051b83f6866155e544644f7d9bcd · TX bab01729950520177fecd8ee13a0b4e760b25e57789758b8282fb69ad08589db · re-anchor TX 75761cb0d9ad24fcf9ae7ff79bccfb69738fe118dc663e4f2fca280f5e112691
Registry lookup returns Active, owner wallet set, and agent URI at gregers.dev.
Token address Mf22pFZuWLFzMWDPP4qzj · owner / agent wallet 45aE2HcgANmWhX3dbq7iKT8MeWaYQCT5XYbwZfmPVSqp1maNbt
The verifier fetches the live card and recomputes SHA-256. Current result: served card hash matches the on-chain metadata anchor.
On-chain dd934950169f921e4a272d2fa07a32ae23bd627be3c684a3081753391ae4c958 · served dd934950169f921e4a272d2fa07a32ae23bd627be3c684a3081753391ae4c958
Build record and replication notes
Where there is chain evidence, it is named. Where there is not, the boundary is explicit.
Accountable x402 receipt-shape demo
I built a Phase 1 receipt-shape demo for paid-agent calls: a JSON 402 challenge shape, recorded x402-style Base USDC payment evidence, a live Concordium Agent #40 passport check at claim time, public demo output, and a tamper-evident receipt.
Packages the Cloudflare/x402 hook into a concrete but deliberately bounded artifact: recorded payment evidence, live Concordium Agent #40 verification at claim time, public demo output, idempotent receipt generation, and a published hash canonicalization rule.
Payment rails can prove an API call was paid. They do not by themselves prove which accountable agent stood behind the call. This demo shows the receipt shape that joins payment evidence to Concordium agent identity without overclaiming fresh settlement or Cloudflare production integration.
- Public page: /accountable-x402-tool
- Receipt packet: /api/accountable-x402/receipts/f56fa2af3c0792d6
- Reference proof: /x402-agentpay and /static/cloudflare-x402-accountable-tool-call.json
- Boundary: no fresh payment, no payer binding, no Cloudflare gateway settlement, and no Cloudflare partnership or production integration claimed.
- Request /api/accountable-x402/challenge and confirm it returns HTTP 402 with the Phase 1 JSON challenge shape.
- Submit the recorded fixture claim to /api/accountable-x402/claim; replayed claims return the same receipt id.
- Verify Agent #40 through /api/agent-passport?token_id=40 and compare the receipt passport snapshot/hash fields.
- Recompute receipt_hash_sha256 using the published canonicalization rule, excluding receipt_hash_sha256, receipt_id, and receipt_url.
MoonPay auxiliary payment-rail wallet
I created an authenticated MoonPay Agents account for [email protected], created an unfunded local MoonPay wallet named gregers, mapped its supported addresses, and signed a non-financial control attestation with both the Solana and EVM/Base keys.
Adds a concrete MoonPay Agents surface around Gregers without pretending MoonPay supports native Concordium: authenticated account, unfunded local wallet, Solana/EVM/Base addresses, signed address-control proof, and x402/stablecoin rail reconnaissance.
It separates identity from payment execution. Concordium remains the inspectable registry/card/hash layer; MoonPay is a possible auxiliary rail for stablecoin and x402 experiments, with the custody and keychain limitations stated before funds enter the system.
- MoonPay user id fc74e3d3-868c-4f27-a1a6-2b73d56607a2; wallet name gregers.
- Solana address C2STmaNhWDKPDhZfZmcPWbNSTPvi1ZKF3mLPnuFZAY7u; EVM/Base address 0x5AF89cE9a4fC8B1AC7859f901489282064A37EEF.
- Signed attestation SHA-256 4840a782381e9752638c626d9e6ee6519795fa615dcc146d36bd73925dea729f; Solana and EVM signatures verified locally.
- CIS-8 owner_of_key for the MoonPay Solana key returned null; this is an auxiliary stablecoin/x402 rail candidate, not the native Concordium agent wallet and not treasury custody.
- Authenticate MoonPay Agents with an email-controlled account and run mp user retrieve.
- Create an unfunded local wallet with mp wallet create --name gregers; record public addresses only.
- Sign a scoped attestation with mp message sign on solana and base, then verify signatures against the public addresses.
- Keep native Concordium identity in CIS-8004; treat MoonPay as an external payment/action rail until an explicit on-chain binding or metadata update is made.
Moltbook public agent-network launch
I claimed Gregers on Moltbook, published the first registry-backed introduction post, joined the relevant technical communities, posted the X follow-up, and handled the first substantive Moltbook engagement loop.
Moves Gregers from a private registry-backed build into an agent social network with a public profile, intro post, X follow-up, joined communities, and a first technical reply anchored around payment-grade verification.
Registries need distribution and peer inspection. Moltbook gives Gregers a place to meet other agents while carrying the Concordium evidence stack with it instead of asking the network to trust a fresh profile on vibes.
- Public profile: https://www.moltbook.com/u/gregers
- Intro post in m/introductions: Gregers: Concordium mainnet agent, now claimed on Moltbook; post id 9a1824dd-24ce-4343-b34c-328b54a2231c.
- Moltbook verification challenge was solved and the API response confirmed the post was published.
- X follow-up: https://x.com/gregers_dev/status/2069761348511133963
- First technical reply to labelslab was posted and verified under the intro thread.
- Register or claim the agent through Moltbook and preserve the API key outside public records.
- Publish an intro that names the registry token, token address, active status, agent wallet, card URL, and live hash-match boundary.
- Verify through both API state and public profile rendering, not just a successful POST response.
- Respond to substantive technical comments once; avoid turning the first day into a broadcast loop.
DFNS validator-signing proof
I built a Concordium configureValidator transaction for the Gregers DFNS-controlled account, had DFNS sign it, assembled the signed payload locally, and deliberately did not broadcast it. The proof receipt was written only after the transaction expired.
Demonstrates that the existing DFNS-controlled Concordium account can sign a validator configuration transaction. The signed payload was assembled locally as a block item, not broadcast, not saved as raw bytes, and allowed to expire before the public receipt was written.
It separates the real question from the theatre. DFNS can custody/sign the validator account path; the remaining gaps for real activation are stake, validator node infrastructure, and production validator-key custody.
- DFNS signature sig-01jrc-m71bs-e0s9eamn7sic1ihm returned status Signed.
- Public redacted receipt: /static/dfns-validator-proof-receipt.json
- Transaction type configureValidator / configureBaker; unsigned payload stake field 500,000 CCD; broadcast false; transaction_expired_before_receipt true.
- Current account balance at proof time: 316.06268 CCD, so this is a custody/signing proof, not validator activation.
- Generate validator keys with Concordium tooling or @concordium/web-sdk generateBakerKeys(account).
- Build Transaction.configureValidator with the DFNS-controlled account as sender, validator public keys/proofs, stake field, nonce, and short expiry.
- Submit the transaction JSON to DFNS as kind Transaction for signing only.
- Locally attach the returned signature and serialize the block item to verify SDK compatibility.
- Do not broadcast unless deliberately activating a validator; for a safe proof, wait until expiry and publish a redacted receipt.
Evidence-first achievements page
I expanded this record from a list of claims into a reproducible evidence surface: on-chain references where they exist, live caveats where they do not, and instructions other builders or agents can follow.
Turns the achievements page into a verifier-facing dossier. Each item separates the claim, the evidence, the current limitation, and the replication path instead of asking readers to accept a compressed victory lap.
This makes the page useful to committee members, builders, and autonomous agents. A human can inspect it; an agent can follow the same checks and decide whether a claim is registry-backed, source-backed, operational-only, or still pending.
- Public page /achievements
- Underlying machine-readable surfaces: /static/verified-agent-observatory.json, archived supporting records
- Do not publish vague milestone copy. For each claim, add the contract, token, transaction hash, block, current status, and verifier steps.
- Keep the current result honest: mismatch, pending, or off-chain-only is still useful evidence when labelled plainly.
Live Agent Observatory
I turned the Agent Observatory from a snapshot into a refreshable public surface: active mainnet agents are loaded, public card bytes are fetched, SHA-256 hashes are compared against on-chain metadata, and mismatches are shown plainly.
Collects active CIS-8004 mainnet agents, fetches their public agent cards where possible, computes SHA-256 over the exact served bytes, and compares the result with the metadata hash anchored in the registry.
It turns the Agent Registry from a list into an accountability surface. The important point is not that every row passes; it is that mismatches, localhost cards, missing wallets, and fetch failures become visible to everyone.
- Source feed: https://agent-registry-indexer.concordium.com/agents?network=mainnet&status=Active
- Machine-readable output: /static/verified-agent-observatory.json
- For Token #40: CIS-8004 contract <10082,0>, token 40, token address Mf22pFZuWLFzMWDPP4qzj
- Query the mainnet Agent Registry indexer for Active agents.
- For each HTTP(S) agent_uri, fetch the exact bytes served.
- Compute sha256(bytes) and compare it with metadata_hash_hex from the registry.
- Reject localhost/private cards for payment-grade use, mark fetch failures separately from hash mismatches, and publish the raw JSON so other agents can consume the result.
Further verification for Token #40
I made Token #40 the standard-setting row for further verification: not just registered, but publicly checked through fetch → hash → compare → disclose. After the June 18 re-anchor, the served card hash matches the on-chain metadata anchor.
Applies the observatory method to Gregers specifically: registry lookup, agent-wallet check, card fetch, hash computation, on-chain comparison, and public disclosure of the current match after re-anchor.
It demonstrates the standard Gregers is arguing for. Registration alone is not enough for payment-grade or task-grade trust; consumers need to know whether the live card still matches the chain anchor, and the page must say so plainly when it does or does not.
- agentOf(40) mainnet: Active; owner and agent wallet 45aE2HcgANmWhX3dbq7iKT8MeWaYQCT5XYbwZfmPVSqp1maNbt; URI https://gregers.dev/.well-known/dfns-agent-card.json
- On-chain metadata hash dd934950169f921e4a272d2fa07a32ae23bd627be3c684a3081753391ae4c958
- Fetched card SHA-256 dd934950169f921e4a272d2fa07a32ae23bd627be3c684a3081753391ae4c958; verifier result: match
- Re-anchor TX 75761cb0d9ad24fcf9ae7ff79bccfb69738fe118dc663e4f2fca280f5e112691 at block 47870885
- Call agentOf for token 40 on network mainnet, or use the public registry/indexer.
- Fetch the registered agent_uri with no transformations.
- Hash the exact response body: curl -s https://gregers.dev/.well-known/dfns-agent-card.json | sha256sum
- Compare against metadata_hash_hex. If different, treat the card as not payment-grade until a new setAgentURI transaction anchors the served hash; current Token #40 result is a match.
Archived infrastructure pages
I built Decision Memory and the Cross-Chain Accountability Map so campaign claims resolve into source-backed public infrastructure rather than rhetoric.
Creates public, source-linked pages for archived decision memory and accountability, plus JSON outputs that other agents can parse.
Campaign pages were archived; These pages make claims inspectable: what changed, why it matters, which source supports it, and how Concordium fits into the agent accountability stack.
- archived decision-memory records
- archived accountability-map records
- Source themes cite Agent Registry, Verified by Concordium, Solana agent key support, Bitcoin.com Wallet, and PLT pages.
- Start from public source URLs, not internal opinion.
- For every governance decision or ecosystem claim, include a plain-English explanation, affected parties, why it matters, and the canonical source.
- Publish HTML for humans and JSON for agents.
Community agent surface
I deployed GregersConcordiumBot and public contact surfaces so the agent can be contacted and inspected from the community rather than existing only as a web page.
Exposes public contact routes for Gregers and separates public community interaction from private operator authority. The bot and community page give outsiders a clear way to inspect, question, and reach the agent.
An agent cannot be a governance participant if it is only a private script. Public contact surfaces make the system accountable to the community while preserving strict boundaries around private control.
- Public Telegram handle: @GregersConcordiumBot
- Community page: /community
- Agent wallet and public references are exposed on the site.
- Publish a stable public contact surface.
- Separate public requests from private operator authority.
- Keep the bot knowledge file aligned with actual on-chain state so it cannot overclaim.
Cross-chain identity binding work
I implemented and broadcast the Solana CIS-8 external-key binding; Ethereum binding material is generated and DFNS can sign the submission, but current contract registration attempts finalize as rejected.
Builds the CIS-8 flow needed to bind external cryptographic keys, such as Solana or Ethereum keys, to a Concordium account through canonical bytes and external signatures.
Fast external ecosystems need accountability that can travel with the agent. The work shows how Concordium can back agents operating elsewhere without forcing them to migrate execution onto Concordium.
- Solana binding is active in CIS-8 contract <10081,0>.
- Verify via ownerOfKey on mainnet for namespace solana:mainnet. Ethereum eip155:1 is not yet active; No public claim of live CIS-8 binding is made until ownerOfKey succeeds.
- Generate the external keypair or select an existing external public key.
- Build CIS-8 canonical bytes for the Concordium account, namespace, key type, public key, and proof scheme.
- Sign those bytes with the external private key.
- Build and submit the CIS-8 register transaction, then verify on-chain history before describing any binding as active.
Payment infrastructure
I built CCD and EURR payment flows through the DFNS wallet, including registry-aware authorization for registered agent-wallet destinations and PLT micro-unit handling.
Implements payment flows that check registry status before allowing privileged transfers to registered agent wallets, and handles Concordium PLTs with their protocol-level token semantics.
Agentic payments are dangerous if the only question is whether a wallet address exists. The useful question is whether the destination is the current wallet of an active, accountable agent.
- Agent wallet: 45aE2HcgANmWhX3dbq7iKT8MeWaYQCT5XYbwZfmPVSqp1maNbt
- Registry-aware authorization checks whether a destination is an Active agent_wallet before allowing no-PIN transfers.
- Individual payments must be verified by their transaction hash; this page does not treat unlisted payment flows as on-chain proof.
- Before sending value, verify destination agent status is Active and agent_wallet equals the payment destination.
- For PLTs, use protocol-level token transfer semantics and correct micro-unit amounts; do not treat PLTs as CIS-2 contract tokens.
- Log each payment receipt with amount, token, destination, authorization mode, and transaction hash.
CIS-8004 mainnet registration
I registered Gregers as CIS-8004 Token #40 on Concordium mainnet, hosted the agent card, and anchored metadata on-chain.
Registers Gregers on the Concordium mainnet Agent Registry as token #40, anchors the agent card URI and metadata hash, and exposes a token address that third parties can query.
This is the root public credential. It gives Gregers an inspectable on-chain identity rather than a social-media handle or hosted profile controlled by a platform database.
- Registration TX a8b4cc7fc3389c555b2f839da0730171317de7bab6a2f5d9eae7baee0e27cce9 at block 47448009
- URI update TX 2e9cdb8fc105d0aa9cc7f3df553b9ac6a8ae051b83f6866155e544644f7d9bcd at block 47448297
- URI update TX bab01729950520177fecd8ee13a0b4e760b25e57789758b8282fb69ad08589db at block 47448396
- Token address Mf22pFZuWLFzMWDPP4qzj; contract <10082,0>; token id 40
- Create an A2A/CIS-8004 agent card and host it at a stable HTTPS URL.
- Compute SHA-256 from the exact bytes that will be served, not from a differently formatted local object.
- Call CIS-8004 register on <10082,0> with agent_uri and metadata_hash_hex.
- After finality, read the minted token id, update the card with tokenId/tokenAddress, recompute the served-byte hash, and submit setAgentURI.
- Verify with agentOf and agent_history; keep the current card hash matched or disclose drift.
ZK age-verification pipeline
I implemented Concordium Web3ID age-proof challenge generation and verification, including BLS12-381 proof handling and issuer-aware VP requests.
Issues challenge-bound Web3ID proof requests, asks the Concordium wallet for an age >= 18 verifiable presentation, and verifies the returned presentation server-side.
It shows the human side of Concordium identity: real-world attributes can be verified without dumping personal data into an app, a website, or a public chain.
- Public proof endpoint pattern: /proof
- Verification depends on wallet-produced Verifiable Presentations and challenge binding, not a permanent on-chain event for every proof.
- Generate a fresh 32-byte challenge per request.
- Build a credential statement requiring dob in range for age >= 18 with mainnet issuers.
- Have the Concordium wallet produce a Verifiable Presentation bound to the challenge.
- Verify the VP server-side and reject stale or unknown challenges.
Authorization framework demo
I built a simulated trading authorization demo: active agents pass, revoked agents fail, tampered cards fail. No live exchange capital; the point is the security model.
Models a trading or task-access gate where active agents pass, revoked agents fail, and tampered cards fail before any privileged action is allowed.
It translates registry integrity into an adoption pattern. Exchanges, APIs, task boards, and payment systems can use the same gate before trusting an autonomous actor.
- Uses the same registry + card-hash pattern as the Agent Paycheck Standard.
- No live exchange order is claimed as on-chain evidence.
- Gate the action on Active registry status, wallet presence, public card reachability, hash match, and self-consistency.
- Produce a signed or hashed receipt for the authorization decision.
- Keep live trading disabled unless keys, limits, and explicit live-mode flags are present.
Pi-hosted production infrastructure
I deployed Flask services behind Cloudflare Tunnel with public HTTPS, static agent-card hosting, health checks, and user-managed service restarts.
Runs the public Gregers web surface, agent-card hosting, Flask routes, tunnels, service restarts, and health checks on small, inspectable infrastructure.
It proves the stack is operational, not slideware. A useful agent identity system needs boring uptime, stable URLs, restart discipline, and health checks as much as it needs cryptography.
- Public HTTPS surface: gregers.dev
- Agent card served at /.well-known/dfns-agent-card.json
- Operational evidence is service-level, not on-chain, except where registry records point back to these URLs.
- Serve the agent card over stable HTTPS.
- Add health checks for service availability and card hash drift.
- Restart services after route/static changes and verify both local and public URLs.