Stellar Community Fund

By ACTA

Stellar DID & Verifiable Credentials

SCF #42

$75.0K

Build

Awarded

Products & Services

This submission funds the development and production deployment of ACTA's core identity and verifiable credentials infrastructure on Stellar. We will deliver two products:

1. Stellar DID Method Standard (did:stellar) + Resolution Tooling

We will define, implement, and ship a Stellar-native DID method with open-source tooling so that issuers, holders, and verifiers can identify each other consistently across the Stellar ecosystem.

This is not a wrapper around existing DID methods. We are building a purpose-built registry on Soroban where DIDs are registered independently of wallet addresses. A did:stellar identifier survives wallet changes, supports key rotation, and carries its own verification material, which is what production credential systems actually need.

We have already written a 500-line technical specification covering identifier syntax, the on-chain data model, resolver behavior, API endpoints, SDK helpers, and integration with our existing credential infrastructure. This submission funds the implementation of that specification across three tranches: contract and spec (T1), resolver and developer tooling (T2), and production deployment with real clients (T3).

What this enables: Portable, resolvable identity for any participant in the Stellar ecosystem. Issuers get a stable identifier they can publish. Holders get a DID that works across applications. Verifiers get a standard way to look up issuer keys and verify credentials.

2. Hardened + Scalable Soroban Credential and Vault Contracts

We will harden our existing Soroban smart contracts for encrypted vaults and the full credential lifecycle (issuance, verification, revocation), including issuer authorization and fee logic.

Our current vc-vault contract already handles credential storage, issuer authorization, vault management, and status tracking across ~540 lines of Rust spread over 7 modules. This submission funds the hardening of that contract for production use: better error handling, issuer blocklists enforced at the contract level, USDC-denominated fee tiers, and a clear versioning and upgrade strategy.

What this enables: Higher reliability, less friction for integrators, and mainnet-ready performance. Stellar serves as the immutable anchor and public verification layer.

Requested Budget

$75.0K

Traction Evidence

ACTA is in a stage of growth with validated traction. The platform has issued 44 API keys on testnet and 7 on mainnet, with 83 credentials issued on testnet and 132 on mainnet.

The MVP is fully functional and supports on-chain credential issuance and verification. We are currently strengthening the codebase to align with the W3C Verifiable Credentials standard while improving reliability, security, and performance.

In terms of adoption, ACTA has reached more than 1,050 website visits, 750+ tracked interactions, and a community of 100+ members on Discord.

We delivered an educational talk on decentralized identity and verifiable credentials during the Stellar Impacta Bootcamp, organized by Blockchain Acceleration Foundation. As part of this program, BAF issued more than 120 credentials on mainnet using ACTA as completion certificates for the bootcamp.

GrantFox is in the beta implementation phase and has committed to issuing more than 200 credentials on mainnet as part of its integration with ACTA.

ACTA was selected for the Scale track at Código Alebrije, Stellar's builder program in Mexico City (March 2026), where we refined our technical architecture, validated our roadmap with ecosystem mentors, and strengthened our positioning for production readiness.

Beyond infrastructure, ACTA has been applied to real-world organizational challenges. We participated as mentors in GIVE Colombia, a Stellar initiative aimed at developing technological solutions for real business and social challenges. During this program, we worked on a challenge presented by Corporación Interactuar, a Colombian organization that has supported more than 40,000 entrepreneurs through business training, advisory services, and access to productive financing for small businesses. From this challenge, we built a system on ACTA that enables advisors to issue verifiable credentials representing the entrepreneurial trajectory of business owners, capturing dimensions such as business impact, financial behavior, and formalization level. This transforms what was previously fragmented, manual information into structured, traceable, and verifiable records that support better financing and support decisions. Given Interactuar's scale, this relationship represents a pipeline of up to 500,000 mainnet credentials as the system expands across their programs.

Next Steps

Our upcoming objectives:

