A distributed key management system running as an EigenLayer AVS that provides threshold cryptography-based secret management using Identity-Based Encryption (IBE).
EigenX KMS enables applications to securely encrypt and decrypt data using a distributed network of operators. The system uses:
- BLS12-381 threshold signatures for distributed key generation and signing
- Identity-Based Encryption (IBE) where application IDs serve as public keys
- Automatic key resharing at regular intervals for security rotation
- Byzantine fault tolerance with ceiling(2n/3) threshold for partial signature recovery
- 100% operator participation required for DKG to ensure complete key distribution
- Go 1.21+
- Access to Ethereum RPC endpoint
- Registered operator with EigenLayer AVS
# Build all binaries
make all
# Or build specific components
make build/cmd/kmsServer # KMS node server
make build/cmd/kmsClient # KMS client CLI./bin/kms-server \
--operator-address "0x..." \
--bn254-private-key "0x..." \
--avs-address "0x..." \
--operator-set-id 0 \
--chain-id 1 \
--rpc-url "https://eth-mainnet.g.alchemy.com/v2/..." \
--port 8080The node will automatically:
- Wait for the first interval boundary (10 minutes for mainnet)
- Detect if genesis DKG is needed (query other operators)
- Execute DKG if no master key exists, or join via reshare
- Automatically reshare keys every interval
# Encrypt data for an application
./bin/kms-client --avs-address "0x..." --operator-set-id 0 \
encrypt --app-id "my-app" --data "secret-config" --output encrypted.hex
# Decrypt data
./bin/kms-client --avs-address "0x..." --operator-set-id 0 \
decrypt --app-id "my-app" --encrypted-data encrypted.hexEvery node runs a 500ms scheduler that:
- Calculates interval boundary (rounded to chain-specific interval)
- Checks if boundary already processed (prevents duplicates)
- Determines operator state:
- Has shares? Run reshare as existing operator
- No shares? Query peers to detect genesis vs existing cluster
- Executes appropriate protocol with synchronized session timestamp
Trigger: First interval boundary when no master key exists
Process:
- Each operator generates random polynomial
f_i(z) - Operators broadcast commitments and send shares to all peers
- Each operator verifies received shares and sends acknowledgements
- All operators finalize:
master_secret = sum(f_i(0))across all operators
Requirement: ALL operators must participate (100% acknowledgements)
Trigger: Every interval boundary (10min/2min/30s depending on chain)
Process:
- Existing operators use current share as
f'_i(0) = current_share_i - Generate new shares and distribute to ALL operators (including new ones)
- Each operator computes new share via Lagrange interpolation
- Master secret preserved:
sum(f'_i(0)) = sum(current_share_i) = original_master_secret
New Operator Joining:
- Waits for next interval boundary
- Detects existing cluster (peers have commitments)
- Receives shares from existing operators
- Computes share via Lagrange interpolation
Encryption: ciphertext = Encrypt(H_1(app_id), master_public_key, plaintext)
Decryption:
- Client collects ceiling(2n/3) partial signatures from operators
- Recovers
app_private_key = sum(lambda_i * partial_sig_i)(Lagrange interpolation) - Decrypts:
plaintext = Decrypt(app_private_key, ciphertext)
The KMS server supports multiple attestation methods for verifying application identity:
- Method:
"gcp"or"intel" - Security: Hardware TEE attestation with cryptographic proof
- Use: Production environments with sensitive secrets
- Setup: Requires GCP project ID or Intel Trust Authority configuration
./bin/kms-server --gcp-project-id my-project \
--attestation-provider google \
--enable-gcp-attestation=true ...- Method:
"ecdsa" - Security: Proves ECDSA key ownership (no TEE proof)
- Use: Development, testing, non-TEE environments
- Setup: No additional configuration required
./bin/kms-server --enable-gcp-attestation=false \
--enable-ecdsa-attestation=true ...# Run the ECDSA attestation example
go run examples/ecdsa_attestation.goSee examples/ecdsa_attestation.go for complete implementation.
cmd/kmsServer: KMS node server with automatic schedulercmd/kmsClient: CLI for encrypting/decrypting datapkg/node: Core node logic, DKG, and reshare protocolspkg/transport: Authenticated P2P communication with BN254 signaturespkg/client: KMSClient library for applicationspkg/crypto: BLS12-381 cryptographic operations
| Chain | Reshare Interval | Use Case |
|---|---|---|
| Mainnet | 10 minutes | Production |
| Sepolia | 2 minutes | Testnet |
| Anvil | 30 seconds | Local testing |
All inter-node messages include:
FromOperatorAddressandToOperatorAddressin signed payloadSessionTimestampfor protocol coordination- BN254 signature over
keccak256(payload)
Recipients verify:
- Payload hash matches
- Signature valid using sender's BN254 public key
- Message intended for this operator
- Session exists and is valid
- DKG: Requires 100% operator participation (all must send shares + acknowledgements)
- Partial Signatures: Requires ceiling(2n/3) operators for app key recovery
- Byzantine Fault Tolerance: System secure with up to floor(n/3) malicious operators
# Run all tests
make test
# Run specific test
go test ./pkg/node -v
# Run integration tests
go test ./internal/tests/integration -vmake lint- CLAUDE.md: Architecture and development guide
- Execution Plan: Implementation milestones
- Server README: Server configuration and API
- Client README: Client usage examples
See LICENSE file for details.
eigenx-kms-go is in active development and is not yet audited. Use at your own risk.