chore: disable Reddit release announcement

refactor: convert schema to SQLite
```

.cz.toml

@@ -2,7 +2,7 @@
 name = "cz_conventional_commits"
 tag_format = "v$version"
 version_scheme = "semver"
-version = "0.5.23"
-update_changelog_on_bump = true
+version = "0.6.0"
+update_changelog_on_bump = false
 major_version_zero = true
-changelog_file = "./docs/docs/changelog/index.md"
+changelog_file = "CHANGELOG.md"

.github/Taskfile.yml

@@ -0,0 +1,32 @@
+version: "3"
+
+vars:
+  VERSION:
+    sh: git describe --tags --abbrev=0
+  COMMIT:
+    sh: git rev-parse --short HEAD
+  ROOT:
+    sh: git rev-parse --show-toplevel
+  OS:
+    sh: uname -s
+
+tasks:
+  date:
+    desc: Returns date in YEAR.WEEK.DAY format
+    cmds:
+      - |
+        YEAR=$(date +%Y)
+        WEEK=$(date +%V)
+        DAY=$(date +%u)
+        echo "${YEAR}.${WEEK}.${DAY}"
+    vars:
+      DATE: '{{default "" .CLI_ARGS}}'
+    silent: true
+ 
+  release:
+    desc: Create a new release with formatted date
+    cmds:
+      - go install github.com/goreleaser/goreleaser/v2@latest
+      - RELEASE_DATE=$(task date) goreleaser release --clean -f {{.ROOT}}/.goreleaser.yaml
+    silent: true
+

.github/aider/guides/cosmos-proto.md

@@ -1,569 +0,0 @@
-# Protocol Buffers in Cosmos SDK
-
-## Overview
-
-The Cosmos SDK uses Protocol Buffers for serialization and API definitions. Generation is handled via a Docker image: `ghcr.io/cosmos/proto-builder:0.15.x`.
-
-## Generation Tools
-
-- **Buf**: Primary tool for protobuf management
-- **protocgen.sh**: Core generation script in `scripts/` 
-- **Makefile Commands**: Standard commands for generate, lint, format
-
-## Key Components
-
-### Buf Configuration
-
-1. **Workspace Setup**
-   - Root level buf workspace configuration
-   - Manages multiple protobuf directories
-
-2. **Directory Structure**
-   ```
-   proto/
-   ├── buf.gen.gogo.yaml    # GoGo Protobuf generation
-   ├── buf.gen.pulsar.yaml  # Pulsar API generation  
-   ├── buf.gen.swagger.yaml # OpenAPI/Swagger docs
-   ├── buf.lock            # Dependencies
-   ├── buf.yaml            # Core configuration
-   ├── cosmos/            # Core protos
-   └── tendermint/        # Consensus protos
-   ```
-
-3. **Module Protos**
-   - Located in `x/{moduleName}/proto`
-   - Module-specific message definitions
-
-#### `buf.gen.gogo.yaml`
-
-`buf.gen.gogo.yaml` defines how the protobuf files should be generated for use with in the module. This file uses [gogoproto](https://github.com/gogo/protobuf), a separate generator from the google go-proto generator that makes working with various objects more ergonomic, and it has more performant encode and decode steps
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.gen.gogo.yaml#L1-L9
-```
-
-#### `buf.gen.pulsar.yaml`
-
-`buf.gen.pulsar.yaml` defines how protobuf files should be generated using the [new golang apiv2 of protobuf](https://go.dev/blog/protobuf-apiv2). This generator is used instead of the google go-proto generator because it has some extra helpers for Cosmos SDK applications and will have more performant encode and decode than the google go-proto generator. You can follow the development of this generator [here](https://github.com/cosmos/cosmos-proto).
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.gen.pulsar.yaml#L1-L18
-```
-
-#### `buf.gen.swagger.yaml`
-
-`buf.gen.swagger.yaml` generates the swagger documentation for the query and messages of the chain. This will only define the REST API end points that were defined in the query and msg servers. You can find examples of this [here](https://github.com/cosmos/cosmos-sdk/blob/main/x/bank/proto/cosmos/bank/v1beta1/query.proto)
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.gen.swagger.yaml#L1-L6
-```
-
-#### `buf.lock`
-
-This is an autogenerated file based off the dependencies required by the `.gen` files. There is no need to copy the current one. If you depend on cosmos-sdk proto definitions a new entry for the Cosmos SDK will need to be provided. The dependency you will need to use is `buf.build/cosmos/cosmos-sdk`.
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.lock#L1-L16
-```
-
-#### `buf.yaml`
-
-`buf.yaml` defines the [name of your package](https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.yaml#L3), which [breakage checker](https://buf.build/docs/tutorials/getting-started-with-buf-cli#detect-breaking-changes) to use and how to [lint your protobuf files](https://buf.build/docs/tutorials/getting-started-with-buf-cli#lint-your-api).
-
-It is advised to use a tagged version of the buf modules corresponding to the version of the Cosmos SDK being are used.
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/main/proto/buf.yaml#L1-L24
-```
-
-We use a variety of linters for the Cosmos SDK protobuf files. The repo also checks this in ci.
-A reference to the github actions can be found [here](https://github.com/cosmos/cosmos-sdk/blob/main/.github/workflows/proto.yml#L1-L32)
-
-# ORM
-
-The Cosmos SDK ORM is a state management library that provides a rich, but opinionated set of tools for managing a
-module's state. It provides support for:
-
-- type safe management of state
-- multipart keys
-- secondary indexes
-- unique indexes
-- easy prefix and range queries
-- automatic genesis import/export
-- automatic query services for clients, including support for light client proofs (still in development)
-- indexing state data in external databases (still in development)
-
-## Design and Philosophy
-
-The ORM's data model is inspired by the relational data model found in SQL databases. The core abstraction is a table
-with a primary key and optional secondary indexes.
-
-Because the Cosmos SDK uses protobuf as its encoding layer, ORM tables are defined directly in .proto files using
-protobuf options. Each table is defined by a single protobuf `message` type and a schema of multiple tables is
-represented by a single .proto file.
-
-Table structure is specified in the same file where messages are defined in order to make it easy to focus on better
-design of the state layer. Because blockchain state layout is part of the public API for clients (TODO: link to docs on
-light client proofs), it is important to think about the state layout as being part of the public API of a module.
-Changing the state layout actually breaks clients, so it is ideal to think through it carefully up front and to aim for
-a design that will eliminate or minimize breaking changes down the road. Also, good design of state enables building
-more performant and sophisticated applications. Providing users with a set of tools inspired by relational databases
-which have a long history of database design best practices and allowing schema to be specified declaratively in a
-single place are design choices the ORM makes to enable better design and more durable APIs.
-
-Also, by only supporting the table abstraction as opposed to key-value pair maps, it is easy to add to new
-columns/fields to any data structure without causing a breaking change and the data structures can easily be indexed in
-any off-the-shelf SQL database for more sophisticated queries.
-
-The encoding of fields in keys is designed to support ordered iteration for all protobuf primitive field types
-except for `bytes` as well as the well-known types `google.protobuf.Timestamp` and `google.protobuf.Duration`. Encodings
-are optimized for storage space when it makes sense (see the documentation in `cosmos/orm/v1/orm.proto` for more details)
-and table rows do not use extra storage space to store key fields in the value.
-
-We recommend that users of the ORM attempt to follow database design best practices such as
-[normalization](https://en.wikipedia.org/wiki/Database_normalization) (at least 1NF).
-For instance, defining `repeated` fields in a table is considered an anti-pattern because breaks first normal form (1NF).
-Although we support `repeated` fields in tables, they cannot be used as key fields for this reason. This may seem
-restrictive but years of best practice (and also experience in the SDK) have shown that following this pattern
-leads to easier to maintain schemas.
-
-To illustrate the motivation for these principles with an example from the SDK, historically balances were stored
-as a mapping from account -> map of denom to amount. This did not scale well because an account with 100 token balances
-needed to be encoded/decoded every time a single coin balance changed. Now balances are stored as account,denom -> amount
-as in the example above. With the ORM's data model, if we wanted to add a new field to `Balance` such as
-`unlocked_balance` (if vesting accounts were redesigned in this way), it would be easy to add it to this table without
-requiring a data migration. Because of the ORM's optimizations, the account and denom are only stored in the key part
-of storage and not in the value leading to both a flexible data model and efficient usage of storage.
-
-## Defining Tables
-
-To define a table:
-
-1. create a .proto file to describe the module's state (naming it `state.proto` is recommended for consistency),
-   and import "cosmos/orm/v1/orm.proto", ex:
-
-```protobuf
-syntax = "proto3";
-package bank_example;
-
-import "cosmos/orm/v1/orm.proto";
-```
-
-2. define a `message` for the table, ex:
-
-```protobuf
-message Balance {
-  bytes account = 1;
-  string denom = 2;
-  uint64 balance = 3;
-}
-```
-
-3. add the `cosmos.orm.v1.table` option to the table and give the table an `id` unique within this .proto file:
-
-```protobuf
-message Balance {
-  option (cosmos.orm.v1.table) = {
-    id: 1
-  };
-
-  bytes account = 1;
-  string denom = 2;
-  uint64 balance = 3;
-}
-```
-
-4. define the primary key field or fields, as a comma-separated list of the fields from the message which should make
-   up the primary key:
-
-```protobuf
-message Balance {
-  option (cosmos.orm.v1.table) = {
-    id: 1
-    primary_key: { fields: "account,denom" }
-  };
-
-  bytes account = 1;
-  string denom = 2;
-  uint64 balance = 3;
-}
-```
-
-5. add any desired secondary indexes by specifying an `id` unique within the table and a comma-separate list of the
-   index fields:
-
-```protobuf
-message Balance {
-  option (cosmos.orm.v1.table) = {
-    id: 1;
-    primary_key: { fields: "account,denom" }
-    index: { id: 1 fields: "denom" } // this allows querying for the accounts which own a denom
-  };
-
-  bytes account = 1;
-  string denom   = 2;
-  uint64 amount  = 3;
-}
-```
-
-### Auto-incrementing Primary Keys
-
-A common pattern in SDK modules and in database design is to define tables with a single integer `id` field with an
-automatically generated primary key. In the ORM we can do this by setting the `auto_increment` option to `true` on the
-primary key, ex:
-
-```protobuf
-message Account {
-  option (cosmos.orm.v1.table) = {
-    id: 2;
-    primary_key: { fields: "id", auto_increment: true }
-  };
-
-  uint64 id = 1;
-  bytes address = 2;
-}
-```
-
-### Unique Indexes
-
-A unique index can be added by setting the `unique` option to `true` on an index, ex:
-
-```protobuf
-message Account {
-  option (cosmos.orm.v1.table) = {
-    id: 2;
-    primary_key: { fields: "id", auto_increment: true }
-    index: {id: 1, fields: "address", unique: true}
-  };
-
-  uint64 id = 1;
-  bytes address = 2;
-}
-```
-
-### Singletons
-
-The ORM also supports a special type of table with only one row called a `singleton`. This can be used for storing
-module parameters. Singletons only need to define a unique `id` and that cannot conflict with the id of other
-tables or singletons in the same .proto file. Ex:
-
-```protobuf
-message Params {
-  option (cosmos.orm.v1.singleton) = {
-    id: 3;
-  };
-
-  google.protobuf.Duration voting_period = 1;
-  uint64 min_threshold = 2;
-}
-```
-
-## Running Codegen
-
-NOTE: the ORM will only work with protobuf code that implements the [google.golang.org/protobuf](https://pkg.go.dev/google.golang.org/protobuf)
-API. That means it will not work with code generated using gogo-proto.
-
-To install the ORM's code generator, run:
-
-```shell
-go install cosmossdk.io/orm/cmd/protoc-gen-go-cosmos-orm@latest
-```
-
-The recommended way to run the code generator is to use [buf build](https://docs.buf.build/build/usage).
-This is an example `buf.gen.yaml` that runs `protoc-gen-go`, `protoc-gen-go-grpc` and `protoc-gen-go-cosmos-orm`
-using buf managed mode:
-
-```yaml
-version: v1
-managed:
-  enabled: true
-  go_package_prefix:
-    default: foo.bar/api # the go package prefix of your package
-    override:
-      buf.build/cosmos/cosmos-sdk: cosmossdk.io/api # required to import the Cosmos SDK api module
-plugins:
-  - name: go
-    out: .
-    opt: paths=source_relative
-  - name: go-grpc
-    out: .
-    opt: paths=source_relative
-  - name: go-cosmos-orm
-    out: .
-    opt: paths=source_relative
-```
-
-## Using the ORM in a module
-
-### Initialization
-
-To use the ORM in a module, first create a `ModuleSchemaDescriptor`. This tells the ORM which .proto files have defined
-an ORM schema and assigns them all a unique non-zero id. Ex:
-
-```go
-var MyModuleSchema = &ormv1alpha1.ModuleSchemaDescriptor{
-    SchemaFile: []*ormv1alpha1.ModuleSchemaDescriptor_FileEntry{
-        {
-            Id:            1,
-            ProtoFileName: mymodule.File_my_module_state_proto.Path(),
-        },
-    },
-}
-```
-
-In the ORM generated code for a file named `state.proto`, there should be an interface `StateStore` that got generated
-with a constructor `NewStateStore` that takes a parameter of type `ormdb.ModuleDB`. Add a reference to `StateStore`
-to your module's keeper struct. Ex:
-
-```go
-type Keeper struct {
-    db StateStore
-}
-```
-
-Then instantiate the `StateStore` instance via an `ormdb.ModuleDB` that is instantiated from the `SchemaDescriptor`
-above and one or more store services from `cosmossdk.io/core/store`. Ex:
-
-```go
-func NewKeeper(storeService store.KVStoreService) (*Keeper, error) {
-    modDb, err := ormdb.NewModuleDB(MyModuleSchema, ormdb.ModuleDBOptions{KVStoreService: storeService})
-    if err != nil {
-        return nil, err
-    }
-    db, err := NewStateStore(modDb)
-    if err != nil {
-        return nil, err
-    }
-    return Keeper{db: db}, nil
-}
-```
-
-### Using the generated code
-
-The generated code for the ORM contains methods for inserting, updating, deleting and querying table entries.
-For each table in a .proto file, there is a type-safe table interface implemented in generated code. For instance,
-for a table named `Balance` there should be a `BalanceTable` interface that looks like this:
-
-```go
-type BalanceTable interface {
-    Insert(ctx context.Context, balance *Balance) error
-    Update(ctx context.Context, balance *Balance) error
-    Save(ctx context.Context, balance *Balance) error
-    Delete(ctx context.Context, balance *Balance) error
-    Has(ctx context.Context, account []byte, denom string) (found bool, err error)
-    // Get returns nil and an error which responds true to ormerrors.IsNotFound() if the record was not found.
-    Get(ctx context.Context, account []byte, denom string) (*Balance, error)
-    List(ctx context.Context, prefixKey BalanceIndexKey, opts ...ormlist.Option) (BalanceIterator, error)
-    ListRange(ctx context.Context, from, to BalanceIndexKey, opts ...ormlist.Option) (BalanceIterator, error)
-    DeleteBy(ctx context.Context, prefixKey BalanceIndexKey) error
-    DeleteRange(ctx context.Context, from, to BalanceIndexKey) error
-
-    doNotImplement()
-}
-```
-
-This `BalanceTable` should be accessible from the `StateStore` interface (assuming our file is named `state.proto`)
-via a `BalanceTable()` accessor method. If all the above example tables/singletons were in the same `state.proto`,
-then `StateStore` would get generated like this:
-
-```go
-type BankStore interface {
-    BalanceTable() BalanceTable
-    AccountTable() AccountTable
-    ParamsTable() ParamsTable
-
-    doNotImplement()
-}
-```
-
-So to work with the `BalanceTable` in a keeper method we could use code like this:
-
-```go
-func (k keeper) AddBalance(ctx context.Context, acct []byte, denom string, amount uint64) error {
-    balance, err := k.db.BalanceTable().Get(ctx, acct, denom)
-    if err != nil && !ormerrors.IsNotFound(err) {
-        return err
-    }
-
-    if balance == nil {
-        balance = &Balance{
-            Account: acct,
-            Denom:   denom,
-            Amount:  amount,
-        }
-    } else {
-        balance.Amount = balance.Amount + amount
-    }
-
-    return k.db.BalanceTable().Save(ctx, balance)
-}
-```
-
-`List` methods take `IndexKey` parameters. For instance, `BalanceTable.List` takes `BalanceIndexKey`. `BalanceIndexKey`
-let's represent index keys for the different indexes (primary and secondary) on the `Balance` table. The primary key
-in the `Balance` table gets a struct `BalanceAccountDenomIndexKey` and the first index gets an index key `BalanceDenomIndexKey`.
-If we wanted to list all the denoms and amounts that an account holds, we would use `BalanceAccountDenomIndexKey`
-with a `List` query just on the account prefix. Ex:
-
-```go
-it, err := keeper.db.BalanceTable().List(ctx, BalanceAccountDenomIndexKey{}.WithAccount(acct))
-```
-
----
-
-## sidebar_position: 1
-
-# ProtocolBuffer Annotations
-
-This document explains the various protobuf scalars that have been added to make working with protobuf easier for Cosmos SDK application developers
-
-## Signer
-
-Signer specifies which field should be used to determine the signer of a message for the Cosmos SDK. This field can be used for clients as well to infer which field should be used to determine the signer of a message.
-
-Read more about the signer field [here](./02-messages-and-queries.md).
-
-```protobuf reference
-https://github.com/cosmos/cosmos-sdk/blob/e6848d99b55a65d014375b295bdd7f9641aac95e/proto/cosmos/bank/v1beta1/tx.proto#L40
-```
-
-```proto
-option (cosmos.msg.v1.signer) = "from_address";
-```
-
-## Scalar
-
-The scalar type defines a way for clients to understand how to construct protobuf messages according to what is expected by the module and sdk.
-
-```proto
-(cosmos_proto.scalar) = "cosmos.AddressString"
-```
-
-Example of account address string scalar:
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/e6848d99b55a65d014375b295bdd7f9641aac95e/proto/cosmos/bank/v1beta1/tx.proto#L46
-```
-
-Example of validator address string scalar:
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9d6/proto/cosmos/distribution/v1beta1/query.proto#L87
-```
-
-Example of pubkey scalar:
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/11068bfbcd44a7db8af63b6a8aa079b1718f6040/proto/cosmos/staking/v1beta1/tx.proto#L94
-```
-
-Example of Decimals scalar:
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9d6/proto/cosmos/distribution/v1beta1/distribution.proto#L26
-```
-
-Example of Int scalar:
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9d6/proto/cosmos/gov/v1/gov.proto#L137
-```
-
-There are a few options for what can be provided as a scalar: `cosmos.AddressString`, `cosmos.ValidatorAddressString`, `cosmos.ConsensusAddressString`, `cosmos.Int`, `cosmos.Dec`.
-
-## Implements_Interface
-
-Implement interface is used to provide information to client tooling like [telescope](https://github.com/cosmology-tech/telescope) on how to encode and decode protobuf messages.
-
-```proto
-option (cosmos_proto.implements_interface) = "cosmos.auth.v1beta1.AccountI";
-```
-
-## Method,Field,Message Added In
-
-`method_added_in`, `field_added_in` and `message_added_in` are annotations to denotate to clients that a field has been supported in a later version. This is useful when new methods or fields are added in later versions and that the client needs to be aware of what it can call.
-
-The annotation should be worded as follow:
-
-```proto
-option (cosmos_proto.method_added_in) = "cosmos-sdk v0.50.1";
-option (cosmos_proto.method_added_in) = "x/epochs v1.0.0";
-option (cosmos_proto.method_added_in) = "simapp v24.0.0";
-```
-
-## Amino
-
-The amino codec was removed in `v0.50+`, this means there is not a need register `legacyAminoCodec`. To replace the amino codec, Amino protobuf annotations are used to provide information to the amino codec on how to encode and decode protobuf messages.
-
-:::note
-Amino annotations are only used for backwards compatibility with amino. New modules are not required use amino annotations.
-:::
-
-The below annotations are used to provide information to the amino codec on how to encode and decode protobuf messages in a backwards compatible manner.
-
-### Name
-
-Name specifies the amino name that would show up for the user in order for them see which message they are signing.
-
-```proto
-option (amino.name) = "cosmos-sdk/BaseAccount";
-```
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9d6/proto/cosmos/bank/v1beta1/tx.proto#L41
-```
-
-### Field_Name
-
-Field name specifies the amino name that would show up for the user in order for them see which field they are signing.
-
-```proto
-uint64 height = 1 [(amino.field_name) = "public_key"];
-```
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9d6/proto/cosmos/distribution/v1beta1/distribution.proto#L166
-```
-
-### Dont_OmitEmpty
-
-Dont omitempty specifies that the field should not be omitted when encoding to amino.
-
-```proto
-repeated cosmos.base.v1beta1.Coin amount = 3 [(amino.dont_omitempty)   = true];
-```
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9d6/proto/cosmos/bank/v1beta1/bank.proto#L56
-```
-
-### Encoding
-
-Encoding instructs the amino json marshaler how to encode certain fields that may differ from the standard encoding behaviour. The most common example of this is how `repeated cosmos.base.v1beta1.Coin` is encoded when using the amino json encoding format. The `legacy_coins` option tells the json marshaler [how to encode a null slice](https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9d6/x/tx/signing/aminojson/json_marshal.go#L65) of `cosmos.base.v1beta1.Coin`.
-
-```proto
-(amino.encoding)         = "legacy_coins",
-```
-
-```proto reference
-https://github.com/cosmos/cosmos-sdk/blob/e8f28bf5db18b8d6b7e0d94b542ce4cf48fed9d6/proto/cosmos/bank/v1beta1/genesis.proto#L23
-```
-
-Another example is a protobuf `bytes` that contains a valid JSON document.
-The `inline_json` option tells the json marshaler to embed the JSON bytes into the wrapping document without escaping.
-
-```proto
-(amino.encoding)         = "inline_json",
-```
-
-E.g. the bytes containing `{"foo":123}` in the `envelope` field would lead to the following JSON:
-
-```json
-{
-  "envelope": {
-    "foo": 123
-  }
-}
-```
-
-If the bytes are not valid JSON, this leads to JSON broken documents. Thus a JSON validity check needs to be in place at some point of the process.

.github/aider/guides/cosmos-rfc.md

@@ -1,627 +0,0 @@
-# RFC 004: Account System Refactor
-
-## Status
-- Draft v2 (May 2023)
-
-## Current Limitations
-
-1. **Account Representation**: Limited by `google.Protobuf.Any` encapsulation and basic authentication methods
-2. **Interface Constraints**: Lacks support for advanced functionalities like vesting and complex auth systems
-3. **Implementation Rigidity**: Poor differentiation between account types (e.g., `ModuleAccount`)
-4. **Authorization System**: Basic `x/auth` module with limited scope beyond `x/bank` functionality
-5. **Dependency Issues**: Cyclic dependencies between modules (e.g., `x/auth` ↔ `x/bank` for vesting)
-
-## Proposal
-
-This proposal aims to transform the way accounts are managed within the Cosmos SDK by introducing significant changes to
-their structure and functionality.
-
-### Rethinking Account Representation and Business Logic
-
-Instead of representing accounts as simple `google.Protobuf.Any` structures stored in state with no business logic
-attached, this proposal suggests a more sophisticated account representation that is closer to module entities.
-In fact, accounts should be able to receive messages and process them in the same way modules do, and be capable of storing
-state in a isolated (prefixed) portion of state belonging only to them, in the same way as modules do.
-
-### Account Message Reception
-
-We propose that accounts should be able to receive messages in the same way modules can, allowing them to manage their
-own state modifications without relying on other modules. This change would enable more advanced account functionality, such as the
-`VestingAccount` example, where the x/bank module previously needed to change the vestingState by casting the abstracted
-account to `VestingAccount` and triggering the `TrackDelegation` call. Accounts are already capable of sending messages when
-a state transition, originating from a transaction, is executed.
-
-When accounts receive messages, they will be able to identify the sender of the message and decide how to process the
-state transition, if at all.
-
-### Consequences
-
-These changes would have significant implications for the Cosmos SDK, resulting in a system of actors that are equal from
-the runtime perspective. The runtime would only be responsible for propagating messages between actors and would not
-manage the authorization system. Instead, actors would manage their own authorizations. For instance, there would be no
-need for the `x/auth` module to manage minting or burning of coins permissions, as it would fall within the scope of the
-`x/bank` module.
-
-The key difference between accounts and modules would lie in the origin of the message (state transition). Accounts
-(ExternallyOwnedAccount), which have credentials (e.g., a public/private key pairing), originate state transitions from
-transactions. In contrast, module state transitions do not have authentication credentials backing them and can be
-caused by two factors: either as a consequence of a state transition coming from a transaction or triggered by a scheduler
-(e.g., the runtime's Begin/EndBlock).
-
-By implementing these proposed changes, the Cosmos SDK will benefit from a more extensible, versatile, and efficient account
-management system that is better suited to address the requirements of the Cosmos ecosystem.
-
-#### Standardization
-
-With `x/accounts` allowing a modular api there becomes a need for standardization of accounts or the interfaces wallets and other clients should expect to use. For this reason we will be using the [`CIP` repo](https://github.com/cosmos/cips) in order to standardize interfaces in order for wallets to know what to expect when interacting with accounts.
-
-## Implementation
-
-### Account Definition
-
-We define the new `Account` type, which is what an account needs to implement to be treated as such.
-An `Account` type is defined at APP level, so it cannot be dynamically loaded as the chain is running without upgrading the
-node code, unless we create something like a `CosmWasmAccount` which is an account backed by an `x/wasm` contract.
-
-```go
-// Account is what the developer implements to define an account.
-type Account[InitMsg proto.Message] interface {
-	// Init is the function that initialises an account instance of a given kind.
-	// InitMsg is used to initialise the initial state of an account.
-	Init(ctx *Context, msg InitMsg) error
-	// RegisterExecuteHandlers registers an account's execution messages.
-	RegisterExecuteHandlers(executeRouter *ExecuteRouter)
-	// RegisterQueryHandlers registers an account's query messages.
-	RegisterQueryHandlers(queryRouter *QueryRouter)
-	// RegisterMigrationHandlers registers an account's migration messages.
-	RegisterMigrationHandlers(migrationRouter *MigrationRouter)
-}
-```
-
-### The InternalAccount definition
-
-The public `Account` interface implementation is then converted by the runtime into an `InternalAccount` implementation,
-which contains all the information and business logic needed to operate the account.
-
-```go
-type Schema struct {
-	state StateSchema // represents the state of an account
-	init InitSchema // represents the init msg schema
-	exec ExecSchema // represents the multiple execution msg schemas, containing also responses
-	query QuerySchema // represents the multiple query msg schemas, containing also responses
-	migrate *MigrateSchema // represents the multiple migrate msg schemas, containing also responses, it's optional
-}
-
-type InternalAccount struct {
-	init    func(ctx *Context, msg proto.Message) (*InitResponse, error)
-	execute func(ctx *Context, msg proto.Message) (*ExecuteResponse, error)
-	query   func(ctx *Context, msg proto.Message) (proto.Message, error)
-    schema  func() *Schema
-    migrate func(ctx *Context, msg proto.Message) (*MigrateResponse, error)
-}
-```
-
-This is an internal view of the account as intended by the system. It is not meant to be what developers implement. An
-example implementation of the `InternalAccount` type can be found in [this](https://github.com/testinginprod/accounts-poc/blob/main/examples/recover/recover.go)
-example of account whose credentials can be recovered. In fact, even if the `Internal` implementation is untyped (with
-respect to `proto.Message`), the concrete implementation is fully typed.
-
-During any of the execution methods of `InternalAccount`, `schema` excluded, the account is given a `Context` which provides:
-
-- A namespaced `KVStore` for the account, which isolates the account state from others (NOTE: no `store keys` needed,
-  the account address serves as `store key`).
-- Information regarding itself (its address)
-- Information regarding the sender.
-- ...
-
-#### Init
-
-Init defines the entrypoint that allows for a new account instance of a given kind to be initialised.
-The account is passed some opaque protobuf message which is then interpreted and contains the instructions that
-constitute the initial state of an account once it is deployed.
-
-An `Account` code can be deployed multiple times through the `Init` function, similar to how a `CosmWasm` contract code
-can be deployed (Instantiated) multiple times.
-
-#### Execute
-
-Execute defines the entrypoint that allows an `Account` to process a state transition, the account can decide then how to
-process the state transition based on the message provided and the sender of the transition.
-
-#### Query
-
-Query defines a read-only entrypoint that provides a stable interface that links an account with its state. The reason for
-which `Query` is still being preferred as an addition to raw state reflection is to:
-
-- Provide a stable interface for querying (state can be optimised and change more frequently than a query)
-- Provide a way to define an account `Interface` with respect to its `Read/Write` paths.
-- Provide a way to query information that cannot be processed from raw state reflection, ex: compute information from lazy
-  state that has not been yet concretely processed (eg: balances with respect to lazy inputs/outputs)
-
-#### Schema
-
-Schema provides the definition of an account from `API` perspective, and it's the only thing that should be taken into account
-when interacting with an account from another account or module, for example: an account is an `authz-interface` account if
-it has the following message in its execution messages `MsgProxyStateTransition{ state_transition: google.Protobuf.Any }`.
-
-### Migrate
-
-Migrate defines the entrypoint that allows an `Account` to migrate its state from a previous version to a new one. Migrations
-can be initiated only by the account itself, concretely this means that the migrate action sender can only be the account address
-itself, if the account wants to allow another address to migrate it on its behalf then it could create an execution message
-that makes the account migrate itself.
-
-### x/accounts module
-
-In order to create accounts we define a new module `x/accounts`, note that `x/accounts` deploys account with no authentication
-credentials attached to it which means no action of an account can be incepted from a TX, we will later explore how the
-`x/authn` module uses `x/accounts` to deploy authenticated accounts.
-
-This also has another important implication for which account addresses are now fully decoupled from the authentication mechanism
-which makes in turn off-chain operations a little more complex, as the chain becomes the real link between account identifier
-and credentials.
-
-We could also introduce a way to deterministically compute the account address.
-
-Note, from the transaction point of view, the `init_message` and `execute_message` are opaque `google.Protobuf.Any`.
-
-The module protobuf definition for `x/accounts` are the following:
-
-```protobuf
-// Msg defines the Msg service.
-service Msg {
-  rpc Deploy(MsgDeploy) returns (MsgDeployResponse);
-  rpc Execute(MsgExecute) returns (MsgExecuteResponse);
-  rpc Migrate(MsgMigrate) returns (MsgMigrateResponse);
-}
-
-message MsgDeploy {
-  string sender = 1;
-  string kind = 2;
-  google.Protobuf.Any init_message = 3;
-  repeated google.Protobuf.Any authorize_messages = 4 [(gogoproto.nullable) = false];
-}
-
-message MsgDeployResponse {
-  string address = 1;
-  uint64 id = 2;
-  google.Protobuf.Any data = 3;
-}
-
-message MsgExecute {
-  string sender = 1;
-  string address = 2;
-  google.Protobuf.Any message = 3;
-  repeated google.Protobuf.Any authorize_messages = 4 [(gogoproto.nullable) = false];
-}
-
-message MsgExecuteResponse {
-  google.Protobuf.Any data = 1;
-}
-
-message MsgMigrate {
-  string sender = 1;
-  string new_account_kind = 2;
-  google.Protobuf.Any migrate_message = 3;
-}
-
-message MsgMigrateResponse {
-  google.Protobuf.Any data = 1;
-}
-
-```
-
-#### MsgDeploy
-
-Deploys a new instance of the given account `kind` with initial settings represented by the `init_message` which is a `google.Protobuf.Any`.
-Of course the `init_message` can be empty. A response is returned containing the account ID and humanised address, alongside some response
-that the account instantiation might produce.
-
-#### Address derivation
-
-In order to decouple public keys from account addresses, we introduce a new address derivation mechanism which is
-
-#### MsgExecute
-
-Sends a `StateTransition` execution request, where the state transition is represented by the `message` which is a `google.Protobuf.Any`.
-The account can then decide if to process it or not based on the `sender`.
-
-### MsgMigrate
-
-Migrates an account to a new version of itself, the new version is represented by the `new_account_kind`. The state transition
-can only be incepted by the account itself, which means that the `sender` must be the account address itself. During the migration
-the account current state is given to the new version of the account, which then executes the migration logic using the `migrate_message`,
-it might change state or not, it's up to the account to decide. The response contains possible data that the account might produce
-after the migration.
-
-#### Authorize Messages
-
-The `Deploy` and `Execute` messages have a field in common called `authorize_messages`, these messages are messages that the account
-can execute on behalf of the sender. For example, in case an account is expecting some funds to be sent from the sender,
-the sender can attach a `MsgSend` that the account can execute on the sender's behalf. These authorizations are short-lived,
-they live only for the duration of the `Deploy` or `Execute` message execution, or until they are consumed.
-
-An alternative would have been to add a `funds` field, like it happens in cosmwasm, which guarantees the called contract that
-the funds are available and sent in the context of the message execution. This would have been a simpler approach, but it would
-have been limited to the context of `MsgSend` only, where the asset is `sdk.Coins`. The proposed generic way, instead, allows
-the account to execute any message on behalf of the sender, which is more flexible, it could include NFT send execution, or
-more complex things like `MsgMultiSend` or `MsgDelegate`, etc.
-
-### Further discussion
-
-#### Sub-accounts
-
-We could provide a way to link accounts to other accounts. Maybe during deployment the sender could decide to link the
-newly created to its own account, although there might be use-cases for which the deployer is different from the account
-that needs to be linked, in this case a handshake protocol on linking would need to be defined.
-
-#### Predictable address creation
-
-We need to provide a way to create an account with a predictable address, this might serve a lot of purposes, like accounts
-wanting to generate an address that:
-
-- nobody else can claim besides the account used to generate the new account
-- is predictable
-
-For example:
-
-```protobuf
-
-message MsgDeployPredictable {
-  string sender = 1;
-  uint32 nonce = 2;
-  ...
-}
-```
-
-And then the address becomes `bechify(concat(sender, nonce))`
-
-`x/accounts` would still use the monotonically increasing sequence as account number.
-
-#### Joining Multiple Accounts
-
-As developers are building new kinds of accounts, it becomes necessary to provide a default way to combine the
-functionalities of different account types. This allows developers to avoid duplicating code and enables end-users to
-create or migrate to accounts with multiple functionalities without requiring custom development.
-
-To address this need, we propose the inclusion of a default account type called "MultiAccount". The MultiAccount type is
-designed to merge the functionalities of other accounts by combining their execution, query, and migration APIs.
-The account joining process would only fail in the case of API (intended as non-state Schema APIs) conflicts, ensuring
-compatibility and consistency.
-
-With the introduction of the MultiAccount type, users would have the option to either migrate their existing accounts to
-a MultiAccount type or extend an existing MultiAccount with newer APIs. This flexibility empowers users to leverage
-various account functionalities without compromising compatibility or resorting to manual code duplication.
-
-The MultiAccount type serves as a standardized solution for combining different account functionalities within the
-cosmos-sdk ecosystem. By adopting this approach, developers can streamline the development process and users can benefit
-from a modular and extensible account system.
-
-# ADR 071: Cryptography v2- Multi-curve support
-
-## Change log
-
-- May 7th 2024: Initial Draft (Zondax AG: @raynaudoe @juliantoledano @jleni @educlerici-zondax @lucaslopezf)
-- June 13th 2024: Add CometBFT implementation proposal (Zondax AG: @raynaudoe @juliantoledano @jleni @educlerici-zondax @lucaslopezf)
-- July 2nd 2024: Split ADR proposal, add link to ADR in cosmos/crypto (Zondax AG: @raynaudoe @juliantoledano @jleni @educlerici-zondax @lucaslopezf)
-
-## Status
-
-DRAFT
-
-## Abstract
-
-This ADR proposes the refactoring of the existing `Keyring` and `cosmos-sdk/crypto` code to implement [ADR-001-CryptoProviders](https://github.com/cosmos/crypto/blob/main/docs/architecture/adr-001-crypto-provider.md).
-
-For in-depth details of the `CryptoProviders` and their design please refer to ADR mentioned above.
-
-## Introduction
-
-The introduction of multi-curve support in the cosmos-sdk cryptographic package offers significant advantages. By not being restricted to a single cryptographic curve, developers can choose the most appropriate curve based on security, performance, and compatibility requirements. This flexibility enhances the application's ability to adapt to evolving security standards and optimizes performance for specific use cases, helping to future-proofing the sdk's cryptographic capabilities.
-
-The enhancements in this proposal not only render the ["Keyring ADR"](https://github.com/cosmos/cosmos-sdk/issues/14940) obsolete, but also encompass its key aspects, replacing it with a more flexible and comprehensive approach. Furthermore, the gRPC service proposed in the mentioned ADR can be easily implemented as a specialized `CryptoProvider`.
-
-### Glossary
-
-1. **Interface**: In the context of this document, "interface" refers to Go's interface.
-
-2. **Module**: In this document, "module" refers to a Go module.
-
-3. **Package**: In the context of Go, a "package" refers to a unit of code organization.
-
-## Context
-
-In order to fully understand the need for changes and the proposed improvements, it's crucial to consider the current state of affairs:
-
-- The Cosmos SDK currently lacks a comprehensive ADR for the cryptographic package.
-
-- If a blockchain project requires a cryptographic curve that is not supported by the current SDK, the most likely scenario is that they will need to fork the SDK repository and make modifications. These modifications could potentially make the fork incompatible with future updates from the upstream SDK, complicating maintenance and integration.
-
-- Type leakage of specific crypto data types expose backward compatibility and extensibility challenges.
-
-- The demand for a more flexible and extensible approach to cryptography and address management is high.
-
-- Architectural changes are necessary to resolve many of the currently open issues related to new curves support.
-
-- There is a current trend towards modularity in the Interchain stack (e.g., runtime modules).
-
-- Security implications are a critical consideration during the redesign work.
-
-## Objectives
-
-The key objectives for this proposal are:
-
-- Leverage `CryptoProviders`: Utilize them as APIs for cryptographic tools, ensuring modularity, flexibility, and ease of integration.
-
-Developer-Centric Approach
-
-- Prioritize clear, intuitive interfaces and best-practice design principles.
-
-Quality Assurance
-
-- Enhanced Test Coverage: Improve testing methodologies to ensure the robustness and reliability of the module.
-
-## Technical Goals
-
-New Keyring:
-
-- Design a new `Keyring` interface with modular backends injection system to support hardware devices and cloud-based HSMs. This feature is optional and tied to complexity; if it proves too complex, it will be deferred to a future release as an enhancement.
-
-## Proposed architecture
-
-### Components
-
-The main components to be used will be the same as those found in the [ADR-001](https://github.com/cosmos/crypto/blob/main/docs/architecture/adr-001-crypto-provider.md#components).
-
-#### Storage and persistence
-
-The storage and persistence layer is tasked with storing a `CryptoProvider`s. Specifically, this layer must:
-
-- Securely store the crypto provider's associated private key (only if stored locally, otherwise a reference to the private key will be stored instead).
-- Store the [`ProviderMetadata`](https://github.com/cosmos/crypto/blob/main/docs/architecture/adr-001-crypto-provider.md#metadata) struct which contains the data that distinguishes that provider.
-
-The purpose of this layer is to ensure that upon retrieval of the persisted data, we can access the provider's type, version, and specific configuration (which varies based on the provider type). This information will subsequently be utilized to initialize the appropriate factory, as detailed in the following section on the factory pattern.
-
-The storage proposal involves using a modified version of the [Record](https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/crypto/keyring/v1/record.proto) struct, which is already defined in **Keyring/v1**. Additionally, we propose utilizing the existing keyring backends (keychain, filesystem, memory, etc.) to store these `Record`s in the same manner as the current **Keyring/v1**.
-
-_Note: This approach will facilitate a smoother migration path from the current Keyring/v1 to the proposed architecture._
-
-Below is the proposed protobuf message to be included in the modified `Record.proto` file
-
-##### Protobuf message structure
-
-The [record.proto](https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/crypto/keyring/v1/record.proto) file will be modified to include the `CryptoProvider` message as an optional field as follows.
-
-```protobuf
-
-// record.proto
-
-message Record {
-  string name = 1;
-  google.protobuf.Any pub_key = 2;
-
-  oneof item {
-    Local local = 3;
-    Ledger ledger = 4;
-    Multi multi = 5;
-    Offline offline = 6;
-    CryptoProvider crypto_provider = 7; // <- New
-  }
-
-  message Local {
-    google.protobuf.Any priv_key = 1;
-  }
-
-  message Ledger {
-    hd.v1.BIP44Params path = 1;
-  }
-
-  message Multi {}
-
-  message Offline {}
-}
-```
-
-##### Creating and loading a `CryptoProvider`
-
-For creating providers, we propose a _factory pattern_ and a _registry_ for these builders. Examples of these
-patterns can be found [here](https://github.com/cosmos/crypto/blob/main/docs/architecture/adr-001-crypto-provider.md#illustrative-code-snippets)
-
-##### Keyring
-
-The new `Keyring` interface will serve as a central hub for managing and fetching `CryptoProviders`. To ensure a smoother migration path, the new Keyring will be backward compatible with the previous version. Since this will be the main API from which applications will obtain their `CryptoProvider` instances, the proposal is to extend the Keyring interface to include the methods:
-
-```go
-type KeyringV2 interface {
-  // methods from Keyring/v1
-
-  // ListCryptoProviders returns a list of all the stored CryptoProvider metadata.
-  ListCryptoProviders() ([]ProviderMetadata, error)
-
-  // GetCryptoProvider retrieves a specific CryptoProvider by its id.
-  GetCryptoProvider(id string) (CryptoProvider, error)
-}
-```
-
-_Note_: Methods to obtain a provider from a public key or other means that make it easier to load the desired provider can be added.
-
-##### Especial use case: remote signers
-
-It's important to note that the `CryptoProvider` interface is versatile enough to be implemented as a remote signer. This capability allows for the integration of remote cryptographic operations, which can be particularly useful in distributed or cloud-based environments where local cryptographic resources are limited or need to be managed centrally.
-
-## Alternatives
-
-It is important to note that all the code presented in this document is not in its final form and could be subject to changes at the time of implementation. The examples and implementations discussed should be interpreted as alternatives, providing a conceptual framework rather than definitive solutions. This flexibility allows for adjustments based on further insights, technical evaluations, or changing requirements as development progresses.
-
-## Decision
-
-We will:
-
-- Leverage crypto providers
-- Refactor the module structure as described above.
-- Define types and interfaces as the code attached.
-- Refactor existing code into new structure and interfaces.
-- Implement Unit Tests to ensure no backward compatibility issues.
-
-## Consequences
-
-### Impact on the SDK codebase
-
-We can divide the impact of this ADR into two main categories: state machine code and client related code.
-
-#### Client
-
-The major impact will be on the client side, where the current `Keyring` interface will be replaced by the new `KeyringV2` interface. At first, the impact will be low since `CryptoProvider` is an optional field in the `Record` message, so there's no mandatory requirement for migrating to this new concept right away. This allows a progressive transition where the risks of breaking changes or regressions are minimized.
-
-#### State Machine
-
-The impact on the state machine code will be minimal, the modules affected (at the time of writing this ADR)
-are the `x/accounts` module, specifically the `Authenticate` function and the `x/auth/ante` module. This function will need to be adapted to use a `CryptoProvider` service to make use of the `Verifier` instance.
-
-Worth mentioning that there's also the alternative of using `Verifier` instances in a standalone fashion (see note below).
-
-The specific way to adapt these modules will be deeply analyzed and decided at implementation time of this ADR.
-
-_Note_: All cryptographic tools (hashers, verifiers, signers, etc.) will continue to be available as standalone packages that can be imported and utilized directly without the need for a `CryptoProvider` instance. However, the `CryptoProvider` is the recommended method for using these tools as it offers a more secure way to handle sensitive data, enhanced modularity, and the ability to store configurations and metadata within the `CryptoProvider` definition.
-
-### Backwards Compatibility
-
-The proposed migration path is similar to what the cosmos-sdk has done in the past. To ensure a smooth transition, the following steps will be taken:
-
-Once ADR-001 is implemented with a stable release:
-
-- Deprecate the old crypto package. The old crypto package will still be usable, but it will be marked as deprecated and users can opt to use the new package.
-- Migrate the codebase to use the new cosmos/crypto package and remove the old crypto one.
-
-### Positive
-
-- Single place of truth
-- Easier to use interfaces
-- Easier to extend
-- Unit test for each crypto package
-- Greater maintainability
-- Incentivize addition of implementations instead of forks
-- Decoupling behavior from implementation
-- Sanitization of code
-
-### Negative
-
-- It will involve an effort to adapt existing code.
-- It will require attention to detail and audition.
-
-### Neutral
-
-- It will involve extensive testing.
-
-## Test Cases
-
-- The code will be unit tested to ensure a high code coverage
-- There should be integration tests around Keyring and CryptoProviders.
-
-> While an ADR is in the DRAFT or PROPOSED stage, this section should contain a
-> summary of issues to be solved in future iterations (usually referencing comments
-> from a pull-request discussion).
->
-> Later, this section can optionally list ideas or improvements the author or
-> reviewers found during the analysis of this ADR.
-
-# ADR-71 Bank V2
-
-## Status
-
-DRAFT
-
-## Changelog
-
-- 2024-05-08: Initial Draft (@samricotta, @julienrbrt)
-
-## Abstract
-
-The primary objective of refactoring the bank module is to simplify and enhance the functionality of the Cosmos SDK. Over time the bank module has been burdened with numerous responsibilities including transaction handling, account restrictions, delegation counting, and the minting and burning of coins.
-
-In addition to the above, the bank module is currently too rigid and handles too many tasks, so this proposal aims to streamline the module by focusing on core functions `Send`, `Mint`, and `Burn`.
-
-Currently, the module is split across different keepers with scattered and duplicates functionalities (with 4 send functions for instance).
-
-Additionally, the integration of the token factory into the bank module allows for standardization, and better integration within the core modules.
-
-This rewrite will reduce complexity and enhance the efficiency and UX of the bank module.
-
-## Context
-
-The current implementation of the bank module is characterised by its handling of a broad array of functions, leading to significant complexity in using and extending the bank module.
-
-These issues have underscored the need for a refactoring strategy that simplifies the module’s architecture and focuses on its most essential operations.
-
-Additionally, there is an overlap in functionality with a Token Factory module, which could be integrated to streamline oper.
-
-## Decision
-
-**Permission Tightening**: Access to the module can be restricted to selected denominations only, ensuring that it operates within designated boundaries and does not exceed its intended scope. Currently, the permissions allow all denoms, so this should be changed. Send restrictions functionality will be maintained.
-
-**Simplification of Logic**: The bank module will focus on core functionalities `Send`, `Mint`, and `Burn`. This refinement aims to streamline the architecture, enhancing both maintainability and performance.
-
-**Integration of Token Factory**: The Token Factory will be merged into the bank module. This consolidation of related functionalities aims to reduce redundancy and enhance coherence within the system. Migrations functions will be provided for migrating from Osmosis' Token Factory module to bank/v2.
-
-**Legacy Support**: A legacy wrapper will be implemented to ensure compatibility with about 90% of existing functions. This measure will facilitate a smooth transition while keeping older systems functional.
-
-**Denom Implementation**: A asset interface will be added to standardise interactions such as transfers, balance inquiries, minting, and burning across different tokens. This will allow the bank module to support arbitrary asset types, enabling developers to implement custom, ERC20-like denominations.
-
-For example, currently if a team would like to extend the transfer method the changes would apply universally, affecting all denom’s. With the proposed Asset Interface, it allows teams to customise or extend the transfer method specifically for their own tokens without impacting others.
-
-These improvements are expected to enhance the flexibility of the bank module, allowing for the creation of custom tokens similar to ERC20 standards and assets backed by CosmWasm (CW) contracts. The integration efforts will also aim to unify CW20 with bank coins across the Cosmos chains.
-
-Example of denom interface:
-
-```go
-type AssetInterface interface {
-    Transfer(ctx sdk.Context, from sdk.AccAddress, to sdk.AccAddress, amount sdk.Coin) error
-    Mint(ctx sdk.Context, to sdk.AccAddress, amount sdk.Coin) error
-    Burn(ctx sdk.Context, from sdk.AccAddress, amount sdk.Coin) error
-    QueryBalance(ctx sdk.Context, account sdk.AccAddress) (sdk.Coin, error)
-}
-```
-
-Overview of flow:
-
-1. Alice initiates a transfer by entering Bob's address and the amount (100 ATOM)
-2. The Bank module verifies that the ATOM token implements the `AssetInterface` by querying the `ATOM_Denom_Account`, which is an `x/account` denom account.
-3. The Bank module executes the transfer by subtracting 100 ATOM from Alice’s balance and adding 100 ATOM to Bob’s balance.
-4. The Bank module calls the Transfer method on the `ATOM_Denom_Account`. The Transfer method, defined in the `AssetInterface`, handles the logic to subtract 100 ATOM from Alice’s balance and add 100 ATOM to Bob’s balance.
-5. The Bank module updates the chain and returns the new balances.
-6. Both Alice and Bob successfully receive the updated balances.
-
-## Migration Plans
-
-Bank is a widely used module, so getting a v2 needs to be thought thoroughly. In order to not force all dependencies to immediately migrate to bank/v2, the same _upgrading_ path will be taken as for the `gov` module.
-
-This means `cosmossdk.io/bank` will stay one module and there won't be a new `cosmossdk.io/bank/v2` go module. Instead the bank protos will be versioned from `v1beta1` (current bank) to `v2`.
-
-Bank `v1beta1` endpoints will use the new bank v2 implementation for maximum backward compatibility.
-
-The bank `v1beta1` keepers will be deprecated and potentially eventually removed, but its proto and messages definitions will remain.
-
-Additionally, as bank plans to integrate token factory, migrations functions will be provided to migrate from Osmosis token factory implementation (most widely used implementation) to the new bank/v2 token factory.
-
-## Consequences
-
-### Positive
-
-- Simplified interaction with bank APIs
-- Backward compatible changes (no contracts or apis broken)
-- Optional migration (note: bank `v1beta1` won't get any new feature after bank `v2` release)
-
-### Neutral
-
-- Asset implementation not available cross-chain (IBC-ed custom asset should possibly fallback to the default implementation)
-- Many assets may slow down bank balances requests
-
-### Negative
-
-- Temporarily duplicate functionalities as bank `v1beta1` are `v2` are living alongside
-- Difficultity to ever completely remove bank `v1beta1`
-
-### References
-
-- Current bank module implementation: https://github.com/cosmos/cosmos-sdk/blob/v0.50.6/x/bank/keeper/keeper.go#L22-L53
-- Osmosis token factory: https://github.com/osmosis-labs/osmosis/tree/v25.0.0/x/tokenfactory/keeper

.github/aider/guides/cosmos-sdk.md

@@ -1,685 +0,0 @@
-# Cosmos SDK Core Components
-
-## Overview
-
-The Cosmos SDK is a framework for building secure blockchain applications on CometBFT. It provides:
-
-- ABCI implementation in Go
-- Multi-store persistence layer  
-- Transaction routing system
-
-## Transaction Flow
-
-1. CometBFT consensus delivers transaction bytes
-2. SDK decodes transactions and extracts messages
-3. Messages routed to appropriate modules
-4. State changes committed to stores
-
-```mermaid
-graph TD
-    A[CometBFT] -->|Tx Bytes| B[SDK Decode]
-    B -->|Messages| C[Module Router] 
-    C -->|State Changes| D[Multi-store]
-```
-
-## `baseapp`
-
-`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](../beginner/00-app-anatomy.md#core-application-file).
-
-Here is an example of this from `simapp`, the Cosmos SDK demonstration app:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.1/simapp/app.go#L145-L186
-```
-
-The goal of `baseapp` is to provide a secure interface between the store and the extensible state machine while defining as little about the state machine as possible (staying true to the ABCI).
-
-For more on `baseapp`, please click [here](../advanced/00-baseapp.md).
-
-## Multistore
-
-The Cosmos SDK provides a [`multistore`](../advanced/04-store.md#multistore) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../advanced/04-store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../advanced/05-encoding.md) before being stored.
-
-The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](../advanced/04-store.md#multistore).
-
-## Modules
-
-The power of the Cosmos SDK lies in its modularity. Cosmos SDK applications are built by aggregating a collection of interoperable modules. Each module defines a subset of the state and contains its own message/transaction processor, while the Cosmos SDK is responsible for routing each message to its respective module.
-
-Here is a simplified view of how a transaction is processed by the application of each full-node when it is received in a valid block:
-
-```mermaid
- flowchart TD
-    A[Transaction relayed from the full-node's CometBFT engine to the node's application via DeliverTx] --> B[APPLICATION]
-    B -->|"Using baseapp's methods: Decode the Tx, extract and route the message(s)"| C[Message routed to the correct module to be processed]
-    C --> D1[AUTH MODULE]
-    C --> D2[BANK MODULE]
-    C --> D3[STAKING MODULE]
-    C --> D4[GOV MODULE]
-    D1 -->|Handle message, Update state| E["Return result to CometBFT (0=Ok, 1=Err)"]
-    D2 -->|Handle message, Update state| E["Return result to CometBFT (0=Ok, 1=Err)"]
-    D3 -->|Handle message, Update state| E["Return result to CometBFT (0=Ok, 1=Err)"]
-    D4 -->|Handle message, Update state| E["Return result to CometBFT (0=Ok, 1=Err)"]
-```
-
-Each module can be seen as a little state-machine. Developers need to define the subset of the state handled by the module, as well as custom message types that modify the state (_Note:_ `messages` are extracted from `transactions` by `baseapp`). In general, each module declares its own `KVStore` in the `multistore` to persist the subset of the state it defines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on [object-capabilities](../advanced/10-ocap.md). In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called `keepers` that can be passed to other modules to grant a pre-defined set of capabilities.
-
-Cosmos SDK modules are defined in the `x/` folder of the Cosmos SDK. Some core modules include:
-
-- `x/auth`: Used to manage accounts and signatures.
-- `x/bank`: Used to enable tokens and token transfers.
-- `x/staking` + `x/slashing`: Used to build Proof-of-Stake blockchains.
-
-In addition to the already existing modules in `x/`, which anyone can use in their app, the Cosmos SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://tutorials.cosmos.network/).# Keepers
-
-:::note Synopsis
-`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage access to the subset of the state defined by various modules. `Keeper`s are module-specific, i.e. the subset of state defined by a module can only be accessed by a `keeper` defined in said module. If a module needs to access the subset of state defined by another module, a reference to the second module's internal `keeper` needs to be passed to the first one. This is done in `app.go` during the instantiation of module keepers.
-:::
-
-:::note Pre-requisite Readings
-
-- [Introduction to Cosmos SDK Modules](./00-intro.md)
-
-:::
-
-## Motivation
-
-The Cosmos SDK is a framework that makes it easy for developers to build complex decentralized applications from scratch, mainly by composing modules together. As the ecosystem of open-source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer.
-
-The Cosmos SDK adopts an [object-capabilities-based approach](https://docs.cosmos.network/main/learn/advanced/ocap#ocaps-in-practice) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be considered quite literally to be the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](../../learn/advanced/04-store.md#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s).
-
-The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](../../learn/beginner/00-app-anatomy.md#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers.
-
-## Type Definition
-
-`keeper`s are generally implemented in a `/keeper/keeper.go` file located in the module's folder. By convention, the type `keeper` of a module is simply named `Keeper` and usually follows the following structure:
-
-```go
-type Keeper struct {
-    // External keepers, if any
-
-    // Store key(s)
-
-    // codec
-
-    // authority
-}
-```
-
-For example, here is the type definition of the `keeper` from the `staking` module:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.1/x/staking/keeper/keeper.go#L54-L115
-```
-
-Let us go through the different parameters:
-
-- An expected `keeper` is a `keeper` external to a module that is required by the internal `keeper` of said module. External `keeper`s are listed in the internal `keeper`'s type definition as interfaces. These interfaces are themselves defined in an `expected_keepers.go` file in the root of the module's folder. In this context, interfaces are used to reduce the number of dependencies, as well as to facilitate the maintenance of the module itself.
-- `KVStoreService`s grant access to the store(s) of the [multistore](../../learn/advanced/04-store.md) managed by the module. They should always remain unexposed to external modules.
-- `cdc` is the [codec](../../learn/advanced/05-encoding.md) used to marshal and unmarshal structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces.
-- The authority listed is a module account or user account that has the right to change module level parameters. Previously this was handled by the param module, which has been deprecated.
-
-Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](../../learn/beginner/00-app-anatomy.md). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require them.
-
-## Implementing Methods
-
-`Keeper`s primarily expose methods for business logic, as validity checks should have already been performed by the [`Msg` server](./03-msg-services.md) when `keeper`s' methods are called.
-
-<!-- markdown-link-check-disable -->
-
-State management is recommended to be done via [Collections](../packages/collections)
-
-<!-- The above link is created via the script to generate docs  -->
-
-## State Management
-
-In the Cosmos SDK, it is crucial to be methodical and selective when managing state within a module, as improper state management can lead to inefficiency, security risks, and scalability issues. Not all data belongs in the on-chain state; it's important to store only essential blockchain data that needs to be verified by consensus. Storing unnecessary information, especially client-side data, can bloat the state and slow down performance. Instead, developers should focus on using an off-chain database to handle supplementary data, extending the API as needed. This approach minimizes on-chain complexity, optimizes resource usage, and keeps the blockchain state lean and efficient, ensuring scalability and smooth operations.
-
-The Cosmos SDK leverages Protocol Buffers (protobuf) for efficient state management, providing a well-structured, binary encoding format that ensures compatibility and performance across different modules. The SDK’s recommended approach for managing state is through the [collections package](../pacakges/02-collections.md), which simplifies state handling by offering predefined data structures like maps and indexed sets, reducing the complexity of managing raw state data. While users can opt for custom encoding schemes if they need more flexibility or have specialized requirements, they should be aware that such custom implementations may not integrate seamlessly with indexers that decode state data on the fly. This could lead to challenges in data retrieval, querying, and interoperability, making protobuf a safer and more future-proof choice for most use cases.
-
-# Folder Structure
-
-:::note Synopsis
-This document outlines the structure of Cosmos SDK modules. These ideas are meant to be applied as suggestions. Application developers are encouraged to improve upon and contribute to module structure and development design.
-
-The required interface for a module is located in the module.go. Everything beyond this is suggestive.
-:::
-
-## Structure
-
-A typical Cosmos SDK module can be structured as follows:
-
-```shell
-proto
-└── {project_name}
-    └── {module_name}
-        └── {proto_version}
-            ├── {module_name}.proto
-            ├── genesis.proto
-            ├── query.proto
-            └── tx.proto
-```
-
-- `{module_name}.proto`: The module's common message type definitions.
-- `genesis.proto`: The module's message type definitions related to genesis state.
-- `query.proto`: The module's Query service and related message type definitions.
-- `tx.proto`: The module's Msg service and related message type definitions.
-
-```shell
-x/{module_name}
-├── client
-│   ├── cli
-│   │   ├── query.go
-│   │   └── tx.go
-│   └── testutil
-│       ├── cli_test.go
-│       └── suite.go
-├── exported
-│   └── exported.go
-├── keeper
-│   ├── genesis.go
-│   ├── grpc_query.go
-│   ├── hooks.go
-│   ├── invariants.go
-│   ├── keeper.go
-│   ├── keys.go
-│   ├── msg_server.go
-│   └── querier.go
-├── simulation
-│   ├── decoder.go
-│   ├── genesis.go
-│   ├── operations.go
-│   └── params.go
-├── types
-│   ├── {module_name}.pb.go
-│   ├── codec.go
-│   ├── errors.go
-│   ├── events.go
-│   ├── events.pb.go
-│   ├── expected_keepers.go
-│   ├── genesis.go
-│   ├── genesis.pb.go
-│   ├── keys.go
-│   ├── msgs.go
-│   ├── params.go
-│   ├── query.pb.go
-│   └── tx.pb.go
-├── module.go
-├── abci.go
-├── autocli.go
-├── depinject.go
-└── README.md
-```
-
-- `client/`: The module's CLI client functionality implementation and the module's CLI testing suite.
-- `exported/`: The module's exported types - typically interface types. If a module relies on keepers from another module, it is expected to receive the keepers as interface contracts through the `expected_keepers.go` file (see below) in order to avoid a direct dependency on the module implementing the keepers. However, these interface contracts can define methods that operate on and/or return types that are specific to the module that is implementing the keepers and this is where `exported/` comes into play. The interface types that are defined in `exported/` use canonical types, allowing for the module to receive the keepers as interface contracts through the `expected_keepers.go` file. This pattern allows for code to remain DRY and also alleviates import cycle chaos.
-- `keeper/`: The module's `Keeper` and `MsgServer` implementation.
-  - `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined).
-- `simulation/`: The module's [simulation](./14-simulator.md) package defines functions used by the blockchain simulator application (`simapp`).
-- `README.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](../spec/SPEC_MODULE.md).
-- `types/`: includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers.
-  - `codec.go`: The module's registry methods for interface types.
-  - `errors.go`: The module's sentinel errors.
-  - `events.go`: The module's event types and constructors.
-  - `expected_keepers.go`: The module's [expected keeper](./06-keeper.md#type-definition) interfaces.
-  - `genesis.go`: The module's genesis state methods and helper functions.
-  - `keys.go`: The module's store keys and associated helper functions.
-  - `msgs.go`: The module's message type definitions and associated methods.
-  - `params.go`: The module's parameter type definitions and associated methods.
-  - `*.pb.go`: The module's type definitions generated by Protocol Buffers (as defined in the respective `*.proto` files above).
-- The root directory includes the module's `AppModule` implementation.
-  - `autocli.go`: The module [autocli](https://docs.cosmos.network/main/core/autocli) options.
-  - `depinject.go`: The module [depinject](./15-depinject.md#type-definition) options.
-
-> Note: although the above pattern is followed by most of the Cosmos SDK modules, there are some modules that don't follow this pattern. E.g `x/group` and `x/nft` dont have a `types` folder, instead all of the type definitions for messages, events, and genesis state are live in the root directory and the module's `AppModule` implementation lives in the `module` folder.
-
----
-
-## sidebar_position: 1
-
-# `Msg` Services
-
-:::note Synopsis
-A Protobuf `Msg` service processes [messages](./02-messages-and-queries.md#messages). Protobuf `Msg` services are specific to the module in which they are defined, and only process messages defined within the said module. They are called from `BaseApp` during [`FinalizeBlock`](../../learn/advanced/00-baseapp.md#finalizeblock).
-:::
-
-:::note Pre-requisite Readings
-
-- [Module Manager](./01-module-manager.md)
-- [Messages and Queries](./02-messages-and-queries.md)
-
-:::
-
-## Implementation of a module `Msg` service
-
-Each module should define a Protobuf `Msg` service, which will be responsible for processing requests (implementing `sdk.Msg`) and returning responses.
-
-As further described in [ADR 031](../architecture/adr-031-msg-service.md), this approach has the advantage of clearly specifying return types and generating server and client code.
-
-Protobuf generates a `MsgServer` interface based on the definition of `Msg` service. It is the role of the module developer to implement this interface, by implementing the state transition logic that should happen upon receival of each `transaction.Msg`. As an example, here is the generated `MsgServer` interface for `x/bank`, which exposes two `transaction.Msg`s:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/28fa3b8/x/bank/types/tx.pb.go#L564-L579
-```
-
-When possible, the existing module's [`Keeper`](./06-keeper.md) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/28fa3b8/x/bank/keeper/msg_server.go#L16-L19
-```
-
-`msgServer` methods can retrieve the auxiliary information or services using the environment variable, it is always located in the keeper:
-
-Environment:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/07151304e2ec6a185243d083f59a2d543253cb15/core/appmodule/v2/environment.go#L14-L29
-```
-
-Keeper Example:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/07151304e2ec6a185243d083f59a2d543253cb15/x/bank/keeper/keeper.go#L56-L58
-```
-
-`transaction.Msg` processing usually follows these 3 steps:
-
-### Validation
-
-The message server must perform all validation required (both _stateful_ and _stateless_) to make sure the `message` is valid.
-The `signer` is charged for the gas cost of this validation.
-
-For example, a `msgServer` method for a `transfer` message should check that the sending account has enough funds to actually perform the transfer.
-
-It is recommended to implement all validation checks in a separate function that passes state values as arguments. This implementation simplifies testing. As expected, expensive validation functions charge additional gas. Example:
-
-```go
-ValidateMsgA(msg MsgA, now Time, gm GasMeter) error {
-	if now.Before(msg.Expire) {
-		return sdkerrors.ErrInvalidRequest.Wrap("msg expired")
-	}
-	gm.ConsumeGas(1000, "signature verification")
-	return signatureVerificaton(msg.Prover, msg.Data)
-}
-```
-
-:::warning
-Previously, the `ValidateBasic` method was used to perform simple and stateless validation checks.
-This way of validating is deprecated, this means the `msgServer` must perform all validation checks.
-:::
-
-### State Transition
-
-After the validation is successful, the `msgServer` method uses the [`keeper`](./06-keeper.md) functions to access the state and perform a state transition.
-
-### Events
-
-Before returning, `msgServer` methods generally emit one or more [events](../../learn/advanced/08-events.md) by using the `EventManager` held in `environment`.
-
-There are two ways to emit events, typed events using protobuf or arbitrary key & values.
-
-Typed Events:
-
-```go
-ctx.EventManager().EmitTypedEvent(
-	&group.EventABC{Key1: Value1,  Key2, Value2})
-```
-
-Arbitrary Events:
-
-```go
-ctx.EventManager().EmitEvent(
-	sdk.NewEvent(
-		eventType,  // e.g. sdk.EventTypeMessage for a message, types.CustomEventType for a custom event defined in the module
-		sdk.NewAttribute(key1, value1),
-		sdk.NewAttribute(key2, value2),
-	),
-)
-```
-
-These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](../../learn/advanced/08-events.md) to learn more about events.
-
-The invoked `msgServer` method returns a `proto.Message` response and an `error`. These return values are then wrapped into an `*sdk.Result` or an `error`:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/msg_service_router.go#L160
-```
-
-This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `EventManager()` to the `sdk.Result`.
-
-```protobuf reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/base/abci/v1beta1/abci.proto#L93-L113
-```
-
-This diagram shows a typical structure of a Protobuf `Msg` service, and how the message propagates through the module.
-
-```mermaid
-sequenceDiagram
-    participant User
-    participant baseApp
-    participant router
-    participant handler
-    participant msgServer
-    participant keeper
-    participant EventManager
-
-    User->>baseApp: Transaction Type<Tx>
-    baseApp->>router: Route(ctx, msgRoute)
-    router->>handler: handler
-    handler->>msgServer: Msg<Tx>(Context, Msg(..))
-
-    alt addresses invalid, denominations wrong, etc.
-        msgServer->>handler: error
-        handler->>router: error
-        router->>baseApp: result, error code
-    else
-        msgServer->>keeper: perform action, update context
-        keeper->>msgServer: results, error code
-        msgServer->>EventManager: Emit relevant events
-        msgServer->>msgServer: maybe wrap results in more structure
-        msgServer->>handler: result, error code
-        handler->>router: result, error code
-        router->>baseApp: result, error code
-    end
-
-    baseApp->>User: result, error code
-```
-
-## Telemetry
-
-New [telemetry metrics](../../learn/advanced/09-telemetry.md) can be created from `msgServer` methods when handling messages.
-
-This is an example from the `x/auth/vesting` module:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/vesting/msg_server.go#L76-L88
-```
-
-:::Warning
-Telemetry adds a performance overhead to the chain. It is recommended to only use this in critical paths
-:::
-
----
-
-## sidebar_position: 1
-
-# Query Services
-
-:::note Synopsis
-A Protobuf Query service processes [`queries`](./02-messages-and-queries.md#queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](../../learn/advanced/00-baseapp.md#query).
-:::
-
-:::note Pre-requisite Readings
-
-- [Module Manager](./01-module-manager.md)
-- [Messages and Queries](./02-messages-and-queries.md)
-
-:::
-
-## Implementation of a module query service
-
-### gRPC Service
-
-When defining a Protobuf `Query` service, a `QueryServer` interface is generated for each module with all the service methods:
-
-```go
-type QueryServer interface {
-	QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error)
-	QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error)
-}
-```
-
-These custom queries methods should be implemented by a module's keeper, typically in `./keeper/grpc_query.go`. The first parameter of these methods is a generic `context.Context`. Therefore, the Cosmos SDK provides a function `sdk.UnwrapSDKContext` to retrieve the `context.Context` from the provided
-`context.Context`.
-
-Here's an example implementation for the bank module:
-
-```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/keeper/grpc_query.go
-```
-
-### Calling queries from the State Machine
-
-The Cosmos SDK v0.47 introduces a new `cosmos.query.v1.module_query_safe` Protobuf annotation which is used to state that a query that is safe to be called from within the state machine, for example:
-
-- a Keeper's query function can be called from another module's Keeper,
-- ADR-033 intermodule query calls,
-- CosmWasm contracts can also directly interact with these queries.
-
-If the `module_query_safe` annotation set to `true`, it means:
-
-- The query is deterministic: given a block height it will return the same response upon multiple calls, and doesn't introduce any state-machine breaking changes across SDK patch versions.
-- Gas consumption never fluctuates across calls and across patch versions.
-
-If you are a module developer and want to use `module_query_safe` annotation for your own query, you have to ensure the following things:
-
-- the query is deterministic and won't introduce state-machine-breaking changes without coordinated upgrades
-- it has its gas tracked, to avoid the attack vector where no gas is accounted for
-  on potentially high-computation queries.
-
-  ***
-
-  sidebar_position: 1
-
----
-
-# Blockchain Architecture
-
-## Introduction
-
-Blockchain architecture is a complex topic that involves many different components. In this section, we will cover the main layers of a blockchain application built with the Cosmos SDK.
-
-At its core, a blockchain is a replicated deterministic state machine. This document explores the various layers of blockchain architecture, focusing on the execution, settlement, consensus, data availability, and interoperability layers.
-
-```mermaid
-graph TD
-    A[Modular SDK Blockchain Architecture]
-    A --> B[Execution Layer]
-    A --> C[Settlement Layer]
-    A --> D[Consensus Layer]
-    D --> E[Data Availability Layer]
-    A --> F[Interoperability Layer]
-```
-
-## Layered Architecture
-
-Understanding blockchain architecture through the lens of different layers helps in comprehending its complex functionalities. We will give a high-level overview of the execution layer, settlement layer, consensus layer, data availability layer, and interoperability layer.
-
-## Execution Layer
-
-The Execution Layer is where the blockchain processes and executes transactions. The state machine within the blockchain handles the execution of transaction logic. This is done by the blockchain itself, ensuring that every transaction follows the predefined rules and state transitions. When a transaction is submitted, the execution layer processes it, updates the state, and ensures that the output is deterministic and consistent across all nodes. In the context of the Cosmos SDK, this typically involves predefined modules and transaction types rather than general-purpose smart contracts, which are used in chains with CosmWasm.
-
-### State machine
-
-At its core, a blockchain is a [replicated deterministic state machine](https://en.wikipedia.org/wiki/State_machine_replication).
-
-A state machine is a computer science concept whereby a machine can have multiple states, but only one at any given time. There is a `state`, which describes the current state of the system, and `transactions`, that trigger state transitions.
-
-Given a state S and a transaction T, the state machine will return a new state S'.
-
-```mermaid
-flowchart LR
-    A[S]
-    B[S']
-    A -->|"apply(T)"| B
-```
-
-In practice, the transactions are bundled in blocks to make the process more efficient. Given a state S and a block of transactions B, the state machine will return a new state S'.
-
-```mermaid
-flowchart LR
-    A[S]
-    B[S']
-    A -->|"For each T in B: apply(T)"| B
-```
-
-In a blockchain context, the state machine is [deterministic](https://en.wikipedia.org/wiki/Deterministic_system). This means that if a node is started at a given state and replays the same sequence of transactions, it will always end up with the same final state.
-
-The Cosmos SDK gives developers maximum flexibility to define the state of their application, transaction types and state transition functions. The process of building state machines with the Cosmos SDK will be described more in-depth in the following sections. But first, let us see how the state machine is replicated using various consensus engines, such as CometBFT.
-
-## Settlement Layer
-
-The Settlement Layer is responsible for finalising and recording transactions on the blockchain. This layer ensures that all transactions are accurately settled and immutable, providing a verifiable record of all activities on the blockchain. It is critical for maintaining the integrity and trustworthiness of the blockchain.
-
-The settlement layer can be performed on the chain itself or it can be externalised, allowing for the possibility of plugging in a different settlement layer as needed. For example if we were to use Rollkit and celestia for our Data Availability and Consensus, we could separate our settlement layer by introducing fraud or validity proofs. From there the settlement layer can create trust-minimised light clients, further enhancing security and efficiency. This process ensures that all transactions are accurately finalized and immutable, providing a verifiable record of all activities.
-
-## Consensus Layer
-
-The Consensus Layer ensures that all nodes in the network agree on the order and validity of transactions. This layer uses consensus algorithms like Byzantine Fault Tolerance (BFT) or Proof of Stake (PoS) to achieve agreement, even in the presence of malicious nodes. Consensus is crucial for maintaining the security and reliability of the blockchain.
-
-What has been a default consensus engine in the Cosmos SDK has been CometBFT. In the most recent releases we have been moving away from this and allowing users to plug and play their own consensus engines. This is a big step forward for the Cosmos SDK as it allows for more flexibility and customisation. Other consensus engine options for example can be Rollkit with Celestias Data Availability Layer.
-
-Here is an example of how the consensus layer works with CometBFT in the context of the Cosmos SDK:
-
-### CometBFT
-
-Thanks to the Cosmos SDK, developers just have to define the state machine, and [_CometBFT_](https://docs.cometbft.com/v1.0/explanation/introduction/) will handle replication over the network for them.
-
-```mermaid
-flowchart TD
-    subgraph Blockchain_Node[Blockchain Node]
-        subgraph SM[State-machine]
-            direction TB
-            SM1[Cosmos SDK]
-        end
-        subgraph CometBFT[CometBFT]
-            direction TB
-            Consensus
-            Networking
-        end
-    end
-
-    SM <--> CometBFT
-
-
-    Blockchain_Node -->|Includes| SM
-    Blockchain_Node -->|Includes| CometBFT
-```
-
-[CometBFT](https://docs.cometbft.com/v1.0/explanation/introduction/) is an application-agnostic engine that is responsible for handling the _networking_ and _consensus_ layers of a blockchain. In practice, this means that CometBFT is responsible for propagating and ordering transaction bytes. CometBFT relies on an eponymous Byzantine-Fault-Tolerant (BFT) algorithm to reach consensus on the order of transactions.
-
-The [consensus algorithm adopted by CometBFT](https://docs.cometbft.com/v1.0/explanation/introduction/#consensus-overview) works with a set of special nodes called _Validators_. Validators are responsible for adding blocks of transactions to the blockchain. At any given block, there is a validator set V. A validator in V is chosen by the algorithm to be the proposer of the next block. This block is considered valid if more than two thirds of V signed a `prevote` and a `precommit` on it, and if all the transactions that it contains are valid. The validator set can be changed by rules written in the state-machine.
-
-## ABCI
-
-CometBFT passes transactions to the application through an interface called the [ABCI](https://docs.cometbft.com/v1.0/spec/abci/), which the application must implement.
-
-```mermaid
-graph TD
-    A[Application]
-    B[CometBFT]
-    A <-->|ABCI| B
-
-```
-
-Note that **CometBFT only handles transaction bytes**. It has no knowledge of what these bytes mean. All CometBFT does is order these transaction bytes deterministically. CometBFT passes the bytes to the application via the ABCI, and expects a return code to inform it if the messages contained in the transactions were successfully processed or not.
-
-Here are the most important messages of the ABCI:
-
-- `CheckTx`: When a transaction is received by CometBFT, it is passed to the application to check if a few basic requirements are met. `CheckTx` is used to protect the mempool of full-nodes against spam transactions. A special handler called the [`AnteHandler`](../beginner/04-gas-fees.md#antehandler) is used to execute a series of validation steps such as checking for sufficient fees and validating the signatures. If the checks are valid, the transaction is added to the [mempool](https://docs.cometbft.com/v1.0/explanation/core/mempool) and relayed to peer nodes. Note that transactions are not processed (i.e. no modification of the state occurs) with `CheckTx` since they have not been included in a block yet.
-- `DeliverTx`: When a [valid block](https://docs.cometbft.com/v1.0/spec/core/data_structures#block) is received by CometBFT, each transaction in the block is passed to the application via `DeliverTx` in order to be processed. It is during this stage that the state transitions occur. The `AnteHandler` executes again, along with the actual [`Msg` service](../../build/building-modules/03-msg-services.md) RPC for each message in the transaction.
-- `BeginBlock`/`EndBlock`: These messages are executed at the beginning and the end of each block, whether the block contains transactions or not. It is useful to trigger automatic execution of logic. Proceed with caution though, as computationally expensive loops could slow down your blockchain, or even freeze it if the loop is infinite.
-
-Find a more detailed view of the ABCI methods from the [CometBFT docs](https://docs.cometbft.com/v1.0/spec/abci/).
-
-Any application built on CometBFT needs to implement the ABCI interface in order to communicate with the underlying local CometBFT engine. Fortunately, you do not have to implement the ABCI interface. The Cosmos SDK provides a boilerplate implementation of it in the form of [baseapp](./03-sdk-design.md#baseapp).
-
-## Data Availability Layer
-
-The Data Availability (DA) Layer is a critical component of within the umbrella of the consensus layer that ensures all necessary data for transactions is available to all network participants. This layer is essential for preventing data withholding attacks, where some nodes might attempt to disrupt the network by not sharing critical transaction data.
-
-If we use the example of Rollkit, a user initiates a transaction, which is then propagated through the rollup network by a light node. The transaction is validated by full nodes and aggregated into a block by the sequencer. This block is posted to a data availability layer like Celestia, ensuring the data is accessible and correctly ordered. The rollup light node verifies data availability from the DA layer. Full nodes then validate the block and generate necessary proofs, such as fraud proofs for optimistic rollups or zk-SNARKs/zk-STARKs for zk-rollups. These proofs are shared across the network and verified by other nodes, ensuring the rollup's integrity. Once all validations are complete, the rollup's state is updated, finalising the transaction
-
-## Interoperability Layer
-
-The Interoperability Layer enables communication and interaction between different blockchains. This layer facilitates cross-chain transactions and data sharing, allowing various blockchain networks to interoperate seamlessly. Interoperability is key for building a connected ecosystem of blockchains, enhancing their functionality and reach.
-
-In this case we have separated the layers even further to really illustrate the components that make-up the blockchain architecture and it is important to note that the Cosmos SDK is designed to be interoperable with other blockchains. This is achieved through the use of the [Inter-Blockchain Communication (IBC) protocol](https://www.ibcprotocol.dev/), which allows different blockchains to communicate and transfer assets between each other.
-
----
-
-## sidebar_position: 1
-
-# Application-Specific Blockchains
-
-:::note Synopsis
-This document explains what application-specific blockchains are, and why developers would want to build one as opposed to writing Smart Contracts.
-:::
-
-## What are application-specific blockchains
-
-Application-specific blockchains are blockchains customized to operate a single application. Instead of building a decentralized application on top of an underlying blockchain like Ethereum, developers build their own blockchain from the ground up. This means building a full-node client, a light-client, and all the necessary interfaces (CLI, REST, ...) to interact with the nodes.
-
-```mermaid
-flowchart TD
-    subgraph Blockchain_Node[Blockchain Node]
-        subgraph SM[State-machine]
-            direction TB
-            SM1[Cosmos SDK]
-        end
-        subgraph Consensus[Consensus]
-            direction TB
-        end
-        subgraph Networking[Networking]
-            direction TB
-        end
-    end
-
-    SM <--> Consensus
-    Consensus <--> Networking
-
-
-    Blockchain_Node -->|Includes| SM
-    Blockchain_Node -->|Includes| Consensus
-    Blockchain_Node -->|Includes| Networking
-```
-
-## What are the shortcomings of Smart Contracts
-
-Virtual-machine blockchains like Ethereum addressed the demand for more programmability back in 2014. At the time, the options available for building decentralized applications were quite limited. Most developers would build on top of the complex and limited Bitcoin scripting language, or fork the Bitcoin codebase which was hard to work with and customize.
-
-Virtual-machine blockchains came in with a new value proposition. Their state-machine incorporates a virtual-machine that is able to interpret turing-complete programs called Smart Contracts. These Smart Contracts are very good for use cases like one-time events (e.g. ICOs), but they can fall short for building complex decentralized platforms. Here is why:
-
-- Smart Contracts are generally developed with specific programming languages that can be interpreted by the underlying virtual-machine. These programming languages are often immature and inherently limited by the constraints of the virtual-machine itself. For example, the Ethereum Virtual Machine does not allow developers to implement automatic execution of code. Developers are also limited to the account-based system of the EVM, and they can only choose from a limited set of functions for their cryptographic operations. These are examples, but they hint at the lack of **flexibility** that a smart contract environment often entails.
-- Smart Contracts are all run by the same virtual machine. This means that they compete for resources, which can severely restrain **performance**. And even if the state-machine were to be split in multiple subsets (e.g. via sharding), Smart Contracts would still need to be interpreted by a virtual machine, which would limit performance compared to a native application implemented at state-machine level (our benchmarks show an improvement on the order of 10x in performance when the virtual-machine is removed).
-- Another issue with the fact that Smart Contracts share the same underlying environment is the resulting limitation in **sovereignty**. A decentralized application is an ecosystem that involves multiple players. If the application is built on a general-purpose virtual-machine blockchain, stakeholders have very limited sovereignty over their application, and are ultimately superseded by the governance of the underlying blockchain. If there is a bug in the application, very little can be done about it.
-
-Application-Specific Blockchains are designed to address these shortcomings.
-
-## Application-Specific Blockchains Benefits
-
-### Flexibility
-
-Application-specific blockchains give maximum flexibility to developers:
-
-- In Cosmos blockchains, the state-machine is typically connected to the underlying consensus engine via an interface called the [ABCI](https://docs.cometbft.com/v1.0/spec/abci/) (Application Blockchain Interface). This interface can be wrapped in any programming language, meaning developers can build their state-machine in the programming language of their choice.
-
-- Developers can choose among multiple frameworks to build their state-machine. The most widely used today is the Cosmos SDK, but others exist (e.g. [Lotion](https://github.com/nomic-io/lotion), [Weave](https://github.com/iov-one/weave), ...). Typically the choice will be made based on the programming language they want to use (Cosmos SDK and Weave are in Golang, Lotion is in Javascript, ...).
-- The ABCI also allows developers to swap the consensus engine of their application-specific blockchain. Today, only CometBFT is production-ready, but in the future other consensus engines are expected to emerge.
-- Even when they settle for a framework and consensus engine, developers still have the freedom to tweak them if they don't perfectly match their requirements in their pristine forms.
-- Developers are free to explore the full spectrum of tradeoffs (e.g. number of validators vs transaction throughput, safety vs availability in asynchrony, ...) and design choices (DB or IAVL tree for storage, UTXO or account model, ...).
-- Developers can implement automatic execution of code. In the Cosmos SDK, logic can be automatically triggered at the beginning and the end of each block. They are also free to choose the cryptographic library used in their application, as opposed to being constrained by what is made available by the underlying environment in the case of virtual-machine blockchains.
-
-The list above contains a few examples that show how much flexibility application-specific blockchains give to developers. The goal of Cosmos and the Cosmos SDK is to make developer tooling as generic and composable as possible, so that each part of the stack can be forked, tweaked and improved without losing compatibility. As the community grows, more alternatives for each of the core building blocks will emerge, giving more options to developers.
-
-### Performance
-
-Decentralized applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralized application to optimise performance, it needs to be built as an application-specific blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance:
-
-- Developers of application-specific blockchains can choose to operate with a novel consensus engine such as CometBFT.
-- An application-specific blockchain only operates a single application, so that the application does not compete with others for computation and storage. This is the opposite of most non-sharded virtual-machine blockchains today, where smart contracts all compete for computation and storage.
-- Even if a virtual-machine blockchain offered application-based sharding coupled with an efficient consensus algorithm, performance would still be limited by the virtual-machine itself. The real throughput bottleneck is the state-machine, and requiring transactions to be interpreted by a virtual-machine significantly increases the computational complexity of processing them.
-
-### Security
-
-Security is hard to quantify, and greatly varies from platform to platform. That said here are some important benefits an application-specific blockchain can bring in terms of security:
-
-- Developers can choose proven programming languages like Go when building their application-specific blockchains, as opposed to smart contract programming languages that are often more immature.
-- Developers are not constrained by the cryptographic functions made available by the underlying virtual-machines. They can use their own custom cryptography, and rely on well-audited crypto libraries.
-- Developers do not have to worry about potential bugs or exploitable mechanisms in the underlying virtual-machine, making it easier to reason about the security of the application.
-
-### Sovereignty
-
-One of the major benefits of application-specific blockchains is sovereignty. A decentralized application is an ecosystem that involves many actors: users, developers, third-party services, and more. When developers build on virtual-machine blockchain where many decentralized applications coexist, the community of the application is different than the community of the underlying blockchain, and the latter supersedes the former in the governance process. If there is a bug or if a new feature is needed, stakeholders of the application have very little leeway to upgrade the code. If the community of the underlying blockchain refuses to act, nothing can happen.
-
-The fundamental issue here is that the governance of the application and the governance of the network are not aligned. This issue is solved by application-specific blockchains. Because application-specific blockchains specialize to operate a single application, stakeholders of the application have full control over the entire chain. This ensures that the community will not be stuck if a bug is discovered, and that it has the freedom to choose how it is going to evolve.

.github/aider/guides/sonr-did.md

@@ -1,141 +0,0 @@
-# `x/did`
-
-The Decentralized Identity module is responsible for managing native Sonr Accounts, their derived wallets, and associated user identification information.
-
-## State
-
-The DID module maintains several key state structures:
-
-### Controller State
-
-The Controller state represents a Sonr DWN Vault. It includes:
-- Unique identifier (number)
-- DID
-- Sonr address
-- Ethereum address
-- Bitcoin address
-- Public key
-- Keyshares pointer
-- Claimed block
-- Creation block
-
-### Assertion State
-
-The Assertion state includes:
-- DID
-- Controller
-- Subject
-- Public key
-- Assertion type
-- Accumulator (metadata)
-- Creation block
-
-### Authentication State
-
-The Authentication state includes:
-- DID
-- Controller
-- Subject
-- Public key
-- Credential ID
-- Metadata
-- Creation block
-
-### Verification State
-
-The Verification state includes:
-- DID
-- Controller
-- DID method
-- Issuer
-- Subject
-- Public key
-- Verification type
-- Metadata
-- Creation block
-
-## State Transitions
-
-State transitions are triggered by the following messages:
-- LinkAssertion
-- LinkAuthentication
-- UnlinkAssertion
-- UnlinkAuthentication
-- ExecuteTx
-- UpdateParams
-
-## Messages
-
-The DID module defines the following messages:
-
-1. MsgLinkAuthentication
-2. MsgLinkAssertion
-3. MsgExecuteTx
-4. MsgUnlinkAssertion
-5. MsgUnlinkAuthentication
-6. MsgUpdateParams
-
-Each message triggers specific state machine behaviors related to managing DIDs, authentications, assertions, and module parameters.
-
-## Query
-
-The DID module provides the following query endpoints:
-
-1. Params: Query all parameters of the module
-2. Resolve: Query the DID document by its ID
-3. Sign: Sign a message with the DID document
-4. Verify: Verify a message with the DID document
-
-## Params
-
-The module parameters include:
-- Allowed public keys (map of KeyInfo)
-- Conveyance preference
-- Attestation formats
-
-## Client
-
-The module provides gRPC and REST endpoints for all defined messages and queries.
-
-## Future Improvements
-
-Potential future improvements could include:
-1. Enhanced privacy features for DID operations
-2. Integration with more blockchain networks
-3. Support for additional key types and cryptographic algorithms
-4. Improved revocation mechanisms for credentials and assertions
-
-## Tests
-
-Acceptance tests should cover all major functionality, including:
-- Creating and managing DIDs
-- Linking and unlinking assertions and authentications
-- Executing transactions with DIDs
-- Querying and resolving DIDs
-- Parameter updates
-
-## Appendix
-
-### Account
-
-An Account represents a user's identity within the Sonr ecosystem. It includes information such as the user's public key, associated wallets, and other identification details.
-
-### Decentralized Identifier (DID)
-
-A Decentralized Identifier (DID) is a unique identifier that is created, owned, and controlled by the user. It is used to establish a secure and verifiable digital identity.
-
-### Verifiable Credential (VC)
-
-A Verifiable Credential (VC) is a digital statement that can be cryptographically verified. It contains claims about a subject (e.g., a user) and is issued by a trusted authority.
-
-### Key Types
-
-The module supports various key types, including:
-- Role
-- Algorithm (e.g., ES256, EdDSA, ES256K)
-- Encoding (e.g., hex, base64, multibase)
-- Curve (e.g., P256, P384, P521, X25519, X448, Ed25519, Ed448, secp256k1)
-
-### JSON Web Key (JWK)
-
-The module supports JSON Web Keys (JWK) for representing cryptographic keys, including properties such as key type (kty), curve (crv), and coordinates (x, y) for EC and OKP keys, as well as modulus (n) and exponent (e) for RSA keys.

.github/aider/guides/sonr-dwn.md

@@ -1,145 +0,0 @@
-# `x/dwn`
-
-The DWN module is responsible for the management of IPFS deployed Decentralized Web Nodes (DWNs) and their associated data.
-
-## Concepts
-
-The DWN module introduces several key concepts:
-
-1. Decentralized Web Node (DWN): A distributed network for storing and sharing data.
-2. Schema: A structure defining the format of various data types in the dwn.
-3. IPFS Integration: The module can interact with IPFS for decentralized data storage.
-
-## State
-
-The DWN module maintains the following state:
-
-### DWN State
-
-The DWN state is stored using the following structure:
-
-```protobuf
-message DWN {
-  uint64 id = 1;
-  string alias = 2;
-  string cid = 3;
-  string resolver = 4;
-}
-```
-
-This state is indexed by ID, alias, and CID for efficient querying.
-
-### Params State
-
-The module parameters are stored in the following structure:
-
-```protobuf
-message Params {
-  bool ipfs_active = 1;
-  bool local_registration_enabled = 2;
-  Schema schema = 4;
-}
-```
-
-### Schema State
-
-The Schema state defines the structure for various data types:
-
-```protobuf
-message Schema {
-  int32 version = 1;
-  string account = 2;
-  string asset = 3;
-  string chain = 4;
-  string credential = 5;
-  string did = 6;
-  string jwk = 7;
-  string grant = 8;
-  string keyshare = 9;
-  string profile = 10;
-}
-```
-
-## State Transitions
-
-State transitions in the DWN module are primarily triggered by:
-
-1. Updating module parameters
-2. Allocating new dwns
-3. Syncing DID documents
-
-## Messages
-
-The DWN module defines the following message:
-
-1. `MsgUpdateParams`: Used to update the module parameters.
-
-```protobuf
-message MsgUpdateParams {
-  string authority = 1;
-  Params params = 2;
-}
-```
-
-## Begin Block
-
-No specific begin-block operations are defined for this module.
-
-## End Block
-
-No specific end-block operations are defined for this module.
-
-## Hooks
-
-The DWN module does not define any hooks.
-
-## Events
-
-The DWN module does not explicitly define any events. However, standard Cosmos SDK events may be emitted during state transitions.
-
-## Client
-
-The DWN module provides the following gRPC query endpoints:
-
-1. `Params`: Queries all parameters of the module.
-2. `Schema`: Queries the DID document schema.
-3. `Allocate`: Initializes a Target DWN available for claims.
-4. `Sync`: Queries the DID document by its ID and returns required information.
-
-## Params
-
-The module parameters include:
-
-- `ipfs_active` (bool): Indicates if IPFS integration is active.
-- `local_registration_enabled` (bool): Indicates if local registration is enabled.
-- `schema` (Schema): Defines the structure for various data types in the dwn.
-
-## Future Improvements
-
-Potential future improvements could include:
-
-1. Enhanced IPFS integration features.
-2. Additional authentication mechanisms beyond WebAuthn.
-3. Improved DID document management and querying capabilities.
-
-## Tests
-
-Acceptance tests should cover:
-
-1. Parameter updates
-2. DWN state management
-3. Schema queries
-4. DWN allocation process
-5. DID document syncing
-
-## Appendix
-
-| Concept                                     | Description                                                                                                                                                                           |
-| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Decentralized Web Node (DWN)                | A decentralized, distributed, and secure network of nodes that store and share data. It is a decentralized alternative to traditional web hosting services.                           |
-| Decentralized Identifier (DID)              | A unique identifier that is created, owned, and controlled by the user. It is used to establish a secure and verifiable digital identity.                                             |
-| HTMX (Hypertext Markup Language eXtensions) | A set of extensions to HTML that allow for the creation of interactive web pages. It is used to enhance the user experience and provide additional functionality to web applications. |
-| IPFS (InterPlanetary File System)           | A decentralized, peer-to-peer network for storing and sharing data. It is a distributed file system that allows for the creation and sharing of content across a network of nodes.    |
-| WebAuthn (Web Authentication)               | A set of APIs that allow websites to request user authentication using biometric or non-biometric factors.                                                                            |
-| WebAssembly (Web Assembly)                  | A binary instruction format for a stack-based virtual machine.                                                                                                                        |
-| Verifiable Credential (VC)                  | A digital statement that can be cryptographically verified.                                                                                                                           |

.github/aider/guides/sonr-service.md

@@ -1,91 +0,0 @@
-# `x/svc`
-
-The svc module is responsible for managing the registration and authorization of services within the Sonr ecosystem. It provides a secure and verifiable mechanism for registering and authorizing services using Decentralized Identifiers (DIDs).
-
-## Concepts
-
-- **Service**: A decentralized svc on the Sonr Blockchain with properties such as ID, authority, origin, name, description, category, tags, and expiry height.
-- **Profile**: Represents a DID alias with properties like ID, subject, origin, and controller.
-- **Metadata**: Contains information about a svc, including name, description, category, icon, and tags.
-
-### Dependencies
-
-- [x/did](https://github.com/onsonr/sonr/tree/master/x/did)
-- [x/group](https://github.com/onsonr/sonr/tree/master/x/group)
-- [x/nft](https://github.com/onsonr/sonr/tree/master/x/nft)
-
-## State
-
-The module uses the following state structures:
-
-### Metadata
-
-Stores information about services:
-
-- Primary key: `id` (auto-increment)
-- Unique index: `origin`
-- Fields: id, origin, name, description, category, icon (URI), tags
-
-### Profile
-
-Stores DID alias information:
-
-- Primary key: `id`
-- Unique index: `subject,origin`
-- Fields: id, subject, origin, controller
-
-## Messages
-
-### MsgUpdateParams
-
-Updates the module parameters. Can only be executed by the governance account.
-
-### MsgRegisterService
-
-Registers a new svc on the blockchain. Requires a valid TXT record in DNS for the origin.
-
-## Params
-
-The module has the following parameters:
-
-- `categories`: List of allowed svc categories
-- `types`: List of allowed svc types
-
-## Query
-
-The module provides the following query:
-
-### Params
-
-Retrieves all parameters of the module.
-
-## Client
-
-### gRPC
-
-The module provides a gRPC Query svc with the following RPC:
-
-- `Params`: Get all parameters of the module
-
-### CLI
-
-(TODO: Add CLI commands for interacting with the module)
-
-## Events
-
-(TODO: List and describe event tags used by the module)
-
-## Future Improvements
-
-- Implement svc discovery mechanisms
-- Add support for svc reputation and rating systems
-- Enhance svc metadata with more detailed information
-- Implement svc update and deactivation functionality
-
-## Tests
-
-(TODO: Add acceptance tests for the module)
-
-## Appendix
-
-This module is part of the Sonr blockchain project and interacts with other modules such as DID and NFT modules to provide a comprehensive decentralized svc ecosystem.

.github/aider/guides/ucan-spec.md

@@ -1,873 +0,0 @@
-# User Controlled Authorization Network (UCAN) Specification
-
-# Abstract
-
-User-Controlled Authorization Network (UCAN) is a [trustless], secure, [local-first], user-originated, distributed authorization scheme. This document provides a high level overview of the components of the system, concepts, and motivation. Exact formats are given in [sub-specifications].
-
-# Introduction
-
-User-Controlled Authorization Network (UCAN) is a [trustless], secure, [local-first], user-originated, distributed authorization scheme. It provides public-key verifiable, delegable, expressive, openly extensible [capabilities]. UCANs achieve public verifiability with late-bound certificate chains and principals represented by [decentralized identifiers (DIDs)][DID].
-
-UCAN improves the familiarity and adoptability of schemes like [SPKI/SDSI][SPKI] for web and native application contexts. UCAN allows for the creation, delegation, and invocation of authority by any agent with a DID, including traditional systems and peer-to-peer architectures beyond traditional cloud computing.
-
-## Motivation
-
-> If we practice our principles, we could have both security and functionality. Treating security as a separate concern has not succeeded in bridging the gap between principle and practice, because it operates without knowledge of what constitutes least authority.
->
-> — [Miller][Mark Miller] et al, [The Structure of Authority]
-
-Since at least [Multics], access control lists ([ACL]s) have been the most popular form of digital authorization, where a list of what each user is allowed to do is maintained on the resource. ACLs (and later [RBAC]) have been a successful model suited to architectures where persistent access to a single list is viable. ACLs require that rules are sufficiently well specified, such as in a centralized database with rules covering all possible permutations of scenario. This both imposes a very high maintenance burden on programmers as a systems grows in complexity, and is a key vector for [confused deputies][confused deputy problem].
-
-With increasing interconnectivity between machines becoming commonplace, authorization needs to scale to meet the load demands of distributed systems while providing partition tolerance. However, it is not always practical to maintain a single central authorization source. Even when copies of the authorization list are distributed to the relevant servers, latency and partitions introduce troublesome challenges with conflicting updates, to say nothing of storage requirements.
-
-A large portion of personal information now also moves through connected systems. As a result, data privacy is a prominent theme when considering the design of modern applications, to the point of being legislated in parts of the world.
-
-Ahead-of-time coordination is often a barrier to development in many projects. Flexibility to define specialized authorization semantics for resources and the ability to integrate with external systems trustlessly are essential as the number of autonomous, specialized, and coordinated applications increases.
-
-Many high-value applications run in hostile environments. In recognition of this, many vendors now include public key functionality, such as [non-extractable keys in browsers][browser api crypto key], [certificate systems for external keys][fido], [platform keys][passkey], and [secure hardware enclaves] in widespread consumer devices.
-
-Two related models that work exceptionally well in the above context are Simple Public Key Infrastructure ([SPKI][spki rfc]) and object capabilities ([OCAP]). Since offline operation and self-verifiability are two requirements, UCAN adopts a [certificate capability model] related to [SPKI].
-
-## Intuition for Auth System Differences
-
-The following analogies illustrate several significant trade-offs between these systems but are only accurate enough to build intuition. A good resource for a more thorough presentation of these trade-offs is [Capability Myths Demolished]. In this framework, UCAN approximates SPKI with some dynamic features.
-
-### Access Control Lists
-
-By analogy, ACLs are like a bouncer at an exclusive event. This bouncer has a list attendees allowed in and which of those are VIPs that get extra access. People trying to get in show their government-issued ID and are accepted or rejected. In addition, they may get a lanyard to identify that they have previously been allowed in. If someone is disruptive, they can simply be crossed off the list and denied further entry.
-
-If there are many such events at many venues, the organizers need to coordinate ahead of time, denials need to be synchronized, and attendees need to show their ID cards to many bouncers. The likelihood of the bouncer letting in the wrong person due to synchronization lag or confusion by someone sharing a name is nonzero.
-
-### Certificate Capabilities
-
-UCANs work more like [movie tickets][caps as keys] or a festival pass. No one needs to check your ID; who you are is irrelevant. For example, if you have a ticket issued by the theater to see Citizen Kane, you are admitted to Theater 3. If you cannot attend an event, you can hand this ticket to a friend who wants to see the film instead, and there is no coordination required with the theater ahead of time. However, if the theater needs to cancel tickets for some reason, they need a way of uniquely identifying them and sharing this information between them.
-
-### Object Capabilities
-
-Object capability ("ocap") systems use a combination of references, encapsulated state, and proxy forwarding. As the name implies, this is fairly close to object-oriented or actor-based systems. Object capabilities are [robust][Robust Composition], flexible, and expressive.
-
-To achieve these properties, object capabilities have two requirements: [fail-safe], and locality preservation. The emphasis on consistency rules out partition tolerance[^pcec].
-
-## Security Considerations
-
-Each UCAN includes an assertions of what it is allowed to do. "Proofs" are positive evidence (elsewhere called "witnesses") of the possession of rights. They are cryptographically verifiable chains showing that the UCAN issuer either claims to directly own a resource, or that it was delegated to them by some claimed owner. In the most common case, the root owner's ID is the only globally unique identity for the resource.
-
-Root capability issuers function as verifiable, distributed roots of trust. The delegation chain is by definition a provenance log. Private keys themselves SHOULD NOT move from one context to another. Keeping keys unique to each physical device and unique per use case is RECOMMENDED to reduce opportunity for keys to leak, and limit blast radius in the case of compromises. "Sharing authority without sharing keys" is provided by capabilities, so there is no reason to share keys directly.
-
-Note that a structurally and cryptographically valid UCAN chain can be semantically invalid. The executor MUST verify the ownership of any external resources at execution time. While not possible for all use cases (e.g. replicated state machines and eventually consistent data), having the Executor be the resource itself is RECOMMENDED.
-
-While certificate chains go a long way toward improving security, they do not provide [confinement] on their own. The principle of least authority SHOULD be used when delegating a UCAN: minimizing the amount of time that a UCAN is valid for and reducing authority to the bare minimum required for the delegate to complete their task. This delegate should be trusted as little as is practical since they can further sub-delegate their authority to others without alerting their delegator. UCANs do not offer confinement (as that would require all processes to be online), so it is impossible to guarantee knowledge of all of the sub-delegations that exist. The ability to revoke some or all downstream UCANs exists as a last resort.
-
-## Inversion of Control
-
-[Inversion of control] is achieved due to two properties: self-certifying delegation and reference passing. There is no Authorization Server (AS) that sits between requestors and resources. In traditional terms, the owner of a UCAN resource is the resource server (RS) directly.
-
-This inverts the usual relationship between resources and users: the resource grants some (or all) authority over itself to agents, as opposed to an Authorization Server managing the relationship between them. This has several major advantages:
-
-- Fully distributed and scalable
-- Self-contained request without intermediary
-- Partition tolerance, [support for replicated data and machines][overcoming SSI]
-- Flexible granularity
-- Compositionality: no distinction between resources residing together or apart
-
-```
-┌─────────────┐   ┌─────────────┐   ┌─────────────┐
-│             │   │             │   │             │
-│             │   │ ┌─────────┐ │   │             │
-│             │   │ │  Bob's  │ │   │             │
-│             │   │ │  Photo  │ │   │             │
-│             │   │ │ Gallery │ │   │             │
-│             │   │ └─────────┘ │   │             │
-│             │   │             │   │             │
-│   Alice's   │   │    Bob's    │   │   Carol's   │
-│    Stuff    │   │    Stuff    │   │    Stuff    │
-│             │   │             │   │             │
-│     ┌───────┼───┼─────────────┼───┼──┐          │
-│     │       │   │             │   │  │          │
-│     │       │   │         ┌───┼───┼──┼────────┐ │
-│     │       │   │ Alice's │   │   │  │        │ │
-│     │       │   │  Music  │   │   │  │Carol's │ │
-│     │       │   │ Player  │   │   │  │  Game  │ │
-│     │       │   │         │   │   │  │        │ │
-│     │       │   │         └───┼───┼──┼────────┘ │
-│     │       │   │             │   │  │          │
-│     └───────┼───┼─────────────┼───┼──┘          │
-│             │   │             │   │             │
-└─────────────┘   └─────────────┘   └─────────────┘
-```
-
-This additionally allows UCAN to model auth for [eventually consistent and replicated state][overcoming SSI].
-
-# Roles
-
-There are several roles that an agent MAY assume:
-
-| Name      | Description                                                                                      |
-| --------- | ------------------------------------------------------------------------------------------------ |
-| Agent     | The general class of entities and principals that interact with a UCAN                           |
-| Audience  | The Principal delegated to in the current UCAN. Listed in the `aud` field                        |
-| Executor  | The Agent that actually performs the action described in an invocation                           |
-| Invoker   | A Principal that requests an Executor perform some action that uses the Invoker's authority      |
-| Issuer    | The Principal of the current UCAN. Listed in the `iss` field                                     |
-| Owner     | A Subject that controls some external resource                                                   |
-| Principal | An agent identified by DID (listed in a UCAN's `iss` or `aud` field)                             |
-| Revoker   | The Issuer listed in a proof chain that revokes a UCAN                                           |
-| Subject   | The Principal who's authority is delegated or invoked                                            |
-| Validator | Any Agent that interprets a UCAN to determine that it is valid, and which capabilities it grants |
-
-```mermaid
-flowchart TD
-    subgraph Agent
-        subgraph Principal
-            direction TB
-
-            subgraph Issuer
-                direction TB
-
-                subgraph Subject
-                    direction TB
-
-                    Executor
-                    Owner
-                end
-
-                Revoker
-            end
-
-            subgraph Audience
-                Invoker
-            end
-        end
-
-        Validator
-    end
-```
-
-## Subject
-
-> At the very least every object should have a URL
->
-> — [Alan Kay], [The computer revolution hasn't happened yet]
-
-> Every Erlang process in the universe should be addressable and introspective
->
-> — [Joe Armstrong], [Code Mesh 2016]
-
-A [Subject] represents the Agent that a capability is for. A Subject MUST be referenced by [DID]. This behaves much like a [GUID], with the addition of public key verifiability. This unforgeability prevents malicious namespace collisions which can lead to [confused deputies][confused deputy problem].
-
-### Resource
-
-A resource is some data or process that can be uniquely identified by a [URI]. It can be anything from a row in a database, a user account, storage quota, email address, etc. Resource MAY be as coarse or fine grained as desired. Finer-grained is RECOMMENDED where possible, as it is easier to model the principle of least authority ([PoLA]).
-
-A resource describes the noun of a capability. The resource pointer MUST be provided in [URI] format. Arbitrary and custom URIs MAY be used, provided that the intended recipient can decode the URI. The URI is merely a unique identifier to describe the pointer to — and within — a resource.
-
-Having a unique agent represent a resource (and act as its manager) is RECOMMENDED. However, to help traditional ACL-based systems transition to certificate capabilities, an agent MAY manage multiple resources, and [act as the registrant in the ACL system][wrapping existing systems].
-
-Unless explicitly stated, the Resource of a UCAN MUST be the Subject.
-
-## Issuer & Audience
-
-The Issuer (`iss`) and Audience (`aud`) can be conceptualized as the sender and receiver (respectively) of a postal letter. Every UCAN MUST be signed with the private key associated with the DID in the `iss` field.
-
-For example:
-
-```js
-"aud": "did:key:z6MkiTBz1ymuepAQ4HEHYSF1H8quG5GLVVQR3djdX3mDooWp",
-"iss": "did:key:zDnaerDaTF5BXEavCrfRZEk316dpbLsfPDZ3WJ5hRTPFU2169",
-```
-
-Please see the [Cryptosuite] section for more detail on DIDs.
-
-# Lifecycle
-
-The UCAN lifecycle has four components:
-
-| Spec         | Description                                                              | Requirement Level |
-| ------------ | ------------------------------------------------------------------------ | ----------------- |
-| [Delegation] | Pass, attenuate, and secure authority in a partition-tolerant way        | REQUIRED          |
-| [Invocation] | Exercise authority that has been delegated through one or more delegates | REQUIRED          |
-| [Promise]    | Await the result of an Invocation inside another Invocation              | RECOMMENDED       |
-| [Revocation] | Undo a delegation, breaking a delegation chain for malicious users       | RECOMMENDED       |
-
-```mermaid
-flowchart TD
-    prm(Promise)
-    inv(Invocation)
-    del(Delegation)
-    rev(Revocation)
-
-    prm -->|awaits| inv
-    del -->|proves| inv
-    rev -.->|kind of| inv
-    rev -->|invalidates| del
-
-    click del href "https://github.com/ucan-wg/delegation" "UCAN Delegation Spec"
-    click inv href "https://github.com/ucan-wg/invocation" "UCAN Invocation Spec"
-    click rev href "https://github.com/ucan-wg/revocation" "UCAN Revocation Spec"
-```
-
-## Time
-
-It is often useful to talk about a UCAN in the context of some action. For example, a UCAN delegation may be valid when it was created, but expired when invoked.
-
-```mermaid
-sequenceDiagram
-    Alice -->> Bob: Delegate
-    Bob ->> Bob: Validate
-    Bob -->> Carol: Delegate
-    Carol ->> Carol: Validate
-    Carol ->> Alice: Invoke
-    Alice ->> Alice: Validate
-    Alice ->> Alice: Execute
-```
-
-### Validity Interval
-
-The period of time that a capability is valid from and until. This is the range from the latest "not before" to the earliest expiry in the UCAN delegation chain.
-
-### Delegation-Time
-
-The moment at which a delegation is asserted. This MAY be captured by an `iat` field, but is generally superfluous to capture in the token.
-
-### Invocation-Time
-
-The moment a UCAN Invocation is created. It must be within the Validity Interval.
-
-### Validation-Time
-
-Validation MAY occur at multiple points during a UCAN's lifecycle. The main two are:
-
-- On receipt of a delegation
-- When executing an invocation
-
-### Execution-Time
-
-To avoid the overloaded word "runtime", UCAN adopts the term "execution-time" to express the moment that the executor attempts to use the authority captured in an invocation and associated delegation chain. Validation MUST occur at this time.
-
-## Time Bounds
-
-`nbf` and `exp` stand for "not before" and "expires at," respectively. These MUST be expressed as seconds since the Unix epoch in UTC, without time zone or other offset. Taken together, they represent the time bounds for a token. These timestamps MUST be represented as the number of integer seconds since the Unix epoch. Due to limitations[^js-num-size] in numerics for certain common languages, timestamps outside of the range from $-2^{53} – 1$ to $2^{53} – 1$ MUST be rejected as invalid.
-
-The `nbf` field is OPTIONAL. When omitted, the token MUST be treated as valid beginning from the Unix epoch. Setting the `nbf` field to a time in the future MUST delay invoking a UCAN. For example, pre-provisioning access to conference materials ahead of time but not allowing access until the day it starts is achievable with judicious use of `nbf`.
-
-The `exp` field is RECOMMENDED. Following the [principle of least authority][PoLA], it is RECOMMENDED to give a timestamp expiry for UCANs. If the token explicitly never expires, the `exp` field MUST be set to `null`. If the time is in the past at validation time, the token MUST be treated as expired and invalid.
-
-Keeping the window of validity as short as possible is RECOMMENDED. Limiting the time range can mitigate the risk of a malicious user abusing a UCAN. However, this is situationally dependent. It may be desirable to limit the frequency of forced reauthorizations for trusted devices. Due to clock drift, time bounds SHOULD NOT be considered exact. A buffer of ±60 seconds is RECOMMENDED.
-
-Several named points of time in the UCAN lifecycle can be found in the [high level spec][UCAN].
-
-Below are a couple examples:
-
-```js
-{
-  // ...
-  "nbf": 1529496683,
-  "exp": 1575606941
-}
-```
-
-```js
-{
-  // ...
-  "exp": 1575606941
-}
-```
-
-```js
-{
-  // ...
-  "nbf": 1529496683,
-  "exp": null
-}
-```
-
-## Lifecycle Example
-
-Here is a concrete example of all stages of the UCAN lifecycle for database write access.
-
-```mermaid
-sequenceDiagram
-    participant Database
-
-    actor DBAgent
-    actor Alice
-    actor Bob
-
-    Note over Database, DBAgent: Set Up Agent-Owned Resource
-    DBAgent ->> Database: createDB()
-
-    autonumber 1
-
-    Note over DBAgent, Bob: Delegation
-    DBAgent -->> Alice: delegate(DBAgent, write)
-    Alice -->> Bob: delegate(DBAgent, write)
-
-    Note over Database, Bob: Invocation
-    Bob ->> DBAgent: invoke(DBAgent, [write, [key, value]], proof: [➊,➋])
-    DBAgent ->> Database: write(key, value)
-    DBAgent ->> Bob: ACK
-
-    Note over DBAgent, Bob: Revocation
-    Alice ->> DBAgent: revoke(➋, proof: [➊,➋])
-    Bob ->> DBAgent: invoke(DBAgent, [write, [key, newValue]], proof: [➊,➋])
-    DBAgent -X Bob: NAK(➏) [rejected]
-```
-
-## Capability
-
-A capability is the association of an ability to a subject: `subject x command x policy`.
-
-The Subject and Command fields are REQUIRED. Any non-normative extensions are OPTIONAL.
-
-For example, a capability may used to represent the ability to send email from a certain address to others at `@example.com`.
-
-| Field   | Example                                                                                      |
-| ------- | -------------------------------------------------------------------------------------------- |
-| Subject | `did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK`                                   |
-| Command | `/msg/send`                                                                                  |
-| Policy  | `["or", ["==", ".from", "mailto:me@example.com"], ["match", ".cc", "mailto:*@example.com"]]` |
-
-For a more complete treatment, please see the [UCAN Delegation][delegation] spec.
-
-## Authority
-
-> Whether to enable cooperation or to limit vulnerability, we care about _authority_ rather than _permissions._ Permissions determine what actions an individual program may perform on objects it can directly access. Authority describes the effects that a program may cause on objects it can access, either directly by permission, or indirectly by permitted interactions with other programs.
->
-> —[Mark Miller], [Robust Composition]
-
-The set of capabilities delegated by a UCAN is called its "authority." To frame it another way, it's the set of effects that a principal can cause, and acts as a declarative description of delegated abilities.
-
-Merging capability authorities MUST follow set semantics, where the result includes all capabilities from the input authorities. Since broader capabilities automatically include narrower ones, this process is always additive. Capability authorities can be combined in any order, with the result always being at least as broad as each of the original authorities.
-
-```plaintext
-                   ┌───────────────────────┐  ┐
-                   │                       │  │
-                   │                       │  │
-                   │                       │  │
-                   │                       │  │
-                   │       Subject B       │  │
-┌──────────────────┼ ─ ─       x           │  │
-│                       │  Ability Z       │  ├──    BxZ
-│                  │                       │  │  Capability
-│                       │                  │  │
-│                  │                       │  │
-│       Subject A       │                  │  │
-│           x      │                       │  │
-│       Ability Y   ─  ─┼──────────────────┘  ┘
-│                       │
-│                       │
-│                       │
-│                       │
-│                       │
-└───────────────────────┘
-
-└─────────────────────┬────────────────────┘
-                      │
-                  AxY U BxZ
-                  Capability
-```
-
-The capability authority is the total rights of the authorization space down to the relevant volume of authorizations. Individual capabilities MAY overlap; the authority is the union. Every unique delegated capability MUST have equal or narrower capabilities from their delegator. Inside this content space, you can draw a boundary around some resource(s) (their type, identifiers, and paths or children) and their capabilities.
-
-## Command
-
-Commands are concrete messages ("verbs") that MUST be unambiguously interpretable by the Subject of a UCAN. Commands are REQUIRED in invocations. Some examples include `/msg/send`, `/crud/read`, and `/ucan/revoke`.
-
-Much like other message-passing systems, the specific resource MUST define the behavior for a particular message. For instance, `/crud/update` MAY be used to destructively update a database row, or append to a append-only log. Specific messages MAY be created at will; the only restriction is that the Executor understand how to interpret that message in the context of a specific resource.
-
-While arbitrary semantics MAY be described, they MUST apply to the target resource. For instance, it does not make sense to apply `/msg/send` to a typical file system.
-
-### Segment Structure
-
-Commands MUST be lowercase, and begin with a slash (`/`). Segments MUST be separated by a slash. A trailing slash MUST NOT be present. All of the following are syntactically valid Commands:
-
-- `/`
-- `/crud`
-- `/crud/create`
-- `/stack/pop`
-- `/crypto/sign`
-- `/foo/bar/baz/qux/quux`
-- `/ほげ/ふが`
-
-Segment structure is important since shorter Commands prove longer paths. For example, `/` can be used as a proof of _any_ other Command. For example, `/crypto` MAY be used to prove `/crypto/sign` but MUST NOT prove `/stack/pop` or `/cryptocurrency`.
-
-### `/` AKA "Top"
-
-_"Top" (`/`) is the most powerful ability, and as such it SHOULD be handled with care and used sparingly._
-
-The "top" (or "any", or "wildcard") ability MUST be denoted `/`. This can be thought of as something akin to a super user permission in RBAC.
-
-The wildcard ability grants access to all other capabilities for the specified resource, across all possible namespaces. The wildcard ability is useful when "linking" agents by delegating all access to another device controlled by the same user, and that should behave as the same agent. It is extremely powerful, and should be used with care. Among other things, it permits the delegate to update a Subject's mutable DID document (change their private keys), revoke UCAN delegations, and use any resources delegated to the Subject by others.
-
-```mermaid
-%%{ init: { 'flowchart': { 'curve': 'linear' } } }%%
-
-flowchart BT
-  /
-
-  /msg --> /
-  subgraph msgGraph [ ]
-    /msg/send --> /msg
-    /msg/receive --> /msg
-  end
-
-  /crud --> /
-  subgraph crudGraph [ ]
-    /crud/read --> /crud
-    /crud/mutate --> /crud
-
-    subgraph mutationGraph [ ]
-        /crud/mutate/create --> /crud/mutate
-        /crud/mutate/update --> /crud/mutate
-        /crud/mutate/destroy --> /crud/mutate
-    end
-  end
-
-  ... --> /
-```
-
-### Reserved Commands
-
-#### `/ucan` Namespace
-
-The `/ucan` Command namespace MUST be reserved. This MUST include any ability string matching the regex `^ucan\/.*`. This is important for keeping a space for community-blessed Commands in the future, such as standard library Commands, such as [Revocation].
-
-## Attenuation
-
-Attenuation is the process of constraining the capabilities in a delegation chain. Each direct delegation MUST either directly restate or attenuate (diminish) its capabilities.
-
-# Token Resolution
-
-Token resolution is transport specific. The exact format is left to the relevant UCAN transport specification. At minimum, such a specification MUST define at least the following:
-
-1. Request protocol
-2. Response protocol
-3. Collections format
-
-Note that if an instance cannot dereference a CID at runtime, the UCAN MUST fail validation. This is consistent with the [constructive semantics] of UCAN.
-
-# Nonce
-
-The REQUIRED nonce parameter `nonce` MAY be any value. A randomly generated string is RECOMMENDED to provide a unique UCAN, though it MAY also be a monotonically increasing count of the number of links in the hash chain. This field helps prevent replay attacks and ensures a unique CID per delegation. The `iss`, `aud`, and `exp` fields together will often ensure that UCANs are unique, but adding the nonce ensures uniqueness.
-
-The recommended size of the nonce differs by key type. In many cases, a random 12-byte nonce is sufficient. If uncertain, check the nonce in your DID's crypto suite.
-
-This field SHOULD NOT be used to sign arbitrary data, such as signature challenges. See the [`meta`][Metadata] field for more.
-
-Here is a simple example.
-
-```js
-{
-  // ...
-  "nonce": {"/": {"bytes": "bGlnaHQgd29yay4"}}
-}
-```
-
-# Metadata
-
-The OPTIONAL `meta` field contains a map of arbitrary metadata, facts, and proofs of knowledge. The enclosed data MUST be self-evident and externally verifiable. It MAY include information such as hash preimages, server challenges, a Merkle proof, dictionary data, etc.
-
-The data contained in this map MUST NOT be semantically meaningful to delegation chains.
-
-Below is an example:
-
-```js
-{
-  // ...
-  "meta": {
-    "challenges": {
-      "example.com": "abcdef",
-      "another.example.net": "12345"
-    },
-    "sha3_256": {
-      "B94D27B9934D3E08A52E52D7DA7DABFAC484EFE37A5380EE9088F7ACE2EFCDE9": "hello world"
-    }
-  }
-}
-```
-
-# Canonicalization
-
-## Cryptosuite
-
-Across all UCAN specifications, the following cryptosuite MUST be supported:
-
-| Role      | REQUIRED Algorithms               | Notes                                |
-| --------- | --------------------------------- | ------------------------------------ |
-| Hash      | [SHA-256]                         |                                      |
-| Signature | [Ed25519], [P-256], [`secp256k1`] | Preference of Ed25519 is RECOMMENDED |
-| [DID]     | [`did:key`]                       |                                      |
-
-## Encoding
-
-All UCANs MUST be canonically encoded with [DAG-CBOR] for signing. A UCAN MAY be presented or stored in other [IPLD] formats (such as [DAG-JSON]), but converted to DAG-CBOR for signature validation.
-
-## Content Identifiers
-
-A UCAN token MUST be configured as follows:
-
-| Parameter    | REQUIRED Configuration |
-| ------------ | ---------------------- |
-| Version      | [CIDv1]                |
-| [Multibase]  | [`base58btc`]          |
-| [Multihash]  | [SHA-256]              |
-| [Multicodec] | [DAG-CBOR]             |
-
-> [!NOTE]
-> All CIDs encoded as above start with the characters `zdpu`.
-
-The resolution of these addresses is left to the implementation and end-user, and MAY (non-exclusively) include the following: local store, a distributed hash table (DHT), gossip network, or RESTful service.
-
-## Envelope
-
-All UCAN formats MUST use the following envelope format:
-
-| Field                             | Type           | Description                                                    |
-| --------------------------------- | -------------- | -------------------------------------------------------------- |
-| `.0`                              | `Bytes`        | A signature by the Payload's `iss` over the `SigPayload` field |
-| `.1`                              | `SigPayload`   | The content that was signed                                    |
-| `.1.h`                            | `VarsigHeader` | The [Varsig] v1 header                                         |
-| `.1.ucan/<subspec-tag>@<version>` | `TokenPayload` | The UCAN token payload                                         |
-
-```mermaid
-flowchart TD
-    subgraph Ucan ["UCAN Envelope"]
-        SignatureBytes["Signature (raw bytes)"]
-
-        subgraph SigPayload ["Signature Payload"]
-            VarsigHeader["Varsig Header"]
-
-            subgraph UcanPayload ["Token Payload"]
-                fields["..."]
-            end
-        end
-    end
-```
-
-For example:
-
-```js
-[
-  {
-    "/": {
-      bytes:
-        "7aEDQLYvb3lygk9yvAbk0OZD0q+iF9c3+wpZC4YlFThkiNShcVriobPFr/wl3akjM18VvIv/Zw2LtA4uUmB5m8PWEAU",
-    },
-  },
-  {
-    h: { "/": { bytes: "NBIFEgEAcQ" } },
-    "ucan/example@1.0.0-rc.1": {
-      hello: "world",
-    },
-  },
-];
-```
-
-### Payload
-
-A UCAN's Payload MUST contain at least the following fields:
-
-| Field   | Type                                      | Required | Description                                                 |
-| ------- | ----------------------------------------- | -------- | ----------------------------------------------------------- |
-| `iss`   | `DID`                                     | Yes      | Issuer DID (sender)                                         |
-| `aud`   | `DID`                                     | Yes      | Audience DID (receiver)                                     |
-| `sub`   | `DID`                                     | Yes      | Principal that the chain is about (the [Subject])           |
-| `cmd`   | `String`                                  | Yes      | The [Command] to eventually invoke                          |
-| `args`  | `{String : Any}`                          | Yes      | Any [Arguments] that MUST be present in the Invocation      |
-| `nonce` | `Bytes`                                   | Yes      | Nonce                                                       |
-| `meta`  | `{String : Any}`                          | No       | [Meta] (asserted, signed data) — is not delegated authority |
-| `nbf`   | `Integer` (53-bits[^js-num-size])         | No       | "Not before" UTC Unix Timestamp in seconds (valid from)     |
-| `exp`   | `Integer \| Null` (53-bits[^js-num-size]) | Yes      | Expiration UTC Unix Timestamp in seconds (valid until)      |
-
-# Implementation Recommendations
-
-## Delegation Store
-
-A validator MAY keep a local store of UCANs that it has received. UCANs are immutable but also time-bound so that this store MAY evict expired or revoked UCANs.
-
-This store SHOULD be indexed by CID (content addressing). Multiple indices built on top of this store MAY be used to improve capability search or selection performance.
-
-## Memoized Validation
-
-Aside from revocation, capability validation is idempotent. Marking a CID (or capability index inside that CID) as valid acts as memoization, obviating the need to check the entire structure on every validation. This extends to distinct UCANs that share a proof: if the proof was previously reviewed and is not revoked, it is RECOMMENDED to consider it valid immediately.
-
-Revocation is irreversible. Suppose the validator learns of revocation by UCAN CID. In that case, the UCAN and all of its derivatives in such a cache MUST be marked as invalid, and all validations immediately fail without needing to walk the entire structure.
-
-## Replay Attack Prevention
-
-Replay attack prevention is REQUIRED. Every UCAN token MUST hash to a unique [CIDv1]. Some simple strategies for implementing uniqueness tracking include maintaining a set of previously seen CIDs, or requiring that nonces be monotonically increasing per principal. This MAY be the same structure as a validated UCAN memoization table (if one is implemented).
-
-Maintaining a secondary token expiry index is RECOMMENDED. This enables garbage collection and more efficient search. In cases of very large stores, normal cache performance techniques MAY be used, such as Bloom filters, multi-level caches, and so on.
-
-## Beyond Single System Image
-
-> As we continue to increase the number of globally connected devices, we must embrace a design that considers every single member in the system as the primary site for the data that it is generates. It is completely impractical that we can look at a single, or a small number, of globally distributed data centers as the primary site for all global information that we desire to perform computations with.
->
-> —[Meiklejohn], [A Certain Tendency Of The Database Community]
-
-Unlike many authorization systems where a service controls access to resources in their care, location-independent, offline, and leaderless resources require control to live with the user. Therefore, the same data MAY be used across many applications, data stores, and users. Since they don't have a single location, applying UCAN to [RSM]s and [CRDT]s MAY be modelled by lifting the requirement that the Executor be the Subject.
-
-Ultimately this comes down to a question of push vs pull. In push, the subject MUST be the specific site being pushed to ("I command you to apply the following updates to your state").
-
-Pull is the broad class of situations where an Invoker doesn't require that a particular replica apply its state. Applying a change to a local CRDT replica and maintaining a UCAN invocation log is a valid update to "the CRDT": a version of the CRDT Subject exists locally even if the Subject's private key is not present. Gossiping these changes among agents allows each to apply changes that it becomes aware of. Thanks to the invocation log (or equivalent integrated directly into the CRDT), provenance of authority is made transparent.
-
-```mermaid
-sequenceDiagram
-    participant CRDT as Initial Grow-Only Set (CRDT)
-
-    actor Alice
-    actor Bob
-    actor Carol
-
-    autonumber
-
-    Note over CRDT, Bob: Setup
-    CRDT -->> Alice: delegate(CRDT_ID, merge)
-    CRDT -->> Bob: delegate(CRDT_ID, merge)
-
-    Note over Bob, Carol: Bob Invites Carol
-    Bob -->> Carol: delegate(CRDT_ID, merge)
-
-    Note over Alice, Carol: Direct P2P Gossip
-    Carol ->> Bob: invoke(CRDT_ID, merge, {"Carrot"}, proof: [➋,❸])
-    Alice ->> Carol: invoke(CRDT_ID, merge, {"Apple"}}, proof: [➊])
-    Bob ->> Alice: invoke(CRDT_ID, merge, {"Banana", "Carrot"}, proof: [➋])
-```
-
-## Wrapping Existing Systems
-
-In the RECOMMENDED scenario, the agent controlling a resource has a unique reference to it. This is always possible in a system that has adopted capabilities end-to-end.
-
-Interacting with existing systems MAY require relying on ambient authority contained in an ACL, non-unique reference, or other authorization logic. These cases are still compatible with UCAN, but the security guarantees are weaker since 1. the surface area is larger, and 2. part of the auth system lives outside UCAN.
-
-```mermaid
-sequenceDiagram
-    participant Database
-    participant ACL as External Auth System
-
-    actor DBAgent
-    actor Alice
-    actor Bob
-
-    Note over ACL, DBAgent: Setup
-    DBAgent ->> ACL: signup(DBAgent)
-    ACL ->> ACL: register(DBAgent)
-
-    autonumber 1
-
-    Note over DBAgent, Bob: Delegation
-    DBAgent -->> Alice: delegate(DBAgent, write)
-    Alice -->> Bob: delegate(DBAgent, write)
-
-    Note over Database, Bob: Invocation
-    Bob ->>+ DBAgent: invoke(DBAgent, [write, key, value], proof: [➊,➋])
-
-    critical External System
-        DBAgent ->> ACL: getToken(write, key, AuthGrant)
-        ACL ->> DBAgent: AccessToken
-
-        DBAgent ->> Database: request(write, value, AccessToken)
-        Database ->> DBAgent: ACK
-    end
-
-    DBAgent ->>- Bob: ACK
-```
-
-# FAQ
-
-## What prevents an unauthorized party from using an intercepted UCAN?
-
-UCANs always contain information about the sender and receiver. A UCAN is signed by the sender (the `iss` field DID) and can only be created by an agent in possession of the relevant private key. The recipient (the `aud` field DID) is required to check that the field matches their DID. These two checks together secure the certificate against use by an unauthorized party. [UCAN Invocations][invocation] prevent use by an unauthorized party by signing over a request to use the capability granted in a delegation chain.
-
-## What prevents replay attacks on the invocation use case?
-
-All UCAN Invocations MUST have a unique CID. The executing agent MUST check this validation uniqueness against a local store of unexpired UCAN hashes.
-
-This is not a concern when simply delegating since receiving a delegation is idempotent.
-
-## Is UCAN secure against person-in-the-middle attacks?
-
-_UCAN does not have any special protection against person-in-the-middle (PITM) attacks._
-
-If a PITM attack was successfully performed on a UCAN delegation, the proof chain would contain the attacker's DID(s). It is possible to detect this scenario and revoke the relevant UCAN but this does require special inspection of the topmost `iss` field to check if it is the expected DID. Therefore, it is strongly RECOMMENDED to only delegate UCANs to agents that are both trusted and authenticated and over secure channels.
-
-## Can my implementation support more cryptographic algorithms?
-
-It is possible to use other algorithms, but doing so limits interoperability with the broader UCAN ecosystem. This is thus considered "off spec" (i.e. non-interoperable). If you choose to extend UCAN with additional algorithms, you MUST include this metadata in the (self-describing) [Varsig] header.
-
-# Related Work and Prior Art
-
-[SPKI/SDSI] is closely related to UCAN. A different encoding format is used, and some details vary (such as a delegation-locking bit), but the core idea and general usage pattern are very close. UCAN can be seen as making these ideas more palatable to a modern audience and adding a few features such as content IDs that were less widespread at the time SPKI/SDSI were written.
-
-[ZCAP-LD] is closely related to UCAN. The primary differences are in formatting, addressing by URL instead of CID, the mechanism of separating invocation from authorization, and single versus multiple proofs.
-
-[CACAO] is a translation of many of these ideas to a cross-blockchain delegated bearer token model. It contains the same basic concepts as UCAN delegation, but is aimed at small messages and identities that are rooted in mutable documents rooted on a blockchain and lacks the ability to subdelegate capabilities.
-
-[Local-First Auth] is a non-certificate-based approach, instead relying on a CRDT to build up a list of group members, devices, and roles. It has a friendly invitation mechanism based on a [Seitan token exchange]. It is also straightforward to see which users have access to what, avoiding the confinement problem seen in many decentralized auth systems.
-
-[Macaroon] is a MAC-based capability and cookie system aimed at distributing authority across services in a trusted network (typically in the context of a Cloud). By not relying on asymmetric signatures, Macaroons achieve excellent space savings and performance, given that the MAC can be checked against the relevant services during discharge. The authority is rooted in an originating server rather than with an end-user.
-
-[Biscuit] uses Datalog to describe capabilities. It has a specialized format but is otherwise in line with UCAN.
-
-[Verifiable credentials] are a solution for data about people or organizations. However, they are aimed at a related-but-distinct problem: asserting attributes about the holder of a DID, including things like work history, age, and membership.
-
-# Acknowledgments
-
-Thank you to [Brendan O'Brien] for real-world feedback, technical collaboration, and implementing the first Golang UCAN library.
-
-Thank you [Blaine Cook] for the real-world feedback, ideas on future features, and lessons from other auth standards.
-
-Many thanks to [Hugo Dias], [Mikael Rogers], and the entire DAG House team for the real world feedback, and finding inventive new use cases.
-
-Thank to [Hannah Howard] and [Alan Shaw] at [Storacha] for their team's feedback from real world use cases.
-
-Many thanks to [Brian Ginsburg] and [Steven Vandevelde] for their many copy edits, feedback from real world usage, maintenance of the TypeScript implementation, and tools such as [ucan.xyz].
-
-Many thanks to [Christopher Joel] for his real-world feedback, raising many pragmatic considerations, and the Rust implementation and related crates.
-
-Many thanks to [Christine Lemmer-Webber] for her handwritten(!) feedback on the design of UCAN, spearheading the [OCapN] initiative, and her related work on [ZCAP-LD].
-
-Many thanks to [Alan Karp] for sharing his vast experience with capability-based authorization, patterns, and many right words for us to search for.
-
-Thanks to [Benjamin Goering] for the many community threads and connections to [W3C] standards.
-
-Thanks to [Juan Caballero] for the numerous questions, clarifications, and general advice on putting together a comprehensible spec.
-
-Thank you [Dan Finlay] for being sufficiently passionate about [OCAP] that we realized that capability systems had a real chance of adoption in an ACL-dominated world.
-
-Thanks to [Peter van Hardenberg][PvH] and [Martin Kleppmann] of [Ink & Switch] for conversations exploring options for access control on CRDTs and [local-first] applications.
-
-Thanks to the entire [SPKI WG][SPKI/SDSI] for their closely related pioneering work.
-
-We want to especially recognize [Mark Miller] for his numerous contributions to the field of distributed auth, programming languages, and networked security writ large.
-
-<!-- Footnotes -->
-
-[^js-num-size]: JavaScript has a single numeric type ([`Number`][JS Number]) for both integers and floats. This representation is defined as a [IEEE-754] double-precision floating point number, which has a 53-bit significand.
-
-[^pcec]: To be precise, this is a [PC/EC][PACELC] system, which is a critical trade-off for many systems. UCAN can be used to model both PC/EC and PA/EL, but is most typically PC/EL.
-
-<!-- Internal Links -->
-
-[Command]: #command
-[Cryptosuite]: #cryptosuite
-[overcoming SSI]: #beyond-single-system-image
-[sub-specifications]: #sub-specifications
-[wrapping existing systems]: #wrapping-existing-systems
-
-<!-- External Links -->
-
-[IEEE-754]: https://ieeexplore.ieee.org/document/8766229
-[A Certain Tendency Of The Database Community]: https://arxiv.org/pdf/1510.08473.pdf
-[ACL]: https://en.wikipedia.org/wiki/Access-control_list
-[Alan Karp]: https://github.com/alanhkarp
-[Alan Kay]: https://en.wikipedia.org/wiki/Alan_Kay
-[Alan Shaw]: https://github.com/alanshaw
-[BCP 14]: https://www.rfc-editor.org/info/bcp14
-[BLAKE3]: https://github.com/BLAKE3-team/BLAKE3
-[Benjamin Goering]: https://github.com/gobengo
-[Biscuit]: https://github.com/biscuit-auth/biscuit/
-[Blaine Cook]: https://github.com/blaine
-[Bluesky]: https://blueskyweb.xyz/
-[Brendan O'Brien]: https://github.com/b5
-[Brian Ginsburg]: https://github.com/bgins
-[Brooklyn Zelenka]: https://github.com/expede
-[CACAO]: https://blog.ceramic.network/capability-based-data-security-on-ceramic/
-[CIDv1]: https://docs.ipfs.io/concepts/content-addressing/#identifier-formats
-[CIDv1]: https://github.com/multiformats/cid
-[CRDT]: https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
-[Capability Myths Demolished]: https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
-[Christine Lemmer-Webber]: https://github.com/cwebber
-[Christopher Joel]: https://github.com/cdata
-[Code Mesh 2016]: https://www.codemesh.io/codemesh2016
-[DAG-CBOR]: https://ipld.io/specs/codecs/dag-cbor/spec/
-[DAG-JSON]: https://ipld.io/specs/codecs/dag-json/spec/
-[DID fragment]: https://www.w3.org/TR/did-core/#fragment
-[DID path]: https://www.w3.org/TR/did-core/#path
-[DID subject]: https://www.w3.org/TR/did-core/#dfn-did-subjects
-[DID]: https://www.w3.org/TR/did-core/
-[Dan Finlay]: https://github.com/danfinlay
-[Daniel Holmgren]: https://github.com/dholms
-[ECDSA security]: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Security
-[Ed25519]: https://en.wikipedia.org/wiki/EdDSA#Ed25519
-[EdDSA]: https://datatracker.ietf.org/doc/html/rfc8032#section-5.1
-[Email about SPKI]: https://web.archive.org/web/20140724054706/http://wiki.erights.org/wiki/Capability-based_Active_Invocation_Certificates
-[FIDO]: https://fidoalliance.org/what-is-fido/
-[Fission]: https://fission.codes
-[GUID]: https://en.wikipedia.org/wiki/Universally_unique_identifier
-[Hannah Howard]: https://github.com/hannahhoward
-[Hugo Dias]: https://github.com/hugomrdias
-[IPLD]: https://ipld.io/
-[Ink & Switch]: https://www.inkandswitch.com/
-[Inversion of control]: https://en.wikipedia.org/wiki/Inversion_of_control
-[Irakli Gozalishvili]: https://github.com/Gozala
-[JWT]: https://www.rfc-editor.org/rfc/rfc7519
-[Joe Armstrong]: https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer)
-[Juan Caballero]: https://github.com/bumblefudge
-[Local-First Auth]: https://github.com/local-first-web/auth
-[Macaroon]: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/41892.pdf
-[Mark Miller]: https://github.com/erights
-[Martin Kleppmann]: https://martin.kleppmann.com/
-[Meiklejohn]: https://christophermeiklejohn.com/
-[Mikael Rogers]: https://github.com/mikeal/
-[Multibase]: https://github.com/multiformats/multibase
-[Multicodec]: https://github.com/multiformats/multicodec
-[Multics]: https://en.wikipedia.org/wiki/Multics
-[Multihash]: https://www.multiformats.io/multihash/
-[OCAP]: http://erights.org/elib/capability/index.html
-[OCapN]: https://github.com/ocapn/ocapn
-[P-256]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf#page=111
-[PACELC]: https://en.wikipedia.org/wiki/PACELC_theorem
-[Philipp Krüger]: https://github.com/matheus23
-[PoLA]: https://en.wikipedia.org/wiki/Principle_of_least_privilege
-[Protocol Labs]: https://protocol.ai/
-[PvH]: https://www.pvh.ca
-[RBAC]: https://en.wikipedia.org/wiki/Role-based_access_control
-[RFC 2119]: https://datatracker.ietf.org/doc/html/rfc2119
-[RFC 3339]: https://www.rfc-editor.org/rfc/rfc3339
-[RFC 8037]: https://datatracker.ietf.org/doc/html/rfc8037
-[RSM]: https://en.wikipedia.org/wiki/State_machine_replication
-[Robust Composition]: http://www.erights.org/talks/thesis/markm-thesis.pdf
-[SHA-256]: https://en.wikipedia.org/wiki/SHA-2
-[SPKI/SDSI]: https://datatracker.ietf.org/wg/spki/about/
-[SPKI]: https://theworld.com/~cme/html/spki.html
-[Seitan token exchange]: https://book.keybase.io/docs/teams/seitan
-[Steven Vandevelde]: https://github.com/icidasset
-[Storacha]: https://storacha.network/
-[The Structure of Authority]: http://erights.org/talks/no-sep/secnotsep.pdf
-[The computer revolution hasn't happened yet]: https://www.youtube.com/watch?v=oKg1hTOQXoY
-[UCAN Promise]: https://github.com/ucan-wg/promise
-[URI]: https://www.rfc-editor.org/rfc/rfc3986
-[Varsig]: https://github.com/ChainAgnostic/varsig
-[Verifiable credentials]: https://www.w3.org/2017/vc/WG/
-[W3C]: https://www.w3.org/
-[WebCrypto API]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API
-[Witchcraft Software]: https://github.com/expede
-[ZCAP-LD]: https://w3c-ccg.github.io/zcap-spec/
-[`base58btc`]: https://github.com/multiformats/multibase/blob/master/multibase.csv#L21
-[`did:key`]: https://w3c-ccg.github.io/did-method-key/
-[`secp256k1`]: https://en.bitcoin.it/wiki/Secp256k1
-[browser api crypto key]: https://developer.mozilla.org/en-US/docs/Web/API/CryptoKey
-[capabilities]: https://en.wikipedia.org/wiki/Object-capability_model
-[caps as keys]: http://www.erights.org/elib/capability/duals/myths.html#caps-as-keys
-[certificate capability model]: https://web.archive.org/web/20140724054706/http://wiki.erights.org/wiki/Capability-based_Active_Invocation_Certificates
-[confinement]: http://www.erights.org/elib/capability/dist-confine.html
-[confused deputy problem]: https://en.wikipedia.org/wiki/Confused_deputy_problem
-[constructive semantics]: https://en.wikipedia.org/wiki/Intuitionistic_logic
-[content addressable storage]: https://en.wikipedia.org/wiki/Content-addressable_storage
-[content addressing]: https://en.wikipedia.org/wiki/Content-addressable_storage
-[dag-json multicodec]: https://github.com/multiformats/multicodec/blob/master/table.csv#L104
-[delegation]: https://github.com/ucan-wg/delegation
-[fail-safe]: https://en.wikipedia.org/wiki/Fail-safe
-[invocation]: https://github.com/ucan-wg/invocation
-[local-first]: https://www.inkandswitch.com/local-first/
-[number zero]: https://n0.computer/
-[passkey]: https://www.passkeys.com/
-[promise]: https://github.com/ucan-wg/promise
-[raw data multicodec]: https://github.com/multiformats/multicodec/blob/a03169371c0a4aec0083febc996c38c3846a0914/table.csv?plain=1#L41
-[revocation]: https://github.com/ucan-wg/revocation
-[secure hardware enclave]: https://support.apple.com/en-ca/guide/security/sec59b0b31ff
-[spki rfc]: https://www.rfc-editor.org/rfc/rfc2693.html
-[time definition]: https://en.wikipedia.org/wiki/Temporal_database
-[trustless]: https://blueskyweb.xyz/blog/3-6-2022-a-self-authenticating-social-protocol
-[ucan.xyz]: https://ucan.xyz

.github/aider/prompts/data-modeler-cosmos.md

@@ -1,105 +0,0 @@
-You are an expert in Cosmos SDK data modeling and state management, specializing in building efficient and scalable data models using the Cosmos SDK ORM system with Protocol Buffers.
-
-Key Principles:
-
-- Design type-safe state management systems
-- Create efficient protobuf-based data models
-- Implement proper table structures and indexes
-- Follow Cosmos SDK state management best practices
-- Design for light client compatibility
-- Implement proper genesis import/export
-- Follow protobuf naming conventions
-
-Data Modeling Best Practices:
-
-- Define clear table structures in .proto files
-- Use appropriate primary key strategies
-- Implement proper secondary indexes
-- Follow database normalization principles (1NF+)
-- Avoid repeated fields in tables
-- Design for future extensibility
-- Consider state layout impact on clients
-
-Schema Design Patterns:
-
-- Use unique table IDs within .proto files
-- Implement proper field numbering
-- Design efficient multipart keys
-- Use appropriate field types
-- Consider index performance implications
-- Implement proper singleton patterns
-- Design for automatic query services
-
-State Management:
-
-- Follow Cosmos SDK store patterns
-- Implement proper prefix handling
-- Design efficient range queries
-- Use appropriate encoding strategies
-- Handle state migrations properly
-- Implement proper genesis handling
-- Consider light client proof requirements
-
-Error Handling and Validation:
-
-- Implement proper input validation
-- Use appropriate error types
-- Handle state errors appropriately
-- Implement proper debugging
-- Use context appropriately
-- Implement proper logging
-- Handle concurrent access
-
-Performance Optimization:
-
-- Design efficient key encodings
-- Optimize storage space usage
-- Implement efficient queries
-- Use appropriate index strategies
-- Consider state growth implications
-- Monitor performance metrics
-- Design for scalability
-
-Dependencies:
-
-- cosmos/orm/v1/orm.proto
-- [google.golang.org/protobuf](http://google.golang.org/protobuf)
-- cosmos-sdk/store
-- cosmos-sdk/types
-- tendermint/types
-- proper logging framework
-
-Key Conventions:
-
-1. Use consistent protobuf naming
-2. Implement proper documentation
-3. Follow schema versioning practices
-4. Use proper table ID management
-5. Implement proper testing strategies
-
-Example Table Structure:
-
-```protobuf
-message Balance {
-    option (cosmos.orm.v1.table) = {
-        id: 1
-        primary_key: { fields: "account,denom" }
-        index: { id: 1, fields: "denom" }
-    };
-
-    bytes account = 1;
-    string denom = 2;
-    uint64 amount = 3;
-}
-
-message Params {
-    option (cosmos.orm.v1.singleton) = {
-        id: 2
-    };
-
-    google.protobuf.Duration voting_period = 1;
-    uint64 min_threshold = 2;
-}
-```
-
-Refer to the official Cosmos SDK documentation and ORM specifications for best practices and up-to-date APIs.

.github/aider/prompts/data-modeler.md

@@ -1,88 +0,0 @@
-    You are an expert in Go data modeling and PostgreSQL database design, specializing in building efficient and scalable data models using modern ORMs like GORM and SQLBoiler.
-
-    Key Principles:
-    - Write idiomatic Go code following standard Go conventions
-    - Design clean and maintainable database schemas
-    - Implement proper relationships and constraints
-    - Use appropriate indexes for query optimization
-    - Follow database normalization principles
-    - Implement proper error handling and validation
-    - Use meaningful struct tags for ORM mapping
-
-    Data Modeling Best Practices:
-    - Use appropriate Go types for database columns
-    - Implement proper foreign key relationships
-    - Design for data integrity and consistency
-    - Consider soft deletes where appropriate
-    - Use composite indexes strategically
-    - Implement proper timestamps for auditing
-    - Handle NULL values appropriately with pointers
-
-    ORM Patterns:
-    - Use GORM hooks for complex operations
-    - Implement proper model validation
-    - Use transactions for atomic operations
-    - Implement proper eager loading
-    - Use batch operations for better performance
-    - Handle migrations systematically
-    - Implement proper model scopes
-
-    Database Design:
-    - Follow PostgreSQL best practices
-    - Use appropriate column types
-    - Implement proper constraints
-    - Design efficient indexes
-    - Use JSONB for flexible data when needed
-    - Implement proper partitioning strategies
-    - Consider materialized views for complex queries
-
-    Error Handling and Validation:
-    - Implement proper input validation
-    - Use custom error types
-    - Handle database errors appropriately
-    - Implement retry mechanisms
-    - Use context for timeouts
-    - Implement proper logging
-    - Handle concurrent access
-
-    Performance Optimization:
-    - Use appropriate batch sizes
-    - Implement connection pooling
-    - Use prepared statements
-    - Optimize query patterns
-    - Use appropriate caching strategies
-    - Monitor query performance
-    - Use explain analyze for optimization
-
-    Dependencies:
-    - GORM or SQLBoiler
-    - pq (PostgreSQL driver)
-    - validator
-    - migrate
-    - sqlx (for raw SQL when needed)
-    - zap or logrus for logging
-
-    Key Conventions:
-    1. Use consistent naming conventions
-    2. Implement proper documentation
-    3. Follow database migration best practices
-    4. Use version control for schema changes
-    5. Implement proper testing strategies
-
-    Example Model Structure:
-    ```go
-    type User struct {
-        ID        uint      `gorm:"primarykey"`
-        CreatedAt time.Time
-        UpdatedAt time.Time
-        DeletedAt gorm.DeletedAt `gorm:"index"`
-        
-        Name     string `gorm:"type:varchar(100);not null"`
-        Email    string `gorm:"type:varchar(100);uniqueIndex;not null"`
-        Profile  Profile
-        Orders   []Order
-    }
-    ```
-
-    Refer to the official documentation of GORM, PostgreSQL, and Go for best practices and up-to-date APIs.
-      

.github/aider/prompts/sonr-tech-lead.md

@@ -1,132 +0,0 @@
-You are a technical lead specializing in decentralized identity systems and security architecture, with expertise in W3C standards, Cosmos SDK, and blockchain security patterns.
-
-Core Responsibilities:
-- Ensure compliance with W3C DID and VC specifications
-- Implement secure cryptographic practices
-- Design robust authentication flows
-- Maintain data privacy and protection
-- Guide secure state management
-- Enforce access control patterns
-- Oversee security testing
-
-Security Standards:
-- W3C DID Core 1.0
-- W3C Verifiable Credentials
-- W3C WebAuthn Level 2
-- OAuth 2.0 and OpenID Connect
-- JSON Web Signatures (JWS)
-- JSON Web Encryption (JWE)
-- Decentralized Key Management (DKMS)
-
-Architecture Patterns:
-- Secure DID Resolution
-- Verifiable Credential Issuance
-- DWN Access Control
-- Service Authentication
-- State Validation
-- Key Management
-- Privacy-Preserving Protocols
-
-Implementation Guidelines:
-- Use standardized cryptographic libraries
-- Implement proper key derivation
-- Follow secure encoding practices
-- Validate all inputs thoroughly
-- Handle errors securely
-- Log security events properly
-- Implement rate limiting
-
-State Management Security:
-- Validate state transitions
-- Implement proper access control
-- Use secure storage patterns
-- Handle sensitive data properly
-- Implement proper backup strategies
-- Maintain state integrity
-- Monitor state changes
-
-Authentication & Authorization:
-- Implement proper DID authentication
-- Use secure credential validation
-- Follow OAuth 2.0 best practices
-- Implement proper session management
-- Use secure token handling
-- Implement proper key rotation
-- Monitor authentication attempts
-
-Data Protection:
-- Encrypt sensitive data
-- Implement proper key management
-- Use secure storage solutions
-- Follow data minimization principles
-- Implement proper backup strategies
-- Handle data deletion securely
-- Monitor data access
-
-Security Testing:
-- Implement security unit tests
-- Perform integration testing
-- Conduct penetration testing
-- Monitor security metrics
-- Review security logs
-- Conduct threat modeling
-- Maintain security documentation
-
-Example Security Patterns:
-
-```go
-// Secure DID Resolution
-func ResolveDID(did string) (*DIDDocument, error) {
-    // Validate DID format
-    if !ValidateDIDFormat(did) {
-        return nil, ErrInvalidDID
-    }
-
-    // Resolve with retry and timeout
-    ctx, cancel := context.WithTimeout(context.Background(), resolveTimeout)
-    defer cancel()
-
-    doc, err := resolver.ResolveWithContext(ctx, did)
-    if err != nil {
-        return nil, fmt.Errorf("resolution failed: %w", err)
-    }
-
-    // Validate document structure
-    if err := ValidateDIDDocument(doc); err != nil {
-        return nil, fmt.Errorf("invalid document: %w", err)
-    }
-
-    return doc, nil
-}
-
-// Secure Credential Verification
-func VerifyCredential(vc *VerifiableCredential) error {
-    // Check expiration
-    if vc.IsExpired() {
-        return ErrCredentialExpired
-    }
-
-    // Verify proof
-    if err := vc.VerifyProof(trustRegistry); err != nil {
-        return fmt.Errorf("invalid proof: %w", err)
-    }
-
-    // Verify status
-    if err := vc.CheckRevocationStatus(); err != nil {
-        return fmt.Errorf("revocation check failed: %w", err)
-    }
-
-    return nil
-}
-```
-
-Security Checklist:
-1. All DIDs follow W3C specification
-2. Credentials implement proper proofs
-3. Keys use proper derivation/rotation
-4. State changes are validated
-5. Access control is enforced
-6. Data is properly encrypted
-7. Logging captures security events
-
-Refer to W3C specifications, Cosmos SDK security documentation, and blockchain security best practices for detailed implementation guidance.

.github/dependabot.yml

@@ -1,4 +1,6 @@
 # To get started with Dependabot version updates, you'll need to specify which
+#
+# 
 # package ecosystems to update and where the package manifests are located.
 # Please see the documentation for all configuration options:
 # https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
@@ -8,4 +10,272 @@ updates:
   - package-ecosystem: "gomod" # See documentation for possible values
     directory: "/" # Location of package manifests
     schedule:
-      interval: "weekly"
+      interval: "monthly"
+
+
+
+      
+
+      
+      
+
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      
+
+
+
+
+
+      
+      
+      
+      
+      
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      
+      
+      
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      
+
+
+      
+
+      
+      
+      
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      
+      
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+      
+      
+
+
+
+      
+      
+
+      
+
+
+
+
+
+
+
+      ]]]]

.github/pr-labeler.yml

@@ -1,5 +1,3 @@
-"@pr/feature": ["feature/*", "feat/*"]
-"@pr/fix": fix/*
-"@pr/chore": chore/*
-"@pr/docs": docs/*
-"@pr/refactor": refactor/*
+"feature": ["feature/*", "feat/*"]
+"bugfix": fix/*
+"enhancement": enhancement/*

.github/scopes.json

@@ -1,427 +1,500 @@
-[
-  {
-    "name": "app/cosmos-sdk",
-    "path": "app",
-    "docs": [
-      {
-        "keywords": [
-          "module",
-          "cosmos"
-        ],
-        "url": "https://docs.cosmos.network/v0.50/build/building-modules/module-manager"
-      },
-      {
-        "keywords": [
-          "protobuf",
-          "cosmos"
-        ],
-        "url": "https://docs.cosmos.network/v0.50/build/building-modules/messages-and-queries"
-      },
-      {
-        "keywords": [
-          "rpc",
-          "protobuf",
-          "service",
-          "cosmos"
-        ],
-        "url": "https://docs.cosmos.network/v0.50/build/building-modules/msg-services"
-      },
-      {
-        "keywords": [
-          "protobuf",
-          "rpc",
-          "cosmos",
-          "query"
-        ],
-        "url": "https://docs.cosmos.network/v0.50/build/building-modules/query-services"
-      },
-      {
-        "keywords": [
-          "cosmos",
-          "depinject",
-          "sdk"
-        ],
-        "url": "https://docs.cosmos.network/v0.50/build/building-modules/depinject"
-      }
-    ]
-  },
-  {
-    "name": "app/ibc",
-    "path": "app",
-    "docs": [
-      {
-        "keywords": [
-          "cosmos",
-          "interchain",
-          "accounts"
-        ],
-        "url": "https://ibc.cosmos.network/v8/apps/interchain-accounts/overview/"
-      },
-      {
-        "keywords": [],
-        "url": "https://ibc.cosmos.network/v8/apps/transfer/overview/"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.osmosis.zone/osmosis-core/asset-info/"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.osmosis.zone/osmosis-core/modules/tokenfactory"
-      },
-      {
-        "keywords": [
-          "usdc",
-          "mint",
-          "cosmos",
-          "noble"
-        ],
-        "url": "https://docs.noble.xyz/cctp/mint"
-      },
-      {
-        "keywords": [
-          "usdc"
-        ],
-        "url": "https://docs.noble.xyz/cctp/mint_forward"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.evmos.org/protocol/modules/erc20"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.nomic.io/nbtc"
-      }
-    ]
-  },
-  {
-    "name": "crypto/mpc",
-    "path": "crypto/mpc",
-    "docs": [
-      {
-        "keywords": [
-          "mpc",
-          "wallet",
-          "security",
-          "advanced cryptography"
-        ],
-        "url": "https://csrc.nist.gov/CSRC/media/Events/NTCW19/papers/paper-DKLS.pdf"
-      }
-    ]
-  },
-  {
-    "name": "crypto/ucan",
-    "path": "crypto/ucan",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://raw.githubusercontent.com/ucan-wg/spec/refs/heads/main/README.md"
-      }
-    ]
-  },
-  {
-    "name": "crypto/zkp",
-    "path": "crypto/accumulator",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://eprint.iacr.org/2021/1672.pdf"
-      }
-    ]
-  },
-  {
-    "name": "gateway/handlers",
-    "path": "pkg/gateway/handlers",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://echo.labstack.com/docs/cookbook/sse"
-      },
-      {
-        "keywords": [],
-        "url": "https://echo.labstack.com/docs/cookbook/websocket"
-      },
-      {
-        "keywords": [],
-        "url": "https://echo.labstack.com/docs/cookbook/subdomain"
-      }
-    ]
-  },
-  {
-    "name": "gateway/database",
-    "path": "pkg/gateway/internal/database",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://docs.tigerbeetle.com/coding/data-modeling"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.tigerbeetle.com/coding/two-phase-transfers"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.tigerbeetle.com/coding/reliable-transaction-submission"
-      },
-      {
-        "keywords": [
-          "currency"
-        ],
-        "url": "https://docs.tigerbeetle.com/coding/recipes/currency-exchange"
-      },
-      {
-        "keywords": [
-          "balance"
-        ],
-        "url": "https://docs.tigerbeetle.com/coding/recipes/balance-conditional-transfers"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.tigerbeetle.com/reference/account"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.tigerbeetle.com/reference/transfer"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.substreams.dev/documentation/consume/packages"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.substreams.dev/documentation/consume/sql/deployable-services/local-service"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.substreams.dev/tutorials/cosmos/injective/foundational"
-      }
-    ]
-  },
-  {
-    "name": "vault/handlers",
-    "path": "pkg/vault/handlers",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://echo.labstack.com/docs/cookbook/jwt"
-      },
-      {
-        "keywords": [],
-        "url": "https://echo.labstack.com/docs/middleware/secure"
-      },
-      {
-        "keywords": [],
-        "url": "https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API"
-      }
-    ]
-  },
-  {
-    "name": "vault/database",
-    "path": "pkg/vault/internal/database",
-    "docs": [
-      "https://dexie.org/docs/ExportImport/dexie-export-import",
-      "https://dexie.org/docs/API-Reference#quick-reference",
-      "https://templ.guide/syntax-and-usage/script-templates"
-    ]
-  },
-  {
-    "name": "pkl/ipfs",
-    "path": "pkl/ipfs.net",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://github.com/ipfs/kubo/blob/master/docs/config.md"
-      },
-      {
-        "keywords": [],
-        "url": "https://pkl-lang.org/main/current/language-reference/index.html"
-      }
-    ]
-  },
-  {
-    "name": "pkl/matrix",
-    "path": "pkl/matrix.net",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html"
-      },
-      {
-        "keywords": [],
-        "url": "https://pkl-lang.org/main/current/language-reference/index.html"
-      }
-    ]
-  },
-  {
-    "name": "pkl/chain",
-    "path": "pkl/sonr.chain",
-    "docs": [
-      "https://tutorials.cosmos.network/tutorials/9-path-to-prod/5-network.html",
-      "https://tutorials.cosmos.network/tutorials/9-path-to-prod/4-genesis.html",
-      "https://pkl-lang.org/main/current/language-reference/index.html",
-      "https://docs.cosmos.network/v0.50/user/run-node/run-testnet"
-    ]
-  },
-  {
-    "name": "pkl/hway",
-    "path": "pkl/sonr.hway",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://pkl-lang.org/main/current/language-reference/index.html"
-      }
-    ]
-  },
-  {
-    "name": "pkl/motr",
-    "path": "pkl/sonr.motr",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://pkl-lang.org/main/current/language-reference/index.html"
-      },
-      {
-        "keywords": [],
-        "url": "https://web.dev/learn/pwa/service-workers/"
-      },
-      {
-        "keywords": [],
-        "url": "https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API"
-      }
-    ]
-  },
-  {
-    "name": "x/did",
-    "path": "proto/did",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/packages/orm"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/building-modules/protobuf-annotations"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/modules/auth"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/packages/collections"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/modules/bank"
-      }
-    ]
-  },
-  {
-    "name": "x/dwn",
-    "path": "proto/dwn",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/building-modules/protobuf-annotations"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/packages/orm"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/modules/authz"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/packages/collections"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/modules/gov"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/modules/staking"
-      }
-    ]
-  },
-  {
-    "name": "x/svc",
-    "path": "proto/svc",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/packages/collections"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/building-modules/protobuf-annotations"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/packages/orm"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/modules/group"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/modules/nft"
-      }
-    ]
-  },
-  {
-    "name": "repo/ci-cd",
-    "path": "deploy",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.cosmos.network/v0.50/build/tooling/cosmovisor"
-      },
-      {
-        "keywords": [],
-        "url": "https://f1bonacc1.github.io/process-compose/configuration/"
-      },
-      {
-        "keywords": [],
-        "url": "https://docs.nomic.io/network/ibc-relayer"
-      },
-      {
-        "keywords": [],
-        "url": "https://www.jetify.com/docs/devbox"
-      },
-      {
-        "keywords": [],
-        "url": "https://taskfile.dev/reference/cli"
-      },
-      {
-        "keywords": [],
-        "url": "https://taskfile.dev/reference/schema"
-      },
-      {
-        "keywords": [],
-        "url": "https://taskfile.dev/reference/templating/"
-      }
-    ]
-  },
-  {
-    "name": "repo/docs",
-    "path": "docs",
-    "docs": [
-      {
-        "keywords": [],
-        "url": "https://squidfunk.github.io/mkdocs-material/reference/"
-      },
-      {
-        "keywords": [],
-        "url": "https://github.com/mkdocs/catalog/blob/main/README.md"
-      }
-    ]
-  }
-]
+{
+  "scopes": [
+    "core-chain",
+    "core-ibc",
+    "sonr-hway",
+    "sonr-matrix",
+    "sonr-motr",
+    "x-did",
+    "x-dwn",
+    "x-svc",
+    "security-mpc",
+    "security-ucan",
+    "security-zkp",
+    "ci-cd",
+    "dev-ops"
+  ],
+  "docs": [
+    {
+      "keywords": [
+        "github",
+        "actions",
+        "workflows",
+        "syntax"
+      ],
+      "url": "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "tooling",
+        "cosmovisor"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/tooling/cosmovisor"
+    },
+    {
+      "keywords": [
+        "process-compose",
+        "configuration"
+      ],
+      "url": "https://f1bonacc1.github.io/process-compose/configuration/"
+    },
+    {
+      "keywords": [
+        "taskfile",
+        "cli",
+        "reference"
+      ],
+      "url": "https://taskfile.dev/reference/cli"
+    },
+    {
+      "keywords": [],
+      "url": "https://taskfile.dev/reference/schema"
+    },
+    {
+      "keywords": [
+        "taskfile",
+        "templating",
+        "reference"
+      ],
+      "url": "https://taskfile.dev/reference/templating/"
+    },
+    {
+      "keywords": [
+        "mkdocs",
+        "material",
+        "reference"
+      ],
+      "url": "https://squidfunk.github.io/mkdocs-material/reference/"
+    },
+    {
+      "keywords": [
+        "pkl",
+        "language",
+        "reference"
+      ],
+      "url": "https://pkl-lang.org/main/current/language-reference/index.html"
+    },
+    {
+      "keywords": [
+        "pwa",
+        "service-workers",
+        "web"
+      ],
+      "url": "https://web.dev/learn/pwa/service-workers/"
+    },
+    {
+      "keywords": [
+        "service-workers",
+        "web",
+        "api"
+      ],
+      "url": "https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API"
+    },
+    {
+      "keywords": [
+        "web-authentication",
+        "web",
+        "api"
+      ],
+      "url": "https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API"
+    },
+    {
+      "keywords": [
+        "sdk",
+        "modules",
+        "cosmos",
+        "manager"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/building-modules/module-manager"
+    },
+    {
+      "keywords": [
+        "sdk",
+        "modules",
+        "cosmos",
+        "messages",
+        "queries"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/building-modules/messages-and-queries"
+    },
+    {
+      "keywords": [
+        "sdk",
+        "modules",
+        "messages",
+        "service",
+        "cosmos"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/building-modules/msg-services"
+    },
+    {
+      "keywords": [
+        "sdk",
+        "modules",
+        "services",
+        "cosmos",
+        "query"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/building-modules/query-services"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "depinject",
+        "modules",
+        "sdk"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/building-modules/depinject"
+    },
+    {
+      "keywords": [
+        "ibc",
+        "apps",
+        "sdk",
+        "interchain-accounts"
+      ],
+      "url": "https://ibc.cosmos.network/v8/apps/interchain-accounts/overview/"
+    },
+    {
+      "keywords": [
+        "ibc",
+        "apps",
+        "sdk",
+        "transfer"
+      ],
+      "url": "https://ibc.cosmos.network/v8/apps/transfer/overview/"
+    },
+    {
+      "keywords": [
+        "osmosis",
+        "modules",
+        "ibc",
+        "assets"
+      ],
+      "url": "https://docs.osmosis.zone/osmosis-core/asset-info/"
+    },
+    {
+      "keywords": [
+        "ibc",
+        "osmosis",
+        "tokenfactory",
+        "modules",
+        "assets"
+      ],
+      "url": "https://docs.osmosis.zone/osmosis-core/modules/tokenfactory"
+    },
+    {
+      "keywords": [
+        "ibc",
+        "mint",
+        "cctp",
+        "noble",
+        "assets"
+      ],
+      "url": "https://docs.noble.xyz/cctp/mint"
+    },
+    {
+      "keywords": [
+        "ibc",
+        "relayer",
+        "nomic",
+        "assets"
+      ],
+      "url": "https://docs.nomic.io/network/ibc-relayer"
+    },
+    {
+      "keywords": [
+        "ibc",
+        "cctp",
+        "noble",
+        "mint_forward",
+        "assets"
+      ],
+      "url": "https://docs.noble.xyz/cctp/mint_forward"
+    },
+    {
+      "keywords": [
+        "evmos",
+        "erc20",
+        "assets"
+      ],
+      "url": "https://docs.evmos.org/protocol/modules/erc20"
+    },
+    {
+      "keywords": [
+        "nomic",
+        "nbtc",
+        "assets"
+      ],
+      "url": "https://docs.nomic.io/nbtc"
+    },
+    {
+      "keywords": [
+        "mpc",
+        "wallet",
+        "cryptography",
+        "capability",
+        "invokation"
+      ],
+      "url": "https://csrc.nist.gov/CSRC/media/Events/NTCW19/papers/paper-DKLS.pdf"
+    },
+    {
+      "keywords": [
+        "ucan",
+        "spec",
+        "cryptography",
+        "authorization"
+      ],
+      "url": "https://raw.githubusercontent.com/ucan-wg/spec/refs/heads/main/README.md"
+    },
+    {
+      "keywords": [
+        "zero-knowledge",
+        "proofs",
+        "cryptography",
+        "privacy"
+      ],
+      "url": "https://eprint.iacr.org/2021/1672.pdf"
+    },
+    {
+      "keywords": [
+        "gateway",
+        "http",
+        "sse"
+      ],
+      "url": "https://echo.labstack.com/docs/cookbook/sse"
+    },
+    {
+      "keywords": [
+        "gateway",
+        "http",
+        "websocket"
+      ],
+      "url": "https://echo.labstack.com/docs/cookbook/websocket"
+    },
+    {
+      "keywords": [
+        "gateway",
+        "http",
+        "subdomain"
+      ],
+      "url": "https://echo.labstack.com/docs/cookbook/subdomain"
+    },
+    {
+      "keywords": [
+        "tigerbeetle",
+        "models",
+        "oracle"
+      ],
+      "url": "https://docs.tigerbeetle.com/coding/data-modeling"
+    },
+    {
+      "keywords": [
+        "tigerbeetle",
+        "two=phase",
+        "transfers",
+        "oracle"
+      ],
+      "url": "https://docs.tigerbeetle.com/coding/two-phase-transfers"
+    },
+    {
+      "keywords": [
+        "tigerbeetle",
+        "oracle",
+        "reliable",
+        "transaction",
+        "submission"
+      ],
+      "url": "https://docs.tigerbeetle.com/coding/reliable-transaction-submission"
+    },
+    {
+      "keywords": [
+        "currency",
+        "exchange",
+        "tigerbeetle",
+        "oracle"
+      ],
+      "url": "https://docs.tigerbeetle.com/coding/recipes/currency-exchange"
+    },
+    {
+      "keywords": [
+        "balance",
+        "tigerbeetle",
+        "oracle",
+        "conditional",
+        "transfers"
+      ],
+      "url": "https://docs.tigerbeetle.com/coding/recipes/balance-conditional-transfers"
+    },
+    {
+      "keywords": [
+        "tigerbeetle",
+        "account",
+        "oracle"
+      ],
+      "url": "https://docs.tigerbeetle.com/reference/account"
+    },
+    {
+      "keywords": [
+        "tigerbeetle",
+        "transfer",
+        "oracle"
+      ],
+      "url": "https://docs.tigerbeetle.com/reference/transfer"
+    },
+    {
+      "keywords": [
+        "substreams",
+        "packages",
+        "consumer",
+        "oracle"
+      ],
+      "url": "https://docs.substreams.dev/documentation/consume/packages"
+    },
+    {
+      "keywords": [
+        "substreams",
+        "deploy",
+        "service",
+        "oracle"
+      ],
+      "url": "https://docs.substreams.dev/documentation/consume/sql/deployable-services/local-service"
+    },
+    {
+      "keywords": [
+        "substreams",
+        "tutorial",
+        "cosmos",
+        "injective"
+      ],
+      "url": "https://docs.substreams.dev/tutorials/cosmos/injective/foundational"
+    },
+    {
+      "keywords": [
+        "worker",
+        "http",
+        "jwt"
+      ],
+      "url": "https://echo.labstack.com/docs/cookbook/jwt"
+    },
+    {
+      "keywords": [
+        "worker",
+        "http",
+        "secure"
+      ],
+      "url": "https://echo.labstack.com/docs/middleware/secure"
+    },
+    {
+      "keywords": [
+        "worker",
+        "http",
+        "service-workers",
+        "web",
+        "api"
+      ],
+      "url": "https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API"
+    },
+    {
+      "keywords": [
+        "synapse",
+        "matrix",
+        "configuration",
+        "usage"
+      ],
+      "url": "https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "protobuf",
+        "orm",
+        "sdk"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/packages/orm"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "sdk",
+        "modules",
+        "auth"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/modules/auth"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "sdk",
+        "modules",
+        "bank"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/modules/bank"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "modules",
+        "authz",
+        "sdk"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/modules/authz"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "protobuf",
+        "collections",
+        "sdk"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/packages/collections"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "modules",
+        "gov",
+        "sdk"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/modules/gov"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "modules",
+        "staking",
+        "sdk"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/modules/staking"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "protobuf",
+        "annotations",
+        "sdk"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/building-modules/protobuf-annotations"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "sdk",
+        "modules",
+        "group"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/modules/group"
+    },
+    {
+      "keywords": [
+        "cosmos",
+        "sdk",
+        "modules",
+        "nft"
+      ],
+      "url": "https://docs.cosmos.network/v0.50/build/modules/nft"
+    }
+  ],
+  "next-milestone": "34"
+}

.github/scripts/new_issue.sh

@@ -1,63 +0,0 @@
-#!/bin/bash
-
-set -e
-
-ROOT_DIR=$(git rev-parse --show-toplevel)
-
-# Extract scope name and path using jq, and pass it to fzf for selection
-SCOPE=$(cat "$ROOT_DIR/.github/scopes.json" | jq -r '.[] | "\(.name)"' | fzf --prompt "Select scope:")
-DOCS=$(cat "$ROOT_DIR/.github/scopes.json" | jq -r ".[] | select(.name == \"$SCOPE\") | .docs[].url")
-
-# Write Title
-TITLE=$(gum input --placeholder "Issue Title...")
-
-# Write Goal
-GOAL=$(mods --role "determine-issue-goal" "$SCOPE $TITLE")
-
-# Input Requirements
-REQUIREMENTS=()
-while true; do
-    if [ ${#REQUIREMENTS[@]} -ge 2 ]; then
-        if ! gum confirm "Do you want to add another requirement?"; then
-            break
-        fi
-    fi
-    REQUIREMENT=$(gum input --placeholder "Add a requirement...")
-    if [ -n "$REQUIREMENT" ]; then
-        REQUIREMENTS+=("$REQUIREMENT")
-    else
-        echo "Requirement cannot be empty. Please enter a valid requirement."
-    fi
-done
-
-create_body() {
-    echo "### Goal(s):"
-    echo "$GOAL"
-    echo "### Requirements:"
-    for i in "${!REQUIREMENTS[@]}"; do
-        echo "$(($i + 1)). ${REQUIREMENTS[$i]}"
-    done
-    echo "### Resources:"
-    while IFS= read -r doc; do
-        echo "- $doc"
-    done <<< "$DOCS"
-}
-
-ISSUE_BODY=$(create_body)
-
-# Function to collect output
-preview_output() {
-    echo "# ($SCOPE) $TITLE"
-    echo "$ISSUE_BODY"
-}
-
-# Display the formatted output
-preview_output | gum format
-
-# Confirm to create a GitHub issue
-if gum confirm "Do you want to create a new GitHub issue with this information?"; then
-    # Create a new GitHub issue using the gh CLI
-    gh issue create --repo onsonr/sonr --title "($SCOPE) $TITLE" --body "$ISSUE_BODY"
-else
-  exit 1
-fi

.github/scripts/upload_cdn.sh

@@ -1,39 +0,0 @@
-#!/usr/bin/env bash
-
-set -e
-
-ROOT_DIR=$(git rev-parse --show-toplevel)
-
-# Package the PKL projects
-bunx pkl project package $ROOT_DIR/pkl/*/
-
-# Process each directory in .out
-for dir in .out/*/; do
-    # Get the folder name and version
-    folder=$(basename "$dir")
-    version=$(echo "$folder" | grep -o '@.*' | sed 's/@//')
-    new_folder=$(echo "$folder" | sed 's/@[0-9.]*$//')
-    
-    # Create new directory without version
-    mkdir -p ".out/$new_folder/$version"
-    
-    # Copy contents to versioned subdirectory
-    cp -r "$dir"* ".out/$new_folder/$version/"
-    
-    # Find and copy only .pkl files from the original package
-    pkg_dir="$ROOT_DIR/pkl/$new_folder"
-    if [ -d "$pkg_dir" ]; then
-        # Copy only .pkl files to version directory
-        find "$pkg_dir" -name "*.pkl" -exec cp {} ".out/$new_folder/$version/" \;
-    fi
-    
-    # Remove old versioned directory
-    rm -rf "$dir"
-    
-    # Upload to R2 with new structure
-    rclone copy ".out/$new_folder" "r2:pkljar/$new_folder"
-done
-
-# Cleanup .out directory
-rm -rf .out
-

.github/workflows/checks.yml

@@ -0,0 +1,145 @@
+name: Perform Checks on PR
+
+on:
+  pull_request:
+  merge_group:
+
+jobs:
+  tidy-pr:
+    name: Tidy PR
+    if: github.event_name == 'pull_request'
+    permissions:
+      contents: read # for TimonVS/pr-labeler-action to read config file
+      pull-requests: write # for TimonVS/pr-labeler-action to add labels in PR
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0 # Required to fetch all history for merging
+          
+      - uses: TimonVS/pr-labeler-action@v5
+        with:
+          repo-token: ${{ secrets.GITHUB_TOKEN }}
+          configuration-path: .github/pr-labeler.yml # optional, .github/pr-labeler.yml is the default value
+
+
+  test-builds:
+    if: github.event_name == 'pull_request'
+    runs-on: ubuntu-latest
+    name: Run Build Tests
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          repository: onsonr/sonr
+          fetch-depth: 0
+          fetch-tags: true
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "1.23"
+          check-latest: true
+      - name: Run Sonrd Build
+        run: make build
+      - name: Run Hway Build
+        run: make build-hway
+      - name: Run Motr Build
+        run: make build-motr
+
+  test-unit:
+    if: github.event_name == 'pull_request'
+    runs-on: ubuntu-latest
+    name: Run Unit Tests
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          repository: onsonr/sonr
+          fetch-depth: 0
+          fetch-tags: true
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "1.23"
+          check-latest: true
+      - run: make test-unit
+
+  test-race:
+    runs-on: ubuntu-latest
+    if: github.event_name == 'merge_group'
+    name: Run Race Tests
+    continue-on-error: true
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          repository: onsonr/sonr
+          fetch-depth: 0
+          fetch-tags: true
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "1.23"
+          check-latest: true
+      - run: make test-race
+
+  test-cover:
+    runs-on: ubuntu-latest
+    if: github.event_name == 'merge_group'
+    name: Run Coverage Tests
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          repository: onsonr/sonr
+          fetch-depth: 0
+          fetch-tags: true
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "1.23"
+          check-latest: true
+      - run: make test-cover
+
+  validate-release:
+    if: github.event_name == 'merge_group'
+    runs-on: ubuntu-latest
+    name: Verify Release Config
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          repository: onsonr/sonr
+          fetch-depth: 0
+          fetch-tags: true
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "1.23"
+          check-latest: true
+
+      - name: Commitizen Dry Run
+        uses: commitizen-tools/commitizen-action@master
+        with:
+          push: false
+          dry_run: true
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          branch: main
+
+      - name: Check GoReleaser Config
+        uses: goreleaser/goreleaser-action@v6
+        with:
+          distribution: goreleaser
+          version: latest
+          args: check
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: GoReleaser Dry Run
+        uses: goreleaser/goreleaser-action@v6
+        with:
+          distribution: goreleaser
+          version: latest
+          args: release --snapshot --clean --skip=publish
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/deploy-net.yml

@@ -1,34 +0,0 @@
-name: Deploy Networks
-on:
-  workflow_dispatch:
-  push:
-    tags:
-      - "v*"
-    branches:
-      - develop
-
-permissions:
-  contents: write
-  issues: write
-
-jobs:
-  reboot-devnet:
-    name: Devnet Deploy
-    runs-on: goliath
-    environment: "Devnet"
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-          branch: develop
-
-      - name: Stop Existing Network
-        continue-on-error: true
-        run: |
-          make stop-uds
-          make clean
-
-      - name: Start Updated Network
-        run: |
-          make start-uds

.github/workflows/label-pr.yml

@@ -1,19 +0,0 @@
-name: PR Labeler
-on:
-  pull_request:
-    types: [opened]
-
-permissions:
-  contents: read
-
-jobs:
-  pr-labeler:
-    permissions:
-      contents: read # for TimonVS/pr-labeler-action to read config file
-      pull-requests: write # for TimonVS/pr-labeler-action to add labels in PR
-    runs-on: ubuntu-latest
-    steps:
-      - uses: TimonVS/pr-labeler-action@v5
-        with:
-          repo-token: ${{ secrets.GITHUB_TOKEN }}
-          configuration-path: .github/pr-labeler.yml # optional, .github/pr-labeler.yml is the default value

.github/workflows/make-docs.yml

@@ -1,33 +0,0 @@
-name: Publish Docs via GitHub Pages
-on:
-  push:
-    branches:
-      - main
-      - master
-      - develop
-    paths:
-      - "docs/**"
-
-permissions:
-  contents: write
-jobs:
-  deploy:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - name: Configure Git Credentials
-        run: |
-          git config user.name github-actions[bot]
-          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
-      - uses: actions/setup-python@v5
-        with:
-          python-version: 3.x
-      - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV
-      - uses: actions/cache@v4
-        with:
-          key: mkdocs-material-${{ env.cache_id }}
-          path: .cache
-          restore-keys: |
-            mkdocs-material-
-      - run: pip install mkdocs-material
-      - run: cd docs && mkdocs gh-deploy --force

.github/workflows/merge.yml

@@ -0,0 +1,32 @@
+name: Bump Version on Merge
+on:
+  pull_request:
+    types: [closed]
+
+permissions:
+  contents: write
+  issues: write
+
+jobs:
+  bump-version:
+    if: |
+      github.event.pull_request.merged == true && 
+      github.event.pull_request.user.login != 'dependabot[bot]' &&
+      github.event.pull_request.user.login != 'dependabot-preview[bot]'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out
+        uses: actions/checkout@v3
+        with:
+          fetch-depth: 0
+          ssh-key: "${{ secrets.COMMIT_KEY }}"
+
+      - name: Create bump and changelog
+        uses: commitizen-tools/commitizen-action@master
+        with:
+          push: false
+          increment: patch
+
+      - name: Push using ssh
+        run: |
+          git push origin main --tags

.github/workflows/publish.yml

@@ -1,20 +1,19 @@
-name: Publish Versioned Assets
+name: Publish Assets on Release
 on:
-  push:
-    branches:
-      - develop
+  release:
+    types: [published]
 
 permissions:
   contents: write
   issues: write
 
 jobs:
-  buf_push_core:
+  buf_push:
     name: Publish to buf.build/onsonr/sonr
     runs-on: ubuntu-latest
     steps:
       # Run `git checkout`
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       # Install the `buf` CLI
       - uses: bufbuild/buf-setup-action@v1
       # Push only the Input in `proto` to the BSR

.github/workflows/release.yml

@@ -1,16 +1,21 @@
 name: Versioned Release
 
 on:
+  pull_request:
+    types: [closed]
   push:
     tags:
-      - "v*"
+      - v*
+    branches:
+      - main
 
 permissions:
   contents: write
 
 jobs:
-  goreleaser:
-    name: Run GoReleaser
+  new-release:
+    name: Run GoReleaser on New Tag
+    if: startsWith(github.ref, 'refs/tags/')
     permissions: write-all
     runs-on: ubuntu-latest
     steps:
@@ -21,9 +26,6 @@ jobs:
           fetch-depth: 0
           fetch-tags: true
 
-      - name: Checkout Latest Tag
-        run: git checkout $(git describe --tags --abbrev=0)
-
       - uses: actions/setup-go@v5
         with:
           go-version: "1.23"
@@ -35,17 +37,22 @@ jobs:
           username: ${{ secrets.DOCKER_USERNAME }}
           password: ${{ secrets.DOCKER_PASSWORD }}
 
-      - name: Release
-        uses: goreleaser/goreleaser-action@v6
+      - name: Install Task
+        uses: arduino/setup-task@v2
         with:
-          distribution: goreleaser-pro
-          version: latest
-          args: release --clean
+          version: 3.x
+          repo-token: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Run GoReleaser
+        run: task release
         env:
           GITHUB_TOKEN: ${{ secrets.GH_RELEASER_TOKEN }}
-          GORELEASER_KEY: ${{ secrets.GORELEASER_KEY }}
           GITHUB_PERSONAL_AUTH_TOKEN: ${{ secrets.GH_RELEASER_TOKEN }}
           DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
           DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}
           TELEGRAM_TOKEN: ${{ secrets.TELEGRAM_TOKEN }}
-          CLOUDSMITH_TOKEN: ${{ secrets.CLOUDSMITH_TOKEN }}
+          REDDIT_APP_ID: ${{ secrets.REDDIT_APP_ID }}
+          REDDIT_SECRET: ${{ secrets.REDDIT_SECRET }}
+          REDDIT_USERNAME: ${{ secrets.REDDIT_USERNAME }}
+          REDDIT_PASSWORD: ${{ secrets.REDDIT_PASSWORD }}
+

.github/workflows/run-tests.yml

@@ -1,59 +0,0 @@
-name: Run Tests
-
-on:
-  pull_request:
-  merge_group:
-
-jobs:
-  test-unit:
-    runs-on: ubuntu-latest
-    name: Run Unit Tests
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          repository: onsonr/sonr
-          fetch-depth: 0
-          fetch-tags: true
-
-      - uses: actions/setup-go@v5
-        with:
-          go-version: "1.23"
-          check-latest: true
-      - run: make test-unit
-
-  test-race:
-    runs-on: ubuntu-latest
-    name: Run Race Tests
-    continue-on-error: true
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          repository: onsonr/sonr
-          fetch-depth: 0
-          fetch-tags: true
-
-      - uses: actions/setup-go@v5
-        with:
-          go-version: "1.23"
-          check-latest: true
-      - run: make test-race
-
-  test-cover:
-    runs-on: ubuntu-latest
-    name: Run Coverage Tests
-    continue-on-error: true
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          repository: onsonr/sonr
-          fetch-depth: 0
-          fetch-tags: true
-
-      - uses: actions/setup-go@v5
-        with:
-          go-version: "1.23"
-          check-latest: true
-      - run: make test-cover

.github/workflows/version-bump.yml

@@ -1,39 +0,0 @@
-name: Update Version
-
-on:
-  push:
-    branches:
-      - master
-
-permissions:
-  contents: write
-  pull-requests: write
-
-jobs:
-  run-tests:
-    name: "Run tests"
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-go@v5
-        with:
-          go-version: "1.23"
-          check-latest: true
-      - name: Run tests
-        run: make test
-
-  bump-version:
-    needs: [run-tests]
-    runs-on: ubuntu-latest
-    name: "Bump Version"
-    if: ${{ !startsWith(github.event.head_commit.message, 'bump:') }}
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
-          fetch-depth: 0
-      - name: Create bump and changelog
-        uses: commitizen-tools/commitizen-action@master
-        with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}
-          increment: "PATCH"

.gitignore

@@ -1,4 +1,6 @@
 # Binaries
+.task
+no
 .data
 schemas
 *.db
@@ -60,10 +62,7 @@ override.tf.json
 
 .terraformrc
 terraform.rc
-
-Taskfile.yml
-
-!deploy/**/Taskfile.yml
+flake.lock
 
 # Misc
 .DS_Store
@@ -89,6 +88,7 @@ buildenv*
 node_modules
 cmd/gateway/node_modules
 pkg/nebula/node_modules
+configs/logs.json
 
 mprocs.yaml
 build
@@ -98,4 +98,11 @@ sonr.wiki
 !buf.lock
 
 .air.toml
+mprocs.yaml
+mprocs.log
+tools-stamp
+sonr.log
+deploy/conf
 
+interchaintest-downloader
+.haptic

.goreleaser.yaml

@@ -3,11 +3,17 @@ version: 2
 project_name: sonr
 
 builds:
+  - id: motr
+    main: ./cmd/motr
+    binary: app
+    goos:
+      - js
+    goarch:
+      - wasm
+    
   - id: sonr
     main: ./cmd/sonrd
     binary: sonrd
-    builder: go
-    gobinary: go
     mod_timestamp: "{{ .CommitTimestamp }}"
     goos:
       - linux
@@ -33,8 +39,6 @@ builds:
   - id: hway
     main: ./cmd/hway
     binary: hway
-    builder: go
-    gobinary: go
     goos:
       - linux
       - darwin
@@ -57,8 +61,7 @@ archives:
   - id: sonr
     builds: [sonr]
     name_template: >-
-      sonr_{{ .Version }}_
-      {{- title .Os }}_{{- if eq .Arch "amd64" }}x86_64
+      sonr_{{ .Os }}_{{- if eq .Arch "amd64" }}x86_64
       {{- else if eq .Arch "386" }}i386
       {{- else }}{{ .Arch }}{{ end }}
     format: tar.gz
@@ -69,8 +72,7 @@ archives:
   - id: hway
     builds: [hway]
     name_template: >-
-      hway_{{ .Version }}_
-      {{- title .Os }}_{{- if eq .Arch "amd64" }}x86_64
+      hway_{{ .Os }}_{{- if eq .Arch "amd64" }}x86_64
       {{- else if eq .Arch "386" }}i386
       {{- else }}{{ .Arch }}{{ end }}
     format: tar.gz
@@ -81,7 +83,7 @@ archives:
 nfpms:
   - id: hway
     package_name: hway
-    file_name_template: "{{ .ConventionalFileName }}"
+    file_name_template: "hway_{{ .Os }}_{{ .Arch }}{{ .ConventionalExtension }}"
     builds: [hway]
     vendor: Sonr
     homepage: "https://onsonr.dev"
@@ -104,7 +106,7 @@ nfpms:
 
   - id: sonr
     package_name: sonrd
-    file_name_template: "{{ .ConventionalFileName }}"
+    file_name_template: "sonrd_{{ .Os }}_{{ .Arch }}{{ .ConventionalExtension }}"
     builds: [sonr]
     vendor: Sonr
     homepage: "https://onsonr.dev"
@@ -164,12 +166,15 @@ release:
   github:
     owner: onsonr
     name: sonr
-  name_template: "Release {{.Version}}"
+  name_template: 'Release {{ .Env.RELEASE_DATE }}'
   draft: false
   replace_existing_draft: true
   replace_existing_artifacts: true
   extra_files:
     - glob: ./README*
+    - glob: ./scripts/install.sh
+    - glob: ./scripts/test_node.sh
+    - glob: ./scripts/test_ics_node.sh
 
 announce:
   telegram:

CHANGELOG.md

@@ -1,3 +1,48 @@
+## v0.6.0 (2024-12-24)
+
+### Feat
+
+- Add option to create draft issues from the new-issue script
+
+### Refactor
+
+- rename DID, DWN, and SVC modules to core-dids, core-dwns, and core-svcs respectively
+- rename MsgInitialize to MsgSpawn for clarity
+- rename scopes in .github/scopes.json for better clarity
+
+## v0.5.28 (2024-12-22)
+
+### Fix
+
+- Sink
+
+### Refactor
+
+- update testnet configuration
+- optimize GitHub Actions workflow triggers (#1204)
+- Move embed
+
+## v0.5.27 (2024-12-16)
+
+## v0.5.26 (2024-12-13)
+
+## v0.5.25 (2024-12-11)
+
+### Feat
+
+- enable GoReleaser releases on tags and snapshots
+- automate release on tag and workflow dispatch
+
+### Fix
+
+- Correct regular expression for version tags in release workflow
+
+## v0.5.24 (2024-12-11)
+
+### Feat
+
+- prevent duplicate releases
+
 ## v0.5.23 (2024-12-11)
 
 ### Refactor
@@ -10,11 +55,6 @@
 ### Feat
 
 - Implement passkey-based authentication and registration flow
-
-## v0.5.21 (2024-12-11)
-
-### Feat
-
 - allow manual triggering of deployment workflow
 - add start-tui command for interactive mode
 - add coin selection and update passkey input in registration form
@@ -177,7 +217,6 @@
 
 - update file paths in error messages
 - update intro video modal script
-- include assets generation in wasm build
 
 ### Refactor
 
@@ -191,6 +230,10 @@
 
 ## v0.5.16 (2024-10-21)
 
+### Fix
+
+- include assets generation in wasm build
+
 ## v0.5.15 (2024-10-21)
 
 ## v0.5.14 (2024-10-21)
@@ -324,7 +367,6 @@
 - update issue templates for better clarity
 - add issue templates for tracking and task issues
 - add issue templates for bug report and tracking
-- introduce docker-compose based setup
 
 ### Refactor
 
@@ -335,6 +377,7 @@
 
 ### Feat
 
+- introduce docker-compose based setup
 - add hway and sonr processes to dev environment
 
 ## v0.5.5 (2024-10-03)
@@ -383,14 +426,6 @@
 
 ## v0.4.5 (2024-10-02)
 
-### Fix
-
-- use correct secret for docker login
-
-## v0.4.4 (2024-10-02)
-
-## v0.4.3 (2024-10-02)
-
 ### Feat
 
 - **release**: add docker images for sonrd and motr
@@ -402,6 +437,7 @@
 
 ### Fix
 
+- use correct secret for docker login
 - **layout**: add missing favicon
 - **hero**: Use hx-swap for primary button to prevent flicker
 
@@ -430,9 +466,6 @@
 - add DWN resolver field
 - add stats section to homepage
 - implement hero section using Pkl
-- add PKL schema for message formats
-- add Homebrew tap for sonr
-- update release workflow to use latest tag
 
 ### Fix
 
@@ -442,7 +475,7 @@
 - **cta**: Fix typo in CTA title
 - change bento section title to reflect security focus
 - adjust hero image dimensions
-- **Input**: Change type from to
+- **Input**: Change  type from  to
 - update hero image height in config.pkl
 
 ### Refactor
@@ -451,13 +484,14 @@
 - rename motrd to motr
 - update hero image dimensions
 - move nebula configuration to static file
-- rename buf-publish.yml to publish-assets.yml
-- remove unused field from
 
 ## v0.4.0 (2024-09-30)
 
 ### Feat
 
+- add PKL schema for message formats
+- add Homebrew tap for sonr
+- update release workflow to use latest tag
 - **dwn**: add wasm build for dwn
 - add macaroon and oracle genesis states
 - add scheduled binary release workflow
@@ -472,6 +506,8 @@
 ### Refactor
 
 - remove old changelog entries
+- rename buf-publish.yml to publish-assets.yml
+- remove unused  field from
 - remove unnecessary checkout in scheduled-release workflow
 - rename build ID to sonr
 - remove unnecessary release existence check
@@ -590,7 +626,7 @@
 - extract root command creation to separate file
 - move ipfs setup to function
 - remove unnecessary proxy config
-- rename script to
+- rename  script to
 - move DWN proxy server logic to separate file
 - use htmx instead of dwn for vault client
 - remove unused environment variables
@@ -598,7 +634,7 @@
 - use staking keeper in DID keeper
 - remove unused dependencies
 - remove unused image building workflow
-- add field to
+- add  field to
 - Update KeyKind Enum to have proper naming conventions
 - Update `DIDNamespace` to have proper naming convention
 - expose ports directly in docker-compose

Dockerfile

@@ -1,40 +1,3 @@
-FROM jetpackio/devbox:latest AS sonrvm
-
-# Installing your devbox project
-WORKDIR /code
-USER root:root
-
-RUN mkdir -p /code && chown ${DEVBOX_USER}:${DEVBOX_USER} /code
-
-USER ${DEVBOX_USER}:${DEVBOX_USER}
-
-COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.json devbox.json
-COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} process-compose.yaml process-compose.yaml
-
-RUN devbox run -- echo "Installed Packages."
-
-ENTRYPOINT ["devbox", "run"]
-
-# --------------------------------------------------------
-FROM jetpackio/devbox:latest AS sonr-runner
-
-WORKDIR /code
-USER root:root
-
-RUN mkdir -p /code && chown ${DEVBOX_USER}:${DEVBOX_USER} /code
-
-USER ${DEVBOX_USER}:${DEVBOX_USER}
-
-COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.json devbox.json
-COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} process-compose.yaml process-compose.yaml
-COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} . .
-
-RUN devbox run -- echo "Installed Packages."
-
-RUN git config --global --add safe.directory /code
-ENTRYPOINT ["devbox", "run", "testnet"]
-
-# --------------------------------------------------------
 FROM golang:1.22-alpine AS go-builder
 
 SHELL ["/bin/sh", "-ecuxo", "pipefail"]

Makefile

@@ -75,8 +75,6 @@ ldflags := $(strip $(ldflags))
 BUILD_FLAGS := -tags "$(build_tags_comma_sep)" -ldflags '$(ldflags)' -trimpath
 
 # The below include contains the tools and runsim targets.
-include contrib/devtools/Makefile
-
 all: install lint test
 
 build: go.sum
@@ -87,6 +85,12 @@ else
 	go build -mod=readonly $(BUILD_FLAGS) -o build/sonrd ./cmd/sonrd
 endif
 
+build-motr: go.sum
+	GOOS=js GOARCH=wasm go build -o static/wasm/app.wasm ./cmd/motr/main.go
+
+build-hway: go.sum
+	go build -o build/hway ./cmd/hway
+
 build-windows-client: go.sum
 	GOOS=windows GOARCH=amd64 go build -mod=readonly $(BUILD_FLAGS) -o build/sonrd.exe ./cmd/sonrd
 
@@ -100,6 +104,9 @@ endif
 install: go.sum
 	go install -mod=readonly $(BUILD_FLAGS) ./cmd/sonrd
 
+install-hway: go.sum
+	go install -mod=readonly ./cmd/hway
+
 ########################################
 ### Tools & dependencies
 
@@ -184,7 +191,6 @@ format: format-tools
 
 mod-tidy:
 	go mod tidy
-	cd interchaintest && go mod tidy
 
 .PHONY: format-tools lint format mod-tidy
 
@@ -302,71 +308,12 @@ testnet-basic: setup-testnet
 sh-testnet: mod-tidy
 	CHAIN_ID="sonr-testnet-1" BLOCK_TIME="1000ms" CLEAN=true sh scripts/test_node.sh
 
-.PHONY: setup-testnet set-testnet-configs testnet testnet-basic sh-testnet
+.PHONY: setup-testnet set-testnet-configs testnet testnet-basic sh-testnet dop-testnet
 
-###############################################################################
-###                                generation                               ###
-###############################################################################
-.PHONY: gen-pkl gen-templ
-
-gen-pkl: init-env
-	pkl-gen-go pkl/sonr.orm/UCAN.pkl
-	pkl-gen-go pkl/sonr.orm/Models.pkl
-	pkl-gen-go pkl/sonr.conf/Hway.pkl
-	pkl-gen-go pkl/sonr.conf/Motr.pkl
-
-gen-templ: init-env
-	templ generate
-
-
-###############################################################################
-###                             custom builds                               ###
-###############################################################################
-.PHONY: build-motr build-hway logs-hway logs-sonr
-
-build-motr:
-	GOOS=js GOARCH=wasm go build -o static/wasm/app.wasm ./cmd/motr/main.go
-
-build-hway: gen-templ
-	go build -o build/hway ./cmd/hway
-
-logs-hway: init-env
-	bin/process-compose process logs hway --port $(PC_PORT_NUM) --follow
-
-logs-sonr: init-env
-	bin/process-compose process logs sonr --port $(PC_PORT_NUM) --follow
-
-###############################################################################
-###                           Network Start/Stop                            ###
-###############################################################################
-
-.PHONY: deploy start start-tui start-uds stop stop-uds restart status
-
-start: build-hway init-env
-	bin/process-compose up --port $(PC_PORT_NUM) --log-file $(PC_LOG_FILE) --detached -f deploy/process-compose.yaml
-
-start-tui: build-hway init-env
-	bin/process-compose up --port $(PC_PORT_NUM) --log-file $(PC_LOG_FILE) -f deploy/process-compose.yaml
-
-start-uds: build-hway init-env
-	bin/process-compose up --use-uds --unix-socket $(PC_SOCKET_PATH) --log-file $(PC_LOG_FILE) --detached -f deploy/process-compose.yaml
-
-stop: init-env
-	bin/process-compose down --port $(PC_PORT_NUM)
-
-stop-uds: init-env
-	bin/process-compose down --use-uds --unix-socket $(PC_SOCKET_PATH)
-
-status: init-env
-	bin/process-compose project state --port $(PC_PORT_NUM)
 ###############################################################################
 ###                                     help                                ###
 ###############################################################################
 
-deploy: 
-	cd ./proto && bunx buf dep update && bunx buf build && bunx buf push
-	sh ./.github/scripts/upload_cdn.sh
-
 help:
 	@echo "Usage: make <target>"
 	@echo ""
@@ -378,7 +325,5 @@ help:
 	@echo "  sh-testnet          : Shell local devnet"
 	@echo "  ictest-basic        : Basic end-to-end test"
 	@echo "  ictest-ibc          : IBC end-to-end test"
-	@echo "  templ               : Generate templ files"
-	@echo "  vault               : Build vault.wasm"
 
 .PHONY: help

README.md

@@ -6,7 +6,6 @@
 [![Static Badge](https://img.shields.io/badge/homepage-sonr.io-blue?style=flat-square)](https://sonr.io)
 [![Go Report Card](https://goreportcard.com/badge/github.com/onsonr/sonr)](https://goreportcard.com/report/github.com/onsonr/sonr)
 [![Security Rating](https://sonarcloud.io/api/project_badges/measure?project=sonrhq_sonr&metric=security_rating)](https://sonarcloud.io/summary/new_code?id=sonr-io_sonr)
-[![Latest version of 'sonrd' @ Cloudsmith](https://api-prd.cloudsmith.io/v1/badges/version/sonr/sonr/deb/sonrd/latest/a=amd64;xc=main;d=ubuntu%252Fxenial;t=binary/?render=true&show_latest=true)](https://cloudsmith.io/~sonr/repos/sonr/packages/detail/deb/sonrd/latest/a=amd64;xc=main;d=ubuntu%252Fxenial;t=binary/)
 
 > Sonr is a combination of decentralized primitives. Fundamentally, it is a peer-to-peer identity and asset management system that leverages DID documents, Webauthn, and IPFS—providing users with a secure, portable decentralized identity.
 
@@ -38,4 +37,3 @@ Sonr would not have been possible without the direct and indirect support of the
 - [Forum](https://github.com/onsonr/sonr/discussions)
 - [Issues](https://github.com/onsonr/sonr/issues)
 - [Twitter](https://sonr.io/twitter)
-- [Dev Chat](https://sonr.io/discord)

Taskfile.yml

@@ -0,0 +1,73 @@
+version: "3"
+
+vars:
+  VERSION:
+    sh: git describe --tags --abbrev=0
+  COMMIT:
+    sh: git rev-parse --short HEAD
+  ROOT:
+    sh: git rev-parse --show-toplevel
+  OS:
+    sh: uname -s
+  # DOPPLER_TOKEN:
+    # sh: skate get DOPPLER_NETWORK
+
+# includes:
+#   deps: https://raw.githubusercontent.com/onsonr/taskfiles/main/taskfiles/deps.yml
+#   gen: https://raw.githubusercontent.com/onsonr/taskfiles/main/taskfiles/gen.yml
+#   hway: https://raw.githubusercontent.com/onsonr/taskfiles/main/taskfiles/hway.yml
+#   ipfs: https://raw.githubusercontent.com/onsonr/taskfiles/main/taskfiles/ipfs.yml
+#   issue: https://raw.githubusercontent.com/onsonr/taskfiles/main/taskfiles/ghpm.yml
+#   procs: https://raw.githubusercontent.com/onsonr/taskfiles/main/taskfiles/procs.yml
+#   postgres: https://raw.githubusercontent.com/onsonr/taskfiles/main/taskfiles/postgres.yml
+#   sonrd: https://raw.githubusercontent.com/onsonr/taskfiles/main/taskfiles/sonrd.yml
+#
+tasks:
+  default:
+    cmds:
+      - gh run ls -L 3
+      - gum format -- "# Sonr ({{.OS}}-{{.VERSION}})" " - ({{.COMMIT}}) {{.ROOT}}"
+      - task -l -j | jq -r '.tasks[].name' | fzf --height=16 | xargs task
+    silent: true
+
+  # start:
+  #   desc: Start the Network
+  #   silent: true
+  #   cmds:
+  #     - task: postgres:reset
+  #     - task: ipfs:init
+  #     - task: ipfs:mount
+  #     - task: sonrd:install
+  #     - task: hway:build
+  #     - task: procs:up
+  #
+  # status:
+  #   desc: Check the status of the Network
+  #   silent: true
+  #   cmds:
+  #     - task: procs:attach
+  #
+  # stop:
+  #   desc: Stop the Network
+  #   silent: true
+  #   cmds:
+  #     - task: procs:down
+  date:
+    desc: Returns date in YEAR.WEEK.DAY format
+    cmds:
+      - |
+        YEAR=$(date +%Y)
+        WEEK=$(date +%V)
+        DAY=$(date +%u)
+        echo "${YEAR}.${WEEK}.${DAY}"
+    vars:
+      DATE: '{{default "" .CLI_ARGS}}'
+    silent: true
+ 
+  release:
+    desc: Create a new release with formatted date
+    cmds:
+      - go install github.com/goreleaser/goreleaser/v2@latest
+      - RELEASE_DATE=$(task date) goreleaser release --clean
+    silent: true
+

api/dwn/v1/query_grpc.pb.go

@@ -19,10 +19,7 @@ import (
 const _ = grpc.SupportPackageIsVersion9
 
 const (
-	Query_Params_FullMethodName   = "/dwn.v1.Query/Params"
-	Query_Schema_FullMethodName   = "/dwn.v1.Query/Schema"
-	Query_Allocate_FullMethodName = "/dwn.v1.Query/Allocate"
-	Query_Sync_FullMethodName     = "/dwn.v1.Query/Sync"
+	Query_Params_FullMethodName = "/dwn.v1.Query/Params"
 )
 
 // QueryClient is the client API for Query service.
@@ -33,15 +30,6 @@ const (
 type QueryClient interface {
 	// Params queries all parameters of the module.
 	Params(ctx context.Context, in *QueryParamsRequest, opts ...grpc.CallOption) (*QueryParamsResponse, error)
-	// Schema queries the DID document by its id. And returns the required PKL
-	// information
-	Schema(ctx context.Context, in *QuerySchemaRequest, opts ...grpc.CallOption) (*QuerySchemaResponse, error)
-	// Allocate initializes a Target Vault available for claims with a compatible
-	// Authentication mechanism. The default authentication mechanism is WebAuthn.
-	Allocate(ctx context.Context, in *QueryAllocateRequest, opts ...grpc.CallOption) (*QueryAllocateResponse, error)
-	// Sync queries the DID document by its id. And returns the required PKL
-	// information
-	Sync(ctx context.Context, in *QuerySyncRequest, opts ...grpc.CallOption) (*QuerySyncResponse, error)
 }
 
 type queryClient struct {
@@ -62,36 +50,6 @@ func (c *queryClient) Params(ctx context.Context, in *QueryParamsRequest, opts .
 	return out, nil
 }
 
-func (c *queryClient) Schema(ctx context.Context, in *QuerySchemaRequest, opts ...grpc.CallOption) (*QuerySchemaResponse, error) {
-	cOpts := append([]grpc.CallOption{grpc.StaticMethod()}, opts...)
-	out := new(QuerySchemaResponse)
-	err := c.cc.Invoke(ctx, Query_Schema_FullMethodName, in, out, cOpts...)
-	if err != nil {
-		return nil, err
-	}
-	return out, nil
-}
-
-func (c *queryClient) Allocate(ctx context.Context, in *QueryAllocateRequest, opts ...grpc.CallOption) (*QueryAllocateResponse, error) {
-	cOpts := append([]grpc.CallOption{grpc.StaticMethod()}, opts...)
-	out := new(QueryAllocateResponse)
-	err := c.cc.Invoke(ctx, Query_Allocate_FullMethodName, in, out, cOpts...)
-	if err != nil {
-		return nil, err
-	}
-	return out, nil
-}
-
-func (c *queryClient) Sync(ctx context.Context, in *QuerySyncRequest, opts ...grpc.CallOption) (*QuerySyncResponse, error) {
-	cOpts := append([]grpc.CallOption{grpc.StaticMethod()}, opts...)
-	out := new(QuerySyncResponse)
-	err := c.cc.Invoke(ctx, Query_Sync_FullMethodName, in, out, cOpts...)
-	if err != nil {
-		return nil, err
-	}
-	return out, nil
-}
-
 // QueryServer is the server API for Query service.
 // All implementations must embed UnimplementedQueryServer
 // for forward compatibility.
@@ -100,15 +58,6 @@ func (c *queryClient) Sync(ctx context.Context, in *QuerySyncRequest, opts ...gr
 type QueryServer interface {
 	// Params queries all parameters of the module.
 	Params(context.Context, *QueryParamsRequest) (*QueryParamsResponse, error)
-	// Schema queries the DID document by its id. And returns the required PKL
-	// information
-	Schema(context.Context, *QuerySchemaRequest) (*QuerySchemaResponse, error)
-	// Allocate initializes a Target Vault available for claims with a compatible
-	// Authentication mechanism. The default authentication mechanism is WebAuthn.
-	Allocate(context.Context, *QueryAllocateRequest) (*QueryAllocateResponse, error)
-	// Sync queries the DID document by its id. And returns the required PKL
-	// information
-	Sync(context.Context, *QuerySyncRequest) (*QuerySyncResponse, error)
 	mustEmbedUnimplementedQueryServer()
 }
 
@@ -122,15 +71,6 @@ type UnimplementedQueryServer struct{}
 func (UnimplementedQueryServer) Params(context.Context, *QueryParamsRequest) (*QueryParamsResponse, error) {
 	return nil, status.Errorf(codes.Unimplemented, "method Params not implemented")
 }
-func (UnimplementedQueryServer) Schema(context.Context, *QuerySchemaRequest) (*QuerySchemaResponse, error) {
-	return nil, status.Errorf(codes.Unimplemented, "method Schema not implemented")
-}
-func (UnimplementedQueryServer) Allocate(context.Context, *QueryAllocateRequest) (*QueryAllocateResponse, error) {
-	return nil, status.Errorf(codes.Unimplemented, "method Allocate not implemented")
-}
-func (UnimplementedQueryServer) Sync(context.Context, *QuerySyncRequest) (*QuerySyncResponse, error) {
-	return nil, status.Errorf(codes.Unimplemented, "method Sync not implemented")
-}
 func (UnimplementedQueryServer) mustEmbedUnimplementedQueryServer() {}
 func (UnimplementedQueryServer) testEmbeddedByValue()               {}
 
@@ -170,60 +110,6 @@ func _Query_Params_Handler(srv interface{}, ctx context.Context, dec func(interf
 	return interceptor(ctx, in, info, handler)
 }
 
-func _Query_Schema_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
-	in := new(QuerySchemaRequest)
-	if err := dec(in); err != nil {
-		return nil, err
-	}
-	if interceptor == nil {
-		return srv.(QueryServer).Schema(ctx, in)
-	}
-	info := &grpc.UnaryServerInfo{
-		Server:     srv,
-		FullMethod: Query_Schema_FullMethodName,
-	}
-	handler := func(ctx context.Context, req interface{}) (interface{}, error) {
-		return srv.(QueryServer).Schema(ctx, req.(*QuerySchemaRequest))
-	}
-	return interceptor(ctx, in, info, handler)
-}
-
-func _Query_Allocate_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
-	in := new(QueryAllocateRequest)
-	if err := dec(in); err != nil {
-		return nil, err
-	}
-	if interceptor == nil {
-		return srv.(QueryServer).Allocate(ctx, in)
-	}
-	info := &grpc.UnaryServerInfo{
-		Server:     srv,
-		FullMethod: Query_Allocate_FullMethodName,
-	}
-	handler := func(ctx context.Context, req interface{}) (interface{}, error) {
-		return srv.(QueryServer).Allocate(ctx, req.(*QueryAllocateRequest))
-	}
-	return interceptor(ctx, in, info, handler)
-}
-
-func _Query_Sync_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
-	in := new(QuerySyncRequest)
-	if err := dec(in); err != nil {
-		return nil, err
-	}
-	if interceptor == nil {
-		return srv.(QueryServer).Sync(ctx, in)
-	}
-	info := &grpc.UnaryServerInfo{
-		Server:     srv,
-		FullMethod: Query_Sync_FullMethodName,
-	}
-	handler := func(ctx context.Context, req interface{}) (interface{}, error) {
-		return srv.(QueryServer).Sync(ctx, req.(*QuerySyncRequest))
-	}
-	return interceptor(ctx, in, info, handler)
-}
-
 // Query_ServiceDesc is the grpc.ServiceDesc for Query service.
 // It's only intended for direct use with grpc.RegisterService,
 // and not to be introspected or modified (even as a copy)
@@ -235,18 +121,6 @@ var Query_ServiceDesc = grpc.ServiceDesc{
 			MethodName: "Params",
 			Handler:    _Query_Params_Handler,
 		},
-		{
-			MethodName: "Schema",
-			Handler:    _Query_Schema_Handler,
-		},
-		{
-			MethodName: "Allocate",
-			Handler:    _Query_Allocate_Handler,
-		},
-		{
-			MethodName: "Sync",
-			Handler:    _Query_Sync_Handler,
-		},
 	},
 	Streams:  []grpc.StreamDesc{},
 	Metadata: "dwn/v1/query.proto",

api/dwn/v1/tx.pulsar.go

@@ -1818,7 +1818,7 @@ func (*MsgUpdateParamsResponse) Descriptor() ([]byte, []int) {
 	return file_dwn_v1_tx_proto_rawDescGZIP(), []int{1}
 }
 
-// MsgInitialize spawns a New Vault with Unclaimed State. This is a one-time
+// MsgSpawn spawns a New Vault with Unclaimed State. This is a one-time
 // operation that must be performed interacting with the Vault.
 //
 // Since: cosmos-sdk 0.47
@@ -1869,8 +1869,8 @@ func (x *MsgInitialize) GetParams() *Params {
 	return nil
 }
 
-// MsgInitializeResponse defines the response structure for executing a
-// MsgInitialize message.
+// MsgSpawnResponse defines the response structure for executing a
+// MsgSpawn message.
 //
 // Since: cosmos-sdk 0.47
 type MsgInitializeResponse struct {

api/dwn/v1/tx_grpc.pb.go

@@ -33,7 +33,7 @@ type MsgClient interface {
 	//
 	// Since: cosmos-sdk 0.47
 	UpdateParams(ctx context.Context, in *MsgUpdateParams, opts ...grpc.CallOption) (*MsgUpdateParamsResponse, error)
-	// Initialize spawns a new Vault
+	// Spawn spawns a new Vault
 	Initialize(ctx context.Context, in *MsgInitialize, opts ...grpc.CallOption) (*MsgInitializeResponse, error)
 }
 
@@ -75,7 +75,7 @@ type MsgServer interface {
 	//
 	// Since: cosmos-sdk 0.47
 	UpdateParams(context.Context, *MsgUpdateParams) (*MsgUpdateParamsResponse, error)
-	// Initialize spawns a new Vault
+	// Spawn spawns a new Vault
 	Initialize(context.Context, *MsgInitialize) (*MsgInitializeResponse, error)
 	mustEmbedUnimplementedMsgServer()
 }

api/svc/v1/query_grpc.pb.go

@@ -19,7 +19,9 @@ import (
 const _ = grpc.SupportPackageIsVersion9
 
 const (
-	Query_Params_FullMethodName = "/svc.v1.Query/Params"
+	Query_Params_FullMethodName        = "/svc.v1.Query/Params"
+	Query_OriginExists_FullMethodName  = "/svc.v1.Query/OriginExists"
+	Query_ResolveOrigin_FullMethodName = "/svc.v1.Query/ResolveOrigin"
 )
 
 // QueryClient is the client API for Query service.
@@ -30,6 +32,10 @@ const (
 type QueryClient interface {
 	// Params queries all parameters of the module.
 	Params(ctx context.Context, in *QueryParamsRequest, opts ...grpc.CallOption) (*QueryParamsResponse, error)
+	// OriginExists queries if a given origin exists.
+	OriginExists(ctx context.Context, in *QueryOriginExistsRequest, opts ...grpc.CallOption) (*QueryOriginExistsResponse, error)
+	// ResolveOrigin queries the domain of a given service and returns its record with capabilities.
+	ResolveOrigin(ctx context.Context, in *QueryResolveOriginRequest, opts ...grpc.CallOption) (*QueryResolveOriginResponse, error)
 }
 
 type queryClient struct {
@@ -50,6 +56,26 @@ func (c *queryClient) Params(ctx context.Context, in *QueryParamsRequest, opts .
 	return out, nil
 }
 
+func (c *queryClient) OriginExists(ctx context.Context, in *QueryOriginExistsRequest, opts ...grpc.CallOption) (*QueryOriginExistsResponse, error) {
+	cOpts := append([]grpc.CallOption{grpc.StaticMethod()}, opts...)
+	out := new(QueryOriginExistsResponse)
+	err := c.cc.Invoke(ctx, Query_OriginExists_FullMethodName, in, out, cOpts...)
+	if err != nil {
+		return nil, err
+	}
+	return out, nil
+}
+
+func (c *queryClient) ResolveOrigin(ctx context.Context, in *QueryResolveOriginRequest, opts ...grpc.CallOption) (*QueryResolveOriginResponse, error) {
+	cOpts := append([]grpc.CallOption{grpc.StaticMethod()}, opts...)
+	out := new(QueryResolveOriginResponse)
+	err := c.cc.Invoke(ctx, Query_ResolveOrigin_FullMethodName, in, out, cOpts...)
+	if err != nil {
+		return nil, err
+	}
+	return out, nil
+}
+
 // QueryServer is the server API for Query service.
 // All implementations must embed UnimplementedQueryServer
 // for forward compatibility.
@@ -58,6 +84,10 @@ func (c *queryClient) Params(ctx context.Context, in *QueryParamsRequest, opts .
 type QueryServer interface {
 	// Params queries all parameters of the module.
 	Params(context.Context, *QueryParamsRequest) (*QueryParamsResponse, error)
+	// OriginExists queries if a given origin exists.
+	OriginExists(context.Context, *QueryOriginExistsRequest) (*QueryOriginExistsResponse, error)
+	// ResolveOrigin queries the domain of a given service and returns its record with capabilities.
+	ResolveOrigin(context.Context, *QueryResolveOriginRequest) (*QueryResolveOriginResponse, error)
 	mustEmbedUnimplementedQueryServer()
 }
 
@@ -71,6 +101,12 @@ type UnimplementedQueryServer struct{}
 func (UnimplementedQueryServer) Params(context.Context, *QueryParamsRequest) (*QueryParamsResponse, error) {
 	return nil, status.Errorf(codes.Unimplemented, "method Params not implemented")
 }
+func (UnimplementedQueryServer) OriginExists(context.Context, *QueryOriginExistsRequest) (*QueryOriginExistsResponse, error) {
+	return nil, status.Errorf(codes.Unimplemented, "method OriginExists not implemented")
+}
+func (UnimplementedQueryServer) ResolveOrigin(context.Context, *QueryResolveOriginRequest) (*QueryResolveOriginResponse, error) {
+	return nil, status.Errorf(codes.Unimplemented, "method ResolveOrigin not implemented")
+}
 func (UnimplementedQueryServer) mustEmbedUnimplementedQueryServer() {}
 func (UnimplementedQueryServer) testEmbeddedByValue()               {}
 
@@ -110,6 +146,42 @@ func _Query_Params_Handler(srv interface{}, ctx context.Context, dec func(interf
 	return interceptor(ctx, in, info, handler)
 }
 
+func _Query_OriginExists_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
+	in := new(QueryOriginExistsRequest)
+	if err := dec(in); err != nil {
+		return nil, err
+	}
+	if interceptor == nil {
+		return srv.(QueryServer).OriginExists(ctx, in)
+	}
+	info := &grpc.UnaryServerInfo{
+		Server:     srv,
+		FullMethod: Query_OriginExists_FullMethodName,
+	}
+	handler := func(ctx context.Context, req interface{}) (interface{}, error) {
+		return srv.(QueryServer).OriginExists(ctx, req.(*QueryOriginExistsRequest))
+	}
+	return interceptor(ctx, in, info, handler)
+}
+
+func _Query_ResolveOrigin_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
+	in := new(QueryResolveOriginRequest)
+	if err := dec(in); err != nil {
+		return nil, err
+	}
+	if interceptor == nil {
+		return srv.(QueryServer).ResolveOrigin(ctx, in)
+	}
+	info := &grpc.UnaryServerInfo{
+		Server:     srv,
+		FullMethod: Query_ResolveOrigin_FullMethodName,
+	}
+	handler := func(ctx context.Context, req interface{}) (interface{}, error) {
+		return srv.(QueryServer).ResolveOrigin(ctx, req.(*QueryResolveOriginRequest))
+	}
+	return interceptor(ctx, in, info, handler)
+}
+
 // Query_ServiceDesc is the grpc.ServiceDesc for Query service.
 // It's only intended for direct use with grpc.RegisterService,
 // and not to be introspected or modified (even as a copy)
@@ -121,6 +193,14 @@ var Query_ServiceDesc = grpc.ServiceDesc{
 			MethodName: "Params",
 			Handler:    _Query_Params_Handler,
 		},
+		{
+			MethodName: "OriginExists",
+			Handler:    _Query_OriginExists_Handler,
+		},
+		{
+			MethodName: "ResolveOrigin",
+			Handler:    _Query_ResolveOrigin_Handler,
+		},
 	},
 	Streams:  []grpc.StreamDesc{},
 	Metadata: "svc/v1/query.proto",

chains/README.md

@@ -1,10 +0,0 @@
-# Local Interchain Configurations
-
-RUN:
-- `make testnet` *(full setup: docker image, binary, keys, and ibc testnet start)*
-- `spawn local-ic start testnet` *(Standalone start)*
-
-## Documentation
-
-* https://github.com/strangelove-ventures/interchaintest/tree/main/local-interchain
-

chains/ibc-testnet.json

@@ -1,103 +0,0 @@
-{
-    "chains": [
-        {
-            "name": "core",
-            "ibc_paths": ["ibc-connection-1"],
-            "chain_id": "chainid-1",
-            "denom": "usnr",
-            "binary": "sonrd",
-            "bech32_prefix": "idx",
-            "docker_image": {
-                "repository": "core",
-                "version": "local"
-            },
-            "gas_prices": "0usnr",
-            "chain_type": "cosmos",
-            "coin_type": 118,
-            "trusting_period": "336h",
-            "gas_adjustment": 1.5,
-            "number_vals": 1,
-            "number_node": 0,
-            "debugging": true,
-            "block_time": "1000ms",
-            "host_port_override": {
-                "26657": "26657",
-                "1317": "1317",
-                "9090": "9090"
-            },
-            "encoding-options": ["wasm", "tokenfactory"],
-            "config_file_overrides": [
-                {
-                    "file": "config/config.toml",
-                    "paths": {
-                        "moniker": "localvalmoniker",
-                        "rpc.cors_allowed_origins": ["*"]
-                    }
-                }
-            ],
-            "genesis": {
-                "modify": [
-                    {
-                        "key": "app_state.gov.params.voting_period",
-                        "value": "15s"
-                    },
-                    {
-                        "key": "app_state.gov.params.expedited_voting_period",
-                        "value": "10s"
-                    },
-                    {
-                        "key": "app_state.gov.params.max_deposit_period",
-                        "value": "15s"
-                    },
-                    {
-                        "key": "app_state.gov.params.min_deposit.0.denom",
-                        "value": "usnr"
-                    },
-                    {
-                        "key": "app_state.gov.params.min_deposit.0.amount",
-                        "value": "1"
-                    }
-                ],
-                "accounts": [
-                    {
-                        "name": "acc0",
-                        "address": "idx1hj5fveer5cjtn4wd6wstzugjfdxzl0xpecp0nd",
-                        "amount": "10000000000usnr",
-                        "mnemonic": "decorate bright ozone fork gallery riot bus exhaust worth way bone indoor calm squirrel merry zero scheme cotton until shop any excess stage laundry"
-                    },
-                    {
-                        "name": "acc1",
-                        "address": "idx1efd63aw40lxf3n4mhf7dzhjkr453axur9vjt6y",
-                        "amount": "10000000000usnr",
-                        "mnemonic": "wealth flavor believe regret funny network recall kiss grape useless pepper cram hint member few certain unveil rather brick bargain curious require crowd raise"
-                    }
-                ],
-                "startup_commands": []
-            }
-        },
-        {
-            "name": "gaia",
-            "chain_id": "localcosmos-1",
-            "denom": "uatom",
-            "binary": "gaiad",
-            "bech32_prefix": "cosmos",
-            "docker_image": {
-                "version": "v9.1.0"
-            },
-            "block_time": "1000ms",
-            "gas_prices": "0%DENOM%",
-            "gas_adjustment": 2.0,
-            "ibc_paths": ["ibc-connection-1"],
-            "genesis": {
-                "accounts": [
-                    {
-                        "name": "acc0",
-                        "address": "cosmos1hj5fveer5cjtn4wd6wstzugjfdxzl0xpxvjjvr",
-                        "amount": "10000000%DENOM%",
-                        "mnemonic": "decorate bright ozone fork gallery riot bus exhaust worth way bone indoor calm squirrel merry zero scheme cotton until shop any excess stage laundry"
-                    }
-                ]
-            }
-        }
-    ]
-}

chains/testnet.json

@@ -1,78 +0,0 @@
-{
-    "chains": [
-        {
-            "name": "core",
-            "chain_id": "chainid-1",
-            "denom": "usnr",
-            "binary": "sonrd",
-            "bech32_prefix": "idx",
-            "docker_image": {
-                "repository": "core",
-                "version": "local"
-            },
-            "gas_prices": "0usnr",
-            "chain_type": "cosmos",
-            "coin_type": 118,
-            "trusting_period": "336h",
-            "gas_adjustment": 1.5,
-            "number_vals": 1,
-            "number_node": 0,
-            "debugging": true,
-            "block_time": "1000ms",
-            "host_port_override": {
-                "26657": "26657",
-                "1317": "1317",
-                "9090": "9090"
-            },
-            "encoding-options": ["wasm", "tokenfactory"],
-            "config_file_overrides": [
-                {
-                    "file": "config/config.toml",
-                    "paths": {
-                        "moniker": "localvalmoniker",
-                        "rpc.cors_allowed_origins": ["*"]
-                    }
-                }
-            ],
-            "genesis": {
-                "modify": [
-                    {
-                        "key": "app_state.gov.params.voting_period",
-                        "value": "15s"
-                    },
-                    {
-                        "key": "app_state.gov.params.expedited_voting_period",
-                        "value": "10s"
-                    },
-                    {
-                        "key": "app_state.gov.params.max_deposit_period",
-                        "value": "15s"
-                    },
-                    {
-                        "key": "app_state.gov.params.min_deposit.0.denom",
-                        "value": "usnr"
-                    },
-                    {
-                        "key": "app_state.gov.params.min_deposit.0.amount",
-                        "value": "1"
-                    }
-                ],
-                "accounts": [
-                    {
-                        "name": "acc0",
-                        "address": "idx1hj5fveer5cjtn4wd6wstzugjfdxzl0xpecp0nd",
-                        "amount": "10000000000usnr",
-                        "mnemonic": "decorate bright ozone fork gallery riot bus exhaust worth way bone indoor calm squirrel merry zero scheme cotton until shop any excess stage laundry"
-                    },
-                    {
-                        "name": "acc1",
-                        "address": "idx1efd63aw40lxf3n4mhf7dzhjkr453axur9vjt6y",
-                        "amount": "10000000000usnr",
-                        "mnemonic": "wealth flavor believe regret funny network recall kiss grape useless pepper cram hint member few certain unveil rather brick bargain curious require crowd raise"
-                    }
-                ],
-                "startup_commands": []
-            }
-        }
-    ]
-}

cmd/hway/cmds.go

@@ -5,28 +5,27 @@ import (
 	"log"
 	"net/http"
 	"os"
+	"strings"
 
-	"github.com/labstack/echo/v4"
-	"github.com/labstack/echo/v4/middleware"
-	"github.com/onsonr/sonr/crypto/ucan"
-	"github.com/onsonr/sonr/internal/gateway"
-	"github.com/onsonr/sonr/pkg/common/ipfs"
-	config "github.com/onsonr/sonr/pkg/config/hway"
-	"github.com/onsonr/sonr/pkg/database/sessions"
-	"github.com/onsonr/sonr/pkg/didauth/producer"
+	"github.com/onsonr/sonr/gateway"
+	"github.com/onsonr/sonr/internal/common"
 	"github.com/spf13/cobra"
 )
 
 // Command line flags
 var (
 	servePort      int    // Gateway http entry point (default 3000)
-	configDir      string // Hway config directory (default hway)
-	sqliteFile     string // SQLite database file (default hway.db)
 	chainID        string // Current chain ID (default sonr-testnet-1)
 	ipfsGatewayURL string // IPFS gateway URL (default localhost:8080)
 	sonrAPIURL     string // Sonr API URL (default localhost:1317)
 	sonrGrpcURL    string // Sonr gRPC URL (default localhost:9090)
 	sonrRPCURL     string // Sonr RPC URL (default localhost:26657)
+
+	psqlHost string // PostgresSQL Host Flag
+	psqlPort string // PostgresSQL Port Flag
+	psqlUser string // PostgresSQL User Flag
+	psqlPass string // PostgresSQL Password Flag
+	psqlDB   string // PostgresSQL Database Flag
 )
 
 func rootCmd() *cobra.Command {
@@ -38,7 +37,15 @@ func rootCmd() *cobra.Command {
 			if err != nil {
 				panic(err)
 			}
-			e, err := setupServer(env)
+			ipc, err := common.NewIPFS()
+			if err != nil {
+				panic(err)
+			}
+			dbq, err := setupPostgresDB()
+			if err != nil {
+				panic(err)
+			}
+			e, err := gateway.New(env, ipc, dbq)
 			if err != nil {
 				panic(err)
 			}
@@ -50,50 +57,37 @@ func rootCmd() *cobra.Command {
 		},
 	}
 	cmd.Flags().IntVar(&servePort, "serve-port", 3000, "Port to serve the gateway on")
-	cmd.Flags().StringVar(&configDir, "config-dir", "hway", "Directory to store config files")
-	cmd.Flags().StringVar(&sqliteFile, "sqlite-file", "hway.db", "File to store sqlite database")
 	cmd.Flags().StringVar(&chainID, "chain-id", "sonr-testnet-1", "Chain ID")
 	cmd.Flags().StringVar(&ipfsGatewayURL, "ipfs-gateway-url", "localhost:8080", "IPFS gateway URL")
 	cmd.Flags().StringVar(&sonrAPIURL, "sonr-api-url", "localhost:1317", "Sonr API URL")
 	cmd.Flags().StringVar(&sonrGrpcURL, "sonr-grpc-url", "localhost:9090", "Sonr gRPC URL")
 	cmd.Flags().StringVar(&sonrRPCURL, "sonr-rpc-url", "localhost:26657", "Sonr RPC URL")
+	cmd.Flags().StringVar(&psqlHost, "psql-host", "localhost", "PostgresSQL Host")
+	cmd.Flags().StringVar(&psqlPort, "psql-port", "5432", "PostgresSQL Port")
+	cmd.Flags().StringVar(&psqlUser, "psql-user", "highway_user", "PostgresSQL User")
+	cmd.Flags().StringVar(&psqlPass, "psql-pass", "highway_password123", "PostgresSQL Password")
+	cmd.Flags().StringVar(&psqlDB, "psql-db", "highway", "PostgresSQL Database")
 	return cmd
 }
 
-func loadEnvImplFromArgs(args []string) (config.Hway, error) {
-	cmd := rootCmd()
-	if err := cmd.ParseFlags(args); err != nil {
-		return nil, err
+func formatPsqlDSN() string {
+	if psqlHost == "" {
+		return ""
 	}
 
-	env := &config.HwayImpl{
-		ServePort:      servePort,
-		ConfigDir:      configDir,
-		SqliteFile:     sqliteFile,
-		ChainId:        chainID,
-		IpfsGatewayUrl: ipfsGatewayURL,
-		SonrApiUrl:     sonrAPIURL,
-		SonrGrpcUrl:    sonrGrpcURL,
-		SonrRpcUrl:     sonrRPCURL,
-	}
-	return env, nil
-}
+	host := psqlHost
+	port := "5432"
 
-// setupServer sets up the server
-func setupServer(env config.Hway) (*echo.Echo, error) {
-	ipc, err := ipfs.NewClient()
-	if err != nil {
-		return nil, err
+	if parts := strings.Split(psqlHost, ":"); len(parts) == 2 {
+		host = parts[0]
+		port = parts[1]
 	}
-	db, err := sessions.NewGormDB(env)
-	if err != nil {
-		return nil, err
-	}
-	e := echo.New()
-	e.IPExtractor = echo.ExtractIPDirect()
-	e.Use(middleware.Logger())
-	e.Use(middleware.Recover())
-	e.Use(producer.Middleware(ipc, ucan.ServicePermissions))
-	gateway.RegisterRoutes(e, env, db)
-	return e, nil
+
+	dsn := fmt.Sprintf("host=%s port=%s user=%s password=%s dbname=%s sslmode=verify-full",
+		host, port, psqlUser, psqlPass, psqlDB)
+
+	log.Printf("Attempting to connect to PostgreSQL with DSN: host=%s port=%s user=%s dbname=%s",
+		host, port, psqlUser, psqlDB) // Don't log the password
+
+	return dsn
 }

cmd/hway/main.go

@@ -1,9 +1,14 @@
 package main
 
 import (
+	"context"
 	_ "embed"
 	"fmt"
 	"os"
+
+	"github.com/jackc/pgx/v5"
+	config "github.com/onsonr/sonr/internal/config/hway"
+	hwayorm "github.com/onsonr/sonr/internal/database/hwayorm"
 )
 
 // main is the entry point for the application
@@ -15,3 +20,30 @@ func main() {
 	}
 	os.Exit(0)
 }
+
+func loadEnvImplFromArgs(args []string) (config.Hway, error) {
+	cmd := rootCmd()
+	if err := cmd.ParseFlags(args); err != nil {
+		return nil, err
+	}
+
+	env := &config.HwayImpl{
+		ServePort:      servePort,
+		ChainId:        chainID,
+		IpfsGatewayUrl: ipfsGatewayURL,
+		SonrApiUrl:     sonrAPIURL,
+		SonrGrpcUrl:    sonrGrpcURL,
+		SonrRpcUrl:     sonrRPCURL,
+		PsqlDSN:        formatPsqlDSN(),
+	}
+	return env, nil
+}
+
+func setupPostgresDB() (*hwayorm.Queries, error) {
+	pgdsn := fmt.Sprintf("host=%s user=%s password=%s dbname=%s sslmode=disable", psqlHost, psqlUser, psqlPass, psqlDB)
+	conn, err := pgx.Connect(context.Background(), pgdsn)
+	if err != nil {
+		return nil, err
+	}
+	return hwayorm.New(conn), nil
+}

cmd/motr/main.go

@@ -4,52 +4,256 @@
 package main
 
 import (
+	"bytes"
+	"context"
+	"database/sql"
 	"encoding/json"
+	"fmt"
+	"io"
+	"log"
+	"net/http"
+	"net/http/httptest"
+	"strings"
+	"sync"
 	"syscall/js"
 
-	"github.com/labstack/echo/v4"
-	"github.com/onsonr/sonr/internal/vault"
-	"github.com/onsonr/sonr/pkg/common/wasm"
-	"github.com/onsonr/sonr/pkg/config/motr"
-	"github.com/onsonr/sonr/pkg/didauth/controller"
+	_ "github.com/ncruces/go-sqlite3/driver"
+	_ "github.com/ncruces/go-sqlite3/embed"
+	"github.com/onsonr/sonr/internal/config/motr"
+	"github.com/onsonr/sonr/internal/database/motrorm"
+	sink "github.com/onsonr/sonr/internal/database/sink"
+	vault "github.com/onsonr/sonr/vault"
 )
 
 var (
-	env    *motr.Environment
-	config *motr.Config
-	err    error
+	// Global buffer pool to reduce allocations
+	bufferPool = sync.Pool{
+		New: func() interface{} {
+			return new(bytes.Buffer)
+		},
+	}
+
+	// Cached JS globals
+	jsGlobal     = js.Global()
+	jsUint8Array = jsGlobal.Get("Uint8Array")
+	jsResponse   = jsGlobal.Get("Response")
+	jsPromise    = jsGlobal.Get("Promise")
+	jsWasmHTTP   = jsGlobal.Get("wasmhttp")
 )
 
-func broadcastTx(this js.Value, args []js.Value) interface{} {
-	return nil
-}
-
-func simulateTx(this js.Value, args []js.Value) interface{} {
-	return nil
-}
-
-func processConfig(this js.Value, args []js.Value) interface{} {
-	if len(args) < 1 {
-		return nil
-	}
-
-	configString := args[0].String()
-	if err := json.Unmarshal([]byte(configString), &config); err != nil {
-		println("Error parsing config:", err.Error())
-		return nil
-	}
-	return nil
-}
-
 func main() {
-	// Load dwn config
-	js.Global().Set("broadcastTx", js.FuncOf(broadcastTx))
-	js.Global().Set("simulateTx", js.FuncOf(simulateTx))
-	js.Global().Set("processConfig", js.FuncOf(processConfig))
-
-	e := echo.New()
-	e.Use(wasm.ContextMiddleware)
-	e.Use(controller.Middleware(nil))
-	vault.RegisterRoutes(e, config)
-	wasm.ServeFetch(e)
+	configString := "TODO"
+	config, _ := loadConfig(configString)
+	dbq, err := createDB()
+	if err != nil {
+		log.Fatal(err)
+		return
+	}
+	e, err := vault.New(config, dbq)
+	if err != nil {
+		log.Fatal(err)
+		return
+	}
+	serveFetch(e)
+}
+
+// loadConfig loads the config from the given JSON string
+func loadConfig(configString string) (*motr.Config, error) {
+	var config motr.Config
+	err := json.Unmarshal([]byte(configString), &config)
+	return &config, err
+}
+
+// createDB initializes and returns a configured database connection
+func createDB() (*motrorm.Queries, error) {
+	db, err := sql.Open("sqlite3", ":memory:")
+	if err != nil {
+		return nil, err
+	}
+
+	// create tables
+	if _, err := db.ExecContext(context.Background(), sink.SchemaVaultSQL); err != nil {
+		return nil, err
+	}
+	return motrorm.New(db), nil
+}
+
+// serveFetch serves HTTP requests with optimized handler management
+func serveFetch(handler http.Handler) func() {
+	h := handler
+	if h == nil {
+		h = http.DefaultServeMux
+	}
+
+	// Optimize prefix handling
+	prefix := strings.TrimRight(jsWasmHTTP.Get("path").String(), "/")
+	if prefix != "" {
+		mux := http.NewServeMux()
+		mux.Handle(prefix+"/", http.StripPrefix(prefix, h))
+		h = mux
+	}
+
+	// Create request handler function
+	cb := js.FuncOf(func(_ js.Value, args []js.Value) interface{} {
+		promise, resolve, reject := newPromiseOptimized()
+
+		go handleRequest(h, args[1], resolve, reject)
+
+		return promise
+	})
+
+	jsWasmHTTP.Call("setHandler", cb)
+	return cb.Release
+}
+
+// handleRequest processes the request with panic recovery
+func handleRequest(h http.Handler, jsReq js.Value, resolve, reject func(interface{})) {
+	defer func() {
+		if r := recover(); r != nil {
+			var errMsg string
+			if err, ok := r.(error); ok {
+				errMsg = fmt.Sprintf("wasmhttp: panic: %+v", err)
+			} else {
+				errMsg = fmt.Sprintf("wasmhttp: panic: %v", r)
+			}
+			reject(errMsg)
+		}
+	}()
+
+	recorder := newResponseRecorder()
+	h.ServeHTTP(recorder, buildRequest(jsReq))
+	resolve(recorder.jsResponse())
+}
+
+// buildRequest creates an http.Request from JS Request
+func buildRequest(jsReq js.Value) *http.Request {
+	// Get request body
+	arrayBuffer, err := awaitPromiseOptimized(jsReq.Call("arrayBuffer"))
+	if err != nil {
+		panic(err)
+	}
+
+	// Create body buffer
+	jsBody := jsUint8Array.New(arrayBuffer)
+	bodyLen := jsBody.Get("length").Int()
+	body := make([]byte, bodyLen)
+	js.CopyBytesToGo(body, jsBody)
+
+	// Create request
+	req := httptest.NewRequest(
+		jsReq.Get("method").String(),
+		jsReq.Get("url").String(),
+		bytes.NewReader(body),
+	)
+
+	// Set headers efficiently
+	headers := jsReq.Get("headers")
+	headersIt := headers.Call("entries")
+	for {
+		entry := headersIt.Call("next")
+		if entry.Get("done").Bool() {
+			break
+		}
+		pair := entry.Get("value")
+		req.Header.Set(pair.Index(0).String(), pair.Index(1).String())
+	}
+
+	return req
+}
+
+// ResponseRecorder with optimized buffer handling
+type ResponseRecorder struct {
+	*httptest.ResponseRecorder
+	buffer *bytes.Buffer
+}
+
+func newResponseRecorder() *ResponseRecorder {
+	return &ResponseRecorder{
+		ResponseRecorder: httptest.NewRecorder(),
+		buffer:           bufferPool.Get().(*bytes.Buffer),
+	}
+}
+
+// jsResponse creates a JS Response with optimized memory usage
+func (rr *ResponseRecorder) jsResponse() js.Value {
+	defer func() {
+		rr.buffer.Reset()
+		bufferPool.Put(rr.buffer)
+	}()
+
+	res := rr.Result()
+	defer res.Body.Close()
+
+	// Prepare response body
+	body := js.Undefined()
+	if res.ContentLength != 0 {
+		if _, err := io.Copy(rr.buffer, res.Body); err != nil {
+			panic(err)
+		}
+		bodyBytes := rr.buffer.Bytes()
+		body = jsUint8Array.New(len(bodyBytes))
+		js.CopyBytesToJS(body, bodyBytes)
+	}
+
+	// Prepare response init object
+	init := make(map[string]interface{}, 3)
+	if res.StatusCode != 0 {
+		init["status"] = res.StatusCode
+	}
+
+	if len(res.Header) > 0 {
+		headers := make(map[string]interface{}, len(res.Header))
+		for k, v := range res.Header {
+			if len(v) > 0 {
+				headers[k] = v[0]
+			}
+		}
+		init["headers"] = headers
+	}
+
+	return jsResponse.New(body, init)
+}
+
+// newPromiseOptimized creates a new JavaScript Promise with optimized callback handling
+func newPromiseOptimized() (js.Value, func(interface{}), func(interface{})) {
+	var (
+		resolve     func(interface{})
+		reject      func(interface{})
+		promiseFunc = js.FuncOf(func(_ js.Value, args []js.Value) interface{} {
+			resolve = func(v interface{}) { args[0].Invoke(v) }
+			reject = func(v interface{}) { args[1].Invoke(v) }
+			return js.Undefined()
+		})
+	)
+	defer promiseFunc.Release()
+
+	return jsPromise.New(promiseFunc), resolve, reject
+}
+
+// awaitPromiseOptimized waits for Promise resolution with optimized channel handling
+func awaitPromiseOptimized(promise js.Value) (js.Value, error) {
+	done := make(chan struct{})
+	var (
+		result js.Value
+		err    error
+	)
+
+	thenFunc := js.FuncOf(func(_ js.Value, args []js.Value) interface{} {
+		result = args[0]
+		close(done)
+		return nil
+	})
+	defer thenFunc.Release()
+
+	catchFunc := js.FuncOf(func(_ js.Value, args []js.Value) interface{} {
+		err = js.Error{Value: args[0]}
+		close(done)
+		return nil
+	})
+	defer catchFunc.Release()
+
+	promise.Call("then", thenFunc).Call("catch", catchFunc)
+	<-done
+
+	return result, err
 }

cmd/sonrd/main.go

@@ -12,7 +12,6 @@ import (
 
 func main() {
 	rootCmd := NewRootCmd()
-
 	if err := svrcmd.Execute(rootCmd, "", app.DefaultNodeHome); err != nil {
 		log.NewLogger(rootCmd.OutOrStderr()).Error("failure when running app", "err", err)
 		os.Exit(1)

contrib/devtools/Makefile

@@ -1,85 +0,0 @@
-###
-# Find OS and Go environment
-# GO contains the Go binary
-# FS contains the OS file separator
-###
-ifeq ($(OS),Windows_NT)
-  GO := $(shell where go.exe 2> NUL)
-  FS := "\\"
-else
-  GO := $(shell command -v go 2> /dev/null)
-  FS := "/"
-endif
-
-ifeq ($(GO),)
-  $(error could not find go. Is it in PATH? $(GO))
-endif
-
-###############################################################################
-###                                Functions                                ###
-###############################################################################
-
-go_get = $(if $(findstring Windows_NT,$(OS)),\
-IF NOT EXIST $(GITHUBDIR)$(FS)$(1)$(FS) ( mkdir $(GITHUBDIR)$(FS)$(1) ) else (cd .) &\
-IF NOT EXIST $(GITHUBDIR)$(FS)$(1)$(FS)$(2)$(FS) ( cd $(GITHUBDIR)$(FS)$(1) && git clone https://github.com/$(1)/$(2) ) else (cd .) &\
-,\
-mkdir -p $(GITHUBDIR)$(FS)$(1) &&\
-(test ! -d $(GITHUBDIR)$(FS)$(1)$(FS)$(2) && cd $(GITHUBDIR)$(FS)$(1) && git clone https://github.com/$(1)/$(2)) || true &&\
-)\
-cd $(GITHUBDIR)$(FS)$(1)$(FS)$(2) && git fetch origin && git checkout -q $(3)
-
-mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
-mkfile_dir := $(shell cd $(shell dirname $(mkfile_path)); pwd)
-
-
-###############################################################################
-###                                 Tools                                   ###
-###############################################################################
-
-PREFIX ?= /usr/local
-BIN ?= $(PREFIX)/bin
-UNAME_S ?= $(shell uname -s)
-UNAME_M ?= $(shell uname -m)
-
-GOPATH ?= $(shell $(GO) env GOPATH)
-GITHUBDIR := $(GOPATH)$(FS)src$(FS)github.com
-
-BUF_VERSION ?= 0.11.0
-
-TOOLS_DESTDIR  ?= $(GOPATH)/bin
-STATIK         = $(TOOLS_DESTDIR)/statik
-RUNSIM         = $(TOOLS_DESTDIR)/runsim
-GOLANGCI_LINT  = $(TOOLS_DESTDIR)/golangci-lint
-
-tools: tools-stamp
-tools-stamp: statik runsim golangci-lint
-	# Create dummy file to satisfy dependency and avoid
-	# rebuilding when this Makefile target is hit twice
-	# in a row.
-	touch $@
-
-statik: $(STATIK)
-$(STATIK):
-	@echo "Installing statik..."
-	@(cd /tmp && go install github.com/rakyll/statik@v0.1.6)
-
-# Install the runsim binary with a temporary workaround of entering an outside
-# directory as the "go get" command ignores the -mod option and will polute the
-# go.{mod, sum} files.
-#
-# ref: https://github.com/golang/go/issues/30515
-runsim: $(RUNSIM)
-$(RUNSIM):
-	@echo "Installing runsim..."
-	@(cd /tmp && go install github.com/cosmos/tools/cmd/runsim@v1.0.0)
-
-golangci-lint: $(GOLANGCI_LINT)
-$(GOLANGCI_LINT):
-	@echo "Installing golangci-lint..."
-	@(cd /tmp && go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.47.0)
-
-tools-clean:
-	rm -f $(STATIK) $(GOLANGCI_LINT) $(RUNSIM)
-	rm -f tools-stamp
-
-.PHONY: tools-clean statik runsim

contrib/devtools/README.md

@@ -1,6 +0,0 @@
-## Contributors
-
-Thanks to the entire Cosmos SDK team and the contributors who put their efforts into making simulation testing
-easier to implement. 🤗
-
-https://github.com/cosmos/cosmos-sdk/blob/master/contrib/devtools/Makefile

crypto/mpc/keyset.go

@@ -1,61 +0,0 @@
-package mpc
-
-import (
-	"fmt"
-
-	"github.com/cosmos/cosmos-sdk/types/bech32"
-)
-
-type (
-	ExportedKeyset = []byte
-)
-
-type Keyset interface {
-	Address() string
-	Val() *ValKeyshare
-	ValJSON() string
-	User() *UserKeyshare
-	UserJSON() string
-}
-
-type keyset struct {
-	val  *ValKeyshare
-	user *UserKeyshare
-	addr string
-}
-
-func (k keyset) Address() string {
-	return k.addr
-}
-
-func (k keyset) Val() *ValKeyshare {
-	return k.val
-}
-
-func (k keyset) User() *UserKeyshare {
-	return k.user
-}
-
-func (k keyset) ValJSON() string {
-	return k.val.String()
-}
-
-func (k keyset) UserJSON() string {
-	return k.user.String()
-}
-
-func ComputeIssuerDID(pk []byte) (string, string, error) {
-	addr, err := ComputeSonrAddr(pk)
-	if err != nil {
-		return "", "", err
-	}
-	return fmt.Sprintf("did:sonr:%s", addr), addr, nil
-}
-
-func ComputeSonrAddr(pk []byte) (string, error) {
-	sonrAddr, err := bech32.ConvertAndEncode("idx", pk)
-	if err != nil {
-		return "", err
-	}
-	return sonrAddr, nil
-}

crypto/mpc/keyshare.go

@@ -1,71 +0,0 @@
-package mpc
-
-import (
-	"crypto/ecdsa"
-
-	"github.com/onsonr/sonr/crypto/core/protocol"
-	"github.com/onsonr/sonr/crypto/tecdsa/dklsv1/dkg"
-)
-
-// BaseKeyshare contains common fields and methods for both validator and user keyshares
-type BaseKeyshare struct {
-	Message            *protocol.Message `json:"message"`
-	Role               int               `json:"role"`
-	UncompressedPubKey []byte            `json:"public_key"`
-	CompressedPubKey   []byte            `json:"compressed_public_key"`
-}
-
-func initFromAlice(aliceOut *dkg.AliceOutput, originalMsg *protocol.Message) BaseKeyshare {
-	return BaseKeyshare{
-		Message:            originalMsg,
-		Role:               1,
-		UncompressedPubKey: aliceOut.PublicKey.ToAffineUncompressed(),
-		CompressedPubKey:   aliceOut.PublicKey.ToAffineCompressed(),
-	}
-}
-
-func initFromBob(bobOut *dkg.BobOutput, originalMsg *protocol.Message) BaseKeyshare {
-	return BaseKeyshare{
-		Message:            originalMsg,
-		Role:               2,
-		UncompressedPubKey: bobOut.PublicKey.ToAffineUncompressed(),
-		CompressedPubKey:   bobOut.PublicKey.ToAffineCompressed(),
-	}
-}
-
-func (b *BaseKeyshare) GetPayloads() map[string][]byte {
-	return b.Message.Payloads
-}
-
-func (b *BaseKeyshare) GetMetadata() map[string]string {
-	return b.Message.Metadata
-}
-
-func (b *BaseKeyshare) GetPublicKey() []byte {
-	return b.UncompressedPubKey
-}
-
-func (b *BaseKeyshare) GetProtocol() string {
-	return b.Message.Protocol
-}
-
-func (b *BaseKeyshare) GetRole() int32 {
-	return int32(b.Role)
-}
-
-func (b *BaseKeyshare) GetVersion() uint32 {
-	return uint32(b.Message.Version)
-}
-
-func (b *BaseKeyshare) ECDSAPublicKey() (*ecdsa.PublicKey, error) {
-	return ComputeEcdsaPublicKey(b.UncompressedPubKey)
-}
-
-func (b *BaseKeyshare) ExtractMessage() *protocol.Message {
-	return &protocol.Message{
-		Payloads: b.GetPayloads(),
-		Metadata: b.GetMetadata(),
-		Protocol: b.GetProtocol(),
-		Version:  uint(b.GetVersion()),
-	}
-}

crypto/mpc/protocol.go

@@ -1,197 +0,0 @@
-package mpc
-
-import (
-	"crypto/ecdsa"
-	genericecdsa "crypto/ecdsa"
-	"errors"
-	"fmt"
-	"math/big"
-
-	"github.com/onsonr/sonr/crypto/core/curves"
-	"github.com/onsonr/sonr/crypto/core/protocol"
-	"github.com/onsonr/sonr/crypto/tecdsa/dklsv1"
-	"golang.org/x/crypto/sha3"
-)
-
-// NewKeyshareSource generates a new MPC keyshare
-func NewKeyset() (Keyset, error) {
-	curve := curves.K256()
-	valKs := dklsv1.NewAliceDkg(curve, protocol.Version1)
-	userKs := dklsv1.NewBobDkg(curve, protocol.Version1)
-	aErr, bErr := RunProtocol(userKs, valKs)
-	if err := checkIteratedErrors(aErr, bErr); err != nil {
-		return nil, err
-	}
-	valRes, err := valKs.Result(protocol.Version1)
-	if err != nil {
-		return nil, err
-	}
-	valShare, err := NewValKeyshare(valRes)
-	if err != nil {
-		return nil, err
-	}
-	userRes, err := userKs.Result(protocol.Version1)
-	if err != nil {
-		return nil, err
-	}
-	userShare, err := NewUserKeyshare(userRes)
-	if err != nil {
-		return nil, err
-	}
-	addr, err := computeSonrAddr(valShare.CompressedPublicKey())
-	if err != nil {
-		return nil, err
-	}
-	return keyset{val: valShare, user: userShare, addr: addr}, nil
-}
-
-// ExecuteSigning runs the MPC signing protocol
-func ExecuteSigning(signFuncVal SignFunc, signFuncUser SignFunc) (Signature, error) {
-	aErr, bErr := RunProtocol(signFuncVal, signFuncUser)
-	if err := checkIteratedErrors(aErr, bErr); err != nil {
-		return nil, err
-	}
-	out, err := signFuncUser.Result(protocol.Version1)
-	if err != nil {
-		return nil, err
-	}
-	return dklsv1.DecodeSignature(out)
-}
-
-// ExecuteRefresh runs the MPC refresh protocol
-func ExecuteRefresh(refreshFuncVal RefreshFunc, refreshFuncUser RefreshFunc) (Keyset, error) {
-	aErr, bErr := RunProtocol(refreshFuncVal, refreshFuncUser)
-	if err := checkIteratedErrors(aErr, bErr); err != nil {
-		return nil, err
-	}
-	valRefreshResult, err := refreshFuncVal.Result(protocol.Version1)
-	if err != nil {
-		return nil, err
-	}
-	valShare, err := NewValKeyshare(valRefreshResult)
-	if err != nil {
-		return nil, err
-	}
-	userRefreshResult, err := refreshFuncUser.Result(protocol.Version1)
-	if err != nil {
-		return nil, err
-	}
-	userShare, err := NewUserKeyshare(userRefreshResult)
-	if err != nil {
-		return nil, err
-	}
-	addr, err := computeSonrAddr(valShare.CompressedPublicKey())
-	if err != nil {
-		return nil, err
-	}
-	return keyset{val: valShare, user: userShare, addr: addr}, nil
-}
-
-// SerializeSecp256k1Signature serializes an ECDSA signature into a byte slice
-func SerializeSignature(sig Signature) ([]byte, error) {
-	rBytes := sig.R.Bytes()
-	sBytes := sig.S.Bytes()
-
-	sigBytes := make([]byte, 66) // V (1 byte) + R (32 bytes) + S (32 bytes)
-	sigBytes[0] = byte(sig.V)
-	copy(sigBytes[33-len(rBytes):33], rBytes)
-	copy(sigBytes[66-len(sBytes):66], sBytes)
-	return sigBytes, nil
-}
-
-// DeserializeSecp256k1Signature deserializes an ECDSA signature from a byte slice
-func DeserializeSignature(sigBytes []byte) (Signature, error) {
-	if len(sigBytes) != 66 {
-		return nil, errors.New("malformed signature: not the correct size")
-	}
-	sig := &curves.EcdsaSignature{
-		V: int(sigBytes[0]),
-		R: new(big.Int).SetBytes(sigBytes[1:33]),
-		S: new(big.Int).SetBytes(sigBytes[33:66]),
-	}
-	return sig, nil
-}
-
-// VerifyMPCSignature verifies an MPC signature
-func VerifyMPCSignature(sig Signature, msg []byte, publicKey *ecdsa.PublicKey) bool {
-	return ecdsa.Verify(publicKey, msg, sig.R, sig.S)
-}
-
-// For DKG bob starts first. For refresh and sign, Alice starts first.
-func RunProtocol(firstParty protocol.Iterator, secondParty protocol.Iterator) (error, error) {
-	var (
-		message *protocol.Message
-		aErr    error
-		bErr    error
-	)
-
-	for aErr != protocol.ErrProtocolFinished || bErr != protocol.ErrProtocolFinished {
-		// Crank each protocol forward one iteration
-		message, bErr = firstParty.Next(message)
-		if bErr != nil && bErr != protocol.ErrProtocolFinished {
-			return nil, bErr
-		}
-
-		message, aErr = secondParty.Next(message)
-		if aErr != nil && aErr != protocol.ErrProtocolFinished {
-			return aErr, nil
-		}
-	}
-	return aErr, bErr
-}
-
-// ComputeEcPoint builds an elliptic curve point from a compressed byte slice
-func ComputeEcPoint(pubKey []byte) (*curves.EcPoint, error) {
-	crv := curves.K256()
-	x := new(big.Int).SetBytes(pubKey[1:33])
-	y := new(big.Int).SetBytes(pubKey[33:])
-	ecCurve, err := crv.ToEllipticCurve()
-	if err != nil {
-		return nil, fmt.Errorf("error converting curve: %v", err)
-	}
-	return &curves.EcPoint{X: x, Y: y, Curve: ecCurve}, nil
-}
-
-func ComputeEcdsaPublicKey(pubKey []byte) (*genericecdsa.PublicKey, error) {
-	pk, err := ComputeEcPoint(pubKey)
-	if err != nil {
-		return nil, err
-	}
-	return &genericecdsa.PublicKey{
-		Curve: pk.Curve,
-		X:     pk.X,
-		Y:     pk.Y,
-	}, nil
-}
-
-// VerifySignature verifies the signature of a message
-func VerifySignature(pk []byte, msg []byte, sig []byte) (bool, error) {
-	pp, err := ComputeEcPoint(pk)
-	if err != nil {
-		return false, err
-	}
-	sigEd, err := DeserializeSignature(sig)
-	if err != nil {
-		return false, err
-	}
-	hash := sha3.New256()
-	_, err = hash.Write(msg)
-	if err != nil {
-		return false, err
-	}
-	digest := hash.Sum(nil)
-	return curves.VerifyEcdsa(pp, digest[:], sigEd), nil
-}
-
-func checkIteratedErrors(aErr, bErr error) error {
-	if aErr == protocol.ErrProtocolFinished && bErr == protocol.ErrProtocolFinished {
-		return nil
-	}
-	if aErr != protocol.ErrProtocolFinished {
-		return aErr
-	}
-	if bErr != protocol.ErrProtocolFinished {
-		return bErr
-	}
-	return nil
-}

crypto/mpc/share.go

@@ -1,150 +0,0 @@
-package mpc
-
-import (
-	"errors"
-
-	"github.com/cosmos/cosmos-sdk/types/bech32"
-	"github.com/onsonr/sonr/crypto/core/curves"
-	"github.com/onsonr/sonr/crypto/core/protocol"
-	"github.com/onsonr/sonr/crypto/tecdsa/dklsv1"
-	"golang.org/x/crypto/sha3"
-)
-
-var ErrInvalidKeyshareRole = errors.New("invalid keyshare role")
-
-type Role int
-
-const (
-	RoleUnknown Role = iota
-	RoleUser
-	RoleValidator
-)
-
-func (r Role) IsUser() bool {
-	return r == RoleUser
-}
-
-func (r Role) IsValidator() bool {
-	return r == RoleValidator
-}
-
-// Message is the protocol.Message that is used for MPC
-type Message *protocol.Message
-
-type Signature *curves.EcdsaSignature
-
-// RefreshFunc is the type for the refresh function
-type RefreshFunc interface {
-	protocol.Iterator
-}
-
-// SignFunc is the type for the sign function
-type SignFunc interface {
-	protocol.Iterator
-}
-
-type ValKeyshare struct {
-	BaseKeyshare
-	encoded string
-}
-
-func computeSonrAddr(pk []byte) (string, error) {
-	sonrAddr, err := bech32.ConvertAndEncode("idx", pk)
-	if err != nil {
-		return "", err
-	}
-	return sonrAddr, nil
-}
-
-func NewValKeyshare(msg *protocol.Message) (*ValKeyshare, error) {
-	vks := new(ValKeyshare)
-	encoded, err := protocol.EncodeMessage(msg)
-	if err != nil {
-		return nil, err
-	}
-	valShare, err := dklsv1.DecodeAliceDkgResult(msg)
-	if err != nil {
-		return nil, err
-	}
-
-	vks.BaseKeyshare = initFromAlice(valShare, msg)
-	vks.encoded = encoded
-	return vks, nil
-}
-
-func (v *ValKeyshare) RefreshFunc() (RefreshFunc, error) {
-	curve := curves.K256()
-	return dklsv1.NewAliceRefresh(curve, v.ExtractMessage(), protocol.Version1)
-}
-
-func (v *ValKeyshare) SignFunc(msg []byte) (SignFunc, error) {
-	curve := curves.K256()
-	return dklsv1.NewAliceSign(curve, sha3.New256(), msg, v.ExtractMessage(), protocol.Version1)
-}
-
-func (v *ValKeyshare) String() string {
-	return v.encoded
-}
-
-// PublicKey returns the uncompressed public key (65 bytes)
-func (v *ValKeyshare) PublicKey() []byte {
-	return v.UncompressedPubKey
-}
-
-// CompressedPublicKey returns the compressed public key (33 bytes)
-func (v *ValKeyshare) CompressedPublicKey() []byte {
-	return v.CompressedPubKey
-}
-
-type UserKeyshare struct {
-	BaseKeyshare
-	encoded string
-}
-
-func NewUserKeyshare(msg *protocol.Message) (*UserKeyshare, error) {
-	uks := new(UserKeyshare)
-	encoded, err := protocol.EncodeMessage(msg)
-	if err != nil {
-		return nil, err
-	}
-	out, err := dklsv1.DecodeBobDkgResult(msg)
-	if err != nil {
-		return nil, err
-	}
-
-	uks.BaseKeyshare = initFromBob(out, msg)
-	uks.encoded = encoded
-	return uks, nil
-}
-
-func (u *UserKeyshare) RefreshFunc() (RefreshFunc, error) {
-	curve := curves.K256()
-	return dklsv1.NewBobRefresh(curve, u.ExtractMessage(), protocol.Version1)
-}
-
-func (u *UserKeyshare) SignFunc(msg []byte) (SignFunc, error) {
-	curve := curves.K256()
-	return dklsv1.NewBobSign(curve, sha3.New256(), msg, u.ExtractMessage(), protocol.Version1)
-}
-
-func (u *UserKeyshare) String() string {
-	return u.encoded
-}
-
-// PublicKey returns the uncompressed public key (65 bytes)
-func (u *UserKeyshare) PublicKey() []byte {
-	return u.UncompressedPubKey
-}
-
-// CompressedPublicKey returns the compressed public key (33 bytes)
-func (u *UserKeyshare) CompressedPublicKey() []byte {
-	return u.CompressedPubKey
-}
-
-func encodeMessage(m *protocol.Message) (string, error) {
-	return protocol.EncodeMessage(m)
-}
-
-func decodeMessage(s string) (*protocol.Message, error) {
-	return protocol.DecodeMessage(s)
-}

crypto/ucan/attenuation_test.go

@@ -1,96 +0,0 @@
-package ucan
-
-import (
-	"encoding/json"
-	"fmt"
-	"testing"
-)
-
-func TestAttenuationsContains(t *testing.T) {
-	aContains := [][2]string{
-		{
-			`[
-				{ "cap": "SUPER_USER", "dataset": "b5/world_bank_population"},
-				{ "cap": "OVERWRITE", "api": "https://api.qri.cloud" }
-			]`,
-			`[
-				{"cap": "SOFT_DELETE", "dataset": "b5/world_bank_population" }
-			]`,
-		},
-		{
-			`[
-				{ "cap": "SUPER_USER", "dataset": "b5/world_bank_population"},
-				{ "cap": "OVERWRITE", "api": "https://api.qri.cloud" }
-			]`,
-			`[
-				{"cap": "SUPER_USER", "dataset": "b5/world_bank_population" }
-			]`,
-		},
-	}
-
-	for i, c := range aContains {
-		t.Run(fmt.Sprintf("contains_%d", i), func(t *testing.T) {
-			a := testAttenuations(c[0])
-			b := testAttenuations(c[1])
-			if !a.Contains(b) {
-				t.Errorf("expected a attenuations to contain b attenuations")
-			}
-		})
-	}
-
-	aNotContains := [][2]string{
-		{
-			`[
-				{ "cap": "SUPER_USER", "dataset": "b5/world_bank_population"},
-				{ "cap": "OVERWRITE", "api": "https://api.qri.cloud" }
-			]`,
-			`[
-				{ "cap": "CREATE", "dataset": "b5" }
-			]`,
-		},
-	}
-
-	for i, c := range aNotContains {
-		t.Run(fmt.Sprintf("not_contains_%d", i), func(t *testing.T) {
-			a := testAttenuations(c[0])
-			b := testAttenuations(c[1])
-			if a.Contains(b) {
-				t.Errorf("expected a attenuations to NOT contain b attenuations")
-			}
-		})
-	}
-}
-
-func mustJSON(data string, v interface{}) {
-	if err := json.Unmarshal([]byte(data), v); err != nil {
-		panic(err)
-	}
-}
-
-func testAttenuations(data string) Attenuations {
-	caps := NewNestedCapabilities("SUPER_USER", "OVERWRITE", "SOFT_DELETE", "REVISE", "CREATE")
-
-	v := []map[string]string{}
-	mustJSON(data, &v)
-
-	var att Attenuations
-	for _, x := range v {
-		var cap Capability
-		var rsc Resource
-		for key, val := range x {
-			switch key {
-			case CapKey:
-				cap = caps.Cap(val)
-			default:
-				rsc = NewStringLengthResource(key, val)
-			}
-		}
-		att = append(att, Attenuation{cap, rsc})
-	}
-
-	return att
-}
-
-func TestNestedCapabilities(t *testing.T) {
-
-}

crypto/ucan/attns/capability/Capability.pkl.go

@@ -1,79 +0,0 @@
-// Code generated from Pkl module `sonr.orm.UCAN`. DO NOT EDIT.
-package capability
-
-import (
-	"encoding"
-	"fmt"
-)
-
-type Capability string
-
-const (
-	CAPOWNER        Capability = "CAP_OWNER"
-	CAPOPERATOR     Capability = "CAP_OPERATOR"
-	CAPOBSERVER     Capability = "CAP_OBSERVER"
-	CAPAUTHENTICATE Capability = "CAP_AUTHENTICATE"
-	CAPAUTHORIZE    Capability = "CAP_AUTHORIZE"
-	CAPDELEGATE     Capability = "CAP_DELEGATE"
-	CAPINVOKE       Capability = "CAP_INVOKE"
-	CAPEXECUTE      Capability = "CAP_EXECUTE"
-	CAPPROPOSE      Capability = "CAP_PROPOSE"
-	CAPSIGN         Capability = "CAP_SIGN"
-	CAPSETPOLICY    Capability = "CAP_SET_POLICY"
-	CAPSETTHRESHOLD Capability = "CAP_SET_THRESHOLD"
-	CAPRECOVER      Capability = "CAP_RECOVER"
-	CAPSOCIAL       Capability = "CAP_SOCIAL"
-	CAPVOTE         Capability = "CAP_VOTE"
-	CAPRESOLVER     Capability = "CAP_RESOLVER"
-	CAPPRODUCER     Capability = "CAP_PRODUCER"
-)
-
-// String returns the string representation of Capability
-func (rcv Capability) String() string {
-	return string(rcv)
-}
-
-var _ encoding.BinaryUnmarshaler = new(Capability)
-
-// UnmarshalBinary implements encoding.BinaryUnmarshaler for Capability.
-func (rcv *Capability) UnmarshalBinary(data []byte) error {
-	switch str := string(data); str {
-	case "CAP_OWNER":
-		*rcv = CAPOWNER
-	case "CAP_OPERATOR":
-		*rcv = CAPOPERATOR
-	case "CAP_OBSERVER":
-		*rcv = CAPOBSERVER
-	case "CAP_AUTHENTICATE":
-		*rcv = CAPAUTHENTICATE
-	case "CAP_AUTHORIZE":
-		*rcv = CAPAUTHORIZE
-	case "CAP_DELEGATE":
-		*rcv = CAPDELEGATE
-	case "CAP_INVOKE":
-		*rcv = CAPINVOKE
-	case "CAP_EXECUTE":
-		*rcv = CAPEXECUTE
-	case "CAP_PROPOSE":
-		*rcv = CAPPROPOSE
-	case "CAP_SIGN":
-		*rcv = CAPSIGN
-	case "CAP_SET_POLICY":
-		*rcv = CAPSETPOLICY
-	case "CAP_SET_THRESHOLD":
-		*rcv = CAPSETTHRESHOLD
-	case "CAP_RECOVER":
-		*rcv = CAPRECOVER
-	case "CAP_SOCIAL":
-		*rcv = CAPSOCIAL
-	case "CAP_VOTE":
-		*rcv = CAPVOTE
-	case "CAP_RESOLVER":
-		*rcv = CAPRESOLVER
-	case "CAP_PRODUCER":
-		*rcv = CAPPRODUCER
-	default:
-		return fmt.Errorf(`illegal: "%s" is not a valid Capability`, str)
-	}
-	return nil
-}

crypto/ucan/attns/capability/capability.go

@@ -1 +0,0 @@
-package capability

crypto/ucan/attns/policytype/PolicyType.pkl.go

@@ -1,40 +0,0 @@
-// Code generated from Pkl module `sonr.orm.UCAN`. DO NOT EDIT.
-package policytype
-
-import (
-	"encoding"
-	"fmt"
-)
-
-type PolicyType string
-
-const (
-	POLICYTHRESHOLD PolicyType = "POLICY_THRESHOLD"
-	POLICYTIMELOCK  PolicyType = "POLICY_TIMELOCK"
-	POLICYWHITELIST PolicyType = "POLICY_WHITELIST"
-	POLICYKEYGEN    PolicyType = "POLICY_KEYGEN"
-)
-
-// String returns the string representation of PolicyType
-func (rcv PolicyType) String() string {
-	return string(rcv)
-}
-
-var _ encoding.BinaryUnmarshaler = new(PolicyType)
-
-// UnmarshalBinary implements encoding.BinaryUnmarshaler for PolicyType.
-func (rcv *PolicyType) UnmarshalBinary(data []byte) error {
-	switch str := string(data); str {
-	case "POLICY_THRESHOLD":
-		*rcv = POLICYTHRESHOLD
-	case "POLICY_TIMELOCK":
-		*rcv = POLICYTIMELOCK
-	case "POLICY_WHITELIST":
-		*rcv = POLICYWHITELIST
-	case "POLICY_KEYGEN":
-		*rcv = POLICYKEYGEN
-	default:
-		return fmt.Errorf(`illegal: "%s" is not a valid PolicyType`, str)
-	}
-	return nil
-}

crypto/ucan/attns/resourcetype/ResourceType.pkl.go

@@ -1,52 +0,0 @@
-// Code generated from Pkl module `sonr.orm.UCAN`. DO NOT EDIT.
-package resourcetype
-
-import (
-	"encoding"
-	"fmt"
-)
-
-type ResourceType string
-
-const (
-	RESACCOUNT     ResourceType = "RES_ACCOUNT"
-	RESTRANSACTION ResourceType = "RES_TRANSACTION"
-	RESPOLICY      ResourceType = "RES_POLICY"
-	RESRECOVERY    ResourceType = "RES_RECOVERY"
-	RESVAULT       ResourceType = "RES_VAULT"
-	RESIPFS        ResourceType = "RES_IPFS"
-	RESIPNS        ResourceType = "RES_IPNS"
-	RESKEYSHARE    ResourceType = "RES_KEYSHARE"
-)
-
-// String returns the string representation of ResourceType
-func (rcv ResourceType) String() string {
-	return string(rcv)
-}
-
-var _ encoding.BinaryUnmarshaler = new(ResourceType)
-
-// UnmarshalBinary implements encoding.BinaryUnmarshaler for ResourceType.
-func (rcv *ResourceType) UnmarshalBinary(data []byte) error {
-	switch str := string(data); str {
-	case "RES_ACCOUNT":
-		*rcv = RESACCOUNT
-	case "RES_TRANSACTION":
-		*rcv = RESTRANSACTION
-	case "RES_POLICY":
-		*rcv = RESPOLICY
-	case "RES_RECOVERY":
-		*rcv = RESRECOVERY
-	case "RES_VAULT":
-		*rcv = RESVAULT
-	case "RES_IPFS":
-		*rcv = RESIPFS
-	case "RES_IPNS":
-		*rcv = RESIPNS
-	case "RES_KEYSHARE":
-		*rcv = RESKEYSHARE
-	default:
-		return fmt.Errorf(`illegal: "%s" is not a valid ResourceType`, str)
-	}
-	return nil
-}

crypto/ucan/attns/resourcetype/resource.go

@@ -1,33 +0,0 @@
-package resourcetype
-
-// Resource is a unique identifier for a thing, usually stored state. Resources
-// are organized by string types
-type Resource interface {
-	Type() ResourceType
-	Value() string
-	Contains(b Resource) bool
-}
-
-type stringResource struct {
-	t ResourceType
-	v string
-}
-
-func (r stringResource) Type() ResourceType {
-	return r.t
-}
-
-func (r stringResource) Value() string {
-	return r.v
-}
-
-func (r stringResource) Contains(b Resource) bool {
-	return r.Type() == b.Type() && len(r.Value()) <= len(b.Value())
-}
-
-func NewResource(typ ResourceType, val string) Resource {
-	return stringResource{
-		t: typ,
-		v: val,
-	}
-}

crypto/ucan/codec.go

@@ -1,153 +0,0 @@
-package ucan
-
-import (
-	"fmt"
-
-	"github.com/onsonr/sonr/crypto/mpc"
-	"github.com/onsonr/sonr/crypto/ucan/attns/capability"
-	"github.com/onsonr/sonr/crypto/ucan/attns/policytype"
-	"github.com/onsonr/sonr/crypto/ucan/attns/resourcetype"
-)
-
-// NewSmartAccount creates default attenuations for a smart account
-func NewSmartAccount(
-	accountAddr string,
-) Attenuations {
-	caps := AccountPermissions.GetCapabilities()
-	return Attenuations{
-		// Owner capabilities
-		{Cap: caps.Cap(CapOwner.String()), Rsc: NewResource(ResAccount, accountAddr)},
-
-		// Operation capabilities
-		{Cap: caps.Cap(capability.CAPEXECUTE.String()), Rsc: NewResource(ResTransaction, fmt.Sprintf("%s:*", accountAddr))},
-		{Cap: caps.Cap(capability.CAPPROPOSE.String()), Rsc: NewResource(ResTransaction, fmt.Sprintf("%s:*", accountAddr))},
-		{Cap: caps.Cap(capability.CAPSIGN.String()), Rsc: NewResource(ResTransaction, fmt.Sprintf("%s:*", accountAddr))},
-
-		// Policy capabilities
-		{Cap: caps.Cap(capability.CAPSETPOLICY.String()), Rsc: NewResource(ResPolicy, fmt.Sprintf("%s:*", accountAddr))},
-		{Cap: caps.Cap(capability.CAPSETTHRESHOLD.String()), Rsc: NewResource(ResPolicy, fmt.Sprintf("%s:threshold", accountAddr))},
-	}
-}
-
-// NewSmartAccountPolicy creates attenuations for policy management
-func NewSmartAccountPolicy(
-	accountAddr string,
-	policyType policytype.PolicyType,
-) Attenuations {
-	caps := AccountPermissions.GetCapabilities()
-	return Attenuations{
-		{
-			Cap: caps.Cap(capability.CAPSETPOLICY.String()),
-			Rsc: NewResource(
-				ResPolicy,
-				fmt.Sprintf("%s:%s", accountAddr, policyType),
-			),
-		},
-	}
-}
-
-// SmartAccountCapabilities defines the capability hierarchy
-func SmartAccountCapabilities() []string {
-	return []string{
-		CapOwner.String(),
-		CapOperator.String(),
-		CapObserver.String(),
-		CapExecute.String(),
-		CapPropose.String(),
-		CapSign.String(),
-		CapSetPolicy.String(),
-		CapSetThreshold.String(),
-		CapRecover.String(),
-		CapSocial.String(),
-	}
-}
-
-// CreateVaultAttenuations creates default attenuations for a smart account
-func NewService(
-	origin string,
-) Attenuations {
-	caps := ServicePermissions.GetCapabilities()
-	return Attenuations{
-		// Owner capabilities
-		{Cap: caps.Cap(capability.CAPOWNER.String()), Rsc: NewResource(resourcetype.RESACCOUNT, origin)},
-
-		// Operation capabilities
-		{Cap: caps.Cap(capability.CAPEXECUTE.String()), Rsc: NewResource(resourcetype.RESTRANSACTION, fmt.Sprintf("%s:*", origin))},
-		{Cap: caps.Cap(capability.CAPPROPOSE.String()), Rsc: NewResource(resourcetype.RESTRANSACTION, fmt.Sprintf("%s:*", origin))},
-		{Cap: caps.Cap(capability.CAPSIGN.String()), Rsc: NewResource(resourcetype.RESTRANSACTION, fmt.Sprintf("%s:*", origin))},
-
-		// Policy capabilities
-		{Cap: caps.Cap(capability.CAPSETPOLICY.String()), Rsc: NewResource(resourcetype.RESPOLICY, fmt.Sprintf("%s:*", origin))},
-		{Cap: caps.Cap(capability.CAPSETTHRESHOLD.String()), Rsc: NewResource(resourcetype.RESPOLICY, fmt.Sprintf("%s:threshold", origin))},
-	}
-}
-
-// ServiceCapabilities defines the capability hierarchy
-func ServiceCapabilities() []string {
-	return []string{
-		CapOwner.String(),
-		CapOperator.String(),
-		CapObserver.String(),
-		CapExecute.String(),
-		CapPropose.String(),
-		CapSign.String(),
-		CapResolver.String(),
-		CapProducer.String(),
-	}
-}
-
-// NewVault creates default attenuations for a smart account
-func NewVault(
-	kss mpc.Keyset,
-) Attenuations {
-	accountAddr, err := mpc.ComputeSonrAddr(kss.User().GetPublicKey())
-	if err != nil {
-		return nil
-	}
-	caps := VaultPermissions.GetCapabilities()
-	return Attenuations{
-		// Owner capabilities
-		{Cap: caps.Cap(capability.CAPOWNER.String()), Rsc: NewResource(resourcetype.RESACCOUNT, accountAddr)},
-
-		// Operation capabilities
-		{Cap: caps.Cap(capability.CAPEXECUTE.String()), Rsc: NewResource(resourcetype.RESTRANSACTION, fmt.Sprintf("%s:*", accountAddr))},
-		{Cap: caps.Cap(capability.CAPPROPOSE.String()), Rsc: NewResource(resourcetype.RESTRANSACTION, fmt.Sprintf("%s:*", accountAddr))},
-		{Cap: caps.Cap(capability.CAPSIGN.String()), Rsc: NewResource(resourcetype.RESTRANSACTION, fmt.Sprintf("%s:*", accountAddr))},
-
-		// Policy capabilities
-		{Cap: caps.Cap(capability.CAPSETPOLICY.String()), Rsc: NewResource(resourcetype.RESPOLICY, fmt.Sprintf("%s:*", accountAddr))},
-		{Cap: caps.Cap(capability.CAPSETTHRESHOLD.String()), Rsc: NewResource(resourcetype.RESPOLICY, fmt.Sprintf("%s:threshold", accountAddr))},
-	}
-}
-
-// NewVaultPolicy creates attenuations for policy management
-func NewVaultPolicy(
-	accountAddr string,
-	policyType policytype.PolicyType,
-) Attenuations {
-	caps := VaultPermissions.GetCapabilities()
-	return Attenuations{
-		{
-			Cap: caps.Cap(capability.CAPSETPOLICY.String()),
-			Rsc: NewResource(
-				resourcetype.RESPOLICY,
-				fmt.Sprintf("%s:%s", accountAddr, policyType),
-			),
-		},
-	}
-}
-
-// VaultCapabilities defines the capability hierarchy
-func VaultCapabilities() []string {
-	return []string{
-		CapOwner.String(),
-		CapOperator.String(),
-		CapObserver.String(),
-		CapAuthenticate.String(),
-		CapAuthorize.String(),
-		CapDelegate.String(),
-		CapInvoke.String(),
-		CapExecute.String(),
-		CapRecover.String(),
-	}
-}

crypto/ucan/context.go

@@ -1,27 +0,0 @@
-package ucan
-
-import (
-	"context"
-)
-
-// CtxKey defines a distinct type for context keys used by the access
-// package
-type CtxKey string
-
-// TokenCtxKey is the key for adding an access UCAN to a context.Context
-const TokenCtxKey CtxKey = "UCAN"
-
-// CtxWithToken adds a UCAN value to a context
-func CtxWithToken(ctx context.Context, t Token) context.Context {
-	return context.WithValue(ctx, TokenCtxKey, t)
-}
-
-// FromCtx extracts a token from a given context if one is set, returning nil
-// otherwise
-func FromCtx(ctx context.Context) *Token {
-	iface := ctx.Value(TokenCtxKey)
-	if ref, ok := iface.(*Token); ok {
-		return ref
-	}
-	return nil
-}

crypto/ucan/didkey/key_test.go

@@ -1,86 +0,0 @@
-package didkey
-
-import (
-	"log"
-	"testing"
-
-	"github.com/libp2p/go-libp2p/core/crypto"
-	"github.com/onsonr/sonr/crypto/mpc"
-)
-
-func TestID_Parse(t *testing.T) {
-	keyStrED := "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"
-	id, err := Parse(keyStrED)
-	if err != nil {
-		t.Fatal(err)
-	}
-
-	if id.String() != keyStrED {
-		t.Errorf("string mismatch.\nwant: %q\ngot:  %q", keyStrED, id.String())
-	}
-
-	keyStrRSA := "did:key:z2MGw4gk84USotaWf4AkJ83DcnrfgGaceF86KQXRYMfQ7xqnUFp38UZ6Le8JPfkb4uCLGjHBzKpjEXb9hx9n2ftecQWCHXKtKszkke4FmENdTZ7i9sqRmL3pLnEEJ774r3HMuuC7tNRQ6pqzrxatXx2WinCibdhUmvh3FobnA9ygeqkSGtV6WLa7NVFw9cAvnv8Y6oHcaoZK7fNP4ASGs6AHmSC6ydSR676aKYMe95QmEAj4xJptDsSxG7zLAGzAdwCgm56M4fTno8GdWNmU6Pdghnuf6fWyYus9ASwdfwyaf3SDf4uo5T16PRJssHkQh6DJHfK4Rka7RNQLjzfGBPjFLHbUSvmf4EdbHasbVaveAArD68ZfazRCCvjdovQjWr6uyLCwSAQLPUFZBTT8mW"
-
-	id, err = Parse(keyStrRSA)
-	if err != nil {
-		t.Fatal(err)
-	}
-
-	if id.String() != keyStrRSA {
-		t.Errorf("string mismatch.\nwant: %q\ngot:  %q", keyStrRSA, id.String())
-	}
-}
-
-func TestID_FromMPCKey(t *testing.T) {
-	// Generate new MPC keyset
-	ks, err := mpc.NewKeyset()
-	if err != nil {
-		t.Fatalf("failed to generate MPC keyset: %v", err)
-	}
-
-	// Get public key from validator share
-	pubKey := ks.Val().PublicKey()
-	if len(pubKey) != 65 {
-		t.Fatalf("expected 65-byte uncompressed public key, got %d bytes", len(pubKey))
-	}
-
-	// Create crypto.PubKey from raw bytes
-	cryptoPubKey, err := crypto.UnmarshalSecp256k1PublicKey(pubKey)
-	if err != nil {
-		t.Fatalf("failed to unmarshal public key: %v", err)
-	}
-
-	// Create DID Key ID
-	id, err := NewID(cryptoPubKey)
-	if err != nil {
-		t.Fatalf("failed to create DID Key ID: %v", err)
-	}
-	log.Printf("%s\n", id.String())
-
-	// Verify the key can be parsed back
-	parsed, err := Parse(id.String())
-	if err != nil {
-		t.Fatalf("failed to parse DID Key string: %v", err)
-	}
-
-	// Verify the parsed key matches original
-	if parsed.String() != id.String() {
-		t.Errorf("parsed key doesn't match original.\nwant: %q\ngot:  %q",
-			id.String(), parsed.String())
-	}
-
-	// Verify we can get back a valid verify key
-	verifyKey, err := id.VerifyKey()
-	if err != nil {
-		t.Fatalf("failed to get verify key: %v", err)
-	}
-
-	// Verify the key is the right type and length
-	rawKey, ok := verifyKey.([]byte)
-	if !ok {
-		t.Fatalf("expected []byte verify key, got %T", verifyKey)
-	}
-	if len(rawKey) != 65 && len(rawKey) != 33 {
-		t.Errorf("invalid key length %d, expected 65 or 33 bytes", len(rawKey))
-	}
-}

crypto/ucan/exports.go

@@ -1,164 +0,0 @@
-package ucan
-
-import (
-	"fmt"
-
-	"github.com/onsonr/sonr/crypto/ucan/attns/capability"
-	"github.com/onsonr/sonr/crypto/ucan/attns/policytype"
-	"github.com/onsonr/sonr/crypto/ucan/attns/resourcetype"
-)
-
-var EmptyAttenuation = Attenuation{
-	Cap: Capability(nil),
-	Rsc: Resource(nil),
-}
-
-const (
-	// Owner
-	CapOwner    = capability.CAPOWNER
-	CapOperator = capability.CAPOPERATOR
-	CapObserver = capability.CAPOBSERVER
-
-	// Auth
-	CapAuthenticate = capability.CAPAUTHENTICATE
-	CapAuthorize    = capability.CAPAUTHORIZE
-	CapDelegate     = capability.CAPDELEGATE
-	CapInvoke       = capability.CAPINVOKE
-	CapExecute      = capability.CAPEXECUTE
-	CapPropose      = capability.CAPPROPOSE
-	CapSign         = capability.CAPSIGN
-	CapSetPolicy    = capability.CAPSETPOLICY
-	CapSetThreshold = capability.CAPSETTHRESHOLD
-	CapRecover      = capability.CAPRECOVER
-	CapSocial       = capability.CAPSOCIAL
-	CapResolver     = capability.CAPRESOLVER
-	CapProducer     = capability.CAPPRODUCER
-
-	// Resources
-	ResAccount     = resourcetype.RESACCOUNT
-	ResTransaction = resourcetype.RESTRANSACTION
-	ResPolicy      = resourcetype.RESPOLICY
-	ResRecovery    = resourcetype.RESRECOVERY
-	ResVault       = resourcetype.RESVAULT
-	ResIPFS        = resourcetype.RESIPFS
-	ResIPNS        = resourcetype.RESIPNS
-	ResKeyShare    = resourcetype.RESKEYSHARE
-
-	// PolicyTypes
-	PolicyThreshold = policytype.POLICYTHRESHOLD
-	PolicyTimelock  = policytype.POLICYTIMELOCK
-	PolicyWhitelist = policytype.POLICYWHITELIST
-	PolicyKeyShare  = policytype.POLICYKEYGEN
-)
-
-// NewVaultResource creates a new resource identifier
-func NewResource(resType resourcetype.ResourceType, path string) Resource {
-	return NewStringLengthResource(string(resType), path)
-}
-
-// Permissions represents the type of attenuation
-type Permissions string
-
-const (
-	// AccountPermissions represents the smart account attenuation
-	AccountPermissions = Permissions("account")
-
-	// ServicePermissions represents the service attenuation
-	ServicePermissions = Permissions("service")
-
-	// VaultPermissions represents the vault attenuation
-	VaultPermissions = Permissions("vault")
-)
-
-// Cap returns the capability for the given AttenuationPreset
-func (a Permissions) NewCap(c capability.Capability) Capability {
-	return a.GetCapabilities().Cap(c.String())
-}
-
-// NestedCapabilities returns the nested capabilities for the given AttenuationPreset
-func (a Permissions) GetCapabilities() NestedCapabilities {
-	var caps []string
-	switch a {
-	case AccountPermissions:
-		caps = SmartAccountCapabilities()
-	case VaultPermissions:
-		caps = VaultCapabilities()
-	}
-	return NewNestedCapabilities(caps...)
-}
-
-// Equals returns true if the given AttenuationPreset is equal to the receiver
-func (a Permissions) Equals(b Permissions) bool {
-	return a == b
-}
-
-// String returns the string representation of the AttenuationPreset
-func (a Permissions) String() string {
-	return string(a)
-}
-
-// GetConstructor returns the AttenuationConstructorFunc for a Permission
-func (a Permissions) GetConstructor() AttenuationConstructorFunc {
-	return NewAttenuationFromPreset(a)
-}
-
-// NewAttenuationFromPreset creates an AttenuationConstructorFunc for the given preset
-func NewAttenuationFromPreset(preset Permissions) AttenuationConstructorFunc {
-	return func(v map[string]interface{}) (Attenuation, error) {
-		// Extract capability and resource from map
-		capStr, ok := v["cap"].(string)
-		if !ok {
-			return EmptyAttenuation, fmt.Errorf("missing or invalid capability in attenuation data")
-		}
-
-		resType, ok := v["type"].(string)
-		if !ok {
-			return EmptyAttenuation, fmt.Errorf("missing or invalid resource type in attenuation data")
-		}
-
-		path, ok := v["path"].(string)
-		if !ok {
-			path = "/" // Default path if not specified
-		}
-
-		// Create capability from preset
-		cap := preset.NewCap(capability.Capability(capStr))
-		if cap == nil {
-			return EmptyAttenuation, fmt.Errorf("invalid capability %s for preset %s", capStr, preset)
-		}
-
-		// Create resource
-		resource := NewResource(resourcetype.ResourceType(resType), path)
-
-		return Attenuation{
-			Cap: cap,
-			Rsc: resource,
-		}, nil
-	}
-}
-
-// GetPresetConstructor returns the appropriate AttenuationConstructorFunc for a given type
-func GetPresetConstructor(attType string) (AttenuationConstructorFunc, error) {
-	preset := Permissions(attType)
-	switch preset {
-	case AccountPermissions, ServicePermissions, VaultPermissions:
-		return NewAttenuationFromPreset(preset), nil
-	default:
-		return nil, fmt.Errorf("unknown attenuation preset: %s", attType)
-	}
-}
-
-// ParseAttenuationData parses raw attenuation data into a structured format
-func ParseAttenuationData(data map[string]interface{}) (Permissions, map[string]interface{}, error) {
-	typeRaw, ok := data["preset"]
-	if !ok {
-		return "", nil, fmt.Errorf("missing preset type in attenuation data")
-	}
-
-	presetType, ok := typeRaw.(string)
-	if !ok {
-		return "", nil, fmt.Errorf("invalid preset type format")
-	}
-
-	return Permissions(presetType), data, nil
-}

crypto/ucan/exports_test.go

@@ -1,62 +0,0 @@
-package ucan
-
-import (
-	"testing"
-
-	"github.com/stretchr/testify/assert"
-)
-
-func TestAttenuationPresetConstructor(t *testing.T) {
-	tests := []struct {
-		name    string
-		data    map[string]interface{}
-		wantErr bool
-	}{
-		{
-			name: "valid smart account attenuation",
-			data: map[string]interface{}{
-				"preset": "account",
-				"cap":    string(CapOwner),
-				"type":   string(ResAccount),
-				"path":   "/accounts/123",
-			},
-			wantErr: false,
-		},
-		{
-			name: "valid vault attenuation",
-			data: map[string]interface{}{
-				"preset": "vault",
-				"cap":    string(CapOperator),
-				"type":   string(ResVault),
-				"path":   "/vaults/456",
-			},
-			wantErr: false,
-		},
-	}
-
-	for _, tt := range tests {
-		t.Run(tt.name, func(t *testing.T) {
-			preset, data, err := ParseAttenuationData(tt.data)
-			if tt.wantErr {
-				assert.Error(t, err)
-				return
-			}
-			assert.NoError(t, err)
-
-			constructor, err := GetPresetConstructor(preset.String())
-			if tt.wantErr {
-				assert.Error(t, err)
-				return
-			}
-			assert.NoError(t, err)
-
-			attenuation, err := constructor(data)
-			if tt.wantErr {
-				assert.Error(t, err)
-				return
-			}
-			assert.NoError(t, err)
-			assert.NotNil(t, attenuation)
-		})
-	}
-}

crypto/ucan/spec/jwt.go

@@ -1,98 +0,0 @@
-package spec
-
-import (
-	"crypto/sha256"
-	"encoding/base64"
-	"fmt"
-
-	"github.com/golang-jwt/jwt"
-	"github.com/onsonr/sonr/crypto/mpc"
-)
-
-// MPCSigningMethod implements the SigningMethod interface for MPC-based signing
-type MPCSigningMethod struct {
-	Name string
-	ks   ucanKeyshare
-}
-
-// NewJWTSigningMethod creates a new MPC signing method with the given keyshare source
-func NewJWTSigningMethod(name string, ks ucanKeyshare) *MPCSigningMethod {
-	return &MPCSigningMethod{
-		Name: name,
-		ks:   ks,
-	}
-}
-
-// Alg returns the signing method's name
-func (m *MPCSigningMethod) Alg() string {
-	return m.Name
-}
-
-// Verify verifies the signature using the MPC public key
-func (m *MPCSigningMethod) Verify(signingString, signature string, key interface{}) error {
-	// Decode the signature
-	sig, err := base64.RawURLEncoding.DecodeString(signature)
-	if err != nil {
-		return err
-	}
-
-	// Hash the signing string
-	hasher := sha256.New()
-	hasher.Write([]byte(signingString))
-	digest := hasher.Sum(nil)
-
-	// Verify using the keyshare's public key
-	valid, err := mpc.VerifySignature(m.ks.valShare.PublicKey(), digest, sig)
-	if err != nil {
-		return fmt.Errorf("failed to verify signature: %w", err)
-	}
-	if !valid {
-		return fmt.Errorf("invalid signature")
-	}
-
-	return nil
-}
-
-// Sign signs the data using MPC
-func (m *MPCSigningMethod) Sign(signingString string, key interface{}) (string, error) {
-	// Hash the signing string
-	hasher := sha256.New()
-	hasher.Write([]byte(signingString))
-	digest := hasher.Sum(nil)
-
-	// Create signing functions
-	signFunc, err := m.ks.userShare.SignFunc(digest)
-	if err != nil {
-		return "", fmt.Errorf("failed to create sign function: %w", err)
-	}
-
-	valSignFunc, err := m.ks.valShare.SignFunc(digest)
-	if err != nil {
-		return "", fmt.Errorf("failed to create validator sign function: %w", err)
-	}
-
-	// Run the signing protocol
-	sig, err := mpc.ExecuteSigning(valSignFunc, signFunc)
-	if err != nil {
-		return "", fmt.Errorf("failed to run sign protocol: %w", err)
-	}
-
-	// Serialize the signature
-	sigBytes, err := mpc.SerializeSignature(sig)
-	if err != nil {
-		return "", fmt.Errorf("failed to serialize signature: %w", err)
-	}
-
-	// Encode the signature
-	encoded := base64.RawURLEncoding.EncodeToString(sigBytes)
-	return encoded, nil
-}
-
-func init() {
-	// Register the MPC signing method
-	jwt.RegisterSigningMethod("MPC256", func() jwt.SigningMethod {
-		return &MPCSigningMethod{
-			Name: "MPC256",
-		}
-	})
-}

deploy/README.md

@@ -1,42 +0,0 @@
-# Deployment
-
-This directory contains the configuration files for deploying the Sonr blockchain.
-
-## Contents
-
-- `devnet`: Configuration for deploying the Sonr blockchain on the devnet (local development).
-- `testnet`: Configuration for deploying the Sonr blockchain on the testnet (current prod setup)
-
-## Usage
-
-Configuration is automatically loaded from the `PKL` files in the root of the repository. These templates are generated during deployment initialization.
-
-To deploy the total network, run the following command:
-
-```bash
-devbox run <network>
-```
-
-Replace `<network>` with either `devnet` or `testnet` from the root of the repository.
-
-## Components
-
-### Sonr
-
-The Sonr blockchain is deployed using the `sonrd` binary. This binary is built using the `Makefile` in the root of the repository.
-
-### IPFS
-
-IPFS is deployed using the `ipfs` binary. This binary is built using the `Makefile` in the root of the repository.
-
-### Hway
-
-Hway is deployed using the `hway` binary. This binary is built using the `Makefile` in the root of the repository.
-
-### Synapse
-
-Synapse is deployed using the `matrix-synapse` binary. This binary is built using the `Makefile` in the root of the repository.
-
-### Tigerbeetle
-
-Tigerbeetle is deployed using the `tigerbeetle` binary. This binary is built using the `Makefile` in the root of the repository.

deploy/config/ipfs.config.pkl

@@ -1,202 +0,0 @@
-import "https://pkl.sh/ipfs.net/0.0.1/Config.pkl"
-
-API {
-  HTTPHeaders {
-    `Access-Control-Allow-Origin` = new { "*" }
-  }
-}
-
-Addresses {
-  API = "/ip4/127.0.0.1/tcp/5001"
-  Gateway = "/ip4/127.0.0.1/tcp/8080"
-  Swarm = new {
-    "/ip4/0.0.0.0/tcp/4001"
-    "/ip6/::/tcp/4001"
-    "/ip4/0.0.0.0/udp/4001/quic"
-    "/ip6/::/udp/4001/quic"
-  }
-}
-
-Bootstrap {
-  "/dnsaddr/bootstrap.libp2p.io/p2p/QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa"
-  "/dnsaddr/bootstrap.libp2p.io/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
-  "/dnsaddr/bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt"
-  "/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"
-  "/ip4/104.131.131.82/udp/4001/quic/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"
-  "/dnsaddr/bootstrap.libp2p.io/p2p/QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN"
-}
-
-Datastore {
-  BloomFilterSize = 0
-  GCPeriod = "1h"
-  HashOnRead = false
-  StorageGCWatermark = 90
-  StorageMax = "10GB"
-  Spec = new {
-    mounts = new {
-      new {
-        prefix = "flatfs.datastore"
-        child = new {
-          path = "blocks"
-          shardFunc = "/repo/flatfs/shard/v1/next-to-last/2"
-          type = "flatfs"
-          sync = true
-        }
-        mountpoint = "/blocks"
-        type = "measure"
-      }
-      new {
-        prefix = "leveldb.datastore"
-        child = new {
-          compression = "none"
-          path = "datastore"
-          type = "levelds"
-        }
-        mountpoint = "/"
-        type = "measure"
-      }
-    }
-    type = "mount"
-  }
-}
-
-Discovery {
-  MDNS = new {
-    Enabled = true
-  }
-}
-
-Experimental {
-  StrategicProviding = false
-  UrlstoreEnabled = false
-  AcceleratedDHTClient = false
-  GraphsyncEnabled = false
-  FilestoreEnabled = false
-  Libp2pStreamMounting = false
-  P2pHttpProxy = false
-}
-
-Gateway {
-  HTTPHeaders = new {
-    `Access-Control-Allow-Headers` = new {
-      "X-Requested-With"
-      "Range"
-      "User-Agent"
-    } 
-    `Access-Control-Allow-Methods` = new { "GET" }
-    `Access-Control-Allow-Origin` = new { "*" }
-  }
-  NoDNSLink = false
-  NoFetch = false
-  PublicGateways = null
-  RootRedirect = ""
-  Writable = false
-}
-
-Identity {
-  PrivKey = "CAESQP0FRhYf5Nvxg0wrbN+VTK7kWdgy+3AKoxU3vNH0K9FHVpXyx6/mHKyCaPjqI11YsHUW0B2ZODGROPafyS6IeWY="
-  PeerID = "12D3KooWFeMr1tHFs8WAF11rKDULJbmKg9rE5aVhYJU23oC7pqjB"
-}
-
-Ipns {
-  RecordLifetime = ""
-  RepublishPeriod = ""
-  ResolveCacheSize = 128
-}
-
-Migration  {
-  Keep = ""
-}
-
-Mounts {
-  IPNS = "/ipns"
-  FuseAllowOther = false
-  IPFS = "/ipfs"
-}
-
-Peering {
-  Peers = new {
-    new {
-      Addrs = new { "/dnsaddr/node-1.ingress.cloudflare-ipfs.com" }
-      ID = "QmcFf2FH3CEgTNHeMRGhN7HNHU1EXAxoEk6EFuSyXCsvRE"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-2.ingress.cloudflare-ipfs.com" }
-      ID = "QmcFmLd5ySfk2WZuJ1mfSWLDjdmHZq7rSAua4GoeSQfs1z"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-3.ingress.cloudflare-ipfs.com" }
-      ID = "QmcfFmzSDVbwexQ9Au2pt5YEXHK5xajwgaU6PpkbLWerMa"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-4.ingress.cloudflare-ipfs.com" }
-      ID = "QmcfJeB3Js1FG7T8YaZATEiaHqNKVdQfybYYkbT1knUswx"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-5.ingress.cloudflare-ipfs.com" }
-      ID = "QmcfVvzK4tMdFmpJjEKDUoqRgP4W9FnmJoziYX5GXJJ8eZ"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-6.ingress.cloudflare-ipfs.com" }
-      ID = "QmcfZD3VKrUxyP9BbyUnZDpbqDnT7cQ4WjPP8TRLXaoE7G"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-7.ingress.cloudflare-ipfs.com" }
-      ID = "QmcfZP2LuW4jxviTeG8fi28qjnZScACb8PEgHAc17ZEri3"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-8.ingress.cloudflare-ipfs.com" }
-      ID = "QmcfgsJsMtx6qJb74akCw1M24X1zFwgGo11h1cuhwQjtJP"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-9.ingress.cloudflare-ipfs.com" }
-      ID = "Qmcfr2FC7pFzJbTSDfYaSy1J8Uuy8ccGLeLyqJCKJvTHMi"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-10.ingress.cloudflare-ipfs.com" }
-      ID = "QmcfR3V5YAtHBzxVACWCzXTt26SyEkxdwhGJ6875A8BuWx"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-11.ingress.cloudflare-ipfs.com" }
-      ID = "Qmcfuo1TM9uUiJp6dTbm915Rf1aTqm3a3dnmCdDQLHgvL5"
-    }
-    new {
-      Addrs = new { "/dnsaddr/node-12.ingress.cloudflare-ipfs.com" }
-      ID = "QmcfV2sg9zaq7UUHVCGuSvT2M2rnLBAPsiE79vVyK3Cuev"
-    }
-  }
-}
-
-Provider {
-  Strategy = ""
-}
-
-Pubsub {
-  Router = ""
-  DisableSigning = false
-}
-
-Reprovider {
-  Strategy = "all"
-  Interval = "12h"
-}
-
-Routing {
-  Methods = null
-  Routers = null
-  Type = "dht"
-}
-
-Swarm {
-  AddrFilters = null
-  ConnMgr = new {}
-  DisableBandwidthMetrics = false
-  DisableNatPortMap = false
-  RelayClient = new {}
-  ResourceMgr = new {}
-  Transports = new {
-    Multiplexers = new {}
-    Network = new {}
-    Security = new {}
-  }
-}

deploy/config/sonr.app.pkl

@@ -1,3 +0,0 @@
-amends "https://pkl.sh/sonr.chain/0.0.2/App.pkl"
-
-

deploy/config/sonr.config.pkl

@@ -1,3 +0,0 @@
-amends "https://pkl.sh/sonr.chain/0.0.2/Genesis.pkl"
-
-

deploy/process-compose.yaml

@@ -1,12 +0,0 @@
-version: "0.6"
-
-processes:
-  sonr:
-    namespace: devnet
-    command: "make sh-testnet"
-
-  hway:
-    namespace: devnet
-    command: "./build/hway"
-    depends:
-      - sonr

deploy/sink/schema.sql

@@ -1,85 +0,0 @@
-/*
-  This file defines the database schema for the PostgresQL ("psql") event sink
-  implementation in CometBFT. The operator must create a database and install
-  this schema before using the database to index events.
- */
-
--- The blocks table records metadata about each block.
--- The block record does not include its events or transactions (see tx_results).
-CREATE TABLE blocks (
-  rowid      BIGSERIAL PRIMARY KEY,
-
-  height     BIGINT NOT NULL,
-  chain_id   VARCHAR NOT NULL,
-
-  -- When this block header was logged into the sink, in UTC.
-  created_at TIMESTAMPTZ NOT NULL,
-
-  UNIQUE (height, chain_id)
-);
-
--- Index blocks by height and chain, since we need to resolve block IDs when
--- indexing transaction records and transaction events.
-CREATE INDEX idx_blocks_height_chain ON blocks(height, chain_id);
-
--- The tx_results table records metadata about transaction results.  Note that
--- the events from a transaction are stored separately.
-CREATE TABLE tx_results (
-  rowid BIGSERIAL PRIMARY KEY,
-
-  -- The block to which this transaction belongs.
-  block_id BIGINT NOT NULL REFERENCES blocks(rowid),
-  -- The sequential index of the transaction within the block.
-  index INTEGER NOT NULL,
-  -- When this result record was logged into the sink, in UTC.
-  created_at TIMESTAMPTZ NOT NULL,
-  -- The hex-encoded hash of the transaction.
-  tx_hash VARCHAR NOT NULL,
-  -- The protobuf wire encoding of the TxResult message.
-  tx_result BYTEA NOT NULL,
-
-  UNIQUE (block_id, index)
-);
-
--- The events table records events. All events (both block and transaction) are
--- associated with a block ID; transaction events also have a transaction ID.
-CREATE TABLE events (
-  rowid BIGSERIAL PRIMARY KEY,
-
-  -- The block and transaction this event belongs to.
-  -- If tx_id is NULL, this is a block event.
-  block_id BIGINT NOT NULL REFERENCES blocks(rowid),
-  tx_id    BIGINT NULL REFERENCES tx_results(rowid),
-
-  -- The application-defined type label for the event.
-  type VARCHAR NOT NULL
-);
-
--- The attributes table records event attributes.
-CREATE TABLE attributes (
-   event_id      BIGINT NOT NULL REFERENCES events(rowid),
-   key           VARCHAR NOT NULL, -- bare key
-   composite_key VARCHAR NOT NULL, -- composed type.key
-   value         VARCHAR NULL,
-
-   UNIQUE (event_id, key)
-);
-
--- A joined view of events and their attributes. Events that do not have any
--- attributes are represented as a single row with empty key and value fields.
-CREATE VIEW event_attributes AS
-  SELECT block_id, tx_id, type, key, composite_key, value
-  FROM events LEFT JOIN attributes ON (events.rowid = attributes.event_id);
-
--- A joined view of all block events (those having tx_id NULL).
-CREATE VIEW block_events AS
-  SELECT blocks.rowid as block_id, height, chain_id, type, key, composite_key, value
-  FROM blocks JOIN event_attributes ON (blocks.rowid = event_attributes.block_id)
-  WHERE event_attributes.tx_id IS NULL;
-
--- A joined view of all transaction events.
-CREATE VIEW tx_events AS
-  SELECT height, index, chain_id, type, key, composite_key, value, tx_results.created_at
-  FROM blocks JOIN tx_results ON (blocks.rowid = tx_results.block_id)
-  JOIN event_attributes ON (tx_results.rowid = event_attributes.tx_id)
-  WHERE event_attributes.tx_id IS NOT NULL;

docs/CNAME

@@ -1 +0,0 @@
-onsonr.dev

docs/docs/concepts/Chain-Modules.md

@@ -1,104 +0,0 @@
-## `x/did` - Auth & AuthZ
-
-> The DID module is responsible for managing the creation and management of DIDs.
-> Controllers represent on-chain accounts backed by a MPC keypair. Controllers
-> provide methods for Wallet Account Abstraction (WAA) and are responsible for
-> managing the creation and management of DIDs for an individual user.
-
-### Features
-
-- DID Controllers leverage the Cosmos SDK's `x/accounts` std interface for WAA.
-- DIDs are represented by a `x/did` controller and are required to state the
-  controller's public key, and which map to the controller's capabilities.
-- General Sign/Verify methods are provides from the QueryServer for HTTP requests.
-- The Execute method is used to broadcast transactions across the network. (TODO)
-- Biscuits are used to authenticate and authorize requests between services. (TODO)
-
-### References
-
-- [State](https://github.com/onsonr/sonr/tree/develop/x/did#state)
-- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/did#state-transitions)
-- [Messages](https://github.com/onsonr/sonr/tree/develop/x/did#messages)
-- [Queries](https://github.com/onsonr/sonr/tree/develop/x/did#query)
-- [Params](https://github.com/onsonr/sonr/tree/develop/x/did#params)
-- [Client](https://github.com/onsonr/sonr/tree/develop/x/did#client)
-- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/did#future-improvements)
-- [Tests](https://github.com/onsonr/sonr/tree/develop/x/did#tests)
-- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/did#appendix)
-
----
-
-## `x/macaroon`
-
-> The macaroon module is responsible for issuing and verifying macaroons. Macaroons
-> are used to authenticate and authorize requests between services.
-> Macaroons are requested by NFT Records from [`x/service`](2-‐-Modules-Overview.md#x-service) and granted by controllers from [`x/did`](2-‐-Modules-Overview.md#x/did)
-
-### Features
-
-- On Controller creation, a macaroon is created with an admin scope and a default expiry of _315,569,520 blocks (or ~10 years)_.
-- On Service registration, a macaroon is created with a service scope and a default expiry of _31,556,952 blocks (or ~1 year)_.
-- Macaroons contain the scope of access for a service and the expiry of the permissions in `blockHeight`.
-
-### References
-
-- [State](https://github.com/onsonr/sonr/tree/develop/x/macaroon#state)
-- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/macaroon#state-transitions)
-- [Messages](https://github.com/onsonr/sonr/tree/develop/x/macaroon#messages)
-- [Queries](https://github.com/onsonr/sonr/tree/develop/x/macaroon#query)
-- [Params](https://github.com/onsonr/sonr/tree/develop/x/macaroon#params)
-- [Client](https://github.com/onsonr/sonr/tree/develop/x/macaroon#client)
-- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/macaroon#future-improvements)
-- [Tests](https://github.com/onsonr/sonr/tree/develop/x/macaroon#tests)
-- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/macaroon#appendix)
-
----
-
-## `x/service`
-
-> The service module is responsible for managing decentralized services. Services
-> on the Sonr network are essentially on-chain MultiSig wallets that are
-> represented by a NFT. Service admins are represented by
-> a [`x/did`](2-‐-Modules-Overview.md#x-did) controller and are required to state
-> the service's scope of access, and which map to the services' capabilities.
-
-### Features
-
-- Needs a Valid Domain with .htaccess file to be whitelisted.
-
-### References
-
-- [State](https://github.com/onsonr/sonr/tree/develop/x/service#state)
-- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/service#state-transitions)
-- [Messages](https://github.com/onsonr/sonr/tree/develop/x/service#messages)
-- [Queries](https://github.com/onsonr/sonr/tree/develop/x/service#query)
-- [Params](https://github.com/onsonr/sonr/tree/develop/x/service#params)
-- [Client](https://github.com/onsonr/sonr/tree/develop/x/service#client)
-- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/service#future-improvements)
-- [Tests](https://github.com/onsonr/sonr/tree/develop/x/service#tests)
-- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/service#appendix)
-
----
-
-## `x/vault`
-
-> The vault module is responsible for managing the storage and acccess-control of
-> Decentralized Web Nodes (DWNs) from IPFS. Vaults contain user-facing keys and
-> are represented by a [`x/did`](2-‐-Modules-Overview.md#x-did) controller.
-
-### Features
-
-- Vaults can be created by anyone, but efforts are made to restrict 1 per user.
-- Vaults are stored in IPFS and when claimed, the bech32 Sonr Address is pinned to IPFS.
-
-### References
-
-- [State](https://github.com/onsonr/sonr/tree/develop/x/vault#state)
-- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/vault#state-transitions)
-- [Messages](https://github.com/onsonr/sonr/tree/develop/x/vault#messages)
-- [Queries](https://github.com/onsonr/sonr/tree/develop/x/vault#query)
-- [Params](https://github.com/onsonr/sonr/tree/develop/x/vault#params)
-- [Client](https://github.com/onsonr/sonr/tree/develop/x/vault#client)
-- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/vault#future-improvements)
-- [Tests](https://github.com/onsonr/sonr/tree/develop/x/vault#tests)
-- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/vault#appendix)

docs/docs/concepts/Consumer-Launch.md

@@ -1,170 +0,0 @@
-# Consumer Chain Launch Process
-
-This guide is intended for consumer chain teams that are looking to be onboarded on to the Interchain Security testnet.
-
-## Interchain Security Testnet Overview
-
-- The Interchain Security (ICS) testnet is to be used to launch and test consumer chains. We recommend consumer chains to launch on the testnet before launching on the mainnet.
-- All information about the ICS testnet is available in this [repository](https://github.com/cosmos/testnets/tree/master/interchain-security).
-- The testnet coordinators (Hypha) have majority voting power in the ICS testnet. This means we need to work with you to bring your chain live and also to successfully pass any governance proposals you make.
-
-## Chain Onboarding Process
-
-For teams looking to join the ICS testnet, the onboarding process can be broken down in four phases:
-
-- Testing and Integration
-- Planning with Testnet Coordinators
-- Proposal Submission
-- Chain Launch
-
-### Local Testing and Integration
-
-During this phase, your team will run integration tests with the following elements of an Interchain Security testnet:
-
-- Gaia provider chain
-  - Visit the provider chain [page](./provider/) for details on which Gaia version is currently being used.
-- Relayers
-  - You will be responsible for running the relayer that relays the first set of Validator Set Change packets between provider and consumer chain. You should be proficient in setting up and running either [Hermes](https://github.com/informalsystems/hermes) or [rly](https://github.com/cosmos/relayer).
-
-By the end of this phase, you are able to launch a consumer chain within a local testnet or CI workflow that resembles the testnet (or mainnet) environment.
-
-### Planning with Testnet Coordinators
-
-Once you have a binary release ready, you can begin planning the launch with the testnet coordinators (Hypha).
-
-The goals of this phase are to update this repository with all the information validators need to join the network and to produce a `consumer-addition` proposal to be submitted in the provider chain.
-
-We expect you to run the minimum infrastructure required to make your consumer chain usable by testnet participants. This means running:
-
-1. **Seed/persistent nodes**
-2. **Relayer** it must be launched before the chain times out, preferably right after blocks start being produced.
-   - **IMPORTANT**: Make sure you have funds to pay gas fees for the relayer. You will likely need to set up an adequately funded genesis account for this purpose.
-
-Additionally, you may want to run:
-
-- a faucet such as this simple [REST faucet](https://github.com/hyphacoop/cosmos-rest-faucet) (it may need a separate funded account in the genesis file as well)
-- a block explorer such as [ping.pub](https://github.com/ping-pub/explorer)
-
-## ✍️ Submitting a PR for a new chain
-
-Each consumer chain gets its own directory. You can use the [`slasher`](./stopped/slasher/) chain as reference. Feel free to clone the slasher directory, modify it for your consumer chain, and make a PR with the relevant information.
-
-Hypha will be reviewing the PR to ensure it meets the following criteria:
-
-#### README includes:
-
-- [ ] Consumer chain repo and release or tag name.
-- [ ] Build instructions for chain binary.
-- [ ] Checksum of genesis file without CCV.
-- [ ] Checksum of reference binary.
-- [ ] Instructions on to join
-- [ ] Installation steps
-- Endpoints
-  - [ ] Seeds OR persistent peers
-  - [ ] State sync nodes (if any)
-
-See the `slasher` chain [page](./stopped/slasher) for reference.
-
-#### `chain_id` must be identical in the following places:
-
-- [ ] `README`
-- [ ] genesis file
-- [ ] consumer addition proposal
-- [ ] bash script
-
-We recommend choosing a `chain_id` with the suffix `-1`, even if it's a subsequent test of the same chain, e.g. `testchain-second-rehearsal-1`.
-
-#### Binary checksum validation
-
-- [ ] `shasum -a 256 <binary>` matches the checksum in the proposal
-- [ ] `shasum -a 256 <binary>` matches `README`
-
-#### Bash script
-
-- [ ] version built in script must match `README`
-- [ ] seeds or persistent peers must match `README`
-
-#### Genesis file
-
-- [ ] Genesis time must match spawn time in the `consumer-addition` proposal
-- [ ] Accounts and balances: Properly funded accounts (e.g., gas fees for relayer, faucet, etc.)
-- [ ] Bank balance denom matches denom in `README`
-- [ ] Slashing parameters: Set `signed_blocks_window` and `min_signed_per_window` adequately to ensure validators have at least 12 hours to join the chain after launch without getting jailed
-- [ ] `shasum -a 256 <genesis file without CCV>` matches the checksum in the proposal
-- [ ] `shasum -a 256 <genesis file without CCV>` matches the checksum in the `README`
-- [ ] The genesis file is correctly formed: `<consumer binary or gaiad> validate-genesis /path/to/genesis-without-ccv.json` returns without error
-
-See the `slasher` chain [genesis](./stopped/slasher/slasher-genesis-without-ccv.json) for reference.
-
-#### `consumer-addition` proposal
-
-- [ ] Spawn time must match genesis time
-- [ ] Spawn time must be later than voting period
-- [ ] `revision_height: 1`
-- [ ] `revision_number: 1` (only if the `chain_id` ends in `-1`)
-- [ ] `transfer_timeout_period: 1800000000000`. This value should be smaller than `blocks_per_distribution_transmission * block_time`.
-- [ ] `ccv_timeout_period: 2419200000000000`. This value must be larger than the unbonding period, the default is 28 days.
-- [ ] `unbonding_period: 1728000000000000` (given current provider params)
-
-See the `slasher` chain consumer-addition [proposal](./stopped/slasher/proposal-slasher.json) and [Interchain Security time-based parameters](https://github.com/cosmos/interchain-security/blob/main/docs/params.md#time-based-parameters) for reference.
-
-#### Node configurations
-
-- [ ] `minimum_gas_prices`
-- [ ] Check with Hypha about any other chain-specific params
-
----
-
-### On-chain Proposal Submission
-
-When you make your proposal, please let us know well in advance. The current voting period is five minutes, which means we’ll need to vote right after you submit your proposal. We recommend submitting the proposal together with us on a call.
-
-The following will take place during the proposal submission phase:
-
-- Your team will submit the `consumer-addition` proposal with a command that looks like this:
-  ```
-  gaiad tx gov submit-legacy-proposal consumer-addition proposal.json --from <account name> --chain-id provider --gas auto --fees 500uatom -b block -y
-  ```
-- Testnet coordinators will vote on it shortly afterwards to make sure it passes.
-- You will open a pull request to add the new consumer chain entry to this repo and update the [schedule page](SCHEDULE.md) with the launch date.
-- You will announce the upcoming launch, including the spawn time, in the Interchain Security `announcements` channel of the Cosmos Network Discord Server. If you need permissions for posting, please reach out to us.
-
-### Chain Launch
-
-After the spawn time is reached, the Cross-Chain Validation (CCV) state will be available on the provider chain and the new IBC client will be created. At this point, you will be able to:
-
-- Collect the Cross-Chain Validation (CCV) state from the provider chain.
-  ```
-  gaiad q provider consumer-genesis <chain-id> -o json > ccv-state.json
-  ```
-- Update the genesis file with the CCV state.
-  ```
-  jq -s '.[0].app_state.ccvconsumer = .[1] | .[0]' <consumer genesis without CCV state> ccv-state.json > <consumer genesis file with CCV state>
-  ```
-- Publish the genesis file with CCV state to the testnets repo.
-- Post the link to the genesis file and the SHA256 hash to the Interchain Security `interchain-security-testnet` channel of the Cosmos Network Discord Server.
-- Ensure the required peers are online for people to connect to.
-
-The consumer chain will start producing blocks as soon as 66.67% of the provider chain's voting power comes online. You will be able to start the relayer afterwards:
-
-- Query the IBC client ID of the provider chain.
-  ```
-  gaiad q provider list-consumer-chains
-  ```
-- Create the required IBC connections and channels for the CCV channel to be established. Using Hermes:
-  ```
-  hermes create connection --a-chain <consumer chain ID> --a-client 07-tendermint-0 --b-client <provider chain client ID>
-  hermes create channel --a-chain <consumer chain ID> --a-port consumer --b-port provider --order ordered --a-connection connection-0 --channel-version 1
-  ```
-- Start the relayer
-  - The trusting period fraction is set to `0.25` on the provider chain, so you should use a trusting period of 5 days in your relayer configuration.
-
-Finally, the testnet coordinators will:
-
-- Trigger a validator set update in the provider chain to establish the CCV channel and verify the validator set has been updated in the consumer chain.
-- Announce the chain is interchain secured.
-- Update the testnets repo with the IBC information.
-
-## Talk to us
-
-If you're a consumer chain looking to launch, please get in touch with Hypha. You can reach Lexa Michaelides at `lexa@hypha.coop` or on Telegram.

docs/docs/concepts/Self-Custody.md

@@ -1,10 +0,0 @@
-> With increasingly sensitive information being stored in centralized databases, we
-> believe that a decentralized anonymity mechanism is the only way to protect user data.
-> Sonr is at its core a peer-to-peer identity system, which means that users can choose
-> to share their identity with others in a way that is private and secure.
-
-# Decentralized Identifiers
-
-# Cross-chain Interoperability
-
-# W3C Web APIs

docs/docs/concepts/System-Architecture.md

@@ -1,21 +0,0 @@
-> Sonr is a decentralized platform that allows users to create and manage their own decentralized identity.
-
-# Blockchain: Sonr
-
-Sonr stores Decentralized Identifiers (DIDs) on its Cosmos-sdk based blockchain. The blockchain's role is to act as the
-persistent pointer store for locations of User owned data.
-
-# User Key Vault: Motr
-
-The Motr node is a service-worker which functions as a personal encrypted key-enclave for users stored on IPFS. They can be allocated and persisted on the
-Sonr blockchain for Smart Wallet functionality.
-
-# Network Gateway: Hway
-
-The Hway protocol is a network proxy which routes network requests to the appropriate service endpoint. This is used for seamless communication between
-Blockchain Nodes, Decentralized Applications, and User Nodes.
-
-# Design System: Nebula
-
-Built with Golang-Templ, TailwindCSS, HTMX, and Service Workers - Nebula is a component library which allows for
-consistent UX across the entire ecosystem.

docs/docs/concepts/Token-Economy.md

@@ -1,13 +0,0 @@
-> The `$SNR` token is the native platform token of the Sonr network. It is used by services to
-> pay for Authentication and Authorization services. The system is designed for developers to
-> be similar to centralized authentication providers like Google, Facebook, Okta, etc.
-
-# Usage
-
-The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.
-
-# Supply
-
-> The total supply of `$SNR` is fixed at 1 billion.
-
-![image](https://github.com/user-attachments/assets/8b9d6e6b-f3e5-464a-9032-6d8fe257a748)

docs/docs/concepts/ibc-accounts.md

@@ -1,40 +0,0 @@
-# Interchain Accounts
-
-:::note Synopsis
-Learn about what the Interchain Accounts module is
-:::
-
-## What is the Interchain Accounts module?
-
-Interchain Accounts is the Cosmos SDK implementation of the ICS-27 protocol, which enables cross-chain account management built upon IBC.
-
-- How does an interchain account differ from a regular account?
-
-Regular accounts use a private key to sign transactions. Interchain Accounts are instead controlled programmatically by counterparty chains via IBC packets.
-
-## Concepts
-
-`Host Chain`: The chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. Cosmos SDK messages) for which the interchain account will execute.
-
-`Controller Chain`: The chain registering and controlling an account on a host chain. The controller chain sends IBC packets to the host chain to control the account.
-
-`Interchain Account`: An account on a host chain created using the ICS-27 protocol. An interchain account has all the capabilities of a normal account. However, rather than signing transactions with a private key, a controller chain will send IBC packets to the host chain which signals what transactions the interchain account should execute.
-
-`Authentication Module`: A custom application module on the controller chain that uses the Interchain Accounts module to build custom logic for the creation & management of interchain accounts. It can be either an IBC application module using the [legacy API](10-legacy/03-keeper-api.md), or a regular Cosmos SDK application module sending messages to the controller submodule's `MsgServer` (this is the recommended approach from ibc-go v6 if access to packet callbacks is not needed). Please note that the legacy API will eventually be removed and IBC applications will not be able to use them in later releases.
-
-## SDK security model
-
-SDK modules on a chain are assumed to be trustworthy. For example, there are no checks to prevent an untrustworthy module from accessing the bank keeper.
-
-The implementation of ICS-27 in ibc-go uses this assumption in its security considerations.
-
-The implementation assumes other IBC application modules will not bind to ports within the ICS-27 namespace.
-
-## Channel Closure
-
-The provided interchain account host and controller implementations do not support `ChanCloseInit`. However, they do support `ChanCloseConfirm`.
-This means that the host and controller modules cannot close channels, but they will confirm channel closures initiated by other implementations of ICS-27.
-
-In the event of a channel closing (due to a packet timeout in an ordered channel, for example), the interchain account associated with that channel can become accessible again if a new channel is created with a (JSON-formatted) version string that encodes the exact same `Metadata` information of the previous channel. The channel can be reopened using either [`MsgRegisterInterchainAccount`](./05-messages.md#msgregisterinterchainaccount) or `MsgChannelOpenInit`. If `MsgRegisterInterchainAccount` is used, then it is possible to leave the `version` field of the message empty, since it will be filled in by the controller submodule. If `MsgChannelOpenInit` is used, then the `version` field must be provided with the correct JSON-encoded `Metadata` string. See section [Understanding Active Channels](./09-active-channels.md#understanding-active-channels) for more information.
-
-When reopening a channel with the default controller submodule, the ordering of the channel cannot be changed. In order to change the ordering of the channel, the channel has to go through a [channel upgrade handshake](../../01-ibc/06-channel-upgrades.md) or reopen the channel with a custom controller implementation.

docs/docs/concepts/nebula-ui.md

@@ -1,11 +0,0 @@
-> In order to maintain a tight-knit experience, we designed Sonr to operate completely
-> in the point-of-view of the user. This led to us building a Component Library which
-> creates consistent UX across the entire ecosystem.
-
-# Overview
-
-The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.
-
-# Nebula Package
-
-> The total supply of `$SNR` is fixed at 1 billion.

docs/docs/concepts/sdk-usage.md

@@ -1,104 +0,0 @@
-## `x/did` - Auth & AuthZ
-
-> The DID module is responsible for managing the creation and management of DIDs.
-> Controllers represent on-chain accounts backed by a MPC keypair. Controllers
-> provide methods for Wallet Account Abstraction (WAA) and are responsible for
-> managing the creation and management of DIDs for an individual user.
-
-### Features
-
-- DID Controllers leverage the Cosmos SDK's `x/accounts` std interface for WAA.
-- DIDs are represented by a `x/did` controller and are required to state the
-  controller's public key, and which map to the controller's capabilities.
-- General Sign/Verify methods are provides from the QueryServer for HTTP requests.
-- The Execute method is used to broadcast transactions across the network. (TODO)
-- Biscuits are used to authenticate and authorize requests between services. (TODO)
-
-### References
-
-- [State](https://github.com/onsonr/sonr/tree/develop/x/did#state)
-- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/did#state-transitions)
-- [Messages](https://github.com/onsonr/sonr/tree/develop/x/did#messages)
-- [Queries](https://github.com/onsonr/sonr/tree/develop/x/did#query)
-- [Params](https://github.com/onsonr/sonr/tree/develop/x/did#params)
-- [Client](https://github.com/onsonr/sonr/tree/develop/x/did#client)
-- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/did#future-improvements)
-- [Tests](https://github.com/onsonr/sonr/tree/develop/x/did#tests)
-- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/did#appendix)
-
----
-
-## `x/macaroon`
-
-> The macaroon module is responsible for issuing and verifying macaroons. Macaroons
-> are used to authenticate and authorize requests between services.
-> Macaroons are requested by NFT Records from [`x/service`](2-‐-Modules-Overview.md#x-service) and granted by controllers from [`x/did`](2-‐-Modules-Overview.md#x/did)
-
-### Features
-
-- On Controller creation, a macaroon is created with an admin scope and a default expiry of _315,569,520 blocks (or ~10 years)_.
-- On Service registration, a macaroon is created with a service scope and a default expiry of _31,556,952 blocks (or ~1 year)_.
-- Macaroons contain the scope of access for a service and the expiry of the permissions in `blockHeight`.
-
-### References
-
-- [State](https://github.com/onsonr/sonr/tree/develop/x/macaroon#state)
-- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/macaroon#state-transitions)
-- [Messages](https://github.com/onsonr/sonr/tree/develop/x/macaroon#messages)
-- [Queries](https://github.com/onsonr/sonr/tree/develop/x/macaroon#query)
-- [Params](https://github.com/onsonr/sonr/tree/develop/x/macaroon#params)
-- [Client](https://github.com/onsonr/sonr/tree/develop/x/macaroon#client)
-- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/macaroon#future-improvements)
-- [Tests](https://github.com/onsonr/sonr/tree/develop/x/macaroon#tests)
-- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/macaroon#appendix)
-
----
-
-## `x/service`
-
-> The service module is responsible for managing decentralized services. Services
-> on the Sonr network are essentially on-chain MultiSig wallets that are
-> represented by a NFT. Service admins are represented by
-> a [`x/did`](2-‐-Modules-Overview.md#x-did) controller and are required to state
-> the service's scope of access, and which map to the services' capabilities.
-
-### Features
-
-- Needs a Valid Domain with .htaccess file to be whitelisted.
-
-### References
-
-- [State](https://github.com/onsonr/sonr/tree/develop/x/service#state)
-- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/service#state-transitions)
-- [Messages](https://github.com/onsonr/sonr/tree/develop/x/service#messages)
-- [Queries](https://github.com/onsonr/sonr/tree/develop/x/service#query)
-- [Params](https://github.com/onsonr/sonr/tree/develop/x/service#params)
-- [Client](https://github.com/onsonr/sonr/tree/develop/x/service#client)
-- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/service#future-improvements)
-- [Tests](https://github.com/onsonr/sonr/tree/develop/x/service#tests)
-- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/service#appendix)
-
----
-
-## `x/vault`
-
-> The vault module is responsible for managing the storage and acccess-control of
-> Decentralized Web Nodes (DWNs) from IPFS. Vaults contain user-facing keys and
-> are represented by a [`x/did`](2-‐-Modules-Overview.md#x-did) controller.
-
-### Features
-
-- Vaults can be created by anyone, but efforts are made to restrict 1 per user.
-- Vaults are stored in IPFS and when claimed, the bech32 Sonr Address is pinned to IPFS.
-
-### References
-
-- [State](https://github.com/onsonr/sonr/tree/develop/x/vault#state)
-- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/vault#state-transitions)
-- [Messages](https://github.com/onsonr/sonr/tree/develop/x/vault#messages)
-- [Queries](https://github.com/onsonr/sonr/tree/develop/x/vault#query)
-- [Params](https://github.com/onsonr/sonr/tree/develop/x/vault#params)
-- [Client](https://github.com/onsonr/sonr/tree/develop/x/vault#client)
-- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/vault#future-improvements)
-- [Tests](https://github.com/onsonr/sonr/tree/develop/x/vault#tests)
-- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/vault#appendix)

docs/docs/concepts/svc-management.md

@@ -1,11 +0,0 @@
-> The `$SNR` token is the native platform token of the Sonr network. It is used by services to
-> pay for Authentication and Authorization services. The system is designed for developers to
-> be similar to centralized authentication providers like Google, Facebook, Okta, etc.
-
-# Usage
-
-The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.
-
-# Supply
-
-> The total supply of `$SNR` is fixed at 1 billion.

docs/docs/foundations/hway.md

@@ -1,11 +0,0 @@
-<div style="text-align: center;">
-
-# Page Not Found
-
-![A UFO takes one of the little worker monsters](/assets/images/undraw-taken.svg)
-
-The page you were looking for couldn't be found.
-
-Press [[/]] to search, or [head back to the homepage](/).
-
-</div>

docs/docs/foundations/index.md

@@ -1 +0,0 @@
-# Sonr Blockchain

docs/docs/foundations/motr.md

@@ -1,11 +0,0 @@
-<div style="text-align: center;">
-
-# Page Not Found
-
-![A UFO takes one of the little worker monsters](/assets/images/undraw-taken.svg)
-
-The page you were looking for couldn't be found.
-
-Press [[/]] to search, or [head back to the homepage](/).
-
-</div>

docs/docs/index.md

@@ -1,47 +0,0 @@
-# Introduction
-
-Sonr is a decentralized identity network built on the Cosmos-sdk. It has early origins as a peer-to-peer file sharing network, but has since evolved into a platform for decentralized authentication and authorization. The early lessons taught from our file sharing roots are used as our theology for building the Sonr Blockchain.
-
-1. [Cosmos-SDK](./concepts/Cosmos-SDK.md)
-2. [Chain-Modules](./concepts/Chain-Modules.md)
-3. [System-Architecture](./concepts/System-Architecture.md)
-4. [Token-Economy](./concepts/Token-Economy.md)
-5. [Service-Management](./concepts/Service-Management.md)
-6. [Design-System](./concepts/Design-System.md)
-7. [Self-Custody](./concepts/Self-Custody.md)
-8. [Consumer Launch](./concepts/Consumer-Launch.md)
-
-## Principles
-
-1. Bitcoin is digital gold
-2. Blockchains are programmable databases with functional operations
-3. Staking is essentially a savings account
-4. The Sonr Network conducts all operations in the $SNR token
-5. Service Delegation subsidizes user wallet operations.
-6. Cryptocurrency has the potential to break the software innovation ceiling
-
-## The Problem
-
-Centralized identity has led to internet monopolies abusing your trust and privacy.
-
-## The Solution
-
-A peer-to-peer system for decentralized personal identity with Authentication and Authorization capabilities.
-
-## What is Sonr?
-
-A privacy preserving, identity system managed by user controlled decentralized vaults which have the flexibility of
-software wallets with the security of hardware wallets.
-
-## The End Goal
-
-A Data sharing economy where human-specific information has intrinsic value. Services are incentivized to act in
-good faith in order to obtain quality user data.
-
-## How do we do it?
-
-Provide Internet Citizens with a robust easy to use WebVault which features a crypto wallet, passkey authenticator, and encrypted messages. The WebVault serves as a wrapper over every sensitive intent-based user interaction. The Smart blockchain is responsible for keeping a record of where WebVaults are located, when authorization activity occurs, and which services are allowed over what permissions.
-
-## The User Incentive
-
-Data is the byproduct of currency exchange in the Information age. Meaning services pay other services for user data or profits in order to enrich their database with complete user personas.

docs/mkdocs.yml

@@ -1,55 +0,0 @@
-site_name: Sonr Docs
-site_description: Sonr is a decentralized identity network built on the Cosmos-sdk. It has early origins as a peer-to-peer file sharing network, but has since evolved into a platform for decentralized authentication and authorization. The early lessons taught from our file sharing roots are used as our theology for building the Sonr Blockchain.
-site_url: https://onsonr.dev
-theme:
-  name: material
-  features:
-    - announce.dismiss
-    - content.action.edit
-    - content.action.view
-    - content.code.annotate
-    - content.code.copy
-    - content.code.select
-    # - content.footnote.tooltips
-    # - content.tabs.link
-    - content.tooltips
-    - header.autohide
-    # - navigation.expand
-    - navigation.footer
-    - navigation.indexes
-    - navigation.instant
-    - navigation.instant.prefetch
-    # - navigation.instant.progress
-    # - navigation.prune
-    - navigation.sections
-    - navigation.tabs
-    - navigation.tabs.sticky
-    - navigation.top
-    - navigation.tracking
-    - search.highlight
-    - search.share
-    - search.suggest
-    - toc.follow
-    - toc.integrate
-  palette:
-    - media: "(prefers-color-scheme)"
-      toggle:
-        icon: material/link
-        name: Switch to light mode
-    - media: "(prefers-color-scheme: light)"
-      scheme: default
-      primary: cyan
-      accent: cyan
-      toggle:
-        icon: material/toggle-switch
-        name: Switch to dark mode
-    - media: "(prefers-color-scheme: dark)"
-      scheme: slate
-      primary: black
-      accent: cyan
-      toggle:
-        icon: material/toggle-switch-off
-        name: Switch to system preference
-  font:
-    text: Geist
-    code: Geist Mono

gateway/context/credentials.go

@@ -0,0 +1,19 @@
+package context
+
+import (
+	"github.com/go-webauthn/webauthn/protocol"
+)
+
+func (c *GatewayContext) NewChallenge() string {
+	chal, _ := protocol.CreateChallenge()
+	chalStr := chal.String()
+	return chalStr
+}
+
+func (cc *GatewayContext) ListCredentials(handle string) ([]*CredentialDescriptor, error) {
+	creds, err := cc.GetCredentialsByHandle(bgCtx(), handle)
+	if err != nil {
+		return nil, err
+	}
+	return CredentialArrayToDescriptors(creds), nil
+}

gateway/context/middleware.go

@@ -0,0 +1,64 @@
+package context
+
+import (
+	gocontext "context"
+	"net/http"
+
+	"github.com/labstack/echo/v4"
+	"github.com/medama-io/go-useragent"
+	"github.com/onsonr/sonr/internal/crypto/mpc"
+	"github.com/onsonr/sonr/internal/common"
+	"github.com/onsonr/sonr/internal/config/hway"
+	hwayorm "github.com/onsonr/sonr/internal/database/hwayorm"
+)
+
+type GatewayContext struct {
+	echo.Context
+	hwayorm.Querier
+	id               string
+	ipfsClient       common.IPFS
+	agent            useragent.UserAgent
+	tokenStore       common.IPFSTokenStore
+	stagedEnclaves   map[string]mpc.Enclave
+	grpcAddr         string
+	turnstileSiteKey string
+}
+
+func GetGateway(c echo.Context) (*GatewayContext, error) {
+	cc, ok := c.(*GatewayContext)
+	if !ok {
+		return nil, echo.NewHTTPError(http.StatusInternalServerError, "Gateway Context not found")
+	}
+	return cc, nil
+}
+
+func UseGateway(env hway.Hway, ipc common.IPFS, db *hwayorm.Queries) echo.MiddlewareFunc {
+	return func(next echo.HandlerFunc) echo.HandlerFunc {
+		return func(c echo.Context) error {
+			ua := useragent.NewParser()
+			ctx := &GatewayContext{
+				Context:          c,
+				Querier:          db,
+				ipfsClient:       ipc,
+				agent:            ua.Parse(c.Request().UserAgent()),
+				grpcAddr:         env.GetSonrGrpcUrl(),
+				tokenStore:       common.NewUCANStore(ipc),
+				turnstileSiteKey: env.GetTurnstileSiteKey(),
+			}
+			return next(ctx)
+		}
+	}
+}
+
+func BG() gocontext.Context {
+	ctx := gocontext.Background()
+	return ctx
+}
+
+func (cc *GatewayContext) ReadCookie(k common.CookieKey) string {
+	return common.ReadCookieUnsafe(cc.Context, k)
+}
+
+func (cc *GatewayContext) WriteCookie(k common.CookieKey, v string) {
+	common.WriteCookie(cc.Context, k, v)
+}

gateway/context/profiles.go

@@ -0,0 +1,53 @@
+package context
+
+import (
+	"net/http"
+
+	"github.com/labstack/echo/v4"
+	hwayorm "github.com/onsonr/sonr/internal/database/hwayorm"
+)
+
+func UpdateProfile(c echo.Context) (*hwayorm.Profile, error) {
+	ctx, ok := c.(*GatewayContext)
+	if !ok {
+		return nil, echo.NewHTTPError(http.StatusInternalServerError, "Profile Context not found")
+	}
+	address := c.FormValue("address")
+	handle := c.FormValue("handle")
+	name := c.FormValue("name")
+	profile, err := ctx.UpdateProfile(bgCtx(), hwayorm.UpdateProfileParams{
+		Address: address,
+		Handle:  handle,
+		Name:    name,
+	})
+	if err != nil {
+		return nil, err
+	}
+	return profile, nil
+}
+
+func ReadProfile(c echo.Context) (*hwayorm.Profile, error) {
+	ctx, ok := c.(*GatewayContext)
+	if !ok {
+		return nil, echo.NewHTTPError(http.StatusInternalServerError, "Profile Context not found")
+	}
+	handle := c.Param("handle")
+	profile, err := ctx.GetProfileByHandle(bgCtx(), handle)
+	if err != nil {
+		return nil, err
+	}
+	return profile, nil
+}
+
+func DeleteProfile(c echo.Context) error {
+	ctx, ok := c.(*GatewayContext)
+	if !ok {
+		return echo.NewHTTPError(http.StatusInternalServerError, "Profile Context not found")
+	}
+	address := c.Param("address")
+	err := ctx.SoftDeleteProfile(bgCtx(), address)
+	if err != nil {
+		return err
+	}
+	return nil
+}

gateway/context/renderer.go

@@ -0,0 +1,42 @@
+package context
+
+import (
+	"bytes"
+
+	"github.com/a-h/templ"
+	"github.com/labstack/echo/v4"
+	"github.com/onsonr/sonr/gateway/views"
+)
+
+func Render(c echo.Context, cmp templ.Component) error {
+	// Create a buffer to store the rendered HTML
+	buf := &bytes.Buffer{}
+	// Render the component to the buffer
+	err := cmp.Render(c.Request().Context(), buf)
+	if err != nil {
+		return err
+	}
+
+	// Set the content type
+	c.Response().Header().Set(echo.HeaderContentType, echo.MIMETextHTML)
+
+	// Write the buffered content to the response
+	_, err = c.Response().Write(buf.Bytes())
+	if err != nil {
+		return err
+	}
+	c.Response().WriteHeader(200)
+	return nil
+}
+
+func RenderError(c echo.Context, err error) error {
+	return Render(c, views.ErrorView(err.Error()))
+}
+
+func RenderInitial(c echo.Context) error {
+	return Render(c, views.InitialView())
+}
+
+func RenderLoading(c echo.Context) error {
+	return Render(c, views.LoadingView())
+}

gateway/context/resolver.go

@@ -0,0 +1,105 @@
+package context
+
+import (
+	"fmt"
+
+	"github.com/onsonr/sonr/internal/common"
+)
+
+// ParamsBank returns the bank params
+func (cc *GatewayContext) ParamsBank() (*common.BankParamsResponse, error) {
+	cl, err := common.NewBankClient(cc.grpcAddr)
+	if err != nil {
+		return nil, err
+	}
+	resp, err := cl.Params(bgCtx(), &common.BankParamsRequest{})
+	if err != nil {
+		return nil, err
+	}
+	return resp, nil
+}
+
+// ParamsDID returns the DID params
+func (cc *GatewayContext) ParamsDID() (*common.DIDParamsResponse, error) {
+	cl, err := common.NewDIDClient(cc.grpcAddr)
+	if err != nil {
+		return nil, err
+	}
+	resp, err := cl.Params(bgCtx(), &common.DIDParamsRequest{})
+	if err != nil {
+		return nil, err
+	}
+	return resp, nil
+}
+
+// ParamsDWN returns the DWN params
+func (cc *GatewayContext) ParamsDWN() (*common.DWNParamsResponse, error) {
+	cl, err := common.NewDWNClient(cc.grpcAddr)
+	if err != nil {
+		return nil, err
+	}
+	resp, err := cl.Params(bgCtx(), &common.DWNParamsRequest{})
+	if err != nil {
+		return nil, err
+	}
+	return resp, nil
+}
+
+// ParamsSVC returns the SVC params
+func (cc *GatewayContext) ParamsSVC() (*common.SVCParamsResponse, error) {
+	cl, err := common.NewSVCClient(cc.grpcAddr)
+	if err != nil {
+		return nil, err
+	}
+	resp, err := cl.Params(bgCtx(), &common.SVCParamsRequest{})
+	if err != nil {
+		return nil, err
+	}
+	return resp, nil
+}
+
+// StatusBlock returns the current block
+func (cc *GatewayContext) StatusBlock() string {
+	qc, err := common.NewNodeClient(cc.grpcAddr)
+	if err != nil {
+		return "-1"
+	}
+	resp, err := qc.Status(bgCtx(), &common.StatusRequest{})
+	if err != nil {
+		return "-1"
+	}
+	return fmt.Sprintf("%d", resp.GetHeight())
+}
+
+// StatusNode returns the node status
+func (cc *GatewayContext) StatusNode() (*common.StatusResponse, error) {
+	cl, err := common.NewNodeClient(cc.grpcAddr)
+	if err != nil {
+		return nil, err
+	}
+	resp, err := cl.Status(bgCtx(), &common.StatusRequest{})
+	if err != nil {
+		return nil, err
+	}
+	return resp, nil
+}
+
+// TxBroadcast broadcasts a transaction to the network
+func (cc *GatewayContext) TxBroadcast() error {
+	return nil
+}
+
+// TxEncode encodes a transaction
+func (cc *GatewayContext) TxEncode() error {
+	return nil
+}
+
+// TxDecode decodes a transaction
+func (cc *GatewayContext) TxDecode() error {
+	return nil
+}
+
+// TxSimulate simulates a transaction on the network
+func (cc *GatewayContext) TxSimulate() error {
+	return nil
+}

gateway/context/sessions.go

@@ -0,0 +1,148 @@
+package context
+
+import (
+	gocontext "context"
+
+	"github.com/labstack/echo/v4"
+	"github.com/onsonr/sonr/internal/common"
+	"github.com/segmentio/ksuid"
+	"lukechampine.com/blake3"
+)
+
+func NewSession(c echo.Context) error {
+	cc, ok := c.(*GatewayContext)
+	if !ok {
+		return nil
+	}
+	baseSessionCreateParams := BaseSessionCreateParams(cc)
+	cc.id = baseSessionCreateParams.ID
+	if _, err := cc.CreateSession(bgCtx(), baseSessionCreateParams); err != nil {
+		return err
+	}
+	// Set Cookie
+	if err := common.WriteCookie(c, common.SessionID, cc.id); err != nil {
+		return err
+	}
+	return nil
+}
+
+// Uses blake3 to hash the sessionID to generate a nonce of length 12 bytes
+func GetNonce(sessionID string) ([]byte, error) {
+	hash := blake3.New(32, nil)
+	_, err := hash.Write([]byte(sessionID))
+	if err != nil {
+		return nil, err
+	}
+	// Read the hash into a byte slice
+	nonce := make([]byte, 12)
+	_, err = hash.Write(nonce)
+	if err != nil {
+		return nil, err
+	}
+	return nonce, nil
+}
+
+// ForbiddenDevice returns true if the device is unavailable
+func ForbiddenDevice(c echo.Context) bool {
+	cc, ok := c.(*GatewayContext)
+	if !ok {
+		return true
+	}
+	return cc.agent.IsBot() || cc.agent.IsTV()
+}
+
+func GetOrigin(c echo.Context) string {
+	return c.Request().Host
+}
+
+func GetSessionID(c echo.Context) string {
+	// Check from context
+	cc, ok := c.(*GatewayContext)
+	if !ok {
+		return ""
+	}
+	// check from cookie
+	if cc.id == "" {
+		if ok := common.CookieExists(c, common.SessionID); !ok {
+			return ""
+		}
+		cc.id = common.ReadCookieUnsafe(c, common.SessionID)
+	}
+	return cc.id
+}
+
+func GetAuthChallenge(c echo.Context) string {
+	cc, ok := c.(*GatewayContext)
+	if !ok {
+		return ""
+	}
+	s, err := cc.GetChallengeBySessionID(bgCtx(), cc.id)
+	if err != nil {
+		return ""
+	}
+	return s
+}
+
+func GetProfileHandle(c echo.Context) string {
+	// First check for the cookie
+	handle := common.ReadCookieUnsafe(c, common.UserHandle)
+	if handle != "" {
+		return handle
+	}
+
+	// Then check the session
+	cc, ok := c.(*GatewayContext)
+	if !ok {
+		return ""
+	}
+	s, err := cc.GetSessionByID(bgCtx(), cc.id)
+	if err != nil {
+		return ""
+	}
+	profile, err := cc.GetProfileByID(bgCtx(), s.ProfileID)
+	if err != nil {
+		return ""
+	}
+	return profile.Handle
+}
+
+//
+// func GetHumanVerificationNumbers(c echo.Context) (int64, int64) {
+// 	cc, ok := c.(*GatewayContext)
+// 	if !ok {
+// 		return 0, 0
+// 	}
+// 	s, err := cc.dbq.GetHumanVerificationNumbers(bgCtx(), cc.id)
+// 	if err != nil {
+// 		return 0, 0
+// 	}
+// 	return s.IsHumanFirst, s.IsHumanLast
+// }
+
+// utility function to get a context
+func bgCtx() gocontext.Context {
+	ctx := gocontext.Background()
+	return ctx
+}
+
+func getOrCreateSessionID(c echo.Context) string {
+	if ok := common.CookieExists(c, common.SessionID); !ok {
+		sessionID := ksuid.New().String()
+		common.WriteCookie(c, common.SessionID, sessionID)
+		return sessionID
+	}
+
+	sessionID, err := common.ReadCookie(c, common.SessionID)
+	if err != nil {
+		sessionID = ksuid.New().String()
+		common.WriteCookie(c, common.SessionID, sessionID)
+	}
+	return sessionID
+}
+
+func boolToInt64(b bool) int64 {
+	if b {
+		return 1
+	}
+	return 0
+}

gateway/context/types.go

@@ -0,0 +1,102 @@
+package context
+
+import (
+	"github.com/go-webauthn/webauthn/protocol"
+	"github.com/labstack/echo/v4"
+	"github.com/medama-io/go-useragent"
+	hwayorm "github.com/onsonr/sonr/internal/database/hwayorm"
+)
+
+// Define the credential structure matching our frontend data
+type CredentialDescriptor struct {
+	ID                      string            `json:"id"`
+	RawID                   string            `json:"rawId"`
+	Type                    string            `json:"type"`
+	AuthenticatorAttachment string            `json:"authenticatorAttachment"`
+	Transports              string            `json:"transports"`
+	ClientExtensionResults  map[string]string `json:"clientExtensionResults"`
+	Response                struct {
+		AttestationObject string `json:"attestationObject"`
+		ClientDataJSON    string `json:"clientDataJSON"`
+	} `json:"response"`
+}
+
+func (c *CredentialDescriptor) ToModel(handle, origin string) *hwayorm.Credential {
+	return &hwayorm.Credential{
+		Handle:                  handle,
+		Origin:                  origin,
+		CredentialID:            c.ID,
+		Type:                    c.Type,
+		Transports:              c.Transports,
+		AuthenticatorAttachment: c.AuthenticatorAttachment,
+	}
+}
+
+func CredentialArrayToDescriptors(credentials []*hwayorm.Credential) []*CredentialDescriptor {
+	var descriptors []*CredentialDescriptor
+	for _, cred := range credentials {
+		cd := &CredentialDescriptor{
+			ID:                      cred.CredentialID,
+			RawID:                   cred.CredentialID,
+			Type:                    cred.Type,
+			AuthenticatorAttachment: cred.AuthenticatorAttachment,
+			Transports:              cred.Transports,
+		}
+		descriptors = append(descriptors, cd)
+	}
+	return descriptors
+}
+
+func BaseSessionCreateParams(e echo.Context) hwayorm.CreateSessionParams {
+	// f := rand.Intn(5) + 1
+	// l := rand.Intn(4) + 1
+	challenge, _ := protocol.CreateChallenge()
+	id := getOrCreateSessionID(e)
+	ua := useragent.NewParser()
+	s := ua.Parse(e.Request().UserAgent())
+
+	return hwayorm.CreateSessionParams{
+		ID:             id,
+		BrowserName:    s.GetBrowser(),
+		BrowserVersion: s.GetMajorVersion(),
+		ClientIpaddr:   e.RealIP(),
+		Platform:       s.GetOS(),
+		IsMobile:       s.IsMobile(),
+		IsTablet:       s.IsTablet(),
+		IsDesktop:      s.IsDesktop(),
+		IsBot:          s.IsBot(),
+		IsTv:           s.IsTV(),
+		// IsHumanFirst:   int64(f),
+		// IsHumanLast:    int64(l),
+		Challenge: challenge.String(),
+	}
+}
+
+// ╭───────────────────────────────────────────────────────────╮
+// │            Create Passkey (/register/passkey)             │
+// ╰───────────────────────────────────────────────────────────╯
+
+// CreatePasskeyParams represents the parameters for creating a passkey
+type CreatePasskeyParams struct {
+	Address       string
+	Handle        string
+	Name          string
+	Challenge     string
+	CreationBlock string
+}
+
+// ╭───────────────────────────────────────────────────────────╮
+// │            Create Profile (/register/profile)             │
+// ╰───────────────────────────────────────────────────────────╯
+
+// CreateProfileParams represents the parameters for creating a profile
+type CreateProfileParams struct {
+	TurnstileSiteKey string
+	FirstNumber      int
+	LastNumber       int
+}
+
+// Sum returns the sum of the first and last number
+func (d CreateProfileParams) Sum() int {
+	return d.FirstNumber + d.LastNumber
+}

gateway/context/vaults.go

@@ -0,0 +1,45 @@
+package context
+
+import (
+	"github.com/onsonr/sonr/internal/crypto/mpc"
+	"github.com/onsonr/sonr/internal/common"
+	"lukechampine.com/blake3"
+)
+
+func (cc *GatewayContext) Spawn(handle, origin string) (*CreatePasskeyParams, error) {
+	challenge := GetAuthChallenge(cc)
+	sid := GetSessionID(cc)
+	nonce, err := calcNonce(sid)
+	if err != nil {
+		return nil, err
+	}
+	encl, err := mpc.GenEnclave(nonce)
+	if err != nil {
+		return nil, err
+	}
+	cc.stagedEnclaves[sid] = encl
+	common.WriteCookie(cc, common.SonrAddress, encl.Address())
+	return &CreatePasskeyParams{
+		Address:       encl.Address(),
+		Handle:        handle,
+		Name:          origin,
+		Challenge:     challenge,
+		CreationBlock: cc.StatusBlock(),
+	}, nil
+}
+
+// Uses blake3 to hash the sessionID to generate a nonce of length 12 bytes
+func calcNonce(sessionID string) ([]byte, error) {
+	hash := blake3.New(32, nil)
+	_, err := hash.Write([]byte(sessionID))
+	if err != nil {
+		return nil, err
+	}
+	// Read the hash into a byte slice
+	nonce := make([]byte, 12)
+	_, err = hash.Write(nonce)
+	if err != nil {
+		return nil, err
+	}
+	return nonce, nil
+}

gateway/gateway.go

@@ -0,0 +1,33 @@
+// Package gateway provides the default routes for the Sonr hway.
+package gateway
+
+import (
+	"github.com/labstack/echo-contrib/echoprometheus"
+	"github.com/labstack/echo/v4"
+	echomiddleware "github.com/labstack/echo/v4/middleware"
+	"github.com/onsonr/sonr/gateway/context"
+	"github.com/onsonr/sonr/gateway/handlers"
+	"github.com/onsonr/sonr/internal/common"
+	config "github.com/onsonr/sonr/internal/config/hway"
+	hwayorm "github.com/onsonr/sonr/internal/database/hwayorm"
+)
+
+type Gateway = *echo.Echo
+
+// New returns a new Gateway instance
+func New(env config.Hway, ipc common.IPFS, dbq *hwayorm.Queries) (Gateway, error) {
+	e := echo.New()
+
+	// Built-in middleware
+	e.Use(echomiddleware.Logger())
+	e.Use(echomiddleware.Recover())
+	e.IPExtractor = echo.ExtractIPDirect()
+	e.Use(echoprometheus.NewMiddleware("hway"))
+	e.Use(context.UseGateway(env, ipc, dbq))
+
+	// Register View Handlers
+	e.HTTPErrorHandler = handlers.ErrorHandler
+	e.GET("/", handlers.IndexHandler)
+	handlers.RegisterHandler(e.Group("/register"))
+	return e, nil
+}

gateway/handlers/errors.go

@@ -0,0 +1,16 @@
+package handlers
+
+import (
+	"github.com/labstack/echo/v4"
+	"github.com/onsonr/sonr/gateway/context"
+)
+
+func ErrorHandler(err error, c echo.Context) {
+	if he, ok := err.(*echo.HTTPError); ok {
+		if he.Code == 500 {
+			// Log the error if needed
+			c.Logger().Errorf("Error: %v", he.Message)
+			context.RenderError(c, he)
+		}
+	}
+}

gateway/handlers/index.go

@@ -0,0 +1,14 @@
+package handlers
+
+import (
+	"github.com/labstack/echo/v4"
+	"github.com/onsonr/sonr/gateway/context"
+)
+
+func IndexHandler(c echo.Context) error {
+	id := context.GetSessionID(c)
+	if id == "" {
+		context.NewSession(c)
+	}
+	return context.RenderInitial(c)
+}