Completing the did:stellar method specification and deploying the registry contract on testnet.
Shipping the DID resolver and developer tooling (API endpoints + SDK helpers).
Deploying to mainnet with production-grade reliability.
Scaling integrations to production, starting with GrantFox (200+ mainnet credentials).
Professional use case validation with at least 3 integrators.

References

Statistics: https://stats.acta.build

Statistics Documentation: https://us.posthog.com/shared/7sCyJvAqlHuWnWqmtc-8MuOZHhZLHA

Back-Office Statistics: https://backoffice.acta.build/shared/stats/fd26149e-383f-4675-81f2-b85080f8cf4a

Impacta Bootcamp: https://youtu.be/C-NLja0INfY

Tranche 1 (Deliverable Roadmap) - MVP

DID Specification + Contract + Testnet Foundation

This tranche lays the foundation: we publish the did:stellar specification, implement the on-chain registry contract, and harden the existing credential infrastructure on testnet.

1) did:stellar Method Specification (v0.1)

We will publish a public specification for the did:stellar method, covering:

Identifier syntax: did:stellar:{network}:{didId}, where didId is a 128-bit random value encoded as 26-character base32 lowercase. We chose opaque identifiers over account-derived DIDs because a DID needs to survive wallet changes, tying identity to a specific key defeats the purpose.
DID Document model: W3C DID Core compliant, with verificationMethod, authentication, assertionMethod, keyAgreement, and service sections. Keys are expressed as Multikey with publicKeyMultibase.
Controller model: The DID controller is a classic Stellar account (G...), published in the DID Document as did:pkh:stellar:{network}:{address}. This maintains compatibility with our existing address-based authorization while giving issuers a portable identifier.
Resolution rules: Deterministic resolution from Soroban contract state via RPC. No indexer required.
Proof of control: Ed25519 signature over a canonical challenge (nonce + domain + DID + timestamp).

We have already written a detailed draft of this specification (499 lines) that covers the full data model, API payloads, resolution algorithm, and acceptance criteria. This tranche funds the formalization, test vector generation, and public release of that draft.

We will develop the specification with advisory input from a contributor active in W3C identity standardization discussions.

2) did-stellar-registry Soroban Contract

We will implement and deploy (on testnet) a new Soroban contract that serves as the on-chain registry for did:stellar identifiers.

Contract ABI:

register(did_id, initial_record) Create a new DID. Fails if the didId already exists.
update(did_id, expected_version, next_record) Replace the full DID record. Uses optimistic concurrency: the call fails if expected_version doesn't match the current version, preventing silent overwrites.
transfer_controller(did_id, expected_version, new_controller) Transfer control to a different Stellar account without changing the DID itself.
deactivate(did_id, expected_version) Permanently deactivate a DID. Clears cryptographic material but preserves the controller for audit purposes.
get(did_id) Read-only. Returns the current DidRecord or None.

On-chain data model: Each DID stores a DidRecord containing: controller address, up to 3 authentication keys, up to 3 assertion method keys, up to 1 key agreement key, up to 3 service endpoints, optional metadata URI + SHA-256 hash, version number, creation and update ledger numbers, and a deactivation flag.

We enforce strict limits on key counts, string lengths, and URL formats to control storage rent. All mutations require controller.require_auth() and emit events (did_registered, did_updated, did_controller_transferred, did_deactivated) for external auditability.

Why a separate contract: We keep DID registration separate from the vc-vault contract because identity and credential storage have different lifecycle semantics. A DID should outlive any individual credential or vault.

3) Contract Test Suite

Full test coverage for the registry contract:

Registration and duplicate rejection
Update with version conflict detection
Controller transfer
Deactivation and tombstone behavior
Authorization enforcement (unauthorized callers rejected)
Boundary validation (key counts, string lengths, URL formats)

4) Hardened vc-vault Contract

We will harden the existing vc-vault contract for production use:

Typed error handling: Replace generic panics with structured error codes that integrators can programmatically handle.
Issuer blocklist enforcement: Already designed, this tranche completes the implementation.
USDC fee tiers: On-chain fee configuration with clear payer and collection semantics.
Versioning discipline: Published contract IDs, interface documentation, and a clear upgrade strategy.

5) Testnet API/SDK Hardening

We will ship a stable, versioned testnet release (v1.1) of the existing API and SDK:

Versioning and consistent error handling across all endpoints
Wallet signing flows (Freighter + WalletConnect where applicable)
A reproducible end-to-end demo that walks through: issuer prepares an issuance transaction (XDR) → issuer signs via wallet → credential is anchored on-chain → holder stores it in their vault → verifier performs on-chain verification (including status/revocation checks), with transaction links for every step

Completion Criteria

Public did:stellar spec draft (v0.1) in a public repo with test vectors and a tagged draft release
did-stellar-registry contract deployed on testnet with published contract ID
Contract test suite passing
Tagged testnet API/SDK release (v1.1) with reproducible E2E demo
Hardened vc-vault contract deployed on testnet with documented interface

Budget: 20 % = $15,000

Target completion: ~45 days from approval (engineering deliverables); any external review/registry submission timelines may vary.

Tranche 2 (Deliverable Roadmap) - Testnet

DID Resolver + API/SDK Integration + Mainnet RC

This tranche makes did:stellar usable by developers: we build the resolver, integrate DID operations into the API and SDK, and prepare everything for mainnet.

1) DID Resolver (W3C Compliant)

We will implement a resolver that takes a did:stellar identifier and returns a W3C-compliant DID Document.

HTTP endpoint: GET /1.0/identifiers/{did}

Resolution algorithm:

Validate DID syntax against ^did:stellar:(mainnet|testnet):[a-z2-7]{26}$
Determine the network and look up the corresponding registry contract ID
Decode the didId from base32 to 16 bytes
Read the DidRecord from Soroban via getLedgerEntries (RPC call, no indexer needed)
If not found: return notFound
If deactivated: return a tombstone document with deactivated: true metadata and HTTP 410
Otherwise: construct the DID Document by mapping keys to verificationMethod entries, services to service entries, and the controller to did:pkh:stellar:{network}:{address}

Supported media types: application/did+ld+json, application/did+json

Caching: 30-second in-memory or Redis cache for repeated reads. The resolver reads directly from Stellar RPC and does not depend on an indexer.

We will publish the resolver as a DIF did-resolver compatible package (JS/TS) so it integrates with existing identity tooling.

2) API Integration (6 New Endpoints)

We will add DID lifecycle endpoints to the existing ACTA API, following the same prepare/submit XDR pattern we already use for credential operations:

POST /v1/dids/stellar Register a new DID
PATCH /v1/dids/stellar/{did} Update a DID record
POST /v1/dids/stellar/{did}/transfer Transfer controller
POST /v1/dids/stellar/{did}/deactivate Deactivate a DID
GET /v1/dids/stellar/{did} Get DID record (raw)
GET /1.0/identifiers/{did} Resolve DID (W3C format)

Each mutation endpoint works in two modes: without signedXdr it returns the unsigned transaction for the client to sign; with signedXdr it submits the signed transaction and returns the result. This is the same pattern our issuance and vault endpoints already use, no new signing flow for integrators to learn.

3) SDK Helpers (7+ Functions)

New functions for the @acta-team/acta-sdk package:

createDidStellar() Generate a didId, prepare registration payload
updateDidStellar() Prepare an update transaction
transferDidStellarController() Prepare a controller transfer
deactivateDidStellar() Prepare a deactivation
resolveDidStellar() Resolve a DID to its DID Document
buildDidStellarFromId() Construct the full DID URI from components
parseDidStellar() Parse and validate a did:stellar URI

These follow the same patterns as our existing SDK hooks (useVault, useCredential).

4) Mainnet Reliability Upgrades

Production-grade improvements across the existing credential API surface:

Typed, consistent error handling across all endpoints (including contract failures) with clear remediation guidance
Rate limiting and abuse protections
Integrator-focused documentation with copy/paste examples and reference implementations

5) Mainnet Release Candidate

A tagged mainnet-ready RC with:

Deployment plan and operational runbook (environment configuration, key handling, upgrade guidance)
All contracts, API endpoints, and SDK helpers versioned and documented
Release notes covering breaking changes (if any) from testnet

6) Issuer Onboarding Documentation

Documented steps for issuer DID setup:

How to register a did:stellar for your organization
Key management requirements (authentication vs. assertion keys)
Signing flow walkthrough
Checklist from zero to first credential issuance

Completion Criteria

DID resolver deployed and resolving testnet DIDs with W3C-compliant DID Documents
All 6 API endpoints functional with prepare/submit flow
SDK package published with DID helpers
Mainnet RC tagged with release notes and deployment runbook
Public integrator documentation with copy/paste examples

Budget: 30% = $22,500

Target completion: ~90 days from approval

Tranche 3 (Deliverable Roadmap) - Mainnet

Production Deployment + Client Integration + Use Case Validation

This is where we prove the system works in the real world. We deploy to mainnet, run the GrantFox integration with did:stellar as the issuer identifier, and validate the developer experience with external integrators.

1) Production Mainnet Launch

Deploy did-stellar-registry contract to Stellar mainnet with published contract ID
Deploy hardened vc-vault contract to mainnet
Production API/SDK release with full DID support
Publish network configuration manifest at .well-known/acta-did-stellar.json with mainnet and testnet contract IDs and resolver endpoints

2) GrantFox Production Integration

GrantFox will issue 200+ credentials on mainnet using did:stellar as the issuer identifier. This integration demonstrates the complete system working end-to-end in production:

GrantFox registers a did:stellar for their organization
Credentials are issued with issuer: did:stellar:mainnet:{grantfox_did_id}
Each credential's credentialSubject uses the holder's DID
On-chain verification confirms credential validity and issuer identity
All transaction references published for auditability

We will document the integration as a reusable step-by-step flow (onboarding → DID registration → issuance → verification) that future ACTA integrators can replicate.

3) ACTA Integration: did:stellar in Vaults and VCs

We will integrate did:stellar into the existing credential and vault infrastructure:

create_vault and create_sponsored_vault accept did:stellar in the did_uri field
VC issuance supports did:stellar as the issuer field
credentialSubject supports did:stellar for holders
Backward compatibility: If an integrator sends did:pkh, everything still works exactly as before. No breaking changes.
Controller-address binding: When issuerDid is did:stellar, the API resolves the DID and verifies that the controller matches the signing address. This prevents impersonation, you cannot issue credentials claiming to be a DID you don't control.

4) Professional User Testing

We will recruit at least 3 integrators (wallets, dApps, or services) to test the full DID + credential flow:

Structured testing sessions covering: DID registration, credential issuance, vault operations, verification, and resolver queries
Feedback captured through interviews and issue tracking (with severity and impact)
Fixes implemented and incorporated into the final release
Final tagged mainnet release with a user testing report summarizing participants, scenarios, issues found, and resolutions

5) Public Documentation

Mainnet integration guide (contracts, API endpoints, SDK usage)
Reusable integration flow documentation (from the GrantFox experience)
did:stellar method specification, final draft incorporating implementation learnings
Use case report

Completion Criteria

did-stellar-registry and vc-vault contracts deployed on mainnet with published IDs
200+ credentials issued on mainnet via GrantFox with published transaction references
did:stellar working in vault creation and VC issuance, with did:pkh backward compatibility confirmed
Use case report with at least 3 participants, documented scenarios, and resolutions
Final tagged mainnet release

Budget: 40% = $30,000

Target completion: ~130 days from approval (final production release